PyObject_RichCompareBool identity shortcut

classic Classic list List threaded Threaded
130 messages Options
1234 ... 7
Reply | Threaded
Open this post in threaded view
|

PyObject_RichCompareBool identity shortcut

Hrvoje Niksic-2
The other day I was surprised to learn this:

 >>> nan = float('nan')
 >>> nan == nan
False
 >>> [nan] == [nan]
True                  # also True in tuples, dicts, etc.

# also:
 >>> l = [nan]
 >>> nan in l
True
 >>> l.index(nan)
0
 >>> l[0] == nan
False

The identity test is not in container comparators, but in
PyObject_RichCompareBool:

     /* Quick result when objects are the same.
        Guarantees that identity implies equality. */
     if (v == w) {
         if (op == Py_EQ)
             return 1;
         else if (op == Py_NE)
             return 0;
     }

The guarantee referred to in the comment is not only (AFAICT)
undocumented, but contradicts the documentation, which states that the
result should be the "equivalent of o1 op o2".

Calling PyObject_RichCompareBool is inconsistent with calling
PyObject_RichCompare and converting its result to bool manually,
something that wrappers (C++) and generators (cython) might reasonably
want to do themselves, for various reasons.

If this is considered a bug, I can open an issue.

Hrvoje
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PyObject_RichCompareBool identity shortcut

Łukasz Langa-2
Wiadomość napisana przez Hrvoje Niksic w dniu 2011-04-27, o godz. 11:37:

> The other day I was surprised to learn this:
>
> >>> nan = float('nan')
> >>> nan == nan
> False
> >>> [nan] == [nan]
> True                  # also True in tuples, dicts, etc.
>
> # also:
> >>> l = [nan]
> >>> nan in l
> True
> >>> l.index(nan)
> 0
> >>> l[0] == nan
> False
>

This surprises me as well. I guess this is all related to the fact that:
>>> nan is nan
True

Have a look at this as well:

>>> inf = float('inf')
>>> inf == inf
True
>>> [inf] == [inf]
True
>>> l = [inf]
>>> inf in l
True
>>> l.index(inf)
0
>>> l[0] == inf
True

# Or even:
>>> inf+1 == inf-1
True

For the infinity part, I believe this is related to the funky IEEE 754 standard. I found
some discussion about this here: http://compilers.iecc.com/comparch/article/98-07-134

--
Best regards,
Łukasz Langa
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PyObject_RichCompareBool identity shortcut

Nick Coghlan
2011/4/27 Łukasz Langa <[hidden email]>:
> # Or even:
>>>> inf+1 == inf-1
> True
>
> For the infinity part, I believe this is related to the funky IEEE 754 standard. I found
> some discussion about this here: http://compilers.iecc.com/comparch/article/98-07-134

The inf behaviour is fine (inf != inf only when you start talking
about aleph levels, and IEEE 754 doesn't handle those).

It's specifically `nan` that is problematic, as it is one of the very
few cases that breaks the reflexivity of equality.

That said, the current behaviour was chosen deliberately so that
containers could cope with `nan` at least somewhat gracefully:
http://bugs.python.org/issue4296

Issue 10912 added an explicit note about this behaviour to the 3.x
series documentation, but that has not as yet been backported to 2.7
(I reopened the issue to request such a backport).

Cheers,
Nick.

--
Nick Coghlan   |   [hidden email]   |   Brisbane, Australia
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PyObject_RichCompareBool identity shortcut

Raymond Hettinger-4
In reply to this post by Hrvoje Niksic-2

On Apr 27, 2011, at 2:37 AM, Hrvoje Niksic wrote:

The other day I was surprised to learn this:

>>> nan = float('nan')
>>> nan == nan
False
>>> [nan] == [nan]
True                  # also True in tuples, dicts, etc.

Would also be surprised if you put an object in a dictionary but couldn't get it out?  Or added it to a list but its count was zero?

Identity-implies-equality is necessary so that classes can maintain their invariants and so that programmers can reason about their code.  It is not just in PyObject_RichCompareBool, it is deeply embedded in the language (the logic inside dicts for example).  It is not a short-cut, it is a way of making sure that internally we can count on equality relations reflexive, symmetric, and transitive.  A programmer needs to be able to make basic deductions such as the relationship between the two forms of the in-operator:   for elem in somelist:  assert elem in somelist  # this should never fail.

What surprises me is that anyone gets surprised by anything when experimenting with an object that isn't equal to itself.  It is roughly in the same category as creating a __hash__ that has no relationship to __eq__ or making self-referencing sets or setting False,True=1,0 in python 2.  See http://bertrandmeyer.com/2010/02/06/reflexivity-and-other-pillars-of-civilization/ for a nice blog post on the subject.


Raymond




_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PyObject_RichCompareBool identity shortcut

Guido van Rossum
On Wed, Apr 27, 2011 at 7:39 AM, Raymond Hettinger
<[hidden email]> wrote:

>
> On Apr 27, 2011, at 2:37 AM, Hrvoje Niksic wrote:
>
> The other day I was surprised to learn this:
>
>>>> nan = float('nan')
>>>> nan == nan
> False
>>>> [nan] == [nan]
> True                  # also True in tuples, dicts, etc.
>
> Would also be surprised if you put an object in a dictionary but couldn't
> get it out?  Or added it to a list but its count was zero?
> Identity-implies-equality is necessary so that classes can maintain their
> invariants and so that programmers can reason about their code.  It is not
> just in PyObject_RichCompareBool, it is deeply embedded in the language (the
> logic inside dicts for example).  It is not a short-cut, it is a way of
> making sure that internally we can count on equality relations reflexive,
> symmetric, and transitive.  A programmer needs to be able to make basic
> deductions such as the relationship between the two forms of the
> in-operator:   for elem in somelist:  assert elem in somelist  # this should
> never fail.
> What surprises me is that anyone gets surprised by anything when
> experimenting with an object that isn't equal to itself.  It is roughly in
> the same category as creating a __hash__ that has no relationship to __eq__
> or making self-referencing sets or setting False,True=1,0 in python 2.
>  See http://bertrandmeyer.com/2010/02/06/reflexivity-and-other-pillars-of-civilization/ for
> a nice blog post on the subject.

Maybe we should just call off the odd NaN comparison behavior?

--
--Guido van Rossum (python.org/~guido)
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PyObject_RichCompareBool identity shortcut

Nick Coghlan
On Thu, Apr 28, 2011 at 12:53 AM, Guido van Rossum <[hidden email]> wrote:
>> What surprises me is that anyone gets surprised by anything when
>> experimenting with an object that isn't equal to itself.  It is roughly in
>> the same category as creating a __hash__ that has no relationship to __eq__
>> or making self-referencing sets or setting False,True=1,0 in python 2.
>>  See http://bertrandmeyer.com/2010/02/06/reflexivity-and-other-pillars-of-civilization/ for
>> a nice blog post on the subject.
>
> Maybe we should just call off the odd NaN comparison behavior?

Rereading Meyer's article (I read it last time this came up, but it's
a nice piece, so I ended up going over it again this time) the quote
that leapt out at me was this one:

"""A few of us who had to examine the issue recently think that —
whatever the standard says at the machine level — a programming
language should support the venerable properties that equality is
reflexive and that assignment yields equality.

Every programming language should decide this on its own; for Eiffel
we think this should be the specification. Do you agree?"""

Currently, Python tries to split the difference: "==" and "!=" follow
IEEE754 for NaN, but most other operations involving builtin types
rely on the assumption that equality is always reflexive (and IEEE754
be damned).

What that means is that "correct" implementations of methods like
__contains__, __eq__, __ne__, index() and count() on containers should
be using "x is y or x == y" to enforce reflexivity, but most such code
does not (e.g. our own collections.abc.Sequence implementation gets
those of these that it implements wrong, and hence Sequence based
containers will handle NaN in a way that differs from the builtin
containers)

And none of that is actually documented anywhere (other than a
behavioural note in the 3.x documentation for
PyObject_RichCompareBool), so it's currently just an implementation
detail of CPython that most of the builtin containers behave that way
in practice.

Given the status quo, what would seem to be the path of least resistance is to:
- articulate in the language specification which container special
methods are expected to enforce reflexivity of equality (even for
non-reflexive types)
- articulate in the library specification which ordinary container
methods enforce reflexivity of equality
- fix any standard library containers that don't enforce reflexivity
to do so where appropriate (e.g. collections.abc.Sequence)

Types with a non-reflexive notion of equality still wouldn't play
nicely with containers that didn't enforce reflexivity where
appropriate, but bad interactions between 3rd party types isn't really
something we can prevent.

Backing away from having float and decimal.Decimal respect the IEEE754
notion of NaN inequality at this late stage of the game seems like one
for the "too hard" basket. It also wouldn't achieve much, since we
want the builtin containers to preserve their invariants even for 3rd
party types with a non-reflexive notion of equality.

Cheers,
Nick.

--
Nick Coghlan   |   [hidden email]   |   Brisbane, Australia
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PyObject_RichCompareBool identity shortcut

Alexander Belopolsky
In reply to this post by Guido van Rossum
On Wed, Apr 27, 2011 at 10:53 AM, Guido van Rossum <[hidden email]> wrote:
..
> Maybe we should just call off the odd NaN comparison behavior?

+1

There was a long thread on this topic last year:

http://mail.python.org/pipermail/python-dev/2010-March/098832.html

I was trying to find a rationale for non-reflexivity of equality in
IEEE and although it is often mentioned that this property simplifies
some numerical algorithms, I am yet to find an important algorithm
that would benefit from it.  I also believe that long history of
suboptimal hardware implementations of nan arithmetics has stifled the
development of practical applications.

High performance applications that rely on non-reflexivity will still
have an option of using ctypes.c_float type or NumPy.
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PyObject_RichCompareBool identity shortcut

Nick Coghlan
On Thu, Apr 28, 2011 at 1:43 AM, Alexander Belopolsky
<[hidden email]> wrote:
> High performance applications that rely on non-reflexivity will still
> have an option of using ctypes.c_float type or NumPy.

However, that's exactly the reason I don't see any reason to reverse
course on having float() and Decimal() follow IEEE754 semantics,
regardless of how irritating we may find those semantics to be.

Since we allow types to customise __eq__ and __ne__ with non-standard
behaviour, if we want to permit *any* type to have a non-reflexive
notion of equality, then we need to write our container types to
enforce reflexivity when appropriate. Many of the builtin types
already do this, by virtue of it being built in to RichCompareBool.
It's now a matter of documenting that properly and updating the
non-conformant types accordingly.

Cheers,
Nick.

--
Nick Coghlan   |   [hidden email]   |   Brisbane, Australia
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PyObject_RichCompareBool identity shortcut

Isaac Morland-2
In reply to this post by Alexander Belopolsky
On Wed, 27 Apr 2011, Alexander Belopolsky wrote:

> High performance applications that rely on non-reflexivity will still
> have an option of using ctypes.c_float type or NumPy.

Python could also provide IEEE-754 equality as a function (perhaps in
"math"), something like:

def ieee_equal (a, b):
  return a == b and not isnan (a) and not isnan (b)

Of course, the definition of math.isnan cannot then be by checking its
argument by comparison with itself - it would have to check the
appropriate bits of the float representation.

Isaac Morland CSCF Web Guru
DC 2554C, x36650 WWW Software Specialist
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PyObject_RichCompareBool identity shortcut

Alexander Belopolsky
In reply to this post by Nick Coghlan
On Wed, Apr 27, 2011 at 11:31 AM, Nick Coghlan <[hidden email]> wrote:
..
> Backing away from having float and decimal.Decimal respect the IEEE754
> notion of NaN inequality at this late stage of the game seems like one
> for the "too hard" basket.

Why?  float('nan') has always been in the use-at-your-own-risk
territory despite recent efforts to support it across Python
platforms.   I cannot speak about decimal.Decimal (and decimal is a
different story because it is tied to a particular standard), but the
only use of non-reflexifity for float nans I've seen was use of x != x
instead of math.isnan(x).

> It also wouldn't achieve much, since we
> want the builtin containers to preserve their invariants even for 3rd
> party types with a non-reflexive notion of equality.

These are orthogonal issues.   A third party type that plays with
__eq__ and other basic operations can easily break stdlib algorithms
no matter what we do.  Therefore it is important to document the
properties of the types that each algorithm relies on.  It is more
important, however that stdlib types do not break 3rd party's
algorithms.   I don't think I've ever seen a third party type that
deliberately defines a non-reflexive __eq__ except as a side effect of
using float attributes or C float members in the underlying structure.
 (Yes, decimal is a counter-example, but this is a very special case.)
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PyObject_RichCompareBool identity shortcut

Alexander Belopolsky
In reply to this post by Isaac Morland-2
On Wed, Apr 27, 2011 at 12:05 PM, Isaac Morland <[hidden email]> wrote:
..
> Of course, the definition of math.isnan cannot then be by checking its
> argument by comparison with itself - it would have to check the appropriate
> bits of the float representation.

math.isnan() is implemented in C and does not rely on float.__eq__ in any way.
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PyObject_RichCompareBool identity shortcut

Antoine Pitrou
In reply to this post by Isaac Morland-2
On Wed, 27 Apr 2011 12:05:12 -0400 (EDT)
Isaac Morland <[hidden email]> wrote:

> On Wed, 27 Apr 2011, Alexander Belopolsky wrote:
>
> > High performance applications that rely on non-reflexivity will still
> > have an option of using ctypes.c_float type or NumPy.
>
> Python could also provide IEEE-754 equality as a function (perhaps in
> "math"), something like:
>
> def ieee_equal (a, b):
>   return a == b and not isnan (a) and not isnan (b)

+1 (perhaps call it math.eq()).

Regards

Antoine.


_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PyObject_RichCompareBool identity shortcut

Raymond Hettinger-4
In reply to this post by Guido van Rossum

On Apr 27, 2011, at 7:53 AM, Guido van Rossum wrote:

> Maybe we should just call off the odd NaN comparison behavior?

I'm reluctant to suggest changing such enshrined behavior.

ISTM, the current state of affairs is reasonable.  
Exotic objects are allowed to generate exotic behaviors
but consumers of those objects are free to ignore some
of those behaviors by making reasonable assumptions
about how an object should behave.

It's possible to make objects where the __hash__ doesn't
correspond to __eq__.; they just won't behave well with
hash tables.  Likewise, it's possible for a sequence to
define a __len__ that is different from it true length; it
just won't behave well with the various pieces of code
that assume collections are equal if the lengths are unequal.

All of this seems reasonable to me.


Raymond


_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PyObject_RichCompareBool identity shortcut

Isaac Morland-2
In reply to this post by Antoine Pitrou
On Wed, 27 Apr 2011, Antoine Pitrou wrote:

> Isaac Morland <[hidden email]> wrote:
>>
>> Python could also provide IEEE-754 equality as a function (perhaps in
>> "math"), something like:
>>
>> def ieee_equal (a, b):
>>   return a == b and not isnan (a) and not isnan (b)
>
> +1 (perhaps call it math.eq()).

Alexander Belopolsky pointed out to me (thanks!) that isnan is implemented
in C so my caveat about the implementation of isnan is not an issue.  But
then that made me realize the ieee_equal (or just "eq" if that's
preferable) probably ought to be implemented in C using a floating point
comparison - i.e., use the processor implementation of the comparison
operation..

Isaac Morland CSCF Web Guru
DC 2554C, x36650 WWW Software Specialist
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PyObject_RichCompareBool identity shortcut

Alexander Belopolsky
In reply to this post by Raymond Hettinger-4
On Wed, Apr 27, 2011 at 12:28 PM, Raymond Hettinger
<[hidden email]> wrote:

>
> On Apr 27, 2011, at 7:53 AM, Guido van Rossum wrote:
>
>> Maybe we should just call off the odd NaN comparison behavior?
>
> I'm reluctant to suggest changing such enshrined behavior.
>
> ISTM, the current state of affairs is reasonable.
> Exotic objects are allowed to generate exotic behaviors
> but consumers of those objects are free to ignore some
> of those behaviors by making reasonable assumptions
> about how an object should behave.

Unfortunately NaNs are not that exotic.  They can be silently produced
in calculations and lead to hard to find errors.  For example:

>>> x = 1e300*1e300
>>> x - x
nan

This means that every program dealing with float data has to detect
nans at every step and handle them correctly.  This in turn makes it
impossible to write efficient code that works equally well with floats
and integers.

Note that historically, Python was trying hard to prevent production
of non-finite floats.  AFAICT, none of the math functions would
produce inf or nan.   I am not sure why arithmetic operations are
different.  For example:

>>> 1e300*1e300
inf

but

>>> 1e300**2
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: (34, 'Result too large')

and

>>> math.pow(1e300,2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: math range error
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PyObject_RichCompareBool identity shortcut

Raymond Hettinger-4

On Apr 27, 2011, at 10:16 AM, Alexander Belopolsky wrote:
Unfortunately NaNs are not that exotic.  

They're exotic in the sense that they have the unusual property of not being equal to themselves.

Exotic (adj) strikingly strange or unusual


Raymond



_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PyObject_RichCompareBool identity shortcut

Terry Reedy
In reply to this post by Guido van Rossum
On 4/27/2011 10:53 AM, Guido van Rossum wrote:
> On Wed, Apr 27, 2011 at 7:39 AM, Raymond Hettinger

 >> Identity-implies-equality is necessary so that classes can maintain
 >> their invariants and so that programmers can reason about their code.
[snip]
>>   See http://bertrandmeyer.com/2010/02/06/reflexivity-and-other-pillars-of-civilization/ for
>> a nice blog post on the subject.

I carefully reread this, with the comments, and again came to the
conclusion that the committee left us no *good* answer, only a choice
between various more-or-less unsatifactory answers. The current Python
compromise may be as good as anything. In any case, I think it should be
explicitly documented with an indexed paragraph, perhaps as follows:

"The IEEE-754 committee defined the float Not_a_Number (NaN) value as
being incomparable with all others floats, including itself. This
violates the math and logic rule that equality is reflexive, that 'a ==
a' is always True. And Python collection classes depend on that rule for
their proper operation. So Python makes the follow compromise. Direct
equality comparisons involving Nan, such as "NaN=float('NaN'); NaN ==
ob", follow the IEEE-754 rule and return False. Indirect comparisons
conducted internally as part of a collection operation, such as 'NaN in
someset' or 'seq.count()' or 'somedict[x]', follow the reflexive rule
and act as it 'Nan == NaN' were True. Most Python programmers will never
see a Nan in real programs."

This might best be an entry in the Glossary under "NaN -- Not a Number".
It should be the first reference for Nan in the General Index and linked
to from the float() builtin and float type Nan mentions.

> Maybe we should just call off the odd NaN comparison behavior?

Eiffel seems to have survived, though I do not know if it used for
numerical work. I wonder how much code would break and what the scipy
folks would think. 3.0 would have been the time, though.

--
Terry Jan Reedy

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PyObject_RichCompareBool identity shortcut

Glenn Linderman-3
In reply to this post by Nick Coghlan
On 4/27/2011 8:31 AM, Nick Coghlan wrote:
> What that means is that "correct" implementations of methods like
> __contains__, __eq__, __ne__, index() and count() on containers should
> be using "x is y or x == y" to enforce reflexivity, but most such code
> does not (e.g. our own collections.abc.Sequence implementation gets
> those of these that it implements wrong, and hence Sequence based
> containers will handle NaN in a way that differs from the builtin
> containers)

+1 to everything Nick said.

One issue that I don't fully understand: I know there is only one
instance of None in Python, but I'm not sure where to discover whether
there is only a single, or whether there can be multiple, instances of
NaN or Inf.  The IEEE 754 spec is clear that there are multiple bit
sequences that can be used to represent these, so I would hope that
there can be, in fact, more than one value containing NaN (and Inf).

This would properly imply that a collection should correctly handle the
case of storing multiple, different items using different NaN (and Inf)
instances.  A dict, for example, should be able to hold hundreds of
items with the index value of NaN.

The distinction between "is" and "==" would permit proper operation, and
I believe that Python's "rebinding" of names to values rather than the
copying of values to variables makes such a distinction possible to use
in a correct manner.

Can someone confirm or explain this issue?
_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PyObject_RichCompareBool identity shortcut

Robert Kern-2
In reply to this post by Terry Reedy
On 4/27/11 12:44 PM, Terry Reedy wrote:
> On 4/27/2011 10:53 AM, Guido van Rossum wrote:

>> Maybe we should just call off the odd NaN comparison behavior?
>
> Eiffel seems to have survived, though I do not know if it used for numerical
> work. I wonder how much code would break and what the scipy folks would think.

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.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PyObject_RichCompareBool identity shortcut

Terry Reedy
In reply to this post by Glenn Linderman-3
On 4/27/2011 2:41 PM, Glenn Linderman wrote:

> One issue that I don't fully understand: I know there is only one
> instance of None in Python, but I'm not sure where to discover whether
> there is only a single, or whether there can be multiple, instances of
> NaN or Inf.

I am sure there are multiple instances with just one bit pattern, the
same as other floats. Otherwise, float('nan') would have to either
randomly or systematically choose from among the possibilities. Ugh.

There are functions in the math module that pull apart (and put
together) floats.

 > The IEEE 754 spec is clear that there are multiple bit
> sequences that can be used to represent these,

Anyone actually interested in those should use C or possibly the math
module float assembly function.

 > so I would hope that
> there can be, in fact, more than one value containing NaN (and Inf).

If you do not know which pattern is which, what use could such passibly be?

--
Terry Jan Reedy

_______________________________________________
Python-Dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/lists%40nabble.com
1234 ... 7