homepage

This issue tracker has been migrated to GitHub , and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients ethan.furman, mark.dickinson, pitrou, serhiy.storchaka, vstinner
Date 2015年01月07日.22:09:04
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1420668545.35.0.754765763598.issue23185@psf.upfronthosting.co.za>
In-reply-to
Content
"History, perhaps? In any case, the sign of a NaN isn't useful information in the same way that the sign of an infinity is. The IEEE 754 standard explicitly refuses to attach any meaning to the sign bit of a NaN. And if we were aiming for a full and faithful representation of NaNs, we'd want to output the payload, too (which is just about as meaningless / meaningful as the sign bit)."
So I understand that adding a math.neg_nan would be useless. As adding one constant per possible "NaN" value :-) If I recall correctly the IEEE 754 standard, there is not single NaN value, but a range of NaN.
"Two kinds of NaN: a quiet NaN (qNaN) and a signaling NaN (sNaN). A NaN may carry a payload that is intended for diagnostic information indicating the source of the NaN. The sign of a NaN has no meaning, but it may be predictable in some circumstances." says Wikipedia.
Well, the current definition of math.nan makes sense, it's the same value than float("nan").
Note: On python-ideas, I asked if math.nan and math.inf should be singleton (as it was requested for float("0.0") in issue #4024). The answer is no.
History
Date User Action Args
2015年01月07日 22:09:05vstinnersetrecipients: + vstinner, mark.dickinson, pitrou, ethan.furman, serhiy.storchaka
2015年01月07日 22:09:05vstinnersetmessageid: <1420668545.35.0.754765763598.issue23185@psf.upfronthosting.co.za>
2015年01月07日 22:09:05vstinnerlinkissue23185 messages
2015年01月07日 22:09:04vstinnercreate

AltStyle によって変換されたページ (->オリジナル) /