Hi,
working on the trunk, I want to tackle some of the failing test cases to make that bar green. ;-)
FloatTest >> testNaN5 fails because the expression
Float nan asIEEE32BitWord printPaddedWith: $0 to: 32 base: 2
yields '11111111110000000000000000000000', but '01111111110000000000000000000000' (note the difference in the first character) is expected.
Looking at IEEE 754, it seems that, for NaN, that very bit may either be 0 or 1 - so both would be correct. In that case, the test itself would be wrong. I'd simply change it, but there should be agreement on whether the standard is interpreted correctly.
Comments?
Best,
Michael
Hi again,
On Thu, Jul 30, 2009 at 1:38 PM, Michael Hauptmhaupt@gmail.com wrote:
Looking at IEEE 754, it seems that, for NaN, that very bit may either be 0 or 1 - so both would be correct.
sorry about this... more correctly stated, the above should read as follows.
Looking at IEEE 754, it seems that, for NaN, the following bit mask would be correct (x means any of 0 or 1): 'x111111111xxxxxxxxxxxxxxxxxxxxxx' - at least for a quiet (non-signalled) NaN.
I suspect Squeak intentionally generates a quiet NaN.
Again, comments?
Best,
Michael
On Jul 30, 2009, at 6:44 AM, Michael Haupt wrote:
Looking at IEEE 754, it seems that, for NaN, the following bit mask would be correct (x means any of 0 or 1): 'x111111111xxxxxxxxxxxxxxxxxxxxxx' - at least for a quiet (non-signalled) NaN.
Yes, that is correct.
I suspect Squeak intentionally generates a quiet NaN.
Correct. It is generated by subtracting two Infinity values, which generates the default quiet NaN as a result.
Again, comments?
The canonical NaN value is generated in Float during class initialization, by the following code:
MaxVal := 1.7976931348623159e308. Infinity := MaxVal * MaxVal. NaN := Infinity - Infinity.
The bit pattern for Infinity is defined by IEEE-754, but the spec only defines NaN values as values with maximum exponent and non-zero fraction (quiet NaN has most-significant fraction bit set, signaling NaN has the most-significant fraction bit clear). So different hardware implementations are free to generate different NaN values (as long as the exponent is all ones and the fraction is non-zero). But this should not be a problem, since any NaN value is treated as a NaN -- so images with a particular NaN value work fine on systems that would generate a different canonical NaN value. Also, in IEEE-754, a NaN does not compare equal to any other value, including itself (which is how Float>>isNaN works), so having different NaN values in the image does not normally cause a problem. The only time it is visible is in cases like the test you are pointing out.
I suggest modifying the test to take this into account (only test for all-ones exponent and non-zero fraction), or remove that particular test.
-- tim
Hi Tim,
thanks for your comment!
On Thu, Jul 30, 2009 at 3:29 PM, Tim Olsontim_olson@att.net wrote:
I suggest modifying the test to take this into account (only test for all-ones exponent and non-zero fraction), or remove that particular test.
I'd rather not remove a test just because it fails, even though the test may be wrong, as in this case. Tests are good. :-)
I think I'll rewrite the test to accept any NaN value - quiet or signalled. It's going to boil down to some substring comparisons...
Best,
Michael
squeak-dev@lists.squeakfoundation.org
-
David T. Lewis -
Michael Haupt -
Tim Olson