TL;DR
Use np.isnan (a) instead of a is np.nan.
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 math.nan and np.nan. (There may be others.)
a is np.nan "If a is 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 aid (), so if you use it, it will be concise, accurate, and prevent misuse.
Recommended Posts