This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH][BZ #14412] Define __sincos_finite as a fast version of sincos
- From: Rich Felker <dalias at aerifal dot cx>
- To: Andrew Haley <aph at redhat dot com>
- Cc: OndÅej BÃlka <neleai at seznam dot cz>, "Joseph S. Myers" <joseph at codesourcery dot com>, Siddhesh Poyarekar <siddhesh at redhat dot com>, libc-alpha at sourceware dot org, libc-ports at sourceware dot org
- Date: Mon, 29 Apr 2013 11:18:48 -0400
- Subject: Re: [PATCH][BZ #14412] Define __sincos_finite as a fast version of sincos
- References: <20130429102739 dot GE1330 at spoyarek dot pnq dot redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1304291332320 dot 10827 at digraph dot polyomino dot org dot uk> <20130429141553 dot GC24033 at domone dot kolej dot mff dot cuni dot cz> <517E894C dot 8090602 at redhat dot com>
On Mon, Apr 29, 2013 at 03:53:00PM +0100, Andrew Haley wrote:
> On 04/29/2013 03:15 PM, OndÅej BÃlka wrote:
> > On Mon, Apr 29, 2013 at 01:34:42PM +0000, Joseph S. Myers wrote:
> >> On Mon, 29 Apr 2013, Siddhesh Poyarekar wrote:
> >>
> >>> This patch brings back the assembly implementation of sincos (with
> >>> some changes) to give a fast alternative to the default sincos
> >>> implementation. This is defined as __sincos_finite and is used if the
> >>> implementing program is compiled with the -ffinite-math-only gcc flag.
> >>
> >> The changes don't seem to include accurate range reduction. Without that,
> >> I think this is inappropriate, as it will result in wildly inaccurate
> >> results for large but finite inputs.
> >>
> > These inputs contain zero significant digits. You cannot expect any
> > accuracty from them.
>
> You can't possibly know that. If the caller asks for sin(2^80) you should
> return a close approximation to sin(2^80), not garbage.
OndÅej is simply repeating the standard fallacy from people who think
floating point numbers represent intervals or some sort of
approximation with a distribution of possible "actual values" centered
on the nominal value. These views are all incorrect. Floating point
values are always exact values. Floating point _calculations_,
including conversion from decimal strings, can be inexact, but the
values represented, and used as inputs to floating point functions and
operators, are exact.
Rich