[Python-ideas] math.inf and math.nan constants
bruce at leban.us
Wed Jan 7 20:02:50 CET 2015
On Wed, Jan 7, 2015 at 8:09 AM, Steven D'Aprano <steve at pearwood.info> wrote:
> In any case, we're talking about an utterly trivial micro-optimization.
> This is Python, not Unix shell scripting. We don't use names like
> "umount" to save one character over "unmount", we encouraging writing
> for clarity and correctness over brevity.
> The math module has constants pi and e because it would be truly an
inconvenience to have to create them yourself:
> pi = 3.14159265389793
> You're missing one key detail. If I see math.nan or math.inf in code, I
know what those values are. If I see a bare nan or inf in the code I don't.
That's an inconvenience too.
> Up to now, I have only discussed inf, not nan, because there is only one
> inf value in floats. (Two if you count -inf.) But the IEEE 754 standard
> provides many different NAN values, and offers a possible interpretion
> of them: the extra "payload" on each NAN can be used to carry diagnostic
> information on which numeric operation failed.
This is a red herring as any future change to support this won't
automatically touch code that uses float("nan") just as it won't touch code
that uses float.nan.
There is a problem here but that's not it. The problem is that
float("nan") is float("nan") => False
math.nan is math.nan => True
So is this an attractive nuisance that will make people think they can
should use x is math.nan instead of math.isnan(x)? Hopefully not but
something to consider. Pylint should flag this usage.
Check out my new puzzle book: http://Ju.mp/ingToConclusions
Get it free here: http://Ju.mp/ingToConclusionsFree (available on iOS)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas