On Mar 24, 2010, at 9:22 AM, Mark Dickinson wrote: > > The obvious way to do this nan interning for floats would be to put > the interning code into PyFloat_FromDouble. I'm not sure whether this > would be worth the cost in terms of added code (and possibly reduced > performance, since the nan check would be done every time a float was > returned), but I'd be willing to review a patch. -1 Propagating support for NaNs has already consumed an enormous amount of your time. The code for the math module doubled in complexity as a result of adding Nan/Inf support. At each stage, some new weirdness emerges (such as complex(Nan, Nan), etc). And each change introduces the risk of new bugs in code that had been stable for a long time. IIRC, the original purpose of a NaN was to serve as a placeholder value in a long series of floating point ops so that the programmer would not have to introduce edge case tests at each stage of a calculation. Yet, I look at the code for the decimal module and the C code for the math module and see that the opposite result occurred, the code is littered with is_special(x) tests and handlers. In terms of practicality, NaNs work great as a way to mark missing values and to propagate through subsequent calculations. IMO, their least useful feature is the property of being not equal to themselves -- that causes more problems than it solves because it impairs a programmer's ability to reason about their programs. Raymond -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20100324/4c458fef/attachment-0001.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4