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
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
On Thu, Apr 28, 2011 at 1:40 AM, Greg Ewing greg.ew...@canterbury.ac.nz 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 ==
On 4/27/2011 8:43 PM, Nick Coghlan wrote:
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
On Thu, Apr 28, 2011 at 2:20 AM, Glenn Linderman v+pyt...@g.nevcal.com 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
On Thu, Apr 28, 2011 at 4:20 PM, Glenn Linderman v+pyt...@g.nevcal.com 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
On 4/27/2011 11:54 PM, Nick Coghlan wrote:
On Thu, Apr 28, 2011 at 4:20 PM, Glenn Lindermanv+pyt...@g.nevcal.com 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
On Thu, Apr 28, 2011 at 2:54 AM, Nick Coghlan ncogh...@gmail.com 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
On Thu, Apr 28, 2011 at 5:27 PM, Glenn Linderman v+pyt...@g.nevcal.com 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
On Thu, Apr 28, 2011 at 5:30 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Thu, Apr 28, 2011 at 2:54 AM, Nick Coghlan ncogh...@gmail.com 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
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
On Thu, Apr 28, 2011 at 3:57 AM, Nick Coghlan ncogh...@gmail.com 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
On 4/28/2011 12:32 AM, Nick Coghlan wrote:
On Thu, Apr 28, 2011 at 5:27 PM, Glenn Lindermanv+pyt...@g.nevcal.com 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
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
On Thu, Apr 28, 2011 at 6:30 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Thu, Apr 28, 2011 at 3:57 AM, Nick Coghlan ncogh...@gmail.com wrote:
..
It is an interesting question of what sane invariants are. Why you
consider the invariants that you listed essential while say
On Thu, Apr 28, 2011 at 7:10 PM, Greg Ewing greg.ew...@canterbury.ac.nz 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
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
On 4/27/11 11:54 PM, Guido van Rossum wrote:
On Wed, Apr 27, 2011 at 9:25 PM, Robert Kernrobert.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
On 4/28/11 12:37 AM, Alexander Belopolsky wrote:
On Thu, Apr 28, 2011 at 12:33 AM, Robert Kernrobert.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
[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 ncogh...@gmail.com wrote:
On Thu, Apr 28, 2011 at 2:54 PM, Guido van Rossum gu...@python.org
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):
...
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
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
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
On Thu, Apr 28, 2011 at 1:25 PM, Steven D'Aprano st...@pearwood.info 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,
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,
On 4/28/2011 6:11 AM, Nick Coghlan wrote:
On Thu, Apr 28, 2011 at 6:30 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Thu, Apr 28, 2011 at 3:57 AM, Nick Coghlanncogh...@gmail.com wrote:
..
It is an interesting question of what sane invariants are. Why you
consider the
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
On Thu, Apr 28, 2011 at 1:48 PM, Terry Reedy tjre...@udel.edu 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*
On 4/28/11 11:55 AM, Guido van Rossum wrote:
On Thu, Apr 28, 2011 at 8:52 AM, Robert Kernrobert.k...@gmail.com 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
On Thu, Apr 28, 2011 at 3:22 PM, Robert Kern robert.k...@gmail.com wrote:
On 4/28/11 11:55 AM, Guido van Rossum wrote:
On Thu, Apr 28, 2011 at 8:52 AM, Robert Kernrobert.k...@gmail.com
wrote:
Smaller, certainly. But now it's a trilemma. :-)
1. Have just np.float64 and np.complex128
On Fri, Apr 29, 2011 at 8:55 AM, Guido van Rossum gu...@python.org 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
On Fri, Apr 29, 2011 at 2:55 AM, Guido van Rossum gu...@python.org 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
On Thu, Apr 28, 2011 at 4:04 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Fri, Apr 29, 2011 at 8:55 AM, Guido van Rossum gu...@python.org 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
On Fri, Apr 29, 2011 at 9:13 AM, Guido van Rossum gu...@python.org 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
On Thu, Apr 28, 2011 at 4:40 PM, Nick Coghlan ncogh...@gmail.com 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
On Thu, Apr 28, 2011 at 7:47 PM, Guido van Rossum gu...@python.org wrote:
On Thu, Apr 28, 2011 at 4:40 PM, Nick Coghlan ncogh...@gmail.com 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
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
On Thu, Apr 28, 2011 at 5:24 PM, Glenn Linderman v+pyt...@g.nevcal.com 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
On 4/28/11 6:13 PM, Guido van Rossum wrote:
On Thu, Apr 28, 2011 at 4:04 PM, Nick Coghlanncogh...@gmail.com wrote:
On Fri, Apr 29, 2011 at 8:55 AM, Guido van Rossumgu...@python.org wrote:
Sorry, we'll have to make an exception for those of course. This will
somewhat complicate the
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 =
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
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.shiver/
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
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
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
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
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
98 matches
Mail list logo
