Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #86958 > unrolled thread

Is nan in (nan,) correct?

Back to article view | Back to comp.lang.python

Contents

  Is nan in (nan,) correct? random832@fastmail.us - 2015-03-05 17:26 -0500
    Re: Is nan in (nan,) correct? sohcahtoa82@gmail.com - 2015-03-05 15:11 -0800
      Re: Is nan in (nan,) correct? Ben Finney <ben+python@benfinney.id.au> - 2015-03-06 10:20 +1100
        Re: Is nan in (nan,) correct? sohcahtoa82@gmail.com - 2015-03-05 15:27 -0800
          Re: Is nan in (nan,) correct? Ben Finney <ben+python@benfinney.id.au> - 2015-03-06 10:39 +1100
          Re: Is nan in (nan,) correct? Chris Angelico <rosuav@gmail.com> - 2015-03-06 10:40 +1100
      Re: Is nan in (nan,) correct? Chris Angelico <rosuav@gmail.com> - 2015-03-06 10:25 +1100
    Re: Is nan in (nan,) correct? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-06 13:09 +1100
      Re: Is nan in (nan,) correct? Ben Finney <ben+python@benfinney.id.au> - 2015-03-06 13:55 +1100
      Re: Is nan in (nan,) correct? Ethan Furman <ethan@stoneleaf.us> - 2015-03-05 19:18 -0800
      Re: Is nan in (nan,) correct? Ben Finney <ben+python@benfinney.id.au> - 2015-03-06 14:26 +1100
      Re: Is nan in (nan,) correct? Ethan Furman <ethan@stoneleaf.us> - 2015-03-05 19:44 -0800
      Re: Is nan in (nan,) correct? Chris Angelico <rosuav@gmail.com> - 2015-03-06 14:49 +1100
      Re: Is nan in (nan,) correct? random832@fastmail.us - 2015-03-05 23:37 -0500
        Re: Is nan in (nan,) correct? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-07 04:07 +1100
      Re: Is nan in (nan,) correct? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-03-06 04:46 +0000
    Re: Is nan in (nan,) correct? Rustom Mody <rustompmody@gmail.com> - 2015-03-06 01:50 -0800
      Re: Is nan in (nan,) correct? Chris Angelico <rosuav@gmail.com> - 2015-03-06 21:01 +1100
        Re: Is nan in (nan,) correct? Rustom Mody <rustompmody@gmail.com> - 2015-03-06 02:22 -0800
          Re: Is nan in (nan,) correct? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-07 03:59 +1100
            Re: Is nan in (nan,) correct? Rustom Mody <rustompmody@gmail.com> - 2015-03-06 10:04 -0800
              Re: Is nan in (nan,) correct? Ethan Furman <ethan@stoneleaf.us> - 2015-03-06 10:16 -0800
        Re: Is nan in (nan,) correct? Grant Edwards <invalid@invalid.invalid> - 2015-03-06 15:34 +0000
      Re: Is nan in (nan,) correct? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-07 03:43 +1100
        Re: Is nan in (nan,) correct? Rustom Mody <rustompmody@gmail.com> - 2015-03-06 09:04 -0800
          Re: Is nan in (nan,) correct? Chris Angelico <rosuav@gmail.com> - 2015-03-07 04:16 +1100
            Re: Is nan in (nan,) correct? Rustom Mody <rustompmody@gmail.com> - 2015-03-06 09:36 -0800
          Re: Is nan in (nan,) correct? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-07 10:33 +1100
            Re: Is nan in (nan,) correct? Rustom Mody <rustompmody@gmail.com> - 2015-03-06 18:37 -0800

Page 2 of 2 — ← Prev page 1 [2]

#87050

On Friday, March 6, 2015 at 10:29:19 PM UTC+5:30, Steven D'Aprano wrote:
> Rustom Mody wrote:
> 
> > On Friday, March 6, 2015 at 3:31:58 PM UTC+5:30, Chris Angelico wrote:
> >> On Fri, Mar 6, 2015 at 8:50 PM, Rustom Mody  wrote:
> >> > In a language like python with decent exceptions we do not need nans.
> >> 
> >> Not so. I could perhaps accept that we don't need signalling NaNs, as
> >> they can be replaced with exceptions, but quiet NaNs are by definition
> >> _not_ exceptions.
> > 
> > My impression (maybe I am wrong):
> > "Catch an exception and ignore it" is a way of converting signalling to
> > quiet With the added advantage of being able to tweak the specs of what
> > happens when nan op normal to one's taste
> 
> 
> I don't understand what you are trying to say.
> 
> Let's take a dirt-simple example:
> 
> def inverse(x):
>     return 1.0/x
> 
> There's an exception there, waiting to bite. If I include inverse() in some
> complex calculation:
> 
> def function(x, y):
>     return atan2(inverse(3*x*y)+1, inverse(1 - x**2 + 3*x - 0.2)**3)
> 
> values = [function(1.5*x, y+2) for x, y in zip(xx, yy)]
> 
> and I just wish to skip over the failed calculations, I can't just "ignore"
> exceptions:
> 
> # This doesn't work!
> def inverse(x):
>     try:
>         return 1.0/x
>     except ZeroDivisionError:
>         pass
> 
> 
> I have to return something that acts like a number but isn't a number.
> 
> Something which, once it enters a calculation, should propagate through it.
> But not necessarily something which once it enters can never be removed! It
> may be that some calculations can "cancel out" these "errors" (indeed, the
> atan2 function is one of those -- it can return non-NANs from at least some
> NAN arguments). So what should I return? It cannot be a number, but it has
> to act like a number. Ideally, it should carry diagnostic information so I
> can see what the failure was, for debugging, although I may not bother to
> do so that information should at least be available for use.
> 
> I have just re-invented NANs.

Ok... Maybe so
As I said I am not too sure about this

However you have to give me a little fuller (if not more realistic) example
[Your xx and yy are what?]

And I have to see if I know how to tweak it nan-less
And at least maintain hopefully improve the clarity, succinctness of the original!  Not saying I will be able -- just that thats the claim

[toc] | [prev] | [next] | [standalone]

#87052

[Multipart message — attachments visible in raw view] — view raw

On 03/06/2015 10:04 AM, Rustom Mody wrote:
> On Friday, March 6, 2015 at 10:29:19 PM UTC+5:30, Steven D'Aprano wrote:

>> def inverse(x):
>>     return 1.0/x
>>
>> There's an exception there, waiting to bite. If I include inverse() in some
>> complex calculation:
>>
>> def function(x, y):
>>     return atan2(inverse(3*x*y)+1, inverse(1 - x**2 + 3*x - 0.2)**3)
>>
>> values = [function(1.5*x, y+2) for x, y in zip(xx, yy)]

> Ok... Maybe so
> As I said I am not too sure about this
> 
> However you have to give me a little fuller (if not more realistic) example
> [Your xx and yy are what?]

xx and yy are lists of floats, and for your test xx should have at least one zero in it.

> And I have to see if I know how to tweak it nan-less
> And at least maintain hopefully improve the clarity, succinctness of the original!  Not saying I will be able -- just that thats the claim

Good luck.  :)

--
~Ethan~

[toc] | [prev] | [next] | [standalone]

#87028

On 2015-03-06, Chris Angelico <rosuav@gmail.com> wrote:
> On Fri, Mar 6, 2015 at 8:50 PM, Rustom Mody <rustompmody@gmail.com> wrote:
>> In a language like python with decent exceptions we do not need nans.
>
> Not so. I could perhaps accept that we don't need signalling NaNs, as
> they can be replaced with exceptions, but quiet NaNs are by definition
> _not_ exceptions.

And quiet NaNs are very, very useful.

-- 
Grant Edwards               grant.b.edwards        Yow! A can of ASPARAGUS,
                                  at               73 pigeons, some LIVE ammo,
                              gmail.com            and a FROZEN DAQUIRI!!

[toc] | [prev] | [next] | [standalone]

#87039

Rustom Mody wrote:

> On Friday, March 6, 2015 at 3:57:12 AM UTC+5:30, rand...@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(⊥)



> And people love this problem so much they keep replicating it:
> 
> - C and null (or Pascal/Lisp and Nil)
> [Hoare's billion dollar mistake
> [https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions ]
> - nul in SQL – Should two nuls compare as same or different?
>   There are good (and different!) reasons for both answers
> - Python and None
> - Floats and nans

This is a random grab-bag of unrelated "problems" that differ in their
causes and their consequences. The only thing they have in common is that
Null/Nil/Nul/None/NAN all begin with N, and are all "special" in some
sense.


> My own thoughts on this (not very well thought out, I admit)
> The letter of the IEEE standard talks of nans and their details
> The spirit of the standard is that nans capture exception-al computations
> ie nan represents an exception
> 
> In a language like python with decent exceptions we do not need nans.

Then you are missing the most important use-case for NANs.

Really, do you think that the designers of IEEE-754 actually didn't think of
this? Long before high-level languages like Python started using
exceptions, low-level languages had "traps" that did more or less the same
thing. If all you want is merely to interrupt your calculation the first
time an error occurs, then you just trap the error condition and you're
done.

But IEEE-754 supports *not* interrupting the calculation, but allowing the
error condition to propagate all the way to the end of the calculation.
Instead of peppering your calculation with dozens of checks ("Look Before
You Leap") to avoid triggering a trap, you just perform the calculation,
and then at the end inspect the result and if it is a NAN you can decide
how to handle it ("Easier To Ask Forgiveness Than Permission"). The whole
point of NANs is to avoid traps (exceptions, signals, or whatever you want
to call this interruption) from being triggered. To replace NANs with
exceptions is to miss their whole reason for existence!

And for those who do want an immediate exception, the standard supports that
too, with *signalling NANs*, which are supposed to trap on just about every
operation. A proper IEEE-754 system will allow you to decide which
operations should trap immediately and which don't, it's not a global
all-or-nothing prospect.

Alas, although many (most? all?) FPUs these days support these features,
hardly any high-level language does. You typically cannot even control
these features from C, but have to drop down to assembly. The fine control
that IEEE-754 offers is under-utilized because the language designers don't
support it.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#87045

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...@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>

[toc] | [prev] | [next] | [standalone]

#87048

On Sat, Mar 7, 2015 at 4:04 AM, Rustom Mody <rustompmody@gmail.com> wrote:
> 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)
> ?

No, I cannot imagine either. Those functions have different
identities. They may be considered *equal* but they should not be
*identical*. I can imagine a language in which they are considered
indistinguishable and optimized down to one, but if you consider them
to be the same function, then you've abolished all concept of
identity.

Also, I have no idea what any of this has to do with nans and
container membership.

ChrisA

[toc] | [prev] | [next] | [standalone]

#87049

On Friday, March 6, 2015 at 10:48:07 PM UTC+5:30, Chris Angelico wrote:
> On Sat, Mar 7, 2015 at 4:04 AM, Rustom Mody  wrote:
> > 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)
> > ?
> 
> No, I cannot imagine either. Those functions have different
> identities. They may be considered *equal* but they should not be
> *identical*. I can imagine a language in which they are considered
> indistinguishable and optimized down to one, but if you consider them
> to be the same function, then you've abolished all concept of
> identity.

Treat id as the python version of bit_representation.
Now we have two things (worlds really)
in-python entities like foo/bar/baz
Their mathematical semantics -- the infinite sets of (domain,range)
pairs that they are intended to capture.
[Jargon note: The id-equal is called intensional-equality the math-equality is
called extensional-equality]

To get foo == bar one can imagine something like
1. Hash the dis of every function
2. If a new function being defined is hash-equal to an old one:
     If dis(new) == dis(old)
        make new_name point to old implementation

To make bar == baz we need more and more heavy-duty theorem provers
And will invariably hit halting-problem in some guise or other

> 
> Also, I have no idea what any of this has to do with nans and
> container membership.

⊥ in semantics is the prototypical example of reifying an undefined entity.
As are all the other examples nil/None/nul/nan.

It buys a bigger problem for a smaller one -- Steven's (other thread) example of
"Should I know whether an asteroid the size of Texas is earth bound?"

To take a less apocalyptic example: 
I am holding a bomb in my hand.
Is it good to know that? DOes it help any?
Does the statement "We have a problem!!" make the 'problem' vanish?
⊥/nul/nil/nan are all 'bombs/problems' in some sense

[toc] | [prev] | [next] | [standalone]

#87067

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...@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@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

[toc] | [prev] | [next] | [standalone]

#87070

On Saturday, March 7, 2015 at 5:04:02 AM UTC+5:30, Steven D'Aprano wrote:
> 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...@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.

Good so far

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

What do you understand by ⊥ 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!"

Straw... er Hayman!

> 
> You have made a claim that None is a reinvention of the ⊥ (bottom) pattern,

Ok

> and that it is impossible to evaluate x == ⊥ due to the Halting Problem.

That depends on how you answer my question above: What do mean by ⊥ value?

> Let's put that to the test:
> 
> [steve@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.

You dont know the difference between analogy and identity?

> 
> 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.
> 


I'd put my money on (some variation of) "Syntax Error"

python3:

>>> x = 1
>>> x == ⊥
  File "<stdin>", line 1
    x == ⊥
         ^
SyntaxError: invalid character in identifier



python2
>>> x = 1
>>> x == ⊥
  File "<stdin>", line 1
    x == ⊥
         ^
SyntaxError: invalid syntax

Which is to say ⊥ does not exist in python.

So until you say what *you* mean by ⊥ we cannot evaluate where the rheostat sits between

"You/I are wrong"  … "You/I are confused" … "You/I are not even wrong"

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web