Message233607
"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. |
|
Date |
User |
Action |
Args |
2015-01-07 22:09:05 | vstinner | set | recipients:
+ vstinner, mark.dickinson, pitrou, ethan.furman, serhiy.storchaka |
2015-01-07 22:09:05 | vstinner | set | messageid: <1420668545.35.0.754765763598.issue23185@psf.upfronthosting.co.za> |
2015-01-07 22:09:05 | vstinner | link | issue23185 messages |
2015-01-07 22:09:04 | vstinner | create | |
|