On Wed, Apr 27, 2011 at 2:48 PM, Robert Kern <robert.kern at gmail.com> wrote: .. > I suspect most of us would oppose changing it on general > backwards-compatibility grounds rather than actually *liking* the current > behavior. If the behavior changed with Python floats, we'd have to mull over > whether we try to match that behavior with our scalar types (one of which > subclasses from float) and our arrays. We would be either incompatible with > Python or C, and we'd probably end up choosing Python to diverge from. It > would make a mess, honestly. We already have to explain why equality is > funky for arrays (arr1 == arr2 is a rich comparison that gives an array, not > a bool, so we can't do containment tests for lists of arrays), so NaN is > pretty easy to explain afterward. Most NumPy applications are actually not exposed to NaN problems because it is recommended that NaNs be avoided in computations and when missing or undefined values are necessary, the recommended solution is to use ma.array or masked array which is a drop-in replacement for numpy array type and carries a boolean "mask" value with every element. This allows to have undefined elements is arrays of any type: float, integer or even boolean. Masked values propagate through all computations including comparisons.
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