Re: Byteswapping floating point types

[Andrew Haley <aph at redhat dot com>]

Andrew Troschinetz wrote:
> On Jul 15, 2009, at 10:13 AM, Andrew Haley wrote:
> 
>> Andrew Troschinetz wrote:
>>
>>> It is not an area in which I am well versed so I probably can't give you
>>> as good an answer as others on this list, but I'll give it a go. "Why
>>> would it?" isn't actually a valid question, you should be asking "why
>>> does it?" because all the tests I've done show that it does.
>>
>> OK.  I'd be very interested to know what values cause problems.
> 
> I'm fairly sure you know more about this than I do. I did some further
> testing and it appears some assumptions I've made are clearly wrong. One
> value that can be used to demonstrate the problem I'm seeing is 50.125484.
> 
> This test: http://codepad.org/OZhEz0az shows that before being swapped
> the bit layout is:
> 
> 01000010010010001000000001111111
> 
> However after being swapped the value isn't what we would expect:
> 
> 01111111110000000100100001000010
> 
> I would expect a 0 in the location of the first fraction bit, but
> instead we have a 1.

Right, that's a NaN.  If the exponent has all bits set and significand
is not 0, the value is a NaN.

> Then after being swapped again the layout isn't back to what it was
> before, but instead it is:
> 
> 01000010010010001100000001111111
> 
> And so 50.125484 becomes 50.187984.
> 
> Now I'm not sure what causes this exactly. Do you have any ideas?

Would it surprise you if I said the first bit of the significand is
what distinguishes a quiet and a signaling NaN?  :-)

>>> When you byteswap a valid floating point value you are very likely
>>> to get an invalid IEEE 754 floating point value, especially with
>>> single precision types.
>>
>> You may well get a NaN, but a NaN is not an invalid IEEE 754 floating
>> point value.  I don't think there is any such thing.
> 
> I didn't mean to imply that NaN was invalid, but that an invalid value
> would be transmogrified into NaN by virtue of it being put into a FPU
> register. But if no IEEE 754 float is invalid, then what is causing the
> issue?

Well, it looks like our lovely (?) hardware is indeed silently converting a
signaling NaN to a quiet NaN, as I guessed.  Thanks for the test case; it's
always nice to know the real reason for things.

Andrew.