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
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
2011/4/27 Łukasz Langa luk...@langa.pl:
# 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
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
On Wed, Apr 27, 2011 at 7:39 AM, Raymond Hettinger
raymond.hettin...@gmail.com 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.
On Thu, Apr 28, 2011 at 12:53 AM, Guido van Rossum gu...@python.org 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
On Wed, Apr 27, 2011 at 10:53 AM, Guido van Rossum gu...@python.org 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
On Thu, Apr 28, 2011 at 1:43 AM, Alexander Belopolsky
alexander.belopol...@gmail.com 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
On Wed, Apr 27, 2011 at 11:31 AM, Nick Coghlan ncogh...@gmail.com 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
On Wed, Apr 27, 2011 at 12:05 PM, Isaac Morland ijmor...@uwaterloo.ca 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
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, 27 Apr 2011 12:05:12 -0400 (EDT)
Isaac Morland ijmor...@uwaterloo.ca 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
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
On Wed, 27 Apr 2011, Antoine Pitrou wrote:
Isaac Morland ijmor...@uwaterloo.ca 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
Ezio Melotti wrote:
On 26/04/2011 22.32, Ethan Furman wrote:
Okay, I finally found a little time and got roundup installed and
operating.
Only major complaint at this point is that the issue messages are
presented in top-post format (argh).
Does anyone know off the top of one's head what
On Wed, Apr 27, 2011 at 12:28 PM, Raymond Hettinger
raymond.hettin...@gmail.com 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
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 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
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/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
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/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 Wed, Apr 27, 2011 at 10:37 AM, Hrvoje Niksic hrvoje.nik...@avl.com 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
On Wed, Apr 27, 2011 at 7:41 PM, Glenn Linderman v+pyt...@g.nevcal.com 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
I've been recently trying to improve the test coverage for the logging package,
and have got to a not unreasonable point:
logging/__init__.py 99% (96%)
logging/config.py 89% (85%)
logging/handlers.py 60% (54%)
where the figures in parentheses include branch coverage measurements.
I'm at the
On 4/27/2011 2:15 PM, Mark Dickinson wrote:
On Wed, Apr 27, 2011 at 7:41 PM, Glenn Lindermanv+pyt...@g.nevcal.com 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
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
On 4/27/2011 2:04 PM, Mark Dickinson wrote:
On Wed, Apr 27, 2011 at 10:37 AM, Hrvoje Niksichrvoje.nik...@avl.com 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
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] == [x]
True
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
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
Would it be a problem to make them available a no-ops?
On 4/26/11, victor.stinner python-check...@python.org wrote:
http://hg.python.org/cpython/rev/75503c26a17f
changeset: 69584:75503c26a17f
user:Victor Stinner victor.stin...@haypocalc.com
date:Tue Apr 26 23:34:58 2011
Mark Dickinson wrote:
On Wed, Apr 27, 2011 at 10:37 AM, Hrvoje Niksic hrvoje.nik...@avl.com 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
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
On 4/27/2011 6:11 PM, Ethan Furman wrote:
Mark Dickinson wrote:
On Wed, Apr 27, 2011 at 10:37 AM, Hrvoje Niksic
hrvoje.nik...@avl.com wrote:
The other day I was surprised to learn this:
nan = float('nan')
nan == nan
False
[nan] == [nan]
True # also True in tuples, dicts,
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
On Thu, Apr 28, 2011 at 7:23 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
I've been recently trying to improve the test coverage for the logging
package,
and have got to a not unreasonable point:
logging/__init__.py 99% (96%)
logging/config.py 89% (85%)
logging/handlers.py 60% (54%)
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 = [1, ..., 499,
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
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
sense,
On Wed, Apr 27, 2011 at 9:28 AM, Raymond Hettinger
raymond.hettin...@gmail.com 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
On Wed, Apr 27, 2011 at 11:48 AM, Robert Kern robert.k...@gmail.com 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
On 2011-04-27 22:16 , Guido van Rossum wrote:
On Wed, Apr 27, 2011 at 11:48 AM, Robert Kernrobert.k...@gmail.com 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
On Thu, Apr 28, 2011 at 12:42 PM, Stephen J. Turnbull
step...@xemacs.org 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
On Wed, Apr 27, 2011 at 8:42 PM, Robert Kern robert.k...@gmail.com 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
On Wed, Apr 27, 2011 at 8:43 PM, Nick Coghlan ncogh...@gmail.com 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
On Wed, Apr 27, 2011 at 2:48 PM, Robert Kern robert.k...@gmail.com 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
On Wed, Apr 27, 2011 at 9:15 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Wed, Apr 27, 2011 at 2:48 PM, Robert Kern robert.k...@gmail.com wrote:
..
I suspect most of us would oppose changing it on general
backwards-compatibility grounds rather than actually *liking* the
On 2011-04-27 23:01 , Guido van Rossum wrote:
On Wed, Apr 27, 2011 at 8:42 PM, Robert Kernrobert.k...@gmail.com 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.
On 2011-04-27 23:24 , Guido van Rossum wrote:
On Wed, Apr 27, 2011 at 9:15 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Wed, Apr 27, 2011 at 2:48 PM, Robert Kernrobert.k...@gmail.com wrote:
..
I suspect most of us would oppose changing it on general
On Thu, Apr 28, 2011 at 2:07 PM, Guido van Rossum gu...@python.org 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
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.
Are you saying
On Wed, Apr 27, 2011 at 9:25 PM, Robert Kern robert.k...@gmail.com 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
On Wed, Apr 27, 2011 at 9:33 PM, Robert Kern robert.k...@gmail.com 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
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 was a
On Thu, Apr 28, 2011 at 2:54 PM, Guido van Rossum gu...@python.org 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
On Wed, Apr 27, 2011 at 11:14 PM, Guido van Rossum gu...@python.org 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
On Thu, Apr 28, 2011 at 12:33 AM, Robert Kern robert.k...@gmail.com 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
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:24 AM, Guido van Rossum gu...@python.org 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
60 matches
Mail list logo
