Why float('Nan') == float('Nan') is False

[Avi Gross]

I think we should realize that Nan and NA and so on are human constructs people Define in programming languages. Some have subdivisions as in not an int as compared to not a float.

Python also has an Inf as well as a -Inf that are abstractions and not a real, so to speak. Number.

Mathematics is arguably a human discovery when it comes to infinities since Cantor but the rules are not the same. CARDINALITY is not a number. It is a logical range of partitions. There obviously are more integers than prime numbers as you count upwards to a thousand or a billion. BUT in the context of infinity, at the Aleph Null level, they sort of map into the same category. So the primes or squares or odd numbers are not equal but in the limit as you approach whatever infinity means, they seem effectively equal as there is always another.  You can sort of make a 1:1 correspondence or mapping. 

But that means that normal mathematics is warped. Double it and/or add a quadrillion and it remains in the same bucket.  But there are other buckets and everything in them is not so much the same as in some sense larger than the previous bucket but smaller than the next higher bucket.

The continuum hypothesis remains open as to whether there is an intermediate bucket you can describe between Aleph Null and Aleph one. Meaning there is no reasonable definition of a bucket the new infinite construct fits in while not fitting existing ones.

Back to python. Or is it IEEE? In type int the number can be arbitrarily large as long as you have enough computer memory and resources. Yet the special concepts of Inf and negative Inf can be compared with other ints but not fruitfully with Nan, right? There are helper functions you can call to ask if a variable is an Inf or a Nan. Doubles have size limits so anything big enough might as well be an Inf. I note some things like numpy use a fixed size int as well.

Some of the confusion may come when a language uses a concept in many ways. In R all an NA can mean is Not Available. Some data structures, just like a numpy array in python, insist on holding objects of one unified type and NA normally matches any such type as a placeholder. Sort of a NULL. You normally do not want to include an NA in calculations as it infects everything. So you often filter it out implicitly or explicitly. It is not necessarily an error but if you use it in calculating a mean, then the result is sort of an error.

You can ask if a variable is an NA as in is.na(x) which returns a Boolean. So to test if x and y are both NA or have the same status by both not being NA, use the functions. Python has similar functionality. Just don't compare the naked singularities to each other!


Sent from AOL Mobile Mail
On Wednesday, February 13, 2019 Chris Angelico <rosuav at gmail.com> wrote:
On Thu, Feb 14, 2019 at 7:12 AM Test Bot <onlinejudge95 at gmail.com> wrote:
>
> This definition of NaN is much better in mentally visualizing all the so
> called bizarreness of IEEE. This also makes intuitive that no 2 NaN will be
> equal just as no 2 infinities would be equal. I believe in a hypothesis(of
> my own creation) that any arithmetic on a data type of NaN would be similar
> to any set of operations on the set of Infinities.
>

Why would no two infinities be equal? In mathematics, there's one
best-known infinity (aleph null, aka the number of counting numbers),
and many many infinities are provably equal to it. (Others are
provably NOT equal to it, like the number of real numbers.) There's
nothing wrong with saying "there are as many prime numbers as there
are odd numbers", or equivalently that "the size/cardinality of the
set of primes is equal to the size of the set of odd numbers" [1]. And
both Python and IEEE agree:

>>> float("inf") == float("inf")
True

NaN and infinity are quite different concepts, and they behave very differently.

ChrisA

[1] I'm sure someone will point out something pedantically wrong in
what I said, but certainly the sets have the same cardinality.
-- 
https://mail.python.org/mailman/listinfo/python-list