weird optimization in sin+cos, x86 backend

[Robert Dewar]

On 2/3/2012 4:32 PM, Vincent Lefevre wrote:

>> Yes, I do! The floating-point representation of this number

> This fact is not even necessarily correct because you don't know the
> intent of the programmer. In the program,

>    double a = 4.47460300787e+182;
>
> could mean two things:
>
> 1. A number which approximates the decimal number 4.47460300787e+182,
> in which case I agree with you. Note that even though it is an
> approximation, the approximated value a is the same on two different
> IEEE 754 platforms, so that one can expect that sin(a) gives two
> values that are close to each other on these two different platforms.
>
> 2. A number exactly equal to the rounding (to nearest) of the decimal
> number 4.47460300787e+182 in double precision. Imagine that you have
> a binary64 (double precision) number, convert it to decimal with
> sufficient precision in order to be able to convert it back to the
> original binary64 number. This decimal string could have been the
> result of such a conversion. IEEE 754 has been designed to be able
> to do that. This choice has also been followed by some XML spec on
> schemas, i.e. if you write 4.47460300787e+182, this really means a
> binary64 number, not the decimal number 4.47460300787e+182 (even
> though an hex format would be less ambiguous without context, the
> decimal format also allows the human to have an idea about the
> number).

Sure, in general that might be possible, but seemed unlikely in
this case, and indeed what was really going on is essentially
random numbers chosen by a test program generating automatic
tests.

Really that's in neither category, though I suppose you could argue
that it is closer to 2, i.e. that the intent of the automatically
generated test program is to get (and test) this rounding.

But in any case, it seems better for him to apply his suggestion
of sticking within the pi/4 makes a difference range :-)

> No, thanks to correct rounding (provided by CRlibm), all machines with
> the same inputs were giving the same results, even though the results
> were meaningless.

All machines that implement IEEE arithmetic :-) As we know only too well
from the universe of machines on which we implement GNAT, this is not
all machines :-)
>