Is nan in (nan,) correct?

Rustom Mody rustompmody at gmail.com
Fri Mar 6 12:04:21 EST 2015


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) 
?

If you can I will just start increasing the gap between bar and baz
and in that game we will be re-executing the details of the halting problem
(and more generally the Rice theorem)

Simpler for you to revise your Theory of computation I think <wink>



More information about the Python-list mailing list