This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: weird optimization in sin+cos, x86 backend
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 :-)