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

Groups > comp.theory > #36344 > unrolled thread

Halting problem erroneously defined

Back to article view | Back to comp.theory

Contents

  Halting problem erroneously defined Mr Flibble <flibble@reddwarf.jmc> - 2021-07-15 18:22 +0100
    Re: Halting problem erroneously defined olcott <NoOne@NoWhere.com> - 2021-07-15 12:42 -0500
      Re: Halting problem erroneously defined Mr Flibble <flibble@reddwarf.jmc> - 2021-07-15 18:48 +0100
        Re: Halting problem erroneously defined Mr Flibble <flibble@reddwarf.jmc> - 2021-07-15 19:00 +0100
          Re: Halting problem erroneously defined olcott <NoOne@NoWhere.com> - 2021-07-15 13:04 -0500
            Re: Halting problem erroneously defined Mr Flibble <flibble@reddwarf.jmc> - 2021-07-15 19:09 +0100
              Re: Halting problem erroneously defined olcott <NoOne@NoWhere.com> - 2021-07-15 13:17 -0500
        Re: Halting problem erroneously defined olcott <NoOne@NoWhere.com> - 2021-07-15 13:01 -0500
    Re: Halting problem erroneously defined Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2021-07-15 20:08 +0100
      Re: Halting problem erroneously defined olcott <NoOne@NoWhere.com> - 2021-07-15 15:57 -0500
        Re: Halting problem erroneously defined Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-15 23:06 +0100
          Re: Halting problem erroneously defined olcott <NoOne@NoWhere.com> - 2021-07-15 18:00 -0500
            Re: Halting problem erroneously defined Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-16 01:29 +0100
              Re: Halting problem erroneously defined olcott <NoOne@NoWhere.com> - 2021-07-15 19:59 -0500
                Re: Halting problem erroneously defined Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-16 02:49 +0100
                  Re: Halting problem erroneously defined olcott <NoOne@NoWhere.com> - 2021-07-15 21:43 -0500
                    Re: Halting problem erroneously defined Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-17 01:29 +0100
                      Re: Halting problem erroneously defined olcott <NoOne@NoWhere.com> - 2021-07-17 11:05 -0500
                        Re: Halting problem erroneously defined Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-18 02:36 +0100
                          Re: Halting problem erroneously defined olcott <NoOne@NoWhere.com> - 2021-07-19 10:09 -0500
                            Re: Halting problem erroneously defined Richard Damon <Richard@Damon-Family.org> - 2021-07-19 08:18 -0700
                            Re: Halting problem erroneously defined Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-20 01:38 +0100
                              Re: Halting problem erroneously defined olcott <NoOne@NoWhere.com> - 2021-07-20 09:29 -0500
                                Re: Halting problem erroneously defined Richard Damon <Richard@Damon-Family.org> - 2021-07-20 09:17 -0700
                                Re: Halting problem erroneously defined Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-21 01:28 +0100
                        Re: Halting problem erroneously defined Richard Damon <Richard@Damon-Family.org> - 2021-07-17 21:57 -0600
      Re: Halting problem erroneously defined Mr Flibble <flibble@reddwarf.jmc> - 2021-07-16 13:25 +0100
        Re: Halting problem erroneously defined olcott <NoOne@NoWhere.com> - 2021-07-16 08:56 -0500
      Re: Halting problem erroneously defined Mr Flibble <flibble@reddwarf.jmc> - 2021-07-16 13:33 +0100
        Re: Halting problem erroneously defined olcott <NoOne@NoWhere.com> - 2021-07-16 09:28 -0500
        Re: Halting problem erroneously defined Alan Mackenzie <acm@muc.de> - 2021-07-16 14:44 +0000
          Re: Halting problem erroneously defined olcott <NoOne@NoWhere.com> - 2021-07-16 09:52 -0500
            Re: Halting problem erroneously defined Alan Mackenzie <acm@muc.de> - 2021-07-16 16:39 +0000
              Re: Halting problem erroneously defined olcott <NoOne@NoWhere.com> - 2021-07-16 12:13 -0500
                Re: Halting problem erroneously defined Mr Flibble <flibble@reddwarf.jmc> - 2021-07-16 18:26 +0100
                  Re: Halting problem erroneously defined olcott <NoOne@NoWhere.com> - 2021-07-16 12:41 -0500
                  Re: Halting problem erroneously defined Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-07-16 19:37 +0100
                Re: Halting problem erroneously defined André G. Isaak <agisaak@gm.invalid> - 2021-07-16 11:53 -0600
                  Re: Halting problem erroneously defined olcott <NoOne@NoWhere.com> - 2021-07-16 13:39 -0500
                    Re: Halting problem erroneously defined André G. Isaak <agisaak@gm.invalid> - 2021-07-16 12:52 -0600
                      Re: Halting problem erroneously defined olcott <NoOne@NoWhere.com> - 2021-07-16 14:40 -0500
                        Re: Halting problem erroneously defined André G. Isaak <agisaak@gm.invalid> - 2021-07-16 13:57 -0600
                          Re: Halting problem erroneously defined olcott <NoOne@NoWhere.com> - 2021-07-16 15:09 -0500
                            Re: Halting problem erroneously defined André G. Isaak <agisaak@gm.invalid> - 2021-07-16 14:30 -0600
                              Re: Halting problem erroneously defined olcott <NoOne@NoWhere.com> - 2021-07-16 16:06 -0500
                                Re: Halting problem erroneously defined André G. Isaak <agisaak@gm.invalid> - 2021-07-16 16:09 -0600
                                  Re: Halting problem erroneously defined olcott <NoOne@NoWhere.com> - 2021-07-16 17:24 -0500
                                    Re: Halting problem erroneously defined André G. Isaak <agisaak@gm.invalid> - 2021-07-16 16:48 -0600
                                      Re: Halting problem erroneously defined olcott <NoOne@NoWhere.com> - 2021-07-17 10:22 -0500
                                        Re: Halting problem erroneously defined Richard Damon <Richard@Damon-Family.org> - 2021-07-17 22:24 -0600
                        Re: Halting problem erroneously defined Richard Damon <Richard@Damon-Family.org> - 2021-07-17 22:09 -0600
                  Re: Halting problem erroneously defined Jeff Barnett <jbb@notatt.com> - 2021-07-16 13:51 -0600
                    Re: Halting problem erroneously defined olcott <NoOne@NoWhere.com> - 2021-07-16 14:57 -0500
                      Re: Halting problem erroneously defined Jeff Barnett <jbb@notatt.com> - 2021-07-16 16:34 -0600
                Re: Halting problem erroneously defined Alan Mackenzie <acm@muc.de> - 2021-07-16 18:25 +0000
                  Re: Halting problem erroneously defined Mr Flibble <flibble@reddwarf.jmc> - 2021-07-16 19:29 +0100
                    Re: Halting problem erroneously defined Alan Mackenzie <acm@muc.de> - 2021-07-16 18:59 +0000
                      Re: Halting problem erroneously defined olcott <NoOne@NoWhere.com> - 2021-07-16 14:42 -0500
                    Re: Halting problem erroneously defined olcott <NoOne@NoWhere.com> - 2021-07-16 14:22 -0500
                  Re: Halting problem erroneously defined olcott <NoOne@NoWhere.com> - 2021-07-16 14:33 -0500
                    Re: Halting problem erroneously defined Alan Mackenzie <acm@muc.de> - 2021-07-16 20:19 +0000
                      Re: Halting problem erroneously defined olcott <NoOne@NoWhere.com> - 2021-07-16 15:34 -0500
                        Re: Halting problem erroneously defined Alan Mackenzie <acm@muc.de> - 2021-07-16 21:30 +0000
                          Re: Halting problem erroneously defined olcott <NoOne@NoWhere.com> - 2021-07-16 16:57 -0500
                            Re: Halting problem erroneously defined Alan Mackenzie <acm@muc.de> - 2021-07-17 09:39 +0000
                              Re: Halting problem erroneously defined [AM] olcott <NoOne@NoWhere.com> - 2021-07-17 10:11 -0500
                                Re: Halting problem erroneously defined [AM] Alan Mackenzie <acm@muc.de> - 2021-07-17 17:41 +0000
                                  Re: Halting problem erroneously defined [AM] olcott <NoOne@NoWhere.com> - 2021-07-17 13:26 -0500
                Re: Halting problem erroneously defined wij <wyniijj@gmail.com> - 2021-07-16 11:45 -0700
                  Re: Halting problem erroneously defined olcott <NoOne@NoWhere.com> - 2021-07-16 14:37 -0500
                    Re: Halting problem erroneously defined Richard Damon <Richard@Damon-Family.org> - 2021-07-17 22:28 -0600
                Re: Halting problem erroneously defined Jeff Barnett <jbb@notatt.com> - 2021-07-16 13:31 -0600
            Re: Halting problem erroneously defined Richard Damon <Richard@Damon-Family.org> - 2021-07-17 22:06 -0600
    Re: Halting problem erroneously defined wij <wyniijj@gmail.com> - 2021-07-17 03:01 -0700
    Re: Halting problem erroneously defined Charlie-Boo <shymathguy@gmail.com> - 2021-07-19 07:35 -0700
      Re: Halting problem erroneously defined olcott <NoOne@NoWhere.com> - 2021-07-19 15:45 -0500
        Re: Halting problem erroneously defined Richard Damon <Richard@Damon-Family.org> - 2021-07-19 20:44 -0700
    Re: Halting problem erroneously defined Charlie-Boo <shymathguy@gmail.com> - 2021-07-19 07:43 -0700
      Re: Halting problem erroneously defined olcott <NoOne@NoWhere.com> - 2021-07-19 15:49 -0500
        Re: Halting problem erroneously defined Richard Damon <Richard@Damon-Family.org> - 2021-07-19 20:46 -0700

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#36650

On 7/19/21 8:09 AM, olcott wrote:
> On 7/17/2021 8:36 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 7/16/2021 7:29 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>
>>>>> If the C equivalent of the Strachey (1965) CPL returns true(halts) to
>>>>> P then P loops. If it returns false(does not halt) to P then P halts.
>>>>>
>>>>> void P(u32 x)
>>>>> {
>>>>>     if (H(x, x))
>>>>>       HERE: goto HERE;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>     Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>> }
>>>>>
>>>>> The self-contradiction of the halting problem counter-examples is
>>>>> apparently modeled after the liar paradox.
>>>>
>>>> P(P) (like all computations) either halts or it does not.  You tell us
>>>> it halts.  You also tell up that H(P,P) == 0.  H(P,P) == 0 is the wrong
>>>> answer for a halting computation.
>>>
>>> int main() { P(P); } specifies infinite recursion that it aborted at
>>> its third function call.
>>
>> P(P) halts (according to you).  H(P,P) == 0 (according to you).  That is
>> wrong (according to everyone but you).
>>
> 
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
> }
> 
> int main()
> {
>   P((u32)P);
> }
> 
> The fact is that the above computation never ever halts unless some H
> aborts some P thus proving beyond all possible doubt that H[0] does
> correctly decide that P[2] (zero based addressing) never halts.

But it halts because the H THAT IS PART OF P decides to abort its
simulation of another copy of P(P), and thus THIS P does Halt on its own
if a finite number of steps, and thus BY DEFINITION, it is a Halting
Computation.

Remember 'P' is the TURING MACHINE, not just the 'C function' for the
Question.

> 
> When a computation only stops running because its simulation was aborted
> this counts as a computation that never halts.

But the top level p never had ITS simulation aborted, because it was
never simulated!!!

> 
> That you simply don't know the x86 language well enough to see that the
> input to H has no possible escape from its infinite recursion does not
> count as any sort of rebuttal at all.

That you don't understand how Turing Machines work, and thus what a real
equivalent to one is makes you 'logic' garbage.



Even you trace of the above shows that P comes to a halt.


Note, the definition of 'Halting' doesn't say why the program reached
its final halt state, just that it did.

And before you go on about this saying that aborting a simulation would
be saying that an aborted infinte loop would be halting, the aborted
simulation never reached it 'halt' state, it was just suspended in the
middle (and the SIMULATOR halts), in this example, the simulation is
aborted and that simulation suspended, and then the SIMULATOR (which is
also with the machine P) comes to its halt, thus showing that P is a
halting computation.

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

#36676

olcott <NoOne@NoWhere.com> writes:

> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
> }
>
> int main()
> {
>   P((u32)P);
> }
>
> The fact is that the above computation never ever halts unless...

The fact is that P(P) halts (according to you).  H(P,P) == 0 (according
to you).  That is wrong.  You know it's wrong:

Me: Every computation that halts, for whatever reason, is a halting
    computation.

You: OK

Are there any facts of the matter that are in dispute?

-- 
Ben.

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

#36704

On 7/19/2021 7:38 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
> 
>> void P(u32 x)
>> {
>>    if (H(x, x))
>>      HERE: goto HERE;
>> }
>>
>> int main()
>> {
>>    P((u32)P);
>> }
>>
>> The fact is that the above computation never ever halts unless...
> 
> The fact is that P(P) halts (according to you).  H(P,P) == 0 (according
> to you).  That is wrong.  You know it's wrong:
> 
> Me: Every computation that halts, for whatever reason, is a halting
>      computation.
> 
> You: OK
> 
> Are there any facts of the matter that are in dispute?
> 

A computation that has its simulation aborted before it comes to its 
natural end is not a halting computation.

A halting computation is a computation that stop running without ever 
having its simulation aborted.

*Conventional Halt Deciding Axiom*
When the pure simulation of the machine description ⟨P⟩ of a machine P 
on its input I never halts we know that P(I) never halts. // based on 
UTM(⟨P⟩,I) ≡ P(I)


-- 
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre 
minds." Einstein

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

#36710

On 7/20/21 7:29 AM, olcott wrote:
> On 7/19/2021 7:38 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> void P(u32 x)
>>> {
>>>    if (H(x, x))
>>>      HERE: goto HERE;
>>> }
>>>
>>> int main()
>>> {
>>>    P((u32)P);
>>> }
>>>
>>> The fact is that the above computation never ever halts unless...
>>
>> The fact is that P(P) halts (according to you).  H(P,P) == 0 (according
>> to you).  That is wrong.  You know it's wrong:
>>
>> Me: Every computation that halts, for whatever reason, is a halting
>>      computation.
>>
>> You: OK
>>
>> Are there any facts of the matter that are in dispute?
>>
> 
> A computation that has its simulation aborted before it comes to its
> natural end is not a halting computation.
> 
> A halting computation is a computation that stop running without ever
> having its simulation aborted.

Right, and in the above code, the P that is called by main comes to its
final stop without having its simulation aborted because it was NEVER
simulated.

H simulated a COPY of this P and aborted the simulation of THAT COPY,
and returned it answer to the P called by main and that P then halts.


> 
> *Conventional Halt Deciding Axiom*
> When the pure simulation of the machine description ⟨P⟩ of a machine P
> on its input I never halts we know that P(I) never halts. // based on
> UTM(⟨P⟩,I) ≡ P(I)
> 
> 

Right. And UTM(P,P) with P as defined above does halt, as even YOU have
shown with traces. Yes, that trace showed H erroneously declaring that P
was non-halting and aborting another copy of P, but THIS copy of P does
halt, and thus showing that the copy of P that H was simulating would
have also halted if H hadn't erroneously aborted it.

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

#36743

olcott <NoOne@NoWhere.com> writes:

> On 7/19/2021 7:38 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>> 
>>> void P(u32 x)
>>> {
>>>    if (H(x, x))
>>>      HERE: goto HERE;
>>> }
>>>
>>> int main()
>>> {
>>>    P((u32)P);
>>> }
>>>
>>> The fact is that the above computation never ever halts unless...
>> The fact is that P(P) halts (according to you).  H(P,P) == 0 (according
>> to you).  That is wrong.  You know it's wrong:
>> Me: Every computation that halts, for whatever reason, is a halting
>>      computation.
>> You: OK
>> Are there any facts of the matter that are in dispute?
>
> A computation that has its simulation aborted before it comes to its
> natural end is not a halting computation.

P(P) halts.  You've shown us the trace.  You've told us it halts.

But you may have been mistaken.  I asked if any of the fact of the
matter are in dispute and you raise this one so, please, correct the
record if you were wrong about that.

-- 
Ben.

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

#36581

On 7/17/21 10:05 AM, olcott wrote:
> On 7/16/2021 7:29 PM, Ben Bacarisse wrote:

>> P(P) (like all computations) either halts or it does not.  You tell us
>> it halts.  You also tell up that H(P,P) == 0.  H(P,P) == 0 is the wrong
>> answer for a halting computation.
>>
> 
> int main() { P(P); } specifies infinite recursion that it aborted at its
> third function call.


Aborted by WHO? The call to P(P) in the above code is NOT being
simulated by anything that should be able to abort it.

If you have put back in you Global Halt Decider, you system is no longer
Turing Complete and you full arguement fails as you fail to have your
code be truly computationally equivalent to the Turing Machines in the
proofs.

If the H called by P aborts its caller, then either H is aborts all
callers and thus fails to be a decider, since it NEVER returned the
answer as needed, or H fails to be a computation and thus does not
qualify to be a Halt Decider, since it isn't the computation equivalent
of a Turing Machine,

Also P(P) is actually NOT infinitely recursive if H will abort it, as
shown that when we ran P(P) is did NOT run to an infinite level of
operation, and stop it purely under its own operation, since the copy of
H within P is part of the Turing Machine/Program P (dispite your
confused instistance that it isn't).



FIRST BIG Error, no need to go farther

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

#36375

On Thu, 15 Jul 2021 20:08:00 +0100
Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:

> On 15/07/2021 18:22, Mr Flibble wrote:
> > Hi!
> > 
> >  From Wikipedia Halting Problem page:
> > 
> > 	For any program f that might determine if programs halt, a
> > 	"pathological" program g, called with some input, can pass
> > its own source and its input to f and then specifically do the
> > 	opposite of what f predicts g will do. No f can exist that
> > 	handles this case.  
> 
> Well, that's awful wording, because it's liable to give readers the 
> impression that some specific g exists which no decider could decide 
> correctly.  That would be nonsense - the fact is that g is derived
> from f, so it would be better to call it N(f) or something [N for
> Nemesis!].
> 
> Then we could say clearly that no f can exist that handles its own
> N(f) case.  This implies that every f gets at least one input wrong
> (e.g. N(f)), so no f can correctly decide halting for all inputs.
> 
> Note that it's the ORDER of choices which is important:  FIRST f is 
> fixed, THEN  N(f) becomes defined (fixed) as a consequence, and f 
> decides N(f) incorrectly.  (Another decider h may decide N(f)
> correctly, but of course that h won't decide N(h) correctly and so
> on.)
> 
> > 
> > To me this looks like everyone is assuming that the halting problem
> > is undecidable based on a misunderstanding of the contradiction
> > crystallized by [Strachen 1965].  
> 
> Do you have a link for [Strachen 1965]?  The only link I've been able
> to find is a short letter of just three paragraphs, here:
> 
>    <https://academic.oup.com/comjnl/article/7/4/313/354243>
> 
> I'll assume that's what you're referring to??
> 
> > 
> > Strachen isn't saying the halting problem is undecidable,   
> 
> Dude, YES HE IS:
> Quote:
>    This left me with an uneasy feeling that the proof must be long
>    and complicated, but in fact it is so short and simple it may be
>    of interest to casual readers.
> 
> HE'S CONFIRMING THAT THE THEOREM IS CORRECT, and has a short proof
> which he then outlines!
> 
> 
> > He saying that
> > there is a contradiction that means that a decider can not be a
> > part of or called by that which is being decided.   
> 
> Dude, HE'S NOT SAYING THAT.
> 
> Quote:
>    ...In each case T(P) has exactly the wrong value, and this
>    contradiction SHOWS THAT THE FUNCTION T CANNOT EXIST.
> 
> [My CAPS.  T is the purported halt decider.]  Where does Strachen say 
> anything about "a decider can not be a part of or called by that
> which is being decided"?
> 
> Get a grip!  JUST READ THE WORDS... :/

You are making exactly the same mistake as everyone else. READ MY WORDS.

/Flibble

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

#36380

On 7/16/2021 7:25 AM, Mr Flibble wrote:
> On Thu, 15 Jul 2021 20:08:00 +0100
> Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
> 
>> On 15/07/2021 18:22, Mr Flibble wrote:
>>> Hi!
>>>
>>>   From Wikipedia Halting Problem page:
>>>
>>> 	For any program f that might determine if programs halt, a
>>> 	"pathological" program g, called with some input, can pass
>>> its own source and its input to f and then specifically do the
>>> 	opposite of what f predicts g will do. No f can exist that
>>> 	handles this case.
>>
>> Well, that's awful wording, because it's liable to give readers the
>> impression that some specific g exists which no decider could decide
>> correctly.  That would be nonsense - the fact is that g is derived
>> from f, so it would be better to call it N(f) or something [N for
>> Nemesis!].
>>
>> Then we could say clearly that no f can exist that handles its own
>> N(f) case.  This implies that every f gets at least one input wrong
>> (e.g. N(f)), so no f can correctly decide halting for all inputs.
>>
>> Note that it's the ORDER of choices which is important:  FIRST f is
>> fixed, THEN  N(f) becomes defined (fixed) as a consequence, and f
>> decides N(f) incorrectly.  (Another decider h may decide N(f)
>> correctly, but of course that h won't decide N(h) correctly and so
>> on.)
>>
>>>
>>> To me this looks like everyone is assuming that the halting problem
>>> is undecidable based on a misunderstanding of the contradiction
>>> crystallized by [Strachen 1965].
>>
>> Do you have a link for [Strachen 1965]?  The only link I've been able
>> to find is a short letter of just three paragraphs, here:
>>
>>     <https://academic.oup.com/comjnl/article/7/4/313/354243>
>>
>> I'll assume that's what you're referring to??
>>
>>>
>>> Strachen isn't saying the halting problem is undecidable,
>>
>> Dude, YES HE IS:
>> Quote:
>>     This left me with an uneasy feeling that the proof must be long
>>     and complicated, but in fact it is so short and simple it may be
>>     of interest to casual readers.
>>
>> HE'S CONFIRMING THAT THE THEOREM IS CORRECT, and has a short proof
>> which he then outlines!
>>
>>
>>> He saying that
>>> there is a contradiction that means that a decider can not be a
>>> part of or called by that which is being decided.
>>
>> Dude, HE'S NOT SAYING THAT.
>>
>> Quote:
>>     ...In each case T(P) has exactly the wrong value, and this
>>     contradiction SHOWS THAT THE FUNCTION T CANNOT EXIST.
>>
>> [My CAPS.  T is the purported halt decider.]  Where does Strachen say
>> anything about "a decider can not be a part of or called by that
>> which is being decided"?
>>

He never says anything like:
     a decider can not be a part of or called by that
     which is being decided.

When he says that function T cannot exist he means that a universal halt 
decider cannot exist.

You and I are the only ones that understand that it is an error for the 
behavior of the halt decider to be a part of the halt deciding decision.
I named this the pathological self-reference(Olcott 2004) error.

My halt decider gets around that problem by remaining a pure simulator 
of its input until after the halt status decision has been made.

>> Get a grip!  JUST READ THE WORDS... :/
> 
> You are making exactly the same mistake as everyone else. READ MY WORDS.
> 
> /Flibble
> 


-- 
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre 
minds." Einstein

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

#36376

On Thu, 15 Jul 2021 20:08:00 +0100
Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:

> On 15/07/2021 18:22, Mr Flibble wrote:
> > Hi!
> > 
> >  From Wikipedia Halting Problem page:
> > 
> > 	For any program f that might determine if programs halt, a
> > 	"pathological" program g, called with some input, can pass
> > its own source and its input to f and then specifically do the
> > 	opposite of what f predicts g will do. No f can exist that
> > 	handles this case.  
> 
> Well, that's awful wording, because it's liable to give readers the 
> impression that some specific g exists which no decider could decide 
> correctly.  That would be nonsense - the fact is that g is derived
> from f, so it would be better to call it N(f) or something [N for
> Nemesis!].
> 
> Then we could say clearly that no f can exist that handles its own
> N(f) case.  This implies that every f gets at least one input wrong
> (e.g. N(f)), so no f can correctly decide halting for all inputs.
> 
> Note that it's the ORDER of choices which is important:  FIRST f is 
> fixed, THEN  N(f) becomes defined (fixed) as a consequence, and f 
> decides N(f) incorrectly.  (Another decider h may decide N(f)
> correctly, but of course that h won't decide N(h) correctly and so
> on.)
> 
> > 
> > To me this looks like everyone is assuming that the halting problem
> > is undecidable based on a misunderstanding of the contradiction
> > crystallized by [Strachen 1965].  
> 
> Do you have a link for [Strachen 1965]?  The only link I've been able
> to find is a short letter of just three paragraphs, here:
> 
>    <https://academic.oup.com/comjnl/article/7/4/313/354243>
> 
> I'll assume that's what you're referring to??
> 
> > 
> > Strachen isn't saying the halting problem is undecidable,   
> 
> Dude, YES HE IS:
> Quote:
>    This left me with an uneasy feeling that the proof must be long
>    and complicated, but in fact it is so short and simple it may be
>    of interest to casual readers.
> 
> HE'S CONFIRMING THAT THE THEOREM IS CORRECT, and has a short proof
> which he then outlines!

NO HE ISN'T. He is saying that T cannot exist as a decider of P because
P is aware of T and attempts to defeat it; this DOES NOT MEAN that a T
cannot decide P where P isn't attempting to defeat T by recursively
referencing it. This is why Strachen refers to is as an "impossible
program".

/Flibble

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

#36383

On 7/16/2021 7:33 AM, Mr Flibble wrote:
> On Thu, 15 Jul 2021 20:08:00 +0100
> Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
> 
>> On 15/07/2021 18:22, Mr Flibble wrote:
>>> Hi!
>>>
>>>   From Wikipedia Halting Problem page:
>>>
>>> 	For any program f that might determine if programs halt, a
>>> 	"pathological" program g, called with some input, can pass
>>> its own source and its input to f and then specifically do the
>>> 	opposite of what f predicts g will do. No f can exist that
>>> 	handles this case.
>>
>> Well, that's awful wording, because it's liable to give readers the
>> impression that some specific g exists which no decider could decide
>> correctly.  That would be nonsense - the fact is that g is derived
>> from f, so it would be better to call it N(f) or something [N for
>> Nemesis!].
>>
>> Then we could say clearly that no f can exist that handles its own
>> N(f) case.  This implies that every f gets at least one input wrong
>> (e.g. N(f)), so no f can correctly decide halting for all inputs.
>>
>> Note that it's the ORDER of choices which is important:  FIRST f is
>> fixed, THEN  N(f) becomes defined (fixed) as a consequence, and f
>> decides N(f) incorrectly.  (Another decider h may decide N(f)
>> correctly, but of course that h won't decide N(h) correctly and so
>> on.)
>>
>>>
>>> To me this looks like everyone is assuming that the halting problem
>>> is undecidable based on a misunderstanding of the contradiction
>>> crystallized by [Strachen 1965].
>>
>> Do you have a link for [Strachen 1965]?  The only link I've been able
>> to find is a short letter of just three paragraphs, here:
>>
>>     <https://academic.oup.com/comjnl/article/7/4/313/354243>
>>
>> I'll assume that's what you're referring to??
>>
>>>
>>> Strachen isn't saying the halting problem is undecidable,
>>
>> Dude, YES HE IS:
>> Quote:
>>     This left me with an uneasy feeling that the proof must be long
>>     and complicated, but in fact it is so short and simple it may be
>>     of interest to casual readers.
>>
>> HE'S CONFIRMING THAT THE THEOREM IS CORRECT, and has a short proof
>> which he then outlines!
> 
> NO HE ISN'T. He is saying that T cannot exist as a decider of P because
> P is aware of T and attempts to defeat it; this DOES NOT MEAN that a T
> cannot decide P where P isn't attempting to defeat T by recursively
> referencing it. This is why Strachen refers to is as an "impossible
> program".
> 
> /Flibble
> 

Conventionally it is understood that the instance of P proves that there 
cannot be any T that always correctly decides the halting status of 
every input.

In the case of my H and P, because my H is a simulating halt decider 
that only acts as a pure simulator until after its halt status decision 
is made the pathological self-reference(olcott 2004) error that you 
correctly object to has no effect on either the behavior of P or the 
halt status decision of H.

H aborts the simulation of its input before any nested H ever returns 
any value to any P. This utterly nullifies the prior issue that seemed 
to prove that P is undecidable.

https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

-- 
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre 
minds." Einstein

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

#36390

Mr Flibble <flibble@reddwarf.jmc> wrote:
> On Thu, 15 Jul 2021 20:08:00 +0100
> Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:

[ .... ]

>> HE'S CONFIRMING THAT THE THEOREM IS CORRECT, and has a short proof
>> which he then outlines!

> NO HE ISN'T. He is saying that T cannot exist as a decider of P ....

He's saying that T cannot exist as a _universal_ decider, because there
exists a program it cannot decide correctly.

> .... because P is aware of T and attempts to defeat it;

That's unsuitably anthropomorphic langauage.  There is no "awareness" in
T.

> this DOES NOT MEAN that a T cannot decide P where P isn't attempting
> to defeat T by recursively referencing it.

Of course not.  Such a T is called a partial halting decider.  Its
existence has nothing to do with the non-existence of a _universal_
halting decider.

Ditto about "attempting" and "defeat".  The plain fact is, for any T,
there exists a P which it incorrectly decides.

> This is why ....

"what", perhaps?

> .... Strachen refers to is as an "impossible program".

He proves there is no such T, yes.

> /Flibble

-- 
Alan Mackenzie (Nuremberg, Germany).

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

#36393

On 7/16/2021 9:44 AM, Alan Mackenzie wrote:
> Mr Flibble <flibble@reddwarf.jmc> wrote:
>> On Thu, 15 Jul 2021 20:08:00 +0100
>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
> 
> [ .... ]
> 
>>> HE'S CONFIRMING THAT THE THEOREM IS CORRECT, and has a short proof
>>> which he then outlines!
> 
>> NO HE ISN'T. He is saying that T cannot exist as a decider of P ....
> 
> He's saying that T cannot exist as a _universal_ decider, because there
> exists a program it cannot decide correctly.
> 
>> .... because P is aware of T and attempts to defeat it;
> 
> That's unsuitably anthropomorphic langauage.  There is no "awareness" in
> T.
> 
>> this DOES NOT MEAN that a T cannot decide P where P isn't attempting
>> to defeat T by recursively referencing it.
> 
> Of course not.  Such a T is called a partial halting decider.  Its
> existence has nothing to do with the non-existence of a _universal_
> halting decider.
> 
> Ditto about "attempting" and "defeat".  The plain fact is, for any T,
> there exists a P which it incorrectly decides.
> 
>> This is why ....
> 
> "what", perhaps?
> 
>> .... Strachen refers to is as an "impossible program".
> 
> He proves there is no such T, yes.
> 
>> /Flibble
> 

Conventionally it is understood that the instance of P proves that there 
cannot be any T that always correctly decides the halting status of 
every input.

// The C equivalent of [Strachey 1965] CPL
void P(u32 x)
{
   if (H(x, x))
     HERE: goto HERE;
}

int main()
{
   Output("Input_Halts = ", H((u32)P, (u32)P));
}

In the case of my H and P, because my H is a simulating halt decider 
that only acts as a pure simulator until after its halt status decision 
is made the pathological self-reference(olcott 2004) error Flibble 
correctly objects to has no effect on either the behavior of P or the 
halt status decision of H.

H aborts the simulation of its input before any nested H ever returns 
any value to any P. This utterly nullifies the prior issue that seemed 
to prove that P is an undecidable input.

When the simulation of P is aborted P stops running. This does not count 
as a P that halts. P has had its execution suspended, not halted.

https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation



-- 
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre 
minds." Einstein

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

#36406

[ Offensive cross-posts removed. ]

In comp.theory olcott <NoOne@nowhere.com> wrote:
> On 7/16/2021 9:44 AM, Alan Mackenzie wrote:
>> Mr Flibble <flibble@reddwarf.jmc> wrote:
>>> On Thu, 15 Jul 2021 20:08:00 +0100
>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:

>> [ .... ]

>>>> HE'S CONFIRMING THAT THE THEOREM IS CORRECT, and has a short proof
>>>> which he then outlines!

>>> NO HE ISN'T. He is saying that T cannot exist as a decider of P ....

>> He's saying that T cannot exist as a _universal_ decider, because there
>> exists a program it cannot decide correctly.

>>> .... because P is aware of T and attempts to defeat it;

>> That's unsuitably anthropomorphic langauage.  There is no "awareness" in
>> T.

>>> this DOES NOT MEAN that a T cannot decide P where P isn't attempting
>>> to defeat T by recursively referencing it.

>> Of course not.  Such a T is called a partial halting decider.  Its
>> existence has nothing to do with the non-existence of a _universal_
>> halting decider.

>> Ditto about "attempting" and "defeat".  The plain fact is, for any T,
>> there exists a P which it incorrectly decides.

>>> This is why ....

>> "what", perhaps?

>>> .... Strachen refers to is as an "impossible program".

>> He proves there is no such T, yes.

>>> /Flibble


> Conventionally it is understood that the instance of P proves that there 
> cannot be any T that always correctly decides the halting status of 
> every input.

"Conventionally" here means by everybody but cranks.  I don't recall any
other candidate false assumption being proffered on these interminable
threads.

> // The C equivalent of [Strachey 1965] CPL
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
> }

> int main()
> {
>   Output("Input_Halts = ", H((u32)P, (u32)P));
> }

> In the case of my H and P, because my H is a simulating halt decider 
> that only acts as a pure simulator until after its halt status decision 
> is made the pathological self-reference(olcott 2004) error Flibble 
> correctly objects to has no effect on either the behavior of P or the 
> halt status decision of H.

The internal mechanism of H isn't of much interest.  It doesn't matter.
As long as it purports to return the halting status of any program/input
pair, there will be such a pair it gets wrong.

> H aborts the simulation of its input before any nested H ever returns 
> any value to any P. This utterly nullifies the prior issue that seemed 
> to prove that P is an undecidable input.

I can't be bothered even to make sense of that.  Whatever, any H is not a
universal halting decider.

> When the simulation of P is aborted P stops running. This does not count 
> as a P that halts. P has had its execution suspended, not halted.

P(P) either halts or it doesn't.  H gets the wrong anwer.


> -- 
> Copyright 2021 Pete Olcott

> "Great spirits have always encountered violent opposition from mediocre 
> minds." Einstein

-- 
Alan Mackenzie (Nuremberg, Germany).

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

#36408

On 7/16/2021 11:39 AM, Alan Mackenzie wrote:
> [ Offensive cross-posts removed. ]
> 
> In comp.theory olcott <NoOne@nowhere.com> wrote:
>> On 7/16/2021 9:44 AM, Alan Mackenzie wrote:
>>> Mr Flibble <flibble@reddwarf.jmc> wrote:
>>>> On Thu, 15 Jul 2021 20:08:00 +0100
>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
> 
>>> [ .... ]
> 
>>>>> HE'S CONFIRMING THAT THE THEOREM IS CORRECT, and has a short proof
>>>>> which he then outlines!
> 
>>>> NO HE ISN'T. He is saying that T cannot exist as a decider of P ....
> 
>>> He's saying that T cannot exist as a _universal_ decider, because there
>>> exists a program it cannot decide correctly.
> 
>>>> .... because P is aware of T and attempts to defeat it;
> 
>>> That's unsuitably anthropomorphic langauage.  There is no "awareness" in
>>> T.
> 
>>>> this DOES NOT MEAN that a T cannot decide P where P isn't attempting
>>>> to defeat T by recursively referencing it.
> 
>>> Of course not.  Such a T is called a partial halting decider.  Its
>>> existence has nothing to do with the non-existence of a _universal_
>>> halting decider.
> 
>>> Ditto about "attempting" and "defeat".  The plain fact is, for any T,
>>> there exists a P which it incorrectly decides.
> 
>>>> This is why ....
> 
>>> "what", perhaps?
> 
>>>> .... Strachen refers to is as an "impossible program".
> 
>>> He proves there is no such T, yes.
> 
>>>> /Flibble
> 
> 
>> Conventionally it is understood that the instance of P proves that there
>> cannot be any T that always correctly decides the halting status of
>> every input.
> 
> "Conventionally" here means by everybody but cranks.  I don't recall any
> other candidate false assumption being proffered on these interminable
> threads.
> 
>> // The C equivalent of [Strachey 1965] CPL
>> void P(u32 x)
>> {
>>    if (H(x, x))
>>      HERE: goto HERE;
>> }
> 
>> int main()
>> {
>>    Output("Input_Halts = ", H((u32)P, (u32)P));
>> }
> 
>> In the case of my H and P, because my H is a simulating halt decider
>> that only acts as a pure simulator until after its halt status decision
>> is made the pathological self-reference(olcott 2004) error Flibble
>> correctly objects to has no effect on either the behavior of P or the
>> halt status decision of H.
> 
> The internal mechanism of H isn't of much interest.  It doesn't matter.
> As long as it purports to return the halting status of any program/input
> pair, there will be such a pair it gets wrong.
> 
>> H aborts the simulation of its input before any nested H ever returns
>> any value to any P. This utterly nullifies the prior issue that seemed
>> to prove that P is an undecidable input.
> 
> I can't be bothered even to make sense of that.  Whatever, any H is not a
> universal halting decider.

In other words I am holding my hands over my ears blah, blah, blah I 
can't hear you but I know that you are wrong because I am a mindless 
conformity robot that totally lacks any capacity to think for myself.


There can be no H that correctly returns the halts status of an input P 
that does the opposite of whatever H(P,P) decides.

Nobody ever bothered to think this ALL THE WAY THROUGH to see that a 
correct halt decider need not return any value to its input.

Everyone that knows software engineering knows that no function ever 
returns any value to its caller when its caller calls it in infinite 
recursion.

The call H(P,P) from P is essentially infinite recursion.
H sees this and aborts the call.

https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

> 
>> When the simulation of P is aborted P stops running. This does not count
>> as a P that halts. P has had its execution suspended, not halted.
> 
> P(P) either halts or it doesn't.  H gets the wrong anwer.
> 

The is what a mindless conformity robot would say.

Groupthink is a phenomenon that occurs when a group of well-intentioned 
people makes irrational or non-optimal decisions spurred by the urge to 
conform or the belief that dissent is impossible.

https://www.psychologytoday.com/us/basics/groupthink




> 
>> -- 
>> Copyright 2021 Pete Olcott
> 
>> "Great spirits have always encountered violent opposition from mediocre
>> minds." Einstein
> 


-- 
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre 
minds." Einstein

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

#36409

On Fri, 16 Jul 2021 12:13:26 -0500
olcott <NoOne@NoWhere.com> wrote:
 
> 
> The is what a mindless conformity robot would say.
> 
> Groupthink is a phenomenon that occurs when a group of
> well-intentioned people makes irrational or non-optimal decisions
> spurred by the urge to conform or the belief that dissent is
> impossible.

Sounds an awful lot like Christianity but you seem content being part
of that particular groupthink. In other words you are being a hypocrite
moaning about people being part of a groupthink.

/Flibble

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

#36410

On 7/16/2021 12:26 PM, Mr Flibble wrote:
> On Fri, 16 Jul 2021 12:13:26 -0500
> olcott <NoOne@NoWhere.com> wrote:
>   
>>
>> The is what a mindless conformity robot would say.
>>
>> Groupthink is a phenomenon that occurs when a group of
>> well-intentioned people makes irrational or non-optimal decisions
>> spurred by the urge to conform or the belief that dissent is
>> impossible.
> 
> Sounds an awful lot like Christianity but you seem content being part
> of that particular groupthink. In other words you are being a hypocrite
> moaning about people being part of a groupthink.
> 
> /Flibble
> 

I am absolutely an anti-conformist.
Until I independently verify a claim I treat it as possibly false.

Since it is impossible to conclusively proof that anything existed five 
minutes ago we cannot know with certainty that Christ ever existed.

https://en.wikipedia.org/wiki/Omphalos_hypothesis#Five-minute_hypothesis

None-the-less his commandment to love one another is necessarily the 
best way to be on the basis that it makes perfect sense.

Most all of those that falsely call themselves Christian miss this key 
point. They put loving one another on a back burner and focus instead on 
getting others to obey a set of rules.

Loving others with empathy is the key to all righteousness specifically 
because it produces the best fruits.

-- 
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre 
minds." Einstein

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

#36420

Mr Flibble <flibble@reddwarf.jmc> writes: 

> On Fri, 16 Jul 2021 12:13:26 -0500
> olcott <NoOne@NoWhere.com> wrote:
>  
>> 
>> The is what a mindless conformity robot would say.
>> 
>> Groupthink is a phenomenon that occurs when a group of
>> well-intentioned people makes irrational or non-optimal decisions
>> spurred by the urge to conform or the belief that dissent is
>> impossible.
>
> Sounds an awful lot like Christianity but you seem content being part
> of that particular groupthink.

I don't think you can level that one at PO.  He has declared himself to
be God in a court of law (look it up, you can find the details online)
and he has published a website which he uses to "bring new scripture to
the world".  That not Christianity, it's NPD.

-- 
Ben.

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

#36411

On 2021-07-16 11:13, olcott wrote:
> On 7/16/2021 11:39 AM, Alan Mackenzie wrote:
>> [ Offensive cross-posts removed. ]
>>
>> In comp.theory olcott <NoOne@nowhere.com> wrote:
>>> On 7/16/2021 9:44 AM, Alan Mackenzie wrote:
>>>> Mr Flibble <flibble@reddwarf.jmc> wrote:
>>>>> On Thu, 15 Jul 2021 20:08:00 +0100
>>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
>>
>>>> [ .... ]
>>
>>>>>> HE'S CONFIRMING THAT THE THEOREM IS CORRECT, and has a short proof
>>>>>> which he then outlines!
>>
>>>>> NO HE ISN'T. He is saying that T cannot exist as a decider of P ....
>>
>>>> He's saying that T cannot exist as a _universal_ decider, because there
>>>> exists a program it cannot decide correctly.
>>
>>>>> .... because P is aware of T and attempts to defeat it;
>>
>>>> That's unsuitably anthropomorphic langauage.  There is no 
>>>> "awareness" in
>>>> T.
>>
>>>>> this DOES NOT MEAN that a T cannot decide P where P isn't attempting
>>>>> to defeat T by recursively referencing it.
>>
>>>> Of course not.  Such a T is called a partial halting decider.  Its
>>>> existence has nothing to do with the non-existence of a _universal_
>>>> halting decider.
>>
>>>> Ditto about "attempting" and "defeat".  The plain fact is, for any T,
>>>> there exists a P which it incorrectly decides.
>>
>>>>> This is why ....
>>
>>>> "what", perhaps?
>>
>>>>> .... Strachen refers to is as an "impossible program".
>>
>>>> He proves there is no such T, yes.
>>
>>>>> /Flibble
>>
>>
>>> Conventionally it is understood that the instance of P proves that there
>>> cannot be any T that always correctly decides the halting status of
>>> every input.
>>
>> "Conventionally" here means by everybody but cranks.  I don't recall any
>> other candidate false assumption being proffered on these interminable
>> threads.
>>
>>> // The C equivalent of [Strachey 1965] CPL
>>> void P(u32 x)
>>> {
>>>    if (H(x, x))
>>>      HERE: goto HERE;
>>> }
>>
>>> int main()
>>> {
>>>    Output("Input_Halts = ", H((u32)P, (u32)P));
>>> }
>>
>>> In the case of my H and P, because my H is a simulating halt decider
>>> that only acts as a pure simulator until after its halt status decision
>>> is made the pathological self-reference(olcott 2004) error Flibble
>>> correctly objects to has no effect on either the behavior of P or the
>>> halt status decision of H.
>>
>> The internal mechanism of H isn't of much interest.  It doesn't matter.
>> As long as it purports to return the halting status of any program/input
>> pair, there will be such a pair it gets wrong.
>>
>>> H aborts the simulation of its input before any nested H ever returns
>>> any value to any P. This utterly nullifies the prior issue that seemed
>>> to prove that P is an undecidable input.
>>
>> I can't be bothered even to make sense of that.  Whatever, any H is not a
>> universal halting decider.
> 
> In other words I am holding my hands over my ears blah, blah, blah I 
> can't hear you but I know that you are wrong because I am a mindless 
> conformity robot that totally lacks any capacity to think for myself.
> 
> 
> There can be no H that correctly returns the halts status of an input P 
> that does the opposite of whatever H(P,P) decides.
> 
> Nobody ever bothered to think this ALL THE WAY THROUGH to see that a 
> correct halt decider need not return any value to its input.

For starters, No function *ever* returns a value to its input. It return 
a value to its *caller*.

Second, a decider, *by definition* must always return a value for every 
possible input. Otherwise it is not a decider.

> Everyone that knows software engineering knows that no function ever 
> returns any value to its caller when its caller calls it in infinite 
> recursion.

And the relevance of this is what exactly? A decider, by definition, 
must always return a value for every possible input. Therefore if you 
are writing a decider, it must be written in a way which precludes any 
input from ever getting stuck in infinite recursion. Otherwise you have 
failed to create a decider.

André

-- 
To email remove 'invalid' & replace 'gm' with well known Google mail 
service.

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

#36421

On 7/16/2021 12:53 PM, André G. Isaak wrote:
> On 2021-07-16 11:13, olcott wrote:
>> On 7/16/2021 11:39 AM, Alan Mackenzie wrote:
>>> [ Offensive cross-posts removed. ]
>>>
>>> In comp.theory olcott <NoOne@nowhere.com> wrote:
>>>> On 7/16/2021 9:44 AM, Alan Mackenzie wrote:
>>>>> Mr Flibble <flibble@reddwarf.jmc> wrote:
>>>>>> On Thu, 15 Jul 2021 20:08:00 +0100
>>>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
>>>
>>>>> [ .... ]
>>>
>>>>>>> HE'S CONFIRMING THAT THE THEOREM IS CORRECT, and has a short proof
>>>>>>> which he then outlines!
>>>
>>>>>> NO HE ISN'T. He is saying that T cannot exist as a decider of P ....
>>>
>>>>> He's saying that T cannot exist as a _universal_ decider, because 
>>>>> there
>>>>> exists a program it cannot decide correctly.
>>>
>>>>>> .... because P is aware of T and attempts to defeat it;
>>>
>>>>> That's unsuitably anthropomorphic langauage.  There is no 
>>>>> "awareness" in
>>>>> T.
>>>
>>>>>> this DOES NOT MEAN that a T cannot decide P where P isn't attempting
>>>>>> to defeat T by recursively referencing it.
>>>
>>>>> Of course not.  Such a T is called a partial halting decider.  Its
>>>>> existence has nothing to do with the non-existence of a _universal_
>>>>> halting decider.
>>>
>>>>> Ditto about "attempting" and "defeat".  The plain fact is, for any T,
>>>>> there exists a P which it incorrectly decides.
>>>
>>>>>> This is why ....
>>>
>>>>> "what", perhaps?
>>>
>>>>>> .... Strachen refers to is as an "impossible program".
>>>
>>>>> He proves there is no such T, yes.
>>>
>>>>>> /Flibble
>>>
>>>
>>>> Conventionally it is understood that the instance of P proves that 
>>>> there
>>>> cannot be any T that always correctly decides the halting status of
>>>> every input.
>>>
>>> "Conventionally" here means by everybody but cranks.  I don't recall any
>>> other candidate false assumption being proffered on these interminable
>>> threads.
>>>
>>>> // The C equivalent of [Strachey 1965] CPL
>>>> void P(u32 x)
>>>> {
>>>>    if (H(x, x))
>>>>      HERE: goto HERE;
>>>> }
>>>
>>>> int main()
>>>> {
>>>>    Output("Input_Halts = ", H((u32)P, (u32)P));
>>>> }
>>>
>>>> In the case of my H and P, because my H is a simulating halt decider
>>>> that only acts as a pure simulator until after its halt status decision
>>>> is made the pathological self-reference(olcott 2004) error Flibble
>>>> correctly objects to has no effect on either the behavior of P or the
>>>> halt status decision of H.
>>>
>>> The internal mechanism of H isn't of much interest.  It doesn't matter.
>>> As long as it purports to return the halting status of any program/input
>>> pair, there will be such a pair it gets wrong.
>>>
>>>> H aborts the simulation of its input before any nested H ever returns
>>>> any value to any P. This utterly nullifies the prior issue that seemed
>>>> to prove that P is an undecidable input.
>>>
>>> I can't be bothered even to make sense of that.  Whatever, any H is 
>>> not a
>>> universal halting decider.
>>
>> In other words I am holding my hands over my ears blah, blah, blah I 
>> can't hear you but I know that you are wrong because I am a mindless 
>> conformity robot that totally lacks any capacity to think for myself.
>>
>>
>> There can be no H that correctly returns the halts status of an input 
>> P that does the opposite of whatever H(P,P) decides.
>>
>> Nobody ever bothered to think this ALL THE WAY THROUGH to see that a 
>> correct halt decider need not return any value to its input.
> 
> For starters, No function *ever* returns a value to its input. It return 
> a value to its *caller*.
> 

In the above example the outermost H simulates P with input P such that 
the simulated P calls H(P,P). The outermost H aborts that infinitely 
recursive sequence because H ever returns any value to the P that called 
it.

> Second, a decider, *by definition* must always return a value for every 
> possible input. Otherwise it is not a decider.
> 

When the decider is called in an infinitely recursive chain it need not 
return an infinite number of values. No function called in infinite 
recursion ever returns any value to its caller.

>> Everyone that knows software engineering knows that no function ever 
>> returns any value to its caller when its caller calls it in infinite 
>> recursion.
> 
> And the relevance of this is what exactly? A decider, by definition, 
> must always return a value for every possible input. 

The outermost H does return a value to its caller.
All of the inner H invocations are aborted when their caller it aborted.

> Therefore if you 
> are writing a decider, it must be written in a way which precludes any 
> input from ever getting stuck in infinite recursion. Otherwise you have 
> failed to create a decider.
> 
> André
> 

I have done this: Infinite_loop() is the first concrete example and 
Infinite_Recursion() is the second.

https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

-- 
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre 
minds." Einstein

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

#36424

On 2021-07-16 12:39, olcott wrote:
> On 7/16/2021 12:53 PM, André G. Isaak wrote:
>> On 2021-07-16 11:13, olcott wrote:
>>> On 7/16/2021 11:39 AM, Alan Mackenzie wrote:
>>>> [ Offensive cross-posts removed. ]
>>>>
>>>> In comp.theory olcott <NoOne@nowhere.com> wrote:
>>>>> On 7/16/2021 9:44 AM, Alan Mackenzie wrote:
>>>>>> Mr Flibble <flibble@reddwarf.jmc> wrote:
>>>>>>> On Thu, 15 Jul 2021 20:08:00 +0100
>>>>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
>>>>
>>>>>> [ .... ]
>>>>
>>>>>>>> HE'S CONFIRMING THAT THE THEOREM IS CORRECT, and has a short proof
>>>>>>>> which he then outlines!
>>>>
>>>>>>> NO HE ISN'T. He is saying that T cannot exist as a decider of P ....
>>>>
>>>>>> He's saying that T cannot exist as a _universal_ decider, because 
>>>>>> there
>>>>>> exists a program it cannot decide correctly.
>>>>
>>>>>>> .... because P is aware of T and attempts to defeat it;
>>>>
>>>>>> That's unsuitably anthropomorphic langauage.  There is no 
>>>>>> "awareness" in
>>>>>> T.
>>>>
>>>>>>> this DOES NOT MEAN that a T cannot decide P where P isn't attempting
>>>>>>> to defeat T by recursively referencing it.
>>>>
>>>>>> Of course not.  Such a T is called a partial halting decider.  Its
>>>>>> existence has nothing to do with the non-existence of a _universal_
>>>>>> halting decider.
>>>>
>>>>>> Ditto about "attempting" and "defeat".  The plain fact is, for any T,
>>>>>> there exists a P which it incorrectly decides.
>>>>
>>>>>>> This is why ....
>>>>
>>>>>> "what", perhaps?
>>>>
>>>>>>> .... Strachen refers to is as an "impossible program".
>>>>
>>>>>> He proves there is no such T, yes.
>>>>
>>>>>>> /Flibble
>>>>
>>>>
>>>>> Conventionally it is understood that the instance of P proves that 
>>>>> there
>>>>> cannot be any T that always correctly decides the halting status of
>>>>> every input.
>>>>
>>>> "Conventionally" here means by everybody but cranks.  I don't recall 
>>>> any
>>>> other candidate false assumption being proffered on these interminable
>>>> threads.
>>>>
>>>>> // The C equivalent of [Strachey 1965] CPL
>>>>> void P(u32 x)
>>>>> {
>>>>>    if (H(x, x))
>>>>>      HERE: goto HERE;
>>>>> }
>>>>
>>>>> int main()
>>>>> {
>>>>>    Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>> }
>>>>
>>>>> In the case of my H and P, because my H is a simulating halt decider
>>>>> that only acts as a pure simulator until after its halt status 
>>>>> decision
>>>>> is made the pathological self-reference(olcott 2004) error Flibble
>>>>> correctly objects to has no effect on either the behavior of P or the
>>>>> halt status decision of H.
>>>>
>>>> The internal mechanism of H isn't of much interest.  It doesn't matter.
>>>> As long as it purports to return the halting status of any 
>>>> program/input
>>>> pair, there will be such a pair it gets wrong.
>>>>
>>>>> H aborts the simulation of its input before any nested H ever returns
>>>>> any value to any P. This utterly nullifies the prior issue that seemed
>>>>> to prove that P is an undecidable input.
>>>>
>>>> I can't be bothered even to make sense of that.  Whatever, any H is 
>>>> not a
>>>> universal halting decider.
>>>
>>> In other words I am holding my hands over my ears blah, blah, blah I 
>>> can't hear you but I know that you are wrong because I am a mindless 
>>> conformity robot that totally lacks any capacity to think for myself.
>>>
>>>
>>> There can be no H that correctly returns the halts status of an input 
>>> P that does the opposite of whatever H(P,P) decides.
>>>
>>> Nobody ever bothered to think this ALL THE WAY THROUGH to see that a 
>>> correct halt decider need not return any value to its input.
>>
>> For starters, No function *ever* returns a value to its input. It 
>> return a value to its *caller*.
>>
> 
> In the above example the outermost H simulates P with input P such that 
> the simulated P calls H(P,P). The outermost H aborts that infinitely 
> recursive sequence because H ever returns any value to the P that called 
> it.

So which invocation of a function do you claim is supposed to return a 
value to its *input*?

>> Second, a decider, *by definition* must always return a value for 
>> every possible input. Otherwise it is not a decider.
>>
> 
> When the decider is called in an infinitely recursive chain it need not 
> return an infinite number of values. No function called in infinite 
> recursion ever returns any value to its caller.

By definition, a decider *always* returns a value. That definition 
doesn't say it always returns a value except in situations where it 
can't. If such situations exist, it is not a decider. Look up the word 
'always' in a dictionary. It doesn't mean the same thing as 'sometimes'.

>>> Everyone that knows software engineering knows that no function ever 
>>> returns any value to its caller when its caller calls it in infinite 
>>> recursion.
>>
>> And the relevance of this is what exactly? A decider, by definition, 
>> must always return a value for every possible input. 
> 
> The outermost H does return a value to its caller.
> All of the inner H invocations are aborted when their caller it aborted.

*Every* instance of H which is called must return a value or your H 
fails to qualify as a decider. Its not just the outermost one that matters.

André

-- 
To email remove 'invalid' & replace 'gm' with well known Google mail 
service.

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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.theory

csiph-web