Mark Dickinson <dicki...@gmail.com> added the comment:
> signalling NaNs are quietly silenced on my machine
I just tested this assertion, and it appears that I was lying: this doesn't
seem to be true. I'm almost *sure* it used to be true, and I'm not sure what
changed, and when. (FWIW: Python 3.9.2 from macPorts on macOS 10.14.6 + Intel
hardware. Earlier versions of Python on the same machine give similar results
to those below, so it's not a core Python change.)
Here's an attempt to create an snan Python float:
Python 3.9.2 (default, Feb 28 2021, 13:47:30)
[Clang 10.0.1 (clang-1001.0.46.4)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> snan_bits = 0x7ff0000000123456
>>> snan = struct.unpack("<d", struct.pack("<Q", snan_bits))[0]
>>> snan
nan
Converting back shows that the attempt was successful: the payload, including
the signalling bit (bit 51, counting with the lsb as bit 0), was preserved:
>>> hex(struct.unpack("<Q", struct.pack("<d", snan))[0])
'0x7ff0000000123456'
As expected, doing any arithmetic on the value converts the signalling nan to
the corresponding quiet nan (so that the leading 16 bits become 0x7ff8 instead
of 0x7ff0), but preserves the rest of the payload.
>>> hex(struct.unpack("<Q", struct.pack("<d", 0.0 + snan))[0])
'0x7ff8000000123456'
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue43475>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
