This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: nan != nan
Type: behavior Stage: resolved
Components: Versions: Python 3.5
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: SilentGhost, niacdoial, tim.peters
Priority: normal Keywords:

Created on 2016-11-01 15:00 by niacdoial, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (3)
msg279878 - (view) Author: Liam Marsh (niacdoial) Date: 2016-11-01 15:00
I found a really weird comportment with NANs:

>>> from math import nan, isnan, inf
>>> nan==nan
False
>>> nan!=nan
True
>>> a=nan  # maybe get another instance would fix it (or so I thought)
>>> a==nan
False
>>> a==a
False
>>> a is a  
True
>>> # because `is` works, it could be a
>>> # deliberate comportment. is it?
>>> a is nan
True
>>> isnan(a) and isnan(nan)
True
>>> nan == -nan
False
>>> nan is -nan
False
>>> a < 1
False
>>> a > 0
False
>>> a < inf
False
>>> b=external_pyd_call_that_returns_nan()
>>> isnan(b)
True
>>> b == nan
False

that sums what I tried up.

thanks for reading this.
msg279879 - (view) Author: SilentGhost (SilentGhost) * (Python triager) Date: 2016-11-01 15:05
That's how IEEE 754's NaN is defined. Seem to be behaving according to the standard.
msg279880 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2016-11-01 15:17
Yes, it's both intended and annoying ;-)  The standard specifies that, by default, comparisons involving NANs are "unordered":  a NAN is _none_ of "less than", "equal to", or "greater than" any other float, including any other NaN, and including itself.
History
Date User Action Args
2022-04-11 14:58:38adminsetgithub: 72765
2016-11-01 15:17:14tim.peterssetnosy: + tim.peters
messages: + msg279880
2016-11-01 15:05:53SilentGhostsetstatus: open -> closed

nosy: + SilentGhost
messages: + msg279879

resolution: not a bug
stage: resolved
2016-11-01 15:00:37niacdoialcreate