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

[Masklinn]

On 25 Mar 2010, at 07:50 , Alexander Belopolsky wrote:
> 
> Since we are now venturing in the realm of python-ideas, I am
> switching the mailing lists.  Please see more below.
> 
> On Wed, Mar 24, 2010 at 7:31 PM, Mark Dickinson <dickinsm at gmail.com> wrote:
>> On Wed, Mar 24, 2010 at 11:11 PM, Alexander Belopolsky
>> <alexander.belopolsky at gmail.com> wrote:
>>> On Wed, Mar 24, 2010 at 7:02 PM, Mark Dickinson <dickinsm at gmail.com> wrote:
>>> ..
>>>> 
>>>> So if I understand correctly, you propose that float('nan') ==
>>>> float('nan') return True.  Would you also suggest extending this
>>>> behaviour to Decimal nans?
>>>> 
>>> 
>>> yes
>>> 
>> 
>> Okay.  So now it seems to me that there are many decisions to make:
> 
> I maybe show my ignorance, but I don't see the significance of
> bringing Decimal nans to the discussion.  My answers below apply
> equally to binary and decimal floating point numbers.
> 
>> should any Decimal nan compare equal to any other?
> 
> Yes.
> 
>>  What if the two nans have different payloads or signs?
> 
> They are still equal.  Just as 0.0 and -0.0 are now.

Excuse me but NaNs propagate right? So we'd have not only
float('nan') == float('nan'), but also float('nan') = float('nan') + 1
right? Indeed, any operation on a NaN would return a result equal (and
identical?) to itself. I'm not sure that makes more sense than the current
behavior (which is at least standard and specified).

> IEEE standards were developed in a different problem domain: hardware
> or low level programming language design.

I don't really agree. They were developed in a problem domain of mapping
abstract mathematical concepts to computing. And it's not like they're 
static and never updated (indeed, IEEE-754 was updated in 2008, if anyone
has an IEEE login it would be possible to check the purposes and
assumptions the standard set for itself).

I believe changing the behavior of nan to have "nan == nan" would be
broken, nan is not a "normal" value (or set of values) of the space.

Having the option of getting an exception upon getting a nan on the other
hand (as the default behavior even, with a switch to the current behavior
using contexts similar to decimal's), why not.

> http://bertrandmeyer.com/2010/02/06/reflexivity-and-other-pillars-of-civilization/

It's interesting that Bertrand starts from

> I am talking about a value, as in mathematics, not an expression, as in programming

but doesn't seem to consider that, in the first place, the very concept of
NaN is due to the limitations of physical space compared to the abstract
mathematical concepts involved. The very idea of IEEE-754 floats are a
a definite departure from the fundamental laws of mathematics, making
Bertrand's final request

> It is rather dangerous indeed to depart from the fundamental laws of mathematics. 

very weird. Unless you remove floats from your language, you're not dealing
with grounds mathematics cover in the first place, you're dealing with
a concretization of mathematical ideas, and as all changes in abstraction
levels, it will leak one way or another.

I'd support "fixing" nan behaviors, but not by making operations on nan
reflexive (and nan a normal value, which it isn't) and instead by
treating all of them as errors, the same way calling an arbitrary
attribute no None results in an AttributeError in Python.