Steven D'Aprano writes:
> (I grant that Alexander is an exception -- I understand that he does do
> a lot of numeric work, and does come across NANs, and still doesn't like
> them one bit.)
I don't think I'd want anybody who *likes* NaNs to have a commit bit
at python.org.
__
Nick Coghlan wrote:
1. IEEE754 is a value-based system, with a finite number of distinct
NaN payloads
2. Python is an object-based system. In addition to their payload, NaN
objects are further distinguished by their identity (infinite in
theory, in practice limited by available memory).
I argu
Nick Coghlan wrote:
I hadn't really thought about it that way before this discussion - it
is the identity checking behaviour of the builtin containers that lets
us sensibly handle cases like sets of NumPy arrays.
Except that it doesn't:
>>> from numpy import array
>>> a1 = array([1,2])
>>> a2
On 4/28/11 6:13 PM, Guido van Rossum wrote:
On Thu, Apr 28, 2011 at 4:04 PM, Nick Coghlan wrote:
On Fri, Apr 29, 2011 at 8:55 AM, Guido van Rossum wrote:
Sorry, we'll have to make an exception for those of course. This will
somewhat complicate the interpretation of well-behaved, because those
On Thu, Apr 28, 2011 at 5:24 PM, Glenn Linderman wrote:
> Would it be reasonable to implement 3 types of containers:
That's something for python-ideas. Occasionally containers that use
custom comparisons come in handy (e.g. case-insensitive dicts).
--
--Guido van Rossum (python.org/~guido)
On 4/28/2011 4:40 PM, Nick Coghlan wrote:
Hmm, true. And things like count() and index() would still be
thoroughly broken for sequences. OK, so scratch that idea - there's
simply no sane way to handle such objects without using an
identity-based container that ignores equality definitions altoget
On Thu, Apr 28, 2011 at 7:47 PM, Guido van Rossum wrote:
> On Thu, Apr 28, 2011 at 4:40 PM, Nick Coghlan wrote:
>> Pondering the NaN problem further, I think we can relatively easily
>> argue that reflexive behaviour at the object level fits within the
>> scope of IEEE754.
>
> Now we're talking.
On Thu, Apr 28, 2011 at 4:40 PM, Nick Coghlan wrote:
> Pondering the NaN problem further, I think we can relatively easily
> argue that reflexive behaviour at the object level fits within the
> scope of IEEE754.
Now we're talking. :-)
> 1. IEEE754 is a value-based system, with a finite number of
On Fri, Apr 29, 2011 at 9:13 AM, Guido van Rossum wrote:
>> I hadn't really thought about it that way before this discussion - it
>> is the identity checking behaviour of the builtin containers that lets
>> us sensibly handle cases like sets of NumPy arrays.
>
> But do they? For non-empty arrays,
On Thu, Apr 28, 2011 at 4:04 PM, Nick Coghlan wrote:
> On Fri, Apr 29, 2011 at 8:55 AM, Guido van Rossum wrote:
>> Sorry, we'll have to make an exception for those of course. This will
>> somewhat complicate the interpretation of well-behaved, because those
>> are *not* well-behaved as far as con
On Fri, Apr 29, 2011 at 2:55 AM, Guido van Rossum wrote:
> Raymond strongly believes that containers must be allowed to use the
> modified definition, I believe purely for performance reasons.
> (Without this rule, a list or tuple could not even cut short being
> compared to *itself*.) It seems yo
On Fri, Apr 29, 2011 at 8:55 AM, Guido van Rossum wrote:
> Sorry, we'll have to make an exception for those of course. This will
> somewhat complicate the interpretation of well-behaved, because those
> are *not* well-behaved as far as containers go (both dict key lookup
> and list membership are
On Thu, Apr 28, 2011 at 3:22 PM, Robert Kern wrote:
> On 4/28/11 11:55 AM, Guido van Rossum wrote:
>
>> On Thu, Apr 28, 2011 at 8:52 AM, Robert Kern
>> wrote:
>>>
>>> Smaller, certainly. But now it's a trilemma. :-)
>>>
>>> 1. Have just np.float64 and np.complex128 scalars follow the Python float
On 4/28/11 11:55 AM, Guido van Rossum wrote:
On Thu, Apr 28, 2011 at 8:52 AM, Robert Kern wrote:
Smaller, certainly. But now it's a trilemma. :-)
1. Have just np.float64 and np.complex128 scalars follow the Python float
semantics since they subclass Python float and complex, respectively.
2.
On Thu, Apr 28, 2011 at 1:48 PM, Terry Reedy wrote:
> On 4/28/2011 12:55 PM, Guido van Rossum wrote:
>
>> *If* my proposal gets accepted, there will be a blanket rule that no
>> matter how exotic an type's __eq__ is defined, self.__eq__(self)
>> (i.e., __eq__ called with the same *object* argument
On 4/28/2011 12:55 PM, Guido van Rossum wrote:
*If* my proposal gets accepted, there will be a blanket rule that no
matter how exotic an type's __eq__ is defined, self.__eq__(self)
(i.e., __eq__ called with the same *object* argument) must return True
if the type's __eq__ is to be considered wel
On 4/28/2011 6:11 AM, Nick Coghlan wrote:
On Thu, Apr 28, 2011 at 6:30 PM, Alexander Belopolsky
wrote:
On Thu, Apr 28, 2011 at 3:57 AM, Nick Coghlan wrote:
..
It is an interesting question of what "sane invariants" are. Why you
consider the invariants that you listed essential while say
if
On 28/04/2011 18:26, Steven D'Aprano wrote:
Rob Cliffe wrote:
To me the idea of non-reflexive equality (an object not being equal
to itself) is abhorrent. Nothing is more likely to put off new
Python users if they happen to run into it.
I believe that's a gross exaggeration. In any case, th
On Thu, Apr 28, 2011 at 1:25 PM, Steven D'Aprano wrote:
..
> But it's perfectly fine to do this:
>
sum(a)
> nan
>
This use case reminded me Kahan's
"""
Were there no way to get rid of NaNs, they would be as useless as
Indefinites on CRAYs; as soon as one were encountered, computation
would
Steven D'Aprano wrote:
I know thousands of words have been spilled on this, including many by
myself, but I really believe this discussion is mostly bike-shedding.
Hmmm... on reflection, I think I may have been a bit unfair. In
particular, I don't mean any slight on any of the people who hav
Guido van Rossum wrote:
*If* my proposal gets accepted, there will be a blanket rule that no
matter how exotic an type's __eq__ is defined, self.__eq__(self)
(i.e., __eq__ called with the same *object* argument) must return True
if the type's __eq__ is to be considered well-behaved; and Python
c
Rob Cliffe wrote:
To me the idea of non-reflexive equality (an object not being equal to
itself) is abhorrent. Nothing is more likely to put off new Python
users if they happen to run into it.
I believe that's a gross exaggeration. In any case, that's just your
opinion, and Python is hardly
Alexander Belopolsky wrote:
With the status quo in Python, it may only make sense to store NaNs in
array.array, but not in a list.
That's a bit extreme. It only gets you into trouble if you reason like this:
>>> a = b = [1, 2, 3, float('nan')]
>>> if a == b:
... for x,y in zip(a,b):
...
[This is a mega-reply, combining responses to several messages in this
thread. I may be repeating myself a bit, but I think I am being
consistent. :-)]
On Wed, Apr 27, 2011 at 10:12 PM, Nick Coghlan wrote:
> On Thu, Apr 28, 2011 at 2:54 PM, Guido van Rossum wrote:
>>> Well, I didn't say that. I
On 4/28/11 12:37 AM, Alexander Belopolsky wrote:
On Thu, Apr 28, 2011 at 12:33 AM, Robert Kern wrote:
On 2011-04-27 23:24 , Guido van Rossum wrote:
..
So do new masks get created when the outcome of an elementwise
operation is a NaN?
No.
Yes.
from MA import array
print array([0])/array(
On 4/27/11 11:54 PM, Guido van Rossum wrote:
On Wed, Apr 27, 2011 at 9:25 PM, Robert Kern wrote:
On 2011-04-27 23:01 , Guido van Rossum wrote:
And I wouldn't want to change that. It sounds like NumPy wouldn't be
much affected if we were to change this (which I'm not saying we
would).
Well, I
I am not a specialist in this area (although I call myself a
mathematician). But they say that sometimes the outsider sees most of
the game, or more likely that sometimes the idiot's point of view is useful.
To me the idea of non-reflexive equality (an object not being equal to
itself) is abh
On Thu, Apr 28, 2011 at 7:10 PM, Greg Ewing wrote:
> Nick Coghlan wrote:
>
>> Because this assertion is an assertion about the behaviour of
>> comparisons that violates IEEE754, while the assertions I list are all
>> assertions about the behaviour of containers that can be made true
>> *regardless
On Thu, Apr 28, 2011 at 6:30 PM, Alexander Belopolsky
wrote:
> On Thu, Apr 28, 2011 at 3:57 AM, Nick Coghlan wrote:
> ..
>>> It is an interesting question of what "sane invariants" are. Why you
>>> consider the invariants that you listed essential while say
>>>
>>> if c1 == c2:
>>> assert all(
Nick Coghlan wrote:
Because this assertion is an assertion about the behaviour of
comparisons that violates IEEE754, while the assertions I list are all
assertions about the behaviour of containers that can be made true
*regardless* of IEEE754 by checking identity explicitly.
Aren't you making
On 4/28/2011 12:32 AM, Nick Coghlan wrote:
On Thu, Apr 28, 2011 at 5:27 PM, Glenn Linderman wrote:
Without having read the original articulations by Raymond or any discussions
of the pros and cons,
In my first post to this thread, I pointed out the bug tracker item
(http://bugs.python.org/iss
On Thu, Apr 28, 2011 at 3:57 AM, Nick Coghlan wrote:
..
>> It is an interesting question of what "sane invariants" are. Why you
>> consider the invariants that you listed essential while say
>>
>> if c1 == c2:
>> assert all(x == y for x,y in zip(c1, c2))
>>
>> optional?
>
> Because this asserti
On 04/28/2011 04:31 AM, Stephen J. Turnbull wrote:
Are you saying you would expect that
nan = float('nan')
a = [1, ..., 499, nan, 501, ..., 999]# meta-ellipsis, not Ellipsis
a == a
False
??
I would expect l1 == l2, where l1 and l2 are both lists, to be
semantically equivalent to len
On Thu, Apr 28, 2011 at 5:30 PM, Alexander Belopolsky
wrote:
> On Thu, Apr 28, 2011 at 2:54 AM, Nick Coghlan wrote:
> ..
>> No, as Raymond has articulated a number of times over the years, it's
>> a property of the equivalence relation that is needed in order to
>> present sane invariants to user
On Thu, Apr 28, 2011 at 5:27 PM, Glenn Linderman wrote:
> Without having read the original articulations by Raymond or any discussions
> of the pros and cons,
In my first post to this thread, I pointed out the bug tracker item
(http://bugs.python.org/issue4296) that included the discussion of
re
On Thu, Apr 28, 2011 at 2:54 AM, Nick Coghlan wrote:
..
> No, as Raymond has articulated a number of times over the years, it's
> a property of the equivalence relation that is needed in order to
> present sane invariants to users of the container. I included in the
> bug report the critical invar
On 4/27/2011 11:54 PM, Nick Coghlan wrote:
On Thu, Apr 28, 2011 at 4:20 PM, Glenn Linderman wrote:
In that bug, Nick, you mention that reflexive equality is something that
container classes rely on in their implementation. Such reliance seems to
me to be a bug, or an inappropriate optimization
On Thu, Apr 28, 2011 at 4:20 PM, Glenn Linderman wrote:
> In that bug, Nick, you mention that reflexive equality is something that
> container classes rely on in their implementation. Such reliance seems to
> me to be a bug, or an inappropriate optimization, rather than a necessity.
> I realize t
On Thu, Apr 28, 2011 at 2:20 AM, Glenn Linderman wrote:
..
> In that bug, Nick, you mention that reflexive equality is something that
> container classes rely on in their implementation. Such reliance seems to
> me to be a bug, or an inappropriate optimization, ..
An alternative interpretation w
On 4/27/2011 8:43 PM, Nick Coghlan wrote:
On Thu, Apr 28, 2011 at 12:42 PM, Stephen J. Turnbull
wrote:
Mark Dickinson writes:
> Declaring that 'nan == nan' should be True seems attractive in
> theory,
No, it's intuitively attractive, but that's because humans like nice
continuous behav
On Thu, Apr 28, 2011 at 1:40 AM, Greg Ewing wrote:
..
> The Pythonic thing to do (in the Python 3 world at least) would
> be to regard NaNs as non-comparable and raise an exception.
As I mentioned in a previous post, I agree in case of <, <=, >, or >=
comparisons, but == and != are a harder cas
Guido van Rossum wrote:
Currently NaN is not violating
any language rules -- it is just violating users' intuition, in a much
worse way than Inf does.
If it's to be an official language non-rule (by which I mean
that types are officially allowed to compare non-reflexively)
then any code assumin
Stephen J. Turnbull wrote:
So what does the 1/0 that
occurs in [1/x for x in range(-5, 6)] mean? In what sense is it
"equal to itself"? How can something which is not a number be
compared for numerical equality?
I would say it *can't* be compared for *numerical* equality.
It might make sense
On Thu, Apr 28, 2011 at 12:24 AM, Guido van Rossum wrote:
> So do new masks get created when the outcome of an elementwise
> operation is a NaN? Because that's the only reason why one should have
> NaNs in one's data in the first place.
If this is the case, why Python almost never produces NaNs
Steven D'Aprano wrote:
You can compare NANs, and the result of the
comparisons are perfectly well defined by either True or False.
But it's *arbitrarily* defined, and it's far from clear that
the definition chosen is useful in any way.
If you perform a computation and get a NaN as the result,
On Thu, Apr 28, 2011 at 12:33 AM, Robert Kern wrote:
> On 2011-04-27 23:24 , Guido van Rossum wrote:
..
>> So do new masks get created when the outcome of an elementwise
>> operation is a NaN?
>
> No.
Yes.
>>> from MA import array
>>> print array([0])/array([0])
[-- ]
(I don't have numpy on thi
On Wed, Apr 27, 2011 at 11:14 PM, Guido van Rossum wrote:
..
>> ISTM, the current state of affairs is reasonable.
>
> Hardly; when I picked the NaN behavior I knew the IEEE std prescribed
> it but had never seen any code that used this.
>
Same here. The only code I've seen that depended on this
On Thu, Apr 28, 2011 at 2:54 PM, Guido van Rossum wrote:
>> Well, I didn't say that. If Python changed its behavior for (float('nan') ==
>> float('nan')), we'd have to seriously consider some changes.
>
> Ah, but I'm not proposing anything of the sort! float('nan') returns a
> new object each time
On 4/27/2011 8:06 PM, Stephen J. Turnbull wrote:
Glenn Linderman writes:
> On 4/27/2011 6:11 PM, Ethan Furman wrote:
> > Totally out of my depth, but what if the a NaN object was allowed to
> > compare equal to itself, but different NaN objects still compared
> > unequal? If NaN
On Wed, Apr 27, 2011 at 9:33 PM, Robert Kern wrote:
> [1] Okay, that's a lie. I'm sure that persistent minority would *love* to
> have NaN == NaN, because that would make their (ab)use of NaNs easier to
> work with.
Too bad, because that won't change. :-) I agree that this is abuse of
NaNs and sh
On Wed, Apr 27, 2011 at 9:25 PM, Robert Kern wrote:
> On 2011-04-27 23:01 , Guido van Rossum wrote:
>> And I wouldn't want to change that. It sounds like NumPy wouldn't be
>> much affected if we were to change this (which I'm not saying we
>> would).
>
> Well, I didn't say that. If Python changed
On 4/27/2011 7:31 PM, Stephen J. Turnbull wrote:
Glenn Linderman writes:
> I would not, however expect the original case that was described:
> >>> nan = float('nan')
> >>> nan == nan
> False
> >>> [nan] == [nan]
> True # also True in tuples, dicts, etc.
On Thu, Apr 28, 2011 at 2:07 PM, Guido van Rossum wrote:
> I'm not sure about array.array -- it doesn't hold objects so I don't
> think there's anything to enforce. It seems to behave the same way as
> NumPy arrays when they don't contain objects.
Yep, after reading Robert's post I realised the p
On 2011-04-27 23:24 , Guido van Rossum wrote:
On Wed, Apr 27, 2011 at 9:15 PM, Alexander Belopolsky
wrote:
On Wed, Apr 27, 2011 at 2:48 PM, Robert Kern wrote:
..
I suspect most of us would oppose changing it on general
backwards-compatibility grounds rather than actually *liking* the current
On 2011-04-27 23:01 , Guido van Rossum wrote:
On Wed, Apr 27, 2011 at 8:42 PM, Robert Kern wrote:
But for dtype=float arrays (which contain C doubles, not Python objects) we
use C semantics. Literally, we use whatever C's == operator gives us for the
two double values. Since there is no conce
On Wed, Apr 27, 2011 at 9:15 PM, Alexander Belopolsky
wrote:
> On Wed, Apr 27, 2011 at 2:48 PM, Robert Kern 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 wit
On Wed, Apr 27, 2011 at 2:48 PM, Robert Kern 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 tha
On Wed, Apr 27, 2011 at 8:43 PM, Nick Coghlan wrote:
> (I also noted that array.array is like collections.Sequence in failing
> to enforce the container invariants in the presence of NaN values)
Regardless of whether we go any further it would indeed be good to be
explicit about the rules in the
On Wed, Apr 27, 2011 at 8:42 PM, Robert Kern wrote:
> On 2011-04-27 22:16 , Guido van Rossum wrote:
>> So does NumPy also follow Python's behavior about ignoring the NaN
>> special-casing when doing array ops?
>
> By "ignoring the NaN special-casing", do you mean that identity is checked
> first?
On Thu, Apr 28, 2011 at 12:42 PM, Stephen J. Turnbull
wrote:
> Mark Dickinson writes:
>
> > Declaring that 'nan == nan' should be True seems attractive in
> > theory,
>
> No, it's intuitively attractive, but that's because humans like nice
> continuous behavior. In *theory*, it's true that some
On 2011-04-27 22:16 , Guido van Rossum wrote:
On Wed, Apr 27, 2011 at 11:48 AM, Robert Kern wrote:
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
On Wed, Apr 27, 2011 at 11:48 AM, Robert Kern wrote:
> 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
>> numer
On Wed, Apr 27, 2011 at 9:28 AM, Raymond Hettinger
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.
No doubt there would be some problems; probably mor
Glenn Linderman writes:
> On 4/27/2011 6:11 PM, Ethan Furman wrote:
> > Totally out of my depth, but what if the a NaN object was allowed to
> > compare equal to itself, but different NaN objects still compared
> > unequal? If NaN was a singleton then the current behavior makes more
> > s
Mark Dickinson writes:
> Declaring that 'nan == nan' should be True seems attractive in
> theory,
No, it's intuitively attractive, but that's because humans like nice
continuous behavior. In *theory*, it's true that some singularities
are removable, and the NaN that occurs when evaluating at t
Glenn Linderman writes:
> I would not, however expect the original case that was described:
> >>> nan = float('nan')
> >>> nan == nan
> False
> >>> [nan] == [nan]
> True # also True in tuples, dicts, etc.
Are you saying you would expect that
>>> nan = float('nan')
>>> a
On 4/27/2011 6:15 PM, Glenn Linderman wrote:
I think it is perfectly reasonable that containers containing items
with non-reflexive equality should sometimes have non-reflexive
equality also (depends on the placement of the item in the container,
and the values of other items, whether the non-r
On 4/27/2011 6:11 PM, Ethan Furman wrote:
Mark Dickinson wrote:
On Wed, Apr 27, 2011 at 10: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.
That one surpri
On 4/27/2011 5:05 PM, Steven D'Aprano wrote:
(2) slow containers down by guaranteeing that they will use __eq__;
(but how much will it actually hurt performance for real-world cases?
and this will have the side-effect that non-reflexivity will propagate
to containers)
I think it is perfect
Mark Dickinson wrote:
On Wed, Apr 27, 2011 at 10: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.
That one surprises me a bit too: I knew we were using
ide
Greg Ewing wrote:
Guido van Rossum wrote:
Maybe we should just call off the odd NaN comparison behavior?
That's probably as good an idea as anything.
The weirdness of NaNs is supposed to ensure that they
propagate through a computation as a kind of exception
signal. But to make that work pro
Terry Reedy wrote:
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
Guido van Rossum wrote:
Maybe we should just call off the odd NaN comparison behavior?
This doesn't solve the broader problem that *any* type might
deliberately define non-reflexive equality, and therefore people will
still be surprised by
>>> x = SomeObject()
>>> x == x
False
>>> [x] ==
On 4/27/2011 2:04 PM, Mark Dickinson wrote:
On Wed, Apr 27, 2011 at 10: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.
That one surprises me a bit too: I k
Guido van Rossum wrote:
Maybe we should just call off the odd NaN comparison behavior?
That's probably as good an idea as anything.
The weirdness of NaNs is supposed to ensure that they
propagate through a computation as a kind of exception
signal. But to make that work properly, comparing tw
On 4/27/2011 2:15 PM, Mark Dickinson wrote:
On Wed, Apr 27, 2011 at 7: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,
On Wed, Apr 27, 2011 at 7: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. The
> IEEE 754
On Wed, Apr 27, 2011 at 10: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.
That one surprises me a bit too: I knew we were using
identity-th
On 4/27/2011 11:31 AM, Nick Coghlan wrote:
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"
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
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
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
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/
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
On Wed, Apr 27, 2011 at 12:28 PM, Raymond Hettinger
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 reasonabl
On Wed, 27 Apr 2011, Antoine Pitrou wrote:
Isaac Morland 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 Belopo
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 consum
On Wed, 27 Apr 2011 12:05:12 -0400 (EDT)
Isaac Morland 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 a
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):
On Wed, Apr 27, 2011 at 12:05 PM, Isaac Morland 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 o
On Wed, Apr 27, 2011 at 11:31 AM, Nick Coghlan 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
te
On Thu, Apr 28, 2011 at 1:43 AM, Alexander Belopolsky
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()
On Wed, Apr 27, 2011 at 10:53 AM, Guido van Rossum 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-reflexiv
On Thu, Apr 28, 2011 at 12:53 AM, Guido van Rossum 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 se
On Wed, Apr 27, 2011 at 7:39 AM, Raymond Hettinger
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.
>
> Woul
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 c
2011/4/27 Łukasz Langa :
> # 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 whe
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
>
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
99 matches
Mail list logo
