At 05:33 PM 8/6/00 +0200, Stephan Rudlof wrote:
>> >> I got identical behavior, in both cases printing:
>> >> sin(arg1): -6.452513e-01
>
>Reading the informations below, this should be the *correct* one! And my
>without optimizations is wrong! :-(

> > -7.469219e-01;

>> (*) 1.0e20 is exactly representable as a double, since
>> it is equal to 2**20 * 5**20, and log-base-2 of 5**20 is
>> less than 47, so it can be represented exactly in the 53
>> bits available to an IEEE double.
>
>Thank you for this information; I didn't know this before.
>So the lib implementors don't have the excuse, that the precision isn't
>sufficient here.

It is actually a problem of precision, even when the input can
be exactly represented as a machine floating point number.  In order
to get the correct approximation for a number as large as 1e20
(about 2**66.4) you need to take the remainder (modulo 2*PI --
the algorithm in fdlibm is actually mod PI/4 plus quadrant
information, I think) and to get the remainder accurately you
need roughly 53+66.4 = ~129 bits (more or less, I am not an
expert here) of accuracy in your "PI".  Pentiums use 68 bits,
so you've got *roughly* 1.5 bits of accuracy in your
input to sin.

For me, there are three inputs that should trigger EDOM:
+Inf, -Inf, and NaN.  People knew how to do range reduction
properly at least ten years ago, and fdlibm is about
that old (fdlibm came from the Sun floating point group, and
I worked at Sun from 1990-1993, and talked to them often).

As to whether a programmer has any business asking for the
sine of 1e20, I have no idea, that is not my department.
It seems to me that returning a wrong answer (not the right
answer, not NaN, not throwing an exception) is a very bad idea
indeed.

David Chase                    --  chase at naturalbridge.com
NaturalBridge Inc              --  http://www.naturalbridge.com
BulletTrain bytecode compiler  --  when you can't wait for performance