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 Thu, Apr 28, 2011 at 7:23 AM, Vinay Sajip 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%)
>
> where the figures
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
Would it be a problem to make them available a no-ops?
On 4/26/11, victor.stinner wrote:
> http://hg.python.org/cpython/rev/75503c26a17f
> changeset: 69584:75503c26a17f
> user:Victor Stinner
> date:Tue Apr 26 23:34:58 2011 +0200
> summary:
> PyGILState_Ensure(), PyGILState_Re
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,
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 poin
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
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 to
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
66 matches
Mail list logo
