[Python-Dev] Why is nan != nan?

David Cournapeau cournape at gmail.com
Mon Mar 29 08:17:34 CEST 2010

On Sun, Mar 28, 2010 at 9:28 AM, Robert Kern <robert.kern at gmail.com> wrote:
> On 2010-03-27 00:32 , David Cournapeau wrote:
>> On Sat, Mar 27, 2010 at 8:16 AM, Raymond Hettinger
>> <raymond.hettinger at gmail.com>  wrote:
>>> On Mar 26, 2010, at 2:16 PM, Xavier Morel wrote:
>>> How about raising an exception instead of creating nans in the first
>>> place,
>>> except maybe within specific contexts (so that the IEEE-754 minded can
>>> get
>>> their nans working as they currently do)?
>>> -1
>>> The numeric community uses NaNs as placeholders in vectorized
>>> calculations.
>> But is this relevant to python itself ? In Numpy, we indeed do use and
>> support NaN, but we have much more control on what happens compared to
>> python float objects. We can control whether invalid operations raises
>> an exception or not, we had isnan/isfinite for a long time, and the
>> fact that nan != nan has never been a real problem AFAIK.
> Nonetheless, the closer our float arrays are to Python's float type, the
> happier I will be.

Me too, but I don't see how to reconcile this with the intent of
simplifying nan handling because they are not intuitive, which seems
to be the goal of this discussion.


More information about the Python-Dev mailing list