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

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

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

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

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

On 7/16/2021 2:57 PM, André G. Isaak wrote:
> On 2021-07-16 13:40, olcott wrote:
>> On 7/16/2021 1:52 PM, André G. Isaak wrote:
>>> 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'.
>>>
>>
>> So in other words you fail to comprehend the basic software
>> engineering principle that no function called in infinite recursion
>> ever returns to its caller. I would say that this is very very dumb on
>> your part.
>
> You seem to be the one with the comprehension problem.
>
> I am fully aware that a function called in infinite recursion will never
> return.
>

void P(u32 x)
{ if (H(x, x))
HERE: goto HERE;
}

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

If you truly understood this and understood that H <is> a pure x86
emulator of P until H matches a non-halting behavior pattern then you
would understand the H must not return a value to P in the above
computation.

On 7/16/2021 3:30 PM, André G. Isaak wrote:
> On 2021-07-16 14:09, olcott wrote:
>> On 7/16/2021 2:57 PM, André G. Isaak wrote:
>>> On 2021-07-16 13:40, olcott wrote:
>>>> On 7/16/2021 1:52 PM, André G. Isaak wrote:
>>>>> 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'.
>>>>>
>>>>
>>>> So in other words you fail to comprehend the basic software
>>>> engineering principle that no function called in infinite recursion
>>>> ever returns to its caller. I would say that this is very very dumb
>>>> on your part.
>>>
>>> You seem to be the one with the comprehension problem.
>>>
>>> I am fully aware that a function called in infinite recursion will
>>> never return.
>>>
>>
>> void P(u32 x)
>> {
>>    if (H(x, x))
>>      HERE: goto HERE;
>> }
>>
>> int main()
>> {
>>    Output("Input_Halts = ", H((u32)P, (u32)P));
>> }
>>
>> If you truly understood this and understood that H <is> a pure x86
>> emulator of P until H matches a non-halting behavior pattern then you
>> would understand the H must not return a value to P in the above
>> computation.
>
>
> And if you understood what the word *requirement* meant, you'd

On 7/16/2021 5:09 PM, André G. Isaak wrote:
> On 2021-07-16 15:06, olcott wrote:
>> On 7/16/2021 3:30 PM, André G. Isaak wrote:
>>> On 2021-07-16 14:09, olcott wrote:
>>>> On 7/16/2021 2:57 PM, André G. Isaak wrote:
>>>>> On 2021-07-16 13:40, olcott wrote:
>>>>>> On 7/16/2021 1:52 PM, André G. Isaak wrote:
>>>>>>> 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'.
>>>>>>>
>>>>>>
>>>>>> So in other words you fail to comprehend the basic software
>>>>>> engineering principle that no function called in infinite
>>>>>> recursion ever returns to its caller. I would say that this is
>>>>>> very very dumb on your part.
>>>>>
>>>>> You seem to be the one with the comprehension problem.
>>>>>
>>>>> I am fully aware that a function called in infinite recursion will
>>>>> never return.
>>>>>
>>>>
>>>> void P(u32 x)
>>>> {
>>>>    if (H(x, x))
>>>>      HERE: goto HERE;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>    Output("Input_Halts = ", H((u32)P, (u32)P));
>>>> }
>>>>
>>>> If you truly understood this and understood that H <is> a pure x86
>>>> emulator of P until H matches a non-halting behavior pattern then
>>>> you would understand the H must not return a value to P in the above
>>>> computation.
>>>
>>>
>>> And if you understood what the word *requirement* meant, you'd
>>
>> If you require 2 > 5 then you are simply wrong.
>
> You're clearly the master of completely specious analogies. This one is
> even stupider than the various natural language analogies you've been
> tossing out recently.
>
> The requirement that a decider always return a value is nothing like the
> above 'requirement', which is simply a false statement. Functions are
> written all the time which are guaranteed to return a value to their
> caller. They accomplish this by being written in a way which precludes
> them from being stuck in infinite loops or infinite recursion. The
> existence of countless such functions clearly shows that this
> requirement is not unreasonable.
>
>> If anyone requires a function to return a value to its caller when
>> called in infinite recursion then this requirement is simply wrong.
>
> No one is requiring that a function return a value to its caller when
> called in infinite recursion. They are requiring that a program which
> purports to be a decider be written in such a way that it doesn't get
> into infinite recursion in the first place. Otherwise it can't meet the
> requirement that a decider always return a value.
>
> The fact that your implementation doesn't meet this requirement in no
> way entails that the requirement is 'wrong'. It just means that you have
> failed to construct a decider.
>
>> Perhaps you are too stupid to understand this.
>>
>>> understand that if it is the case that H cannot return a value to P
>>> in the above computation that H fails to qualify as a decider.
>>>
>>
>> In the actual code shown below it it not possible for H to correctly
>> return any value to P, thus proving that any requirement that H return
>> a value to P is simply wrong.
>
> No. It shows that your H fails to meet the requirement. It in no way
> shows that there is anything 'wrong' with the requirement.
>
> André
>

On 7/17/2021 4:39 AM, Alan Mackenzie wrote:
> olcott <NoOne@nowhere.com> wrote:
>> On 7/16/2021 4:30 PM, Alan Mackenzie wrote:
>>> olcott <NoOne@nowhere.com> wrote:
>>>> On 7/16/2021 3:19 PM, Alan Mackenzie wrote:
>>>>> olcott <NoOne@nowhere.com> wrote:
>>>>>> On 7/16/2021 1:25 PM, Alan Mackenzie wrote:
>
> [ .... ]
>
>>>> You say that all input that stops running proves that it halts my
>>>> halt decider causes Infinite_Loop() to stop running.
>
>>> That "sentence" doesn't parse.
>
>> Simulating halt decider is merely fulfilling the requirements of this
>> axiom:
>
>> 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.
>
> That's a strange notion to call an axiom. All it seems to be saying is
> that simulation is possible.
>

It is the equivalence of UTM(⟨P⟩,I) and TM(P,I)
Learned by rote people fail to notice this.

>> Simulating halt decider H is only answering the question:
>> Would the input halt on its input if H never stopped simulating it?
>> (a) An answer of "no" universally means that the input never halts.
>> (b) An answer of "yes" universally means that the input halts.
>
> Seems over-complicated. The question should be "does the input program
> halt?".
>

The new axioms are not subject to the pathological self-reference error.

The halt decider acts as a pure simulator until after its halt status
decision has been made. This eliminates the possibility of any feedback
loop where the halt decider has any effect on the behavior of its input.

For all computations that halt without intervention, the simulating halt
decider remains in pure simulator mode.

For all computations that do not halt without intervention, the
simulating halt decide immediately aborts the simulation of its input as
soon as a non-halting behavior pattern is recognized.

The above system makes it impossible for the input to prevent a correct
halt status decision.

Here is a complete example:

void P(u32 x)
{ if (H(x, x))
HERE: goto HERE;
}

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

_P()
[00000c36](01) 55 push ebp
[00000c37](02) 8bec mov ebp,esp
[00000c39](03) 8b4508 mov eax,[ebp+08]
[00000c3c](01) 50 push eax
[00000c3d](03) 8b4d08 mov ecx,[ebp+08]
[00000c40](01) 51 push ecx
[00000c41](05) e820fdffff call 00000966
[00000c46](03) 83c408 add esp,+08
[00000c49](02) 85c0 test eax,eax
[00000c4b](02) 7402 jz 00000c4f
[00000c4d](02) ebfe jmp 00000c4d
[00000c4f](01) 5d pop ebp
[00000c50](01) c3 ret
Size in bytes:(0027) [00000c50]

_main()
[00000c56](01) 55 push ebp
[00000c57](02) 8bec mov ebp,esp
[00000c59](05) 68360c0000 push 00000c36
[00000c5e](05) 68360c0000 push 00000c36
[00000c63](05) e8fefcffff call 00000966
[00000c68](03) 83c408 add esp,+08
[00000c6b](01) 50 push eax
[00000c6c](05) 6857030000 push 00000357
[00000c71](05) e810f7ffff call 00000386
[00000c76](03) 83c408 add esp,+08
[00000c79](02) 33c0 xor eax,eax
[00000c7b](01) 5d pop ebp
[00000c7c](01) c3 ret
Size in bytes:(0039) [00000c7c]

===============================
....[00000c56][0010172a][00000000] 55 push ebp
....[00000c57][0010172a][00000000] 8bec mov ebp,esp
....[00000c59][00101726][00000c36] 68360c0000 push 00000c36 // push P
....[00000c5e][00101722][00000c36] 68360c0000 push 00000c36 // push P
....[00000c63][0010171e][00000c68] e8fefcffff call 00000966 // call H

Begin Local Halt Decider Simulation at Machine Address:c36
....[00000c36][002117ca][002117ce] 55 push ebp
....[00000c37][002117ca][002117ce] 8bec mov ebp,esp
....[00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08]
....[00000c3c][002117c6][00000c36] 50 push eax // push P
....[00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08]
....[00000c40][002117c2][00000c36] 51 push ecx // push P
....[00000c41][002117be][00000c46] e820fdffff call 00000966 // call H
....[00000c36][0025c1f2][0025c1f6] 55 push ebp
....[00000c37][0025c1f2][0025c1f6] 8bec mov ebp,esp
....[00000c39][0025c1f2][0025c1f6] 8b4508 mov eax,[ebp+08]
....[00000c3c][0025c1ee][00000c36] 50 push eax // push P
....[00000c3d][0025c1ee][00000c36] 8b4d08 mov ecx,[ebp+08]
....[00000c40][0025c1ea][00000c36] 51 push ecx // push P
....[00000c41][0025c1e6][00000c46] e820fdffff call 00000966 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Because the halt decider acts as a pure simulator until after its halt
status decision is made it can ignore its own address range in any
execution trace basis of its halt status decision.

This means that the above repeating sequence of the first 7 instructions
pf P() prove that P() will never halt. None of these 7 instructions can
possibly break out of this infinite repetition.

....[00000c68][0010172a][00000000] 83c408 add esp,+08
....[00000c6b][00101726][00000000] 50 push eax
....[00000c6c][00101722][00000357] 6857030000 push 00000357
---[00000c71][00101722][00000357] e810f7ffff call 00000386
Input_Halts = 0
....[00000c76][0010172a][00000000] 83c408 add esp,+08
....[00000c79][0010172a][00000000] 33c0 xor eax,eax
....[00000c7b][0010172e][00100000] 5d pop ebp
....[00000c7c][00101732][00000068] c3 ret
Number_of_User_Instructions(27)
Number of Instructions Executed(23721)

> [ .... ]
>
>>>>> That concept "proof", in the mathematical sense, is one you don't
>>>>> understand. It's the fact that things can be shown to be absolutely
>>>>> correct or absolutely incorrect, without a shadow of doubt, for all time.
>>>>> If you could understand that, you'd be less pig-headed and possibly
>>>>> amenable to the truth.
>
>>>> An actual working program that shows all of the steps of correctly
>>>> deciding the impossible inputs supersedes and over-rules and proof to
>>>> the contrary that relies on false assumptions about the details of
>>>> unspecified steps.
>
>>> No it doesn't. It's merely erroneous. Like I said, you do not
>>> understand the concept of proof - you literally don't get it.
>
>> When you start with premises that can be verified as definitely true and
>> only apply truth preserving operations to these true premises then the
>> consequence/conclusion is necessarily true.
>
> That's one form of proof, yes. But you don't get it - you don't
> understand in the soul of your being that something mathematically proven
> is absolute truth. You seem to think something proven is merely some
> sort of provisional result. You are wrong.
>

The HP proof only show that no correct halt status can be returned to an
input that is designed to do the opposite of whatever the halt decider
decides.

Categorically exhaustive reasoning (my system of reasoning) finds a key
gap in this proof. I provided all the details above.

When H aborts its simulation of P before ever returning any value to P
it escapes the pathological self-reference(Olcott 2004) error.

Because this second level H is merely a part of the slave process that
is under the total control of the master H, the master H can cut off
simulation of the slave process at any point.

A slave decider need not return any value because it can have its
execution cut off at any point by its master.

As shown above the second time that a slave P calls H(P,P) its whole
slave process is terminated. Because the H in this slave process is a
part of a slave process its master can cut it off at any time.

>> Other forms of "proof" that diverge for this model are bogus.
>
> You could hardly be more wrong, here. For example, there is proof by
> contradiction. Here we assume, provisionally, something we wish to show
> is false, and by "truth preserving arguments" show that this leads to a
> contradiction. Thus this assumption is proven wrong, and we have shown
> the something to be false.
>

That is not a divergence.

>>> You don't understand the proofs of the halting problem that you have
>>> quoted here over the months and years. You do not understand that
>>> some things are unassailably and eternally true. Pythagoras's Theorem
>>> is one example - a plane triangle with sides 3, 4, and 5 will have an
>>> exact right angle. The impossibility of a universal halting decider
>>> is another example.
>
>>>> Every HP proof is never more than a sketch of a proof because it
>>>> always leaves out almost all of the details of the definition of the
>>>> computations.
>
>>> You don't get it: it leaves out unimportant details which are
>>> irrelevant to the proof. The internal structure of the computations
>>> is wholly unimportant. It doesn't matter. Whether by analysis, or
>>> simulation, or magic is wholly unimportant - just that a yes/no
>>> answer is always returned, and the same answer is always return for
>>> the same input.
>
> [ .... ]
>
>> --
>> Copyright 2021 Pete Olcott
>
>> "Great spirits have always encountered violent opposition from mediocre
>> minds." Einstein
>

On 7/16/2021 5:48 PM, André G. Isaak wrote:
> On 2021-07-16 16:24, olcott wrote:
>> On 7/16/2021 5:09 PM, André G. Isaak wrote:
>>> On 2021-07-16 15:06, olcott wrote:
>>>> On 7/16/2021 3:30 PM, André G. Isaak wrote:
>>>>> On 2021-07-16 14:09, olcott wrote:
>>>>>> On 7/16/2021 2:57 PM, André G. Isaak wrote:
>>>>>>> On 2021-07-16 13:40, olcott wrote:
>>>>>>>> On 7/16/2021 1:52 PM, André G. Isaak wrote:
>>>>>>>>> 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'.
>>>>>>>>>
>>>>>>>>
>>>>>>>> So in other words you fail to comprehend the basic software
>>>>>>>> engineering principle that no function called in infinite
>>>>>>>> recursion ever returns to its caller. I would say that this is
>>>>>>>> very very dumb on your part.
>>>>>>>
>>>>>>> You seem to be the one with the comprehension problem.
>>>>>>>
>>>>>>> I am fully aware that a function called in infinite recursion
>>>>>>> will never return.
>>>>>>>
>>>>>>
>>>>>> void P(u32 x)
>>>>>> {
>>>>>>    if (H(x, x))
>>>>>>      HERE: goto HERE;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>>    Output("Input_Halts = ", H((u32)P, (u32)P));
>>>>>> }
>>>>>>
>>>>>> If you truly understood this and understood that H <is> a pure x86
>>>>>> emulator of P until H matches a non-halting behavior pattern then
>>>>>> you would understand the H must not return a value to P in the
>>>>>> above computation.
>>>>>
>>>>>
>>>>> And if you understood what the word *requirement* meant, you'd
>>>>
>>>> If you require 2 > 5 then you are simply wrong.
>>>
>>> You're clearly the master of completely specious analogies. This one
>>> is even stupider than the various natural language analogies you've
>>> been tossing out recently.
>>>
>>> The requirement that a decider always return a value is nothing like
>>> the above 'requirement', which is simply a false statement. Functions
>>> are written all the time which are guaranteed to return a value to
>>> their caller. They accomplish this by being written in a way which
>>> precludes them from being stuck in infinite loops or infinite
>>> recursion. The existence of countless such functions clearly shows
>>> that this requirement is not unreasonable.
>>>
>>>> If anyone requires a function to return a value to its caller when
>>>> called in infinite recursion then this requirement is simply wrong.
>>>
>>> No one is requiring that a function return a value to its caller when
>>> called in infinite recursion. They are requiring that a program which
>>> purports to be a decider be written in such a way that it doesn't get
>>> into infinite recursion in the first place. Otherwise it can't meet
>>> the requirement that a decider always return a value.
>>>
>>> The fact that your implementation doesn't meet this requirement in no
>>> way entails that the requirement is 'wrong'. It just means that you
>>> have failed to construct a decider.
>>>
>>>> Perhaps you are too stupid to understand this.
>>>>
>>>>> understand that if it is the case that H cannot return a value to P
>>>>> in the above computation that H fails to qualify as a decider.
>>>>>
>>>>
>>>> In the actual code shown below it it not possible for H to correctly
>>>> return any value to P, thus proving that any requirement that H
>>>> return a value to P is simply wrong.
>>>
>>> No. It shows that your H fails to meet the requirement. It in no way
>>> shows that there is anything 'wrong' with the requirement.
>>>
>>> André
>>>
>>
>> It is very obvious from the details of this code when we understand
>> that H is a pure x86 emulator of its input until H recognizes an
>> infinite execution pattern that no H can possibly correctly return any
>> value to P without violating the basic software engineering principle
>> to no function can every return to any called calling it is infinite
>> recursion.
>
> And if this is indeed very obvious then it simply confirms what I write
> above. H fails to meet the requirements of a decider, which include the
> requirement that a decider *always* return a value.
>
> It doesn't matter *why* H can't return a value. If it can't return a
> value in all instances, then it isn't a decider.
>

On 7/17/2021 12:41 PM, Alan Mackenzie wrote:
> [ Malicious cross posting removed ]
>
> In comp.theory olcott <NoOne@nowhere.com> wrote:
>> On 7/17/2021 4:39 AM, Alan Mackenzie wrote:
>>> olcott <NoOne@nowhere.com> wrote:
>>>> On 7/16/2021 4:30 PM, Alan Mackenzie wrote:
>>>>> olcott <NoOne@nowhere.com> wrote:
>>>>>> On 7/16/2021 3:19 PM, Alan Mackenzie wrote:
>>>>>>> olcott <NoOne@nowhere.com> wrote:
>>>>>>>> On 7/16/2021 1:25 PM, Alan Mackenzie wrote:
>
>>> [ .... ]
>
>>>>>> You say that all input that stops running proves that it halts my
>>>>>> halt decider causes Infinite_Loop() to stop running.
>
>>>>> That "sentence" doesn't parse.
>
>>>> Simulating halt decider is merely fulfilling the requirements of this
>>>> axiom:
>
>>>> 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.
>
>>> That's a strange notion to call an axiom. All it seems to be saying is
>>> that simulation is possible.
>
>
>> It is the equivalence of UTM(⟨P⟩,I) and TM(P,I)
>> Learned by rote people fail to notice this.
>
>>>> Simulating halt decider H is only answering the question:
>>>> Would the input halt on its input if H never stopped simulating it?
>>>> (a) An answer of "no" universally means that the input never halts.
>>>> (b) An answer of "yes" universally means that the input halts.
>
>>> Seems over-complicated. The question should be "does the input program
>>> halt?".
>
>
>> The new axioms are not subject to the pathological self-reference error.
>
> There is no such thing.
>

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)

Stipulated Definition of Halting
An input to a halt decider is defined to halt if and only if this input
stops running while simulating halt decider H remains a pure simulator
of this input.

Pathological Input to a halt decider is defined as any input that was
defined to do the opposite of whatever its corresponding halt decider
decides.

It seems to me that the Stipulated Definition of Halting does not add
anything but clarity to the Conventional Halt Deciding Axiom. Others may
see this differently.

None-the-less the Stipulated Definition of Halting does provide the
means to correctly decide the halting status of Pathological Inputs.

int main() { P(P); } is defined to be a non-halting computation under
the stipulated definition.

The stipulated definition of halting defines the exact same set as the
conventional definition of halting with the possible exception that
pathological inputs are decided as non-halting inputs.

Because the stipulated definition of halting is merely a paraphrase of
the Conventional Halt Deciding Axiom I propose that this stipulated
definition of halting merely provides clarity and does not change the
conventional definition of halting at all.

>> The halt decider acts as a pure simulator until after its halt status
>> decision has been made. This eliminates the possibility of any feedback
>> loop where the halt decider has any effect on the behavior of its input.
>
> If you understood the proofs of the halting problem, you would know that
> the internal details of the purported halting decider are irrelevant and
> unimportant. They're also uninteresting, so ....
>
> [ Snip more uninteresting irrelevant stuff. ]
>
>
>>> [ .... ]
>
>>>>>>> That concept "proof", in the mathematical sense, is one you don't
>>>>>>> understand. It's the fact that things can be shown to be
>>>>>>> absolutely correct or absolutely incorrect, without a shadow of
>>>>>>> doubt, for all time. If you could understand that, you'd be less
>>>>>>> pig-headed and possibly amenable to the truth.
>
>>>>>> An actual working program that shows all of the steps of correctly
>>>>>> deciding the impossible inputs supersedes and over-rules and proof
>>>>>> to the contrary that relies on false assumptions about the details
>>>>>> of unspecified steps.
>
>>>>> No it doesn't. It's merely erroneous. Like I said, you do not
>>>>> understand the concept of proof - you literally don't get it.
>
>>>> When you start with premises that can be verified as definitely true
>>>> and only apply truth preserving operations to these true premises
>>>> then the consequence/conclusion is necessarily true.
>
>>> That's one form of proof, yes. But you don't get it - you don't
>>> understand in the soul of your being that something mathematically
>>> proven is absolute truth. You seem to think something proven is
>>> merely some sort of provisional result. You are wrong.
>
>
>> The HP proof only show that no correct halt status can be returned to
>> an input that is designed to do the opposite of whatever the halt
>> decider decides.
>
> No. It shows further that there is no universal halt decider possible.
>
>> Categorically exhaustive reasoning (my system of reasoning) finds a key
>> gap in this proof. I provided all the details above.
>
> How can you find a gap in a proof when you don't even understand what
> "proof" means? You didn't provide any such details. Just prolix
> irrelevancies. The Linz version of the proof is short and easy to
> understand, possibly even for you. Which step in that proof is not
> rigorously correct?
>
> [ more irrelevant internal details of the purported decider snipped. ]
>
>>>> Other forms of "proof" that diverge for this model are bogus.
>
>>> You could hardly be more wrong, here. For example, there is proof by
>>> contradiction. Here we assume, provisionally, something we wish to show
>>> is false, and by "truth preserving arguments" show that this leads to a
>>> contradiction. Thus this assumption is proven wrong, and we have shown
>>> the something to be false.
>
>
>> That is not a divergence.
>
> Then your utterance about "Other forms of "proof" ..." is meaningless.
>
>>>>> You don't understand the proofs of the halting problem that you have
>>>>> quoted here over the months and years. You do not understand that
>>>>> some things are unassailably and eternally true. Pythagoras's Theorem
>>>>> is one example - a plane triangle with sides 3, 4, and 5 will have an
>>>>> exact right angle. The impossibility of a universal halting decider
>>>>> is another example.
>
>>>>>> Every HP proof is never more than a sketch of a proof because it
>>>>>> always leaves out almost all of the details of the definition of the
>>>>>> computations.
>
>>>>> You don't get it: it leaves out unimportant details which are
>>>>> irrelevant to the proof. The internal structure of the computations
>>>>> is wholly unimportant. It doesn't matter. Whether by analysis, or
>>>>> simulation, or magic is wholly unimportant - just that a yes/no
>>>>> answer is always returned, and the same answer is always return for
>>>>> the same input.
>
>> --
>> 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