Issue 28579: nan != nan (original) (raw)

Issue28579

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:38 admin set github: 72765
2016-11-01 15:17:14 tim.peters set nosy: + tim.petersmessages: +
2016-11-01 15:05:53 SilentGhost set status: open -> closednosy: + SilentGhostmessages: + resolution: not a bugstage: resolved
2016-11-01 15:00:37 niacdoial create