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 :-)
