Mark Dickinson added the comment:
> Looks like the sign bit is off (0) in 2.7.
Yep, that looks like issue 22590. It's "fixed" in Python 3, and I don't think
it's worth changing in Python 2.
About this issue (sign in repr of NaN): sorry, but I'm unconvinced. :-)
>From the standpoint of IEEE 754, the only part that's really relevant is
>section 5.12 ("Details of conversion between floating-point data and external
>character sequences"), and there's nothing in that section indicating that a
>sign is either recommended or required. The most relevant part is this one:
"""
Conversion of a quiet NaN in a supported format to an external character
sequence shall produce a language-defined one of “nan” or a sequence that is
equivalent except for case (e.g., “NaN”), with an optional preceding sign.
(This standard does not interpret the sign of a NaN.)
"""
Yes, it's true that copysign copies the sign bit, but I don't see the leap from
there to saying that the *repr* of a NaN should include it. total_order doesn't
really seem relevant here, since Python doesn't implement it, and if it were
implemented that implementation would almost certainly not be via the repr.
To your catan example: Python follows Annex G of the C99 specification for its
cmath functions. catan is specified in terms of catanh, and the relevant line
there is:
"""
catanh(NaN + i∞) returns ±0 + iπ /2 (where the sign of the real part of the
result is unspecified).
"""
Note that the sign of the zero is unspecified here. There's no part of Annex G
that introduces any dependence on the sign of a NaN. So no, unlike the sign of
a zero, the sign of a NaN does *not* play a role in selecting which side of a
branch cut an input to a complex function lies on. (The branch cuts for
cmath.atan are both on the imaginary axis, with real part 0; while it's not
really clear what kind of topology applies to a C99-style extended complex
plane, it would be a stretch to regard inf +/- iNaN as being anywhere on or
near that branch cut.)
The roundtrip argument doesn't really hold water either: a quiet NaN has 52
extra bits of information - a sign bit and a 51-bit payload; if we were
attempting to roundtrip the bits, we'd need to include the payload information
too. I don't see that it's any more important to distinguish NaNs with
different signs than to distinguish NaNs with different payloads.
> MSVC 2015 and MinGW-W64 v4.9.2 output (source below) for '-nan' values are:
> MSVC: -nan(ind)
> MinGW-W64: -1.#IND00
Sure, and clang on OS X produces "nan" for the same source.
> It is reasonable to assume some will need to preserve it.
Maybe, but I've read and worked with a lot of numerical code over the last two
and a half decades, and I have yet to see any whose correctness depends on
interpreting the sign of a NaN. Access to the sign bit of a NaN is a rare need,
and not something that needs be included in the repr. For those who really do
need it for some kind of custom use-case, it's not hard to use copysign to
extract it.
In sum, I don't see any benefit to adding the sign, and there's an obvious
drawback in the form of code breakage (in doctests, for example).
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26785>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
