np.isnan (a) instead of
a is np.nan.
nan (Not A Number). The comparison, not the nan "number", is defined by IEEE754. This is not equal to anything. Even
nan == nan is
False. For Python, there are
np.nan. (There may be others.)
a is np.nan"
nan, it cannot be checked with
a == np.nan. Because, as mentioned above, it is decided by IEEE754. So, what to do is that some sites say
a is np.nan. Sure, this works in many cases, but apparently it just happens to work (it's supposed to refer to the same nan object) ** due to the implementation of numpy and math. So, I would like to conclude that it is basically the wrong check method.
That's why it's a counterexample.
#The following is Python 3.91 + numpy 1.19.I tried it in 4. It's basically the same with math nan. import numpy as np a = np.nan b = a * 2 print(a) # => nan print(b) # => nan print(a is np.nan) # => True (This is often used. This is ok) print(b is np.nan) # => False (This happens.)
Isn't it possible to calculate on
nan? The result is still (of course?)
Nan. If you compare with
is here, it will be
Flase because the reference destination seems to be different. So **
a is np.nan is wrong (as a check to see if it's nan) **.
It's best to use
np.isnan () obediently. It's easy to understand. As a trick (?) That took the definition in the wrong direction, there is also a comparison with itself
a == a (
nan if is
False), but I refrain from it because it is confusing. ..
It's Python (Bassari). The root of all evil is the introduction of things like
is. This intuitive function causes ambiguous be verbs to play the important role of "comparison of references", causing confusion. To make matters worse, the
is formula becomes widespread because it is easy to understand in English depending on how you read it (even if you misunderstand the meaning). Even if there is no
is, there is a
id (), so if you use it, it will be concise, accurate, and prevent misuse.