On Wed, Apr 27, 2011 at 2:48 PM, Robert Kern <robert.k...@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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to