Is nan in (nan,) correct?

[Steven D'Aprano]

Rustom Mody wrote:

> On Friday, March 6, 2015 at 10:13:55 PM UTC+5:30, Steven D'Aprano wrote:
>> Rustom Mody wrote:
>> 
>> > On Friday, March 6, 2015 at 3:57:12 AM UTC+5:30, rand... at fastmail.us
>> > wrote:
>> >> It's been brought up on Stack Overflow that the "in" operator (on
>> >> tuples, and by my testing on dict and list, as well as dict lookup)
>> >> uses object identity as a shortcut, and returns true immediately if
>> >> the object being tested *is* an element of the container. However, the
>> >> contains operation does not specify whether object identity or
>> >> equality is to be used. In effect, the built-in container types use a
>> >> hybrid test: "a is b or a == b".
>> >> 
>> >> My question is, is this a *correct* implementation of the operator, or
>> >> are objects "supposed to" use a basis of equality for these tests?
>> > 
>> > nan is an illegal or bogus value.
>> 
>> NANs *represent* bogus values, they aren't bogus themselves.
>> 
>> 
>> > As usual legalizing the illegal is always fraught with increasing
>> > conundrums.
>> > 
>> > The most (to me) classic instance of this is denotational semantics.
>> > In DS one tries to give semantics to programs by mapping programs to
>> > math-functions across some domains
>> > 
>> > However some programs crash. What should be the semantics of such a
>> > program. We say its a partial function – undefined at the crash-points.
>> > But partial functions are not nearly as tractable (to mathematicians!)
>> > as total functions.
>> > So we invent a bogus value  ⊥ (called bottom) and totalize all
>> > functions by mapping to this.
>> > 
>> > Very nice…
>> > 
>> > So nice in fact that we wish to add ⊥ to our programming language
>> > 
>> > And now all hell breaks loose because the question x == ⊥ is the
>> > halting problem.
>> 
>> Oh nonsense. x == ⊥ is easily performed with the equivalent of:
>> 
>> type(x) == BottomType and bit_representation(x) == bit_representation(⊥)
> 
> You dont grok your theory of computation very well do you?
> 
> def foo(x): return x + x
> def bar(x): return x + x
> def baz(x): return 2*x
> 
> One can imagine an implementation where
> id(foo) == id(bar)
> [I am assuming that id is a good enough approx to bit_representation]
> 
> Can you imagine an implementation where
> id(bar) == id(baz)
> ?

Not necessarily if x are floats. But I'll grant you that 2*x and x+x are
computationally equivalent if x is an int. I'll also grant you that there
are other functions which are computationally equivalent to x+x  but
immeasurably more complex, and that for the compiler to recognise all such
functions is equivalent to the halting problem.

What does this have to do with the ability to perform an equality test
against some ⊥ value?

Your argument is analogous to this:

"Somewhere, out in the immensity of space, floats an infinite number of
haystacks. Inside just one of those haystacks is a single tiny needle.
Since it is impossible to locate that needle, it is likewise impossible to
locate this needle I hold between my fingers!"

You have made a claim that None is a reinvention of the ⊥ (bottom) pattern,
and that it is impossible to evaluate x == ⊥ due to the Halting Problem.
Let's put that to the test:

[steve at ando ~]$ python -c "x = 23; print x == None"
False


I was hoping to have time to make a cup of tea while Python tried to solve
the Halting Problem, possibly even to go to the market, do some shopping,
do my house work, watch a movie, and catch a good night's sleep, but it
only took a small fraction of a second for x == None to complete.

I can draw only two possible conclusions:

(1) The halting problem, and therefore Godel's Incompleteness Theorem as
well, are disproven and the very fundamentals of mathematics and logic are
overturned; or

(2) You are mistaken that evaluating x == ⊥ is equivalent to solving the
Halting Problem.


If I were a betting man, I know where I would put my money.



-- 
Steven