On Sat, Nov 10, 2018 at 3:26 PM, Steven D'Aprano <steve@pearwood.info> wrote:
On Fri, Nov 09, 2018 at 01:17:09PM -0800, Chris Barker via Python-Dev wrote:
works for me, too:
In [9]: x = cast_int2float(0x7ff8000000000001) In [10]: hex(cast_float2int(x)) Out[10]: '0x7ff8000000000001'
In [11]: x = cast_int2float(0x7ff0000000000001) In [12]: hex(cast_float2int(x)) Out[12]: '0x7ff0000000000001'
Fascinating. I borrowed a Debian system and tried it on there, and got the same results as you. So I wonder whether it is something unusual about my Red Hat system that it prevents the formation of signalling NANs?
Apparently loading a sNaN into an x87 register silently converts it to a qNaN, and on Linux C compilers are allowed to do that at any point: https://stackoverflow.com/questions/22816095/signalling-nan-was-corrupted-wh... So the Debian/RH difference may just be different register allocation in two slightly different compiler versions. Also, gcc doesn't even try to support sNaN correctly unless you pass -fsignaling-nans, and the docs warn that this isn't very well tested: https://www.cleancss.com/explain-command/gcc/5197 IEEE754 is a wonderful thing, and even imperfect implementations are still way better than what came before, but real systems are almost universally sloppy about details. I don't think any real libm even tries to set all the status flags correctly. And I'm not sure sNaN support is actually useful anyway... Of course if all you want is a value that raises an exception whenever it's used in an arithmetic expression, then Python does support that :-) sNaN = object() -n -- Nathaniel J. Smith -- https://vorpus.org