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.
