[squeak-dev] FloatTest >> testNaN5

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 Haupt<[hidden email]> 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 Olson<[hidden email]> 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

Hi again,

OK - the fix is in the trunk. One less test that fails. :-)

Best,

Michael

On Thu, Jul 30, 2009 at 04:23:58PM +0200, Michael Haupt wrote:
> Hi again,
>
> OK - the fix is in the trunk. One less test that fails. :-)
>

Excellent :)