On Sun, 29 May 2011 18:44:08 +0100, MRAB wrote:
Would there be any advantage to making NaN a singleton?
Absolutely not. That would be a step backwards.
NANs can carry payload (a code indicating what sort of NAN it represents
-- log(-1) and 1/INF are not the same). So although Python currently
On Sun, 29 May 2011 20:05:07 +0200, Christian Heimes wrote:
Am 29.05.2011 19:44, schrieb MRAB:
Would there be any advantage to making NaN a singleton? I'm thinking
that it could make checking for it cheaper in the implementation of
sets and dicts. Or making NaN unhashable?
It can't
On Sun, 29 May 2011 10:29:28 +, Steven D'Aprano wrote:
The correct answer to nan == nan is to raise an exception, because
you have asked a question for which the answer is nether True nor False.
Wrong.
That's overstating it. There's a good argument to be made for raising
On Sun, 29 May 2011 22:19:49 +0100, Nobody wrote:
On Sun, 29 May 2011 10:29:28 +, Steven D'Aprano wrote:
The correct answer to nan == nan is to raise an exception,
because
you have asked a question for which the answer is nether True nor
False.
Wrong.
That's overstating
Incidentally, note:
$ python
...
nan = float(nan)
nan
nan
nan is nan
True
nan == nan
False
In article 4de1e3e7$0$2195$742ec...@news.sonic.net
John Nagle na...@animats.com wrote:
The correct answer to nan == nan is to raise an exception, because
you
On Sunday, May 29, 2011 4:31:19 PM UTC-7, Steven D#39;Aprano wrote:
On Sun, 29 May 2011 22:19:49 +0100, Nobody wrote:
On Sun, 29 May 2011 10:29:28 +, Steven D'Aprano wrote:
The correct answer to nan == nan is to raise an exception,
because
you have asked a question
for NaN objects, so the buggy behavior is
observed.
Python makes this assumption in lots of common situations (apparently in an
implementation-defined manner):
nan = float(nan)
nan == nan
False
[nan] == [nan]
True
Therefore, I'd recommend never to rely on NaN != NaN except in casual throwaway
On Mon, May 30, 2011 at 10:55 AM, Carl Banks pavlovevide...@gmail.com wrote:
If exceptions had commonly existed in that environment there's no chance they
would have chosen that behavior; comparison against NaN (or any operation
with NaN) would have signaled a floating point exception
On Sunday, May 29, 2011 6:14:58 PM UTC-7, Chris Angelico wrote:
On Mon, May 30, 2011 at 10:55 AM, Carl Banks
wrote:
If exceptions had commonly existed in that environment there's no chance
they would have chosen that behavior; comparison against NaN (or any
operation with NaN) would
On Mon, May 30, 2011 at 12:17 PM, Carl Banks pavlovevide...@gmail.com wrote:
If I were designing a new floating-point standard for hardware, I would
consider getting rid of NaN. However, with the floating point standard that
exists, that almost all floating point hardware mostly conforms
On May 30, 7:53 am, Chris Angelico ros...@gmail.com wrote:
On Mon, May 30, 2011 at 12:17 PM, Carl Banks pavlovevide...@gmail.com wrote:
If I were designing a new floating-point standard for hardware, I would
consider getting rid of NaN. However, with the floating point standard
exceptions. That's as far back as 1966. I'd be shocked if earlier
Fortrans didn't also have support for traps.
http://www.bitsavers.org/pdf/ibm/7040/C28-6806-1_7040ftnMathSubrs.pdf
The IEEE standard specifies that you should be able to control whether a
calculation traps or returns a NAN. That's
On Mon, 30 May 2011 11:14:58 +1000, Chris Angelico wrote:
So, apart from float(nan), are there actually any places where real
production code has to handle NaN? I was unable to get a nan by any of
the above methods, except for operations involving inf; for instance,
float(inf)-float(inf
precision (or could use a REXX-style numeric digits 100
command to change the internal rounding, and automatically update
sys.float_info). And in that case, there would be no NaN value.
NANs aren't for overflow, that's what INFs are for. Even if you had
infinite precision floats and could get rid
On 5/29/2011 9:15 PM, Steven D'Aprano wrote:
On Mon, 30 May 2011 11:14:58 +1000, Chris Angelico wrote:
So, apart from float(nan), are there actually any places where real
production code has to handle NaN?
Yes. I used to write dynamic simulation engines. There were
situations
In article 4de31635$0$29990$c3e8da3$54964...@news.astraweb.com,
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote:
That's also completely wrong. The correct way to test for a NAN is with
the IEEE-mandated function isnan(). The NAN != NAN trick is exactly that,
a trick, used
On May 28, 4:41 pm, MRAB pyt...@mrabarnett.plus.com wrote:
Here's a curiosity. float(nan) can occur multiple times in a set or as
a key in a dict:
Which is by design.
NaNs intentionally have multiple possible instances (some
implementations even include distinct payload values).
Sets
In article irv6ev01...@news1.newsguy.com I wrote, in part:
_inf = float(inf)
def isinf(x):
return x == _inf
del _inf
Oops, take out the del, or otherwise fix the obvious problem,
e.g., perhaps:
def isinf(x):
return x == isinf._inf
isinf._inf = float(inf)
(Of
Here's a curiosity. float(nan) can occur multiple times in a set or as
a key in a dict:
{float(nan), float(nan)}
{nan, nan}
except that sometimes it can't:
nan = float(nan)
{nan, nan}
{nan}
--
http://mail.python.org/mailman/listinfo/python-list
MRAB wrote:
Here's a curiosity. float(nan) can occur multiple times in a set or as
a key in a dict:
{float(nan), float(nan)}
{nan, nan}
except that sometimes it can't:
nan = float(nan)
{nan, nan}
{nan}
It's fundamentally because NaN is not equal to itself, by design.
Dictionaries
On Sun, 2011-05-29 at 00:41 +0100, MRAB wrote:
Here's a curiosity. float(nan) can occur multiple times in a set or as
a key in a dict:
{float(nan), float(nan)}
{nan, nan}
These two nans are not equal (they are two different nans)
except that sometimes it can't:
nan = float(nan
On 29 May 2011 10:16, Erik Max Francis m...@alcyone.com wrote:
MRAB wrote:
Here's a curiosity. float(nan) can occur multiple times in a set or as a
key in a dict:
{float(nan), float(nan)}
{nan, nan}
except that sometimes it can't:
nan = float(nan)
{nan, nan}
{nan}
It's
On Sun, 29 May 2011 00:41:16 +0100, MRAB wrote:
Here's a curiosity. float(nan) can occur multiple times in a set or as
a key in a dict:
{float(nan), float(nan)}
{nan, nan}
That's an implementation detail. Python is free to reuse the same object
when you create an immutable object twice
On Sun, May 29, 2011 at 10:28 AM, Albert Hopkins mar...@letterboxes.org wrote:
This is the same nan, so it is equal to itself.
Actually, they're not. But it's possible the dictionary uses an 'is'
check to save computation, and if one thing 'is' another, it is
assumed to equal it. That's true
Albert Hopkins wrote:
On Sun, 2011-05-29 at 00:41 +0100, MRAB wrote:
1.0 == 1.0
True
float(nan) == float(nan)
False
I can't cite this in a spec, but it makes sense (to me) that two things
which are nan are not necessarily the same nan.
It's part of the IEEE standard.
--
Erik Max Francis
MRAB wrote:
float(nan) can occur multiple times in a set or as
a key in a dict:
{float(nan), float(nan)}
{nan, nan}
except that sometimes it can't:
nan = float(nan)
{nan, nan}
{nan}
NaNs are weird. They're not equal to themselves:
Python 2.7 (r27:82500, Oct 15 2010, 21:14:33)
[GCC
On 2011-05-29, Albert Hopkins mar...@letterboxes.org wrote:
On Sun, 2011-05-29 at 00:41 +0100, MRAB wrote:
Here's a curiosity. float(nan) can occur multiple times in a set or as
a key in a dict:
{float(nan), float(nan)}
{nan, nan}
These two nans are not equal (they are two different
Mark Dickinson dicki...@gmail.com added the comment:
Table 5.2 referenced above lists 10 operations, four of which (, ,
=, and =) are given spellings that are identical to the spellings of
Python comparison operators.
Yep, those are included amongst the various ad-hoc and traditional names
Mark Dickinson dicki...@gmail.com added the comment:
Prof. Kahan states that nan x must signal.
Would that be the sentence that starts In the syntax of C ... ?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11986
Mark Dickinson dicki...@gmail.com added the comment:
keep naive implementation of builtin max()
Agreed.
provide symmetric float.max such that nan.max(x) = x.max(nan) = x (nan
result would be a valid but less useful alternative.)
That might be viable (a math module function might also make
comparison operators
signaling. What is the reason to make them quiet for floats other
than backward compatibility? Note that backward compatibility is
likely not to be an issue if we make nan comparisons generate a
warning (possibly even off by default) rather than error
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Sat, May 21, 2011 at 3:22 PM, Mark Dickinson rep...@bugs.python.org wrote:
Mark Dickinson dicki...@gmail.com added the comment:
Prof. Kahan states that nan x must signal.
Would that be the sentence that starts
Mark Dickinson dicki...@gmail.com added the comment:
What is the reason to make them quiet for floats other
than backward compatibility?
For me, none. I'll happily agree that, all other things being equal, it's more
natural (and more consistent with other languages) to have correspond to
Mark Dickinson dicki...@gmail.com added the comment:
On the idea of a warning, I don't really see the point; I find it hard to
imagine it's really going to catch many real errors.
--
___
Python tracker rep...@bugs.python.org
Mark Dickinson dicki...@gmail.com added the comment:
This is just sophistry. If Python was more popular than C at the
time Prof. Kahan wrote this, he would write in the syntax of Python.
I doubt it. C has a standard that explicitly states that must signal on
comparison with NaNs. Python
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Sat, May 21, 2011 at 3:50 PM, Mark Dickinson rep...@bugs.python.org wrote:
..
On the idea of a warning, I don't really see the point; I find it hard to
imagine it's really going to catch many real errors.
My
Mark Dickinson dicki...@gmail.com added the comment:
Hmm, okay. Call me +0 on the warning.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11949
___
Mark Dickinson dicki...@gmail.com added the comment:
and it's dishonest to claim it is.
This language was going too far, and I apologise for it. I think I need one of
those 'wait 5 minutes before allowing you to post' controls.
--
keywords: +gsoc
be implemented very
efficiently because one can simply use float's binary representation
interpreted as an integer for the key.
If we were going to add such a method, it should follow IEEE 754:
nan.max(x) == x.max(n) == x,
but also nan.min(x) == x.min(nan) == x, for finite x. (See section
Changes by Raymond Hettinger raymond.hettin...@gmail.com:
--
assignee: - rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11949
___
___
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Sat, May 14, 2011 at 2:50 PM, Mark Dickinson rep...@bugs.python.org wrote:
..
On the issue itself, I'm -1 on making comparisons with float('nan') raise: I
don't see that there's a real problem here that needs solving
a challenge - review your code that will work differently if
nan ordering was disallowed and report whether that code does the
right thing for all kinds of float (including nan, inf and signed 0).
So far, I have not seen any responses to this.
My own experiment with the Python library itself, have revealed
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
A tracker bug has mangled the following paragraph following the IEEE 754
standard quote in my previous post:
Table 5.2 referenced above lists 10 operations, four of which (, ,
=, and =) are given spellings that are
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
rhettinger Your other tracker item correctly focused on the behavior of
rhettinger float('NaN') itself,
You closed issue11949 as well, so it won't help. I disagree that this issue
would be resolved by resolving
Changes by Raymond Hettinger raymond.hettin...@gmail.com:
--
assignee: - rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11986
___
___
with float('nan') raise: I
don't see that there's a real problem here that needs solving.
Note that the current behaviour does *not* violate IEEE 754, since there's
nothing anywhere in IEEE 754 that says that Python's operation should raise
for comparisons involving NaNs: all that's said
Mark Dickinson dicki...@gmail.com added the comment:
Therefore making , , etc. raise on NaN while keeping the
status quo for != and == would bring Python floats closer to
compliance with IEEE 754.
Not so. Either way, Python would be providing exactly 10 of the 22 required
IEEE 754
Raymond Hettinger raymond.hettin...@gmail.com added the comment:
On the issue itself, I'm -1 on making comparisons
with float('nan') raise: I don't see that there's
a real problem here that needs solving.
Note that the current behaviour does *not* violate IEEE 754, ...
I agree with Mark
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Tue, May 3, 2011 at 12:05 PM, Mark Dickinson rep...@bugs.python.org wrote:
..
I was thinking of something like the rAssertAlmostEqual method in test_cmath.
This one is good. I wonder if it would be appropriate to move
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
There are lots of almost-equality tests in the test-suite already,
between test_math, test_float, test_cmath and test_complex.
Do you need to implement another one here, or can you reuse one
of the existing ones?
I
Mark Dickinson dicki...@gmail.com added the comment:
I was thinking of something like the rAssertAlmostEqual method in test_cmath.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11949
___
New submission from Alexander Belopolsky belopol...@users.sourceforge.net:
nan = float('nan')
min(nan, 5)
nan
min(5, nan)
5
Good arguments can be made in favor of either result, but different value for
min(x, y) depending on the order of arguments can hardly be justified.
In the face
Antoine Pitrou pit...@free.fr added the comment:
Not specific to NaNs:
min({1}, {2})
{1}
min({2}, {1})
{2}
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11986
___
Raymond Hettinger raymond.hettin...@gmail.com added the comment:
Undefined ordering means just that.
--
nosy: +rhettinger
resolution: - invalid
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11986
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Tue, May 3, 2011 at 2:41 PM, Raymond Hettinger
rep...@bugs.python.org wrote:
..
Undefined ordering means just that.
Means what? Compare float behavior to
Decimal('1')
Decimal(1).max(Decimal('nan'))
Decimal('1')
max
Raymond Hettinger raymond.hettin...@gmail.com added the comment:
Alexander, I urge you to take a good deal of care with this tracker item and
not make any changes lightly. Take a look at how other languages have dealt
with the issue.
Also, consider that unorderable may not be the right
Raymond Hettinger raymond.hettin...@gmail.com added the comment:
Also, if you're going to make a change, please consult the scipy/numpy
community. They are the most knowledgeable on the subject and the most
affected by any change.
Given that they have not made any feature requests or bug
Raymond Hettinger raymond.hettin...@gmail.com added the comment:
The report is invalid because min/max make no guarantees about values without a
total ordering.
Your other tracker item correctly focused on the behavior of float('NaN')
itself, rather than on the behavior of everything else
Changes by Mark Dickinson dicki...@gmail.com:
--
nosy: +mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11949
___
___
Mark Dickinson dicki...@gmail.com added the comment:
sqrt(-0.0) to return -0.0. Does anyone know what the relevant standard says?
sqrt(-0.0) should indeed be -0.0, according to IEEE 754.
--
___
Python tracker rep...@bugs.python.org
Mark Dickinson dicki...@gmail.com added the comment:
Alexander,
There are lots of almost-equality tests in the test-suite already, between
test_math, test_float, test_cmath and test_complex. Do you need to implement
another one here, or can you reuse one of the existing ones?
--
Changes by Daniel Urban urban.dani...@gmail.com:
--
nosy: +durban
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11945
___
___
Python-bugs-list
Changes by Daniel Urban urban.dani...@gmail.com:
--
nosy: +durban
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11949
___
___
Python-bugs-list
There's a big discussion going on at python-dev and python-ideas about NaN
(not-a-number, from IEEE 754). I haven't really gotten into any scientific
computing or numeric programming so I have never knowingly dealt with NaN.
However, I have read the discussions and several things are not clear
On Thu, Apr 28, 2011 at 9:21 AM, Eric Snow ericsnowcurren...@gmail.com wrote:
There's a big discussion going on at python-dev and python-ideas about NaN
(not-a-number, from IEEE 754). I haven't really gotten into any scientific
computing or numeric programming so I have never knowingly dealt
On Thu, Apr 28, 2011 at 11:01 AM, Chris Rebert c...@rebertia.com wrote:
On Thu, Apr 28, 2011 at 9:21 AM, Eric Snow ericsnowcurren...@gmail.com
wrote:
There's a big discussion going on at python-dev and python-ideas about
NaN
(not-a-number, from IEEE 754). I haven't really gotten into any
On Thu, 28 Apr 2011 10:01:49 -0700, Chris Rebert wrote:
2. What are the use cases for NaN? Looks like it gets used a lot as a
numeric (float?) object with non-value.
[...]
And it's
used to represent missing numeric data values, sort of like a
numerical None/Null: How much does the truck
On 2011-04-28, Chris Rebert c...@rebertia.com wrote:
2. What are the use cases for NaN? Looks like it gets used a lot as a
numeric (float?) object with non-value.
FWICT, it's useful in lower-level languages (which typically lack
exceptions and often lack nice ways of returning multiple
On 4/28/2011 2:59 PM, Steven D'Aprano wrote:
Still, it could be worse... I've seen a programs use to represent
missing values, on the basis that nobody could ever have more than (say)
5000 invoices in the database...
(I wish I was exaggerating.)
All 9s in a field for missing was once
.
The statistics language R has a specific value NA to use for missing,
distinct from NANs.
Still, it could be worse... I've seen a programs use to
represent missing values, on the basis that nobody could ever have
more than (say) 5000 invoices in the database...
All 1's in a float is a NaN, so
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
I think it is presently a bug that a list containing
a NaN value compares equal to itself.
Moreover, it also compares equal to another list containing the same NaN:
[nan] is [nan]
False
[nan] == [nan]
True
Here
Nick Coghlan ncogh...@gmail.com added the comment:
The status quo works. Proposals to change it on theoretical grounds have a
significantly higher bar to meet than proposals to simply document it clearly.
--
___
Python tracker rep...@bugs.python.org
Changes by Raymond Hettinger raymond.hettin...@gmail.com:
--
assignee: docs@python - rhettinger
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11945
___
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Thu, Apr 28, 2011 at 3:01 AM, Nick Coghlan rep...@bugs.python.org wrote:
..
The status quo works.
No it does not. I am yet to see a Python program that uses
non-reflexivity of NaN in a meaningful way. What I've seen
Nick Coghlan ncogh...@gmail.com added the comment:
By works I merely meant that you can currently achieve both of the following:
1. Write fully conformant implementations of IEEE754 floating point types,
including the non-reflexive NaN comparisons (keeping in mind that, as a
value-based
Glenn Linderman v+pyt...@g.nevcal.com added the comment:
Nick says (and later explains better what he meant):
The status quo works. Proposals to change it on theoretical grounds have a
significantly higher bar to meet than proposals to simply document it clearly.
I say:
What the status quo
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Thu, Apr 28, 2011 at 3:26 AM, Nick Coghlan rep...@bugs.python.org wrote:
..
1. Write fully conformant implementations of IEEE754 floating point types,
including the non-reflexive NaN comparisons
(keeping in mind
Changes by Mark Dickinson dicki...@gmail.com:
--
nosy: +mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11945
___
___
New submission from Alexander Belopolsky belopol...@users.sourceforge.net:
Rationale:
IEEE 754 assigns values to all relational expressions involving NaN.
In the syntax of C, the predicate x != y is True but all others, x
y , x = y , x == y , x = y and x y, are False whenever x or y or
both
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
Added file: http://bugs.python.org/file21829/unorderable-nans.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11949
___
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
Removed file: http://bugs.python.org/file21828/unorderable-nans.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11949
___
Terry J. Reedy tjre...@udel.edu added the comment:
To repeat concisely what I said on pydev list, I think Reference 5.9.
Comparisons, which says
Tuples and lists are compared lexicographically using comparison of
corresponding elements. This means that to compare equal, each element must
Changes by Terry J. Reedy tjre...@udel.edu:
--
resolution: - fixed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4296
___
___
Python-bugs-list
Nick Coghlan ncogh...@gmail.com added the comment:
After further discussion on python-dev, it is clear that this identity checking
behaviour handles more than just NaNs - it also allows containers to cope more
gracefully with objects like NumPy arrays that make use of rich comparisons to
Nick Coghlan ncogh...@gmail.com added the comment:
Scratch the first half of that last comment - Guido pointed out that false
positives rear their ugly head almost immediately if you try to store rich
comparison objects in other containers.
--
___
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Actually, my first attempt to fix the test was faulty. The correct logic seems
to be
+def is_negative_zero(x):
+return x == 0 and math.copysign(1, x) 0
+
+def almost_equal(value, expected):
+if
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
Removed file: http://bugs.python.org/file21829/unorderable-nans.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11949
___
Alex Gaynor alex.gay...@gmail.com added the comment:
The C standard (and/or the POSIX one, I forget) says sqrt(-0.0) returns -0.0.
--
nosy: +alex
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11949
New submission from Nick Coghlan ncogh...@gmail.com:
The question of the way Python handles NaN came up again on python-dev
recently. The current semantics have been assessed as a reasonable compromise,
but a poorly explained and inconsistently implemented one.
Based on a suggestion from
Nick Coghlan ncogh...@gmail.com added the comment:
Actually, based on the NumPy precedent [1], array.array should be fine as is.
Since it uses raw C floats and doubles internally, rather than Python objects,
there is no clear concept of object identity to use to enforce reflexivity.
[1]
to itself. As to assignment,
what good can it be if it does not make the target equal to the source value?
The argument is flawed: now that NaN exists, and is not equal to itself in
value, there should be, and need be, no expectation that assignment elsewhere
should make the target equal to the source
Changes by Mark Dickinson dicki...@gmail.com:
--
nosy: +mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10809
___
___
New submission from Andrew Dalke da...@dalkescientific.com:
complex(nan) raises ValueError: complex() arg is a malformed string while
complex(float(nan)) returns (nan+0j). This was reported in
http://bugs.python.org/issue2121 with the conclusion wont fix.
complex(inf) has the same behaviors
, credits or license for more information.
complex(nan-nanj)
(nan+nanj)
This means that the comments are correct and the error was in my understanding,
as influenced by issue2121.
I therefore closed this.
--
resolution: - out of date
status: open - closed
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
nosy: +mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue737648
___
___
Mark Dickinson dicki...@gmail.com added the comment:
Reclassifying as out of date. NaN handling in Python 2.6 and later is
non-accidental.
--
resolution: later - out of date
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Mark Dickinson dicki...@gmail.com added the comment:
(and math.isnan is the recommended way to test for a nan).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue737648
New submission from Jean-Michel Fauth wxjmfa...@gmail.com:
I did not find any report about this.
Windows 7, Python 2.6.4
float('inf') == float('inf')
True
float('-inf') == float('-inf')
True
float('-inf') == float('inf')
False
float('-inf') != float('inf')
True
float('nan') == float('nan
Mark Dickinson dicki...@gmail.com added the comment:
float('nan') == float('nan')
False
float('nan') != float('nan')
True
This is deliberate, though perhaps surprising if you haven't seen it before.
There's a long history of nan comparisons behaving this way (that is, x == nan
always
Mark Dickinson dicki...@gmail.com added the comment:
Fixed in trunk in r77139. I'll wait to check that the buildbots are
happy, and then merge to py3k.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7534
801 - 900 of 1188 matches
Mail list logo
