[issue42210] float.hex discards sign from -nan

Sree added the comment: Thanks, all. I just wanted to know if this was a deliberate decision or an oversight. It also took me a while to realize it washex, and not fromhex. That allows the current behaviour to be easily worked around in Python code, and a backwards compatible optional parame

[issue42210] float.hex discards sign from -nan

Mark Dickinson added the comment: This isn't a bug: it was a deliberate decision, just like the choice to represent `-nan` as `nan` in `float.__repr__` was a deliberate decision. NaNs don't have a meaningful sign - they have a sign *bit*, but it's best to regard that as just an extra bit of

[issue42210] float.hex discards sign from -nan

Vedran Čačić added the comment: inf and -inf are really two different values (in the scope of the standard). Same as 5. and -5., or even 0. and -0. They behave differently in some exactly specified operations, and it is useful. Are there any exactly specified operations whose specifications r

[issue42210] float.hex discards sign from -nan

Raymond Hettinger added the comment: Having fromhex() support signed NaNs was reasonable because it is a valid possible input; however, the case isn't as clear-cut for output. Since applications are allowed to ignore the sign bit, no application should rely on seeing a particular sign for a

[issue42210] float.hex discards sign from -nan

Change by Raymond Hettinger : -- nosy: +tim.peters ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://ma

[issue42210] float.hex discards sign from -nan

New submission from Sree : float.hex(float.fromhex("-nan")) returns 'nan'. PyOS_double_to_string seems to check only if it is a NaN, but ignores the sign (unlike its handling of inf a few lines below):