Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #6501 > unrolled thread

Re: float("nan") in set or as key

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: float("nan") in set or as key Albert Hopkins <marduk@letterboxes.org> - 2011-05-28 20:28 -0400
    Re: float("nan") in set or as key Erik Max Francis <max@alcyone.com> - 2011-05-28 17:44 -0700
    Re: float("nan") in set or as key Grant Edwards <invalid@invalid.invalid> - 2011-05-29 02:25 +0000
      Re: float("nan") in set or as key Wolfgang Rohdewald <wolfgang@rohdewald.de> - 2011-05-29 10:27 +0200
        Re: float("nan") in set or as key Grant Edwards <invalid@invalid.invalid> - 2011-05-29 14:41 +0000
          Re: float("nan") in set or as key MRAB <python@mrabarnett.plus.com> - 2011-05-29 18:44 +0100
            Re: float("nan") in set or as key Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-29 18:27 +0000
          Re: float("nan") in set or as key Chris Angelico <rosuav@gmail.com> - 2011-05-30 03:50 +1000
          Re: float("nan") in set or as key Christian Heimes <lists@cheimes.de> - 2011-05-29 20:05 +0200
            Re: float("nan") in set or as key Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-29 18:46 +0000
          Re: float("nan") in set or as key Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2011-05-29 20:36 -0700

#6501 — Re: float("nan") in set or as key

On Sun, 2011-05-29 at 00:41 +0100, MRAB wrote:
> Here's a curiosity. float("nan") can occur multiple times in a set or as 
> a key in a dict:
> 
>  >>> {float("nan"), float("nan")}
> {nan, nan}
> 
These two nans are not equal (they are two different nans)

> except that sometimes it can't:
> 
>  >>> nan = float("nan")
>  >>> {nan, nan}
> {nan}

This is the same nan, so it is equal to itself.

Two "nan"s are not equal in the manner that 1.0 and 1.0 are equal:

>>> 1.0 == 1.0
True
>>> float("nan") == float("nan")
False


I can't cite this in a spec, but it makes sense (to me) that two things
which are nan are not necessarily the same nan.

[toc] | [next] | [standalone]

#6503

Albert Hopkins wrote:
> On Sun, 2011-05-29 at 00:41 +0100, MRAB wrote:
>>>> 1.0 == 1.0
> True
>>>> float("nan") == float("nan")
> False
> 
> I can't cite this in a spec, but it makes sense (to me) that two things
> which are nan are not necessarily the same nan.

It's part of the IEEE standard.

-- 
Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
  San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Skype erikmaxfrancis
   There was never a good war or a bad peace.
    -- Benjamin Franklin, 1706-1790

[toc] | [prev] | [next] | [standalone]

#6510

On 2011-05-29, Albert Hopkins <marduk@letterboxes.org> wrote:
> On Sun, 2011-05-29 at 00:41 +0100, MRAB wrote:
>> Here's a curiosity. float("nan") can occur multiple times in a set or as 
>> a key in a dict:
>> 
>>  >>> {float("nan"), float("nan")}
>> {nan, nan}
>> 
> These two nans are not equal (they are two different nans)
>
>> except that sometimes it can't:
>> 
>>  >>> nan = float("nan")
>>  >>> {nan, nan}
>> {nan}
>
> This is the same nan, so it is equal to itself.

No, it's not.

>>> x = float("nan")
>>> y = x
>>> x is y
True
>>> x == y
False

> I can't cite this in a spec, but it makes sense (to me) that two things
> which are nan are not necessarily the same nan.

Even if they _are_ the same nan, it's still not equal to itself.

-- 
Grant

[toc] | [prev] | [next] | [standalone]

#6518

On Sonntag 29 Mai 2011, Tim Delaney wrote:
> There's a second part the mystery - sets and dictionaries (and
> I think lists) assume that identify implies equality (hence
> the second result). This was recently discussed on
> python-dev, and the decision was to leave things as-is.

On Sonntag 29 Mai 2011, Grant Edwards wrote:
> Even if they are the same nan, it's still not equal to itself.

if I understand this thread correctly, they are not equal to
itself as specified by IEEE but Python treats them equal in
sets and dictionaries for performance reasons

-- 
Wolfgang

[toc] | [prev] | [next] | [standalone]

#6543

On 2011-05-29, Wolfgang Rohdewald <wolfgang@rohdewald.de> wrote:
> On Sonntag 29 Mai 2011, Tim Delaney wrote:
>> There's a second part the mystery - sets and dictionaries (and
>> I think lists) assume that identify implies equality (hence
>> the second result). This was recently discussed on
>> python-dev, and the decision was to leave things as-is.
>
> On Sonntag 29 Mai 2011, Grant Edwards wrote:
>> Even if they are the same nan, it's still not equal to itself.
>
> if I understand this thread correctly, they are not equal to itself
> as specified by IEEE

And Python follows that convention.

> but Python treats them equal in sets and dictionaries for performance
> reasons

It treats them as identical (not sure if that's the right word).  The
implementation is checking for ( A is B or A == B ).  Presumably, the
assumpting being that all objects are equal to themselves.  That
assumption is not true for NaN objects, so the buggy behavior is
observed.

-- 
Grant

[toc] | [prev] | [next] | [standalone]

#6553

On 29/05/2011 15:41, Grant Edwards wrote:
> On 2011-05-29, Wolfgang Rohdewald<wolfgang@rohdewald.de>  wrote:
>> On Sonntag 29 Mai 2011, Tim Delaney wrote:
>>> There's a second part the mystery - sets and dictionaries (and
>>> I think lists) assume that identify implies equality (hence
>>> the second result). This was recently discussed on
>>> python-dev, and the decision was to leave things as-is.
>>
>> On Sonntag 29 Mai 2011, Grant Edwards wrote:
>>> Even if they are the same nan, it's still not equal to itself.
>>
>> if I understand this thread correctly, they are not equal to itself
>> as specified by IEEE
>
> And Python follows that convention.
>
>> but Python treats them equal in sets and dictionaries for performance
>> reasons
>
> It treats them as identical (not sure if that's the right word).  The
> implementation is checking for ( A is B or A == B ).  Presumably, the
> assumpting being that all objects are equal to themselves.  That
> assumption is not true for NaN objects, so the buggy behavior is
> observed.
>
Would there be any advantage to making NaN a singleton? I'm thinking
that it could make checking for it cheaper in the implementation of
sets and dicts. Or making NaN unhashable?

[toc] | [prev] | [next] | [standalone]

#6559

On Sun, 29 May 2011 18:44:08 +0100, MRAB wrote:

> Would there be any advantage to making NaN a singleton?

Absolutely not. That would be a step backwards.

NANs can carry payload (a code indicating what sort of NAN it represents 
-- log(-1) and 1/INF are not the same). So although Python currently has 
no easy way to access that payload (you can do it with the struct 
module), it does exist and for serious work you would want to be able to 
set and get it.


> I'm thinking
> that it could make checking for it cheaper in the implementation of sets
> and dicts. 

I don't see how would it be cheaper, but even if it were, talk about a 
micro-optimization! I'd really *love* to see the code where the time it 
takes to insert a NAN in a set was the bottleneck!



> Or making NaN unhashable?

I could live with that, although I don't think it is necessary. What 
actual problem are you hoping to solve here?



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#6554

On Mon, May 30, 2011 at 3:44 AM, MRAB <python@mrabarnett.plus.com> wrote:
> Would there be any advantage to making NaN a singleton? I'm thinking
> that it could make checking for it cheaper in the implementation of
> sets and dicts. Or making NaN unhashable?

Doesn't matter. It still wouldn't be equal to itself, even though it
'is' itself, which will greatly confuse anything that optimizes that
away. Numbers are well-behaved; NaN is not a number; NaN is not
well-behaved. It makes sense... in a way.

Chris Angelico

[toc] | [prev] | [next] | [standalone]

#6558

Am 29.05.2011 19:44, schrieb MRAB:
> Would there be any advantage to making NaN a singleton? I'm thinking
> that it could make checking for it cheaper in the implementation of
> sets and dicts. Or making NaN unhashable?

It can't be a singleton, because IEEE 754 specifies millions of millions
of different NaN values. There are positive and negative NaNs, quiet
NaNs and signaling NaNs. 50 of 52 mantissa bits can vary freely, one bit
makes the difference between signaling and quiet NaNs and at least one
bit must be non-zero.

Christian

[toc] | [prev] | [next] | [standalone]

#6562

On Sun, 29 May 2011 20:05:07 +0200, Christian Heimes wrote:

> Am 29.05.2011 19:44, schrieb MRAB:
>> Would there be any advantage to making NaN a singleton? I'm thinking
>> that it could make checking for it cheaper in the implementation of
>> sets and dicts. Or making NaN unhashable?
> 
> It can't be a singleton, because IEEE 754 specifies millions of millions
> of different NaN values. 

A million-millioneton then? *wink*


> There are positive and negative NaNs, 

I've never quite understood that. NANs are unordered, and therefore 
cannot be said to be larger than zero (positive) or less than zero 
(negative). So even if a NAN has the sign bit set, surely the right way 
to think about that is to treat the sign bit as part of the payload?

It seems to me that talking about signed NANs is inaccurate and adds 
confusion. NANs cause enough confusion as it is, without adding to it...

(I would expect the copysign function to honour the sign bit, so I 
suppose in that sense one might describe NANs as signed.)



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#6616

On Mon, 30 May 2011 03:50:15 +1000, Chris Angelico <rosuav@gmail.com>
declaimed the following in gmane.comp.python.general:

> 
> Doesn't matter. It still wouldn't be equal to itself, even though it
> 'is' itself, which will greatly confuse anything that optimizes that
> away. Numbers are well-behaved; NaN is not a number; NaN is not
> well-behaved. It makes sense... in a way.

	As I recall, NaN behaves just like Null does in SQL... Null never
compares equal to Null.

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web