[Bug math/14412] Removal of sysdeps/x86_64/fpu/s_sincos.S causes regressions

["neleai at seznam dot cz" <sourceware-bugzilla@sourceware.org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=14412

--- Comment #31 from Ondrej Bilka <neleai at seznam dot cz> 2013-04-29 13:21:18 UTC ---
On Mon, Apr 29, 2013 at 12:32:34PM +0000, wbrana at gmail dot com wrote:
> http://sourceware.org/bugzilla/show_bug.cgi?id=14412
> 
> --- Comment #28 from wbrana at gmail dot com 2013-04-29 12:32:34 UTC ---
> according to http://sourceware.org/bugzilla/show_bug.cgi?id=13658#c2
> fast functions can be used when source operand is in certain range.
> Slow functions should be used only outside interval.
> 
> "The FPTAN, FSIN, FCOS, and FSINCOS instructions set the C2 flag to 1 to
> indicate that the source operand is beyond the allowable range of ±2^63 and
> clear the C2 flag if the source operand is within the allowable range."
> 
> So, outside the interval [-2^63,+2^63] ("allowable range"), these instructions
> must not be used (or they can be used, but with a fallback if the C2 flag is
> set to 1). But note that the glibc implementation is more accurate, even with
> (very probably) correct rounding, so that it is better to use it anyway.
>
Well results of sin,cos.. with large numbers are pure garbage no matter
what you try. As cos(1.0e18*PI) = cos(1.0e18*PI + PI) you can basicaly print
random
number between -1.0 and 1.0 and be correct.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
>From glibc-bugs-return-18510-listarch-glibc-bugs=sources.redhat.com@sourceware.org Mon Apr 29 13:25:16 2013
Return-Path: <glibc-bugs-return-18510-listarch-glibc-bugs=sources.redhat.com@sourceware.org>
Delivered-To: listarch-glibc-bugs@sources.redhat.com
Received: (qmail 7441 invoked by alias); 29 Apr 2013 13:25:16 -0000
Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <glibc-bugs.sourceware.org>
List-Subscribe: <mailto:glibc-bugs-subscribe@sourceware.org>
List-Post: <mailto:glibc-bugs@sourceware.org>
List-Help: <mailto:glibc-bugs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: glibc-bugs-owner@sourceware.org
Delivered-To: mailing list glibc-bugs@sourceware.org
Received: (qmail 7382 invoked by uid 48); 29 Apr 2013 13:25:13 -0000
From: "bugdal at aerifal dot cx" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug math/14412] Removal of sysdeps/x86_64/fpu/s_sincos.S causes regressions
Date: Mon, 29 Apr 2013 13:25:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: glibc
X-Bugzilla-Component: math
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: bugdal at aerifal dot cx
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: 2.18
X-Bugzilla-Changed-Fields:
Message-ID: <bug-14412-131-6agf3oZOD0@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-14412-131@http.sourceware.org/bugzilla/>
References: <bug-14412-131@http.sourceware.org/bugzilla/>
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
X-SW-Source: 2013-04/txt/msg00217.txt.bz2
Content-length: 1430

http://sourceware.org/bugzilla/show_bug.cgi?id\x14412

--- Comment #32 from Rich Felker <bugdal at aerifal dot cx> 2013-04-29 13:25:12 UTC ---
wbrana, unfortunately that information is mistaken; fsin DOES NOT work on the
interval [-2^63,+2^63]. A quick test reveals:

#include <math.h>
#include <stdio.h>

double x87_sin(double x)
{
        __asm__("fsin" : "+t"(x));
        return x;
}

int main()
{
        double x = 0x1p63;
        printf("%.15g %.15g\n", sin(x), x87_sin(x));
}

$ ./a.out
0.999930376673442 9.22337203685478e+18

I suspect this is just a boundary issue (the [] should be () in the range)
since slightly smaller values give more reasonable, but still badly wrong,
results. For example if x is 0x1p62,

-0.702922443619209 -0.707132927452779

which is wrong in the third decimal place.

Siddhesh, could you explain the motivation for "overloading" the meaning of
"_finite" with "fast but wrong"? I'm guessing the idea is that you're thinking
finite math implies not just lack of infinities but also "unreasonably large"
inputs? This is definitely the glibc team's call, since there's no reasonable
basis for assuming you'll get correct results from non-default
performance-oriented math settings, but I think some justification would be
nice.

--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.