On 7/25/2022 10:43 PM, Dennis Bush wrote:
> On Monday, July 25, 2022 at 11:34:23 PM UTC-4, olcott wrote:
>> On 7/25/2022 10:15 PM, Dennis Bush wrote:
>>> On Monday, July 25, 2022 at 11:13:11 PM UTC-4, olcott wrote:
>>>> On 7/25/2022 9:59 PM, Dennis Bush wrote:
>>>>> On Monday, July 25, 2022 at 10:55:14 PM UTC-4, olcott wrote:
>>>>>> On 7/25/2022 9:42 PM, Dennis Bush wrote:
>>>>>>> On Monday, July 25, 2022 at 9:56:49 PM UTC-4, olcott wrote:
>>>>>>>> On 7/25/2022 7:51 PM, Dennis Bush wrote:
>>>>>>>>> On Monday, July 25, 2022 at 8:30:15 PM UTC-4, olcott wrote:
>>>>>>>>>> On 7/25/2022 4:54 PM, Mr Flibble wrote:
>>>>>>>>>>> On Mon, 25 Jul 2022 16:39:41 -0500
>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 7/25/2022 3:25 PM, Mr Flibble wrote:
>>>>>>>>>>>>> On Mon, 25 Jul 2022 15:20:39 -0500
>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 7/25/2022 3:17 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>> On Mon, 25 Jul 2022 15:14:21 -0500
>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 7/25/2022 3:01 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>> On Mon, 25 Jul 2022 14:58:15 -0500
>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 7/25/2022 2:22 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>> How can we help Olcott understand that his "infinite
>>>>>>>>>>>>>>>>>>> recursion" is a property of his simulating halting decider
>>>>>>>>>>>>>>>>>>> and NOT a property of the input passed to his decider? His
>>>>>>>>>>>>>>>>>>> error is compounded by him incorrectly mapping his decider's
>>>>>>>>>>>>>>>>>>> recursion to the input being non-halting.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> *People that don't comprehend that this is true*
>>>>>>>>>>>>>>>>>> *don't comprehend that I am correct*
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> In every case where the simulation would never stop unless
>>>>>>>>>>>>>>>>>> aborted a non-halting behavior pattern is specified by the
>>>>>>>>>>>>>>>>>> input.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If a simulating halt decider continues to correctly simulate
>>>>>>>>>>>>>>>>>> its input until it correctly matches a non-halting behavior
>>>>>>>>>>>>>>>>>> pattern then this SHD is necessarily correct when it aborts its
>>>>>>>>>>>>>>>>>> simulation and reports non-halting.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> But I have designed an SHD that has no recursion at all:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> https://github.com/i42output/halting-problem#readme
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> So you are wrong to claim that infinite recursion is necessary
>>>>>>>>>>>>>>>>> property for SHDs.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yes you are definitely clueless on these things.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> H correctly determines that Infinite_Recursion() never halts
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> void Infinite_Recursion(int N)
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> Infinite_Recursion(N);
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)Infinite_Recursion, 0x777));
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> _Infinite_Recursion()
>>>>>>>>>>>>>>>> [000010f2](01) 55 push ebp
>>>>>>>>>>>>>>>> [000010f3](02) 8bec mov ebp,esp
>>>>>>>>>>>>>>>> [000010f5](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>> [000010f8](01) 50 push eax
>>>>>>>>>>>>>>>> [000010f9](05) e8f4ffffff call 000010f2
>>>>>>>>>>>>>>>> [000010fe](03) 83c404 add esp,+04
>>>>>>>>>>>>>>>> [00001101](01) 5d pop ebp
>>>>>>>>>>>>>>>> [00001102](01) c3 ret
>>>>>>>>>>>>>>>> Size in bytes:(0017) [00001102]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But P isn't recursive; your H is.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In every case where the simulation would never stop unless aborted
>>>>>>>>>>>>>> a non-halting behavior pattern is specified by the input.
>>>>>>>>>>>>>
>>>>>>>>>>>>> FALSE. The following input specifies a halting "behavior pattern":
>>>>>>>>>>>>>
>>>>>>>>>>>>> void Px()
>>>>>>>>>>>>> {
>>>>>>>>>>>>> (void)H(Px, Px);
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> main()
>>>>>>>>>>>> {
>>>>>>>>>>>> H(Px,Px); // simulated input is infinitely recursive.
>>>>>>>>>>>> Px(Px); // halts
>>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> And there's the rub: everyone except you can see a problem there.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> Everyone besides me simply assumes that the behavior must be the same
>>>>>>>>>> while not bothering to verify that it is proven fact that the behavior
>>>>>>>>>> is not the same.
>>>>>>>>>>
>>>>>>>>>> In example 05 shown in my paper
>>>>>>>>>>
>>>>>>>>>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>>>>>>>>>>
>>>>>>>>>> When we look at the line-by-line execution trace of P(P) and the
>>>>>>>>>> simulation of the input to H(P,P) we see that in both cases this exactly
>>>>>>>>>> matches the line-by-line x86 source-code listing of P.
>>>>>>>>>
>>>>>>>>> FALSE. A line-by-line comparison shows that the trace of both are *identical* up to the point where the simulation by H aborts. Then the direct execution continues past that point to a final state,
>>>>>>>> Yes that much is true.
>>>>>>>>> demonstrating that H aborted too soon.
>>>>>>>> No that is counter-factual.
>>>>>>>
>>>>>>> Not according to a UTM simulation of the same input, i.e. UTM(Pa,Pa)
>>>>>>>
>>>>>>>>
>>>>>>>> I know that you are smart enough to know that it is an easily verified
>>>>>>>> fact (for every master of the x86 language) to see that if H(P,P) never
>>>>>>>> aborted the simulation of its input
>>>>>>>
>>>>>>> Is irrelevant because it DOES abort. And because it does, there is no infinite recursion.
>>>>>> In other words you are saying there is no infinite loop because the
>>>>>> simulated infinite loop is aborted.
>>>>>
>>>>> Again, there is no simulated infinite loop. Ha thinks there is but there is not. UTM(Pa,Pa) demonstrates this fact.
>>>>>
>>>> So when H0 simulates Infinite_Loop() there is no partial simulation of
>>>> any infinite loop?
>>>
>>>
>>> The difference is that UTM(Infinite_Loop) does not halt, while UTM(Pa,Pa) does halt. That means there is no infinite loop in Pa(Pa), contrary to what Ha might think.
>> I just looked up your profile again. I was born in Orange New Jersey.
>> Your profile seems to indicate that you have great technical competence:
>>
>> "I develop primarily in C and Java, with interests in network
>> programming, encryption, network security, and multicast."
>>
>> *It does not indicate any competence with the x86 language*
>>
>> Simulate(P,P) halts
>> P(P) halts
>> H1(P,P) reports 1 for halting
>>
>> The correctly simulated input to H(P,P) does not halt only because H and
>> P have the following pathological relationship to each other:
>>
>> For any program H that might determine if programs halt, a
>> "pathological" program P, called with some input, can pass its own
>> source and its input to H and then specifically do the opposite of what
>> H predicts P will do. No H can exist that handles this case.
>> https://en.wikipedia.org/wiki/Halting_problem
>>
>> The execution trace of the correct simulation of the input to H(P,P)
>> proves that it never reaches its "return" instruction and halts whether
>> or not it is aborted.
>>
>> It seems that no one understands the x86 language well enough to see
>> this, and tries to bluff through their ignorance and claim that I am
>> incorrect anyway.
>
> You are claiming that no implementation of the function H can simulate the function P to completion.
Go back and carefully read what I said and see that I already answered
this.

On Monday, July 25, 2022 at 11:47:05 PM UTC-4, olcott wrote:
> On 7/25/2022 10:43 PM, Dennis Bush wrote:
> > On Monday, July 25, 2022 at 11:34:23 PM UTC-4, olcott wrote:
> >> On 7/25/2022 10:15 PM, Dennis Bush wrote:
> >>> On Monday, July 25, 2022 at 11:13:11 PM UTC-4, olcott wrote:
> >>>> On 7/25/2022 9:59 PM, Dennis Bush wrote:
> >>>>> On Monday, July 25, 2022 at 10:55:14 PM UTC-4, olcott wrote:
> >>>>>> On 7/25/2022 9:42 PM, Dennis Bush wrote:
> >>>>>>> On Monday, July 25, 2022 at 9:56:49 PM UTC-4, olcott wrote:
> >>>>>>>> On 7/25/2022 7:51 PM, Dennis Bush wrote:
> >>>>>>>>> On Monday, July 25, 2022 at 8:30:15 PM UTC-4, olcott wrote:
> >>>>>>>>>> On 7/25/2022 4:54 PM, Mr Flibble wrote:
> >>>>>>>>>>> On Mon, 25 Jul 2022 16:39:41 -0500
> >>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> On 7/25/2022 3:25 PM, Mr Flibble wrote:
> >>>>>>>>>>>>> On Mon, 25 Jul 2022 15:20:39 -0500
> >>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 7/25/2022 3:17 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>> On Mon, 25 Jul 2022 15:14:21 -0500
> >>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On 7/25/2022 3:01 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>> On Mon, 25 Jul 2022 14:58:15 -0500
> >>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On 7/25/2022 2:22 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>> How can we help Olcott understand that his "infinite
> >>>>>>>>>>>>>>>>>>> recursion" is a property of his simulating halting decider
> >>>>>>>>>>>>>>>>>>> and NOT a property of the input passed to his decider? His
> >>>>>>>>>>>>>>>>>>> error is compounded by him incorrectly mapping his decider's
> >>>>>>>>>>>>>>>>>>> recursion to the input being non-halting.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> *People that don't comprehend that this is true*
> >>>>>>>>>>>>>>>>>> *don't comprehend that I am correct*
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> In every case where the simulation would never stop unless
> >>>>>>>>>>>>>>>>>> aborted a non-halting behavior pattern is specified by the
> >>>>>>>>>>>>>>>>>> input.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> If a simulating halt decider continues to correctly simulate
> >>>>>>>>>>>>>>>>>> its input until it correctly matches a non-halting behavior
> >>>>>>>>>>>>>>>>>> pattern then this SHD is necessarily correct when it aborts its
> >>>>>>>>>>>>>>>>>> simulation and reports non-halting.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> But I have designed an SHD that has no recursion at all:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> https://github.com/i42output/halting-problem#readme
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> So you are wrong to claim that infinite recursion is necessary
> >>>>>>>>>>>>>>>>> property for SHDs.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Yes you are definitely clueless on these things.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> H correctly determines that Infinite_Recursion() never halts
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> void Infinite_Recursion(int N)
> >>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>> Infinite_Recursion(N);
> >>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> int main()
> >>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)Infinite_Recursion, 0x777));
> >>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> _Infinite_Recursion()
> >>>>>>>>>>>>>>>> [000010f2](01) 55 push ebp
> >>>>>>>>>>>>>>>> [000010f3](02) 8bec mov ebp,esp
> >>>>>>>>>>>>>>>> [000010f5](03) 8b4508 mov eax,[ebp+08]
> >>>>>>>>>>>>>>>> [000010f8](01) 50 push eax
> >>>>>>>>>>>>>>>> [000010f9](05) e8f4ffffff call 000010f2
> >>>>>>>>>>>>>>>> [000010fe](03) 83c404 add esp,+04
> >>>>>>>>>>>>>>>> [00001101](01) 5d pop ebp
> >>>>>>>>>>>>>>>> [00001102](01) c3 ret
> >>>>>>>>>>>>>>>> Size in bytes:(0017) [00001102]
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> But P isn't recursive; your H is.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> In every case where the simulation would never stop unless aborted
> >>>>>>>>>>>>>> a non-halting behavior pattern is specified by the input.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> FALSE. The following input specifies a halting "behavior pattern":
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> void Px()
> >>>>>>>>>>>>> {
> >>>>>>>>>>>>> (void)H(Px, Px);
> >>>>>>>>>>>>> }
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> main()
> >>>>>>>>>>>> {
> >>>>>>>>>>>> H(Px,Px); // simulated input is infinitely recursive.
> >>>>>>>>>>>> Px(Px); // halts
> >>>>>>>>>>>> }
> >>>>>>>>>>>
> >>>>>>>>>>> And there's the rub: everyone except you can see a problem there.
> >>>>>>>>>>>
> >>>>>>>>>>> /Flibble
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>> Everyone besides me simply assumes that the behavior must be the same
> >>>>>>>>>> while not bothering to verify that it is proven fact that the behavior
> >>>>>>>>>> is not the same.
> >>>>>>>>>>
> >>>>>>>>>> In example 05 shown in my paper
> >>>>>>>>>>
> >>>>>>>>>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
> >>>>>>>>>>
> >>>>>>>>>> When we look at the line-by-line execution trace of P(P) and the
> >>>>>>>>>> simulation of the input to H(P,P) we see that in both cases this exactly
> >>>>>>>>>> matches the line-by-line x86 source-code listing of P.
> >>>>>>>>>
> >>>>>>>>> FALSE. A line-by-line comparison shows that the trace of both are *identical* up to the point where the simulation by H aborts. Then the direct execution continues past that point to a final state,
> >>>>>>>> Yes that much is true.
> >>>>>>>>> demonstrating that H aborted too soon.
> >>>>>>>> No that is counter-factual.
> >>>>>>>
> >>>>>>> Not according to a UTM simulation of the same input, i.e. UTM(Pa,Pa)
> >>>>>>>
> >>>>>>>>
> >>>>>>>> I know that you are smart enough to know that it is an easily verified
> >>>>>>>> fact (for every master of the x86 language) to see that if H(P,P) never
> >>>>>>>> aborted the simulation of its input
> >>>>>>>
> >>>>>>> Is irrelevant because it DOES abort. And because it does, there is no infinite recursion.
> >>>>>> In other words you are saying there is no infinite loop because the
> >>>>>> simulated infinite loop is aborted.
> >>>>>
> >>>>> Again, there is no simulated infinite loop. Ha thinks there is but there is not. UTM(Pa,Pa) demonstrates this fact.
> >>>>>
> >>>> So when H0 simulates Infinite_Loop() there is no partial simulation of
> >>>> any infinite loop?
> >>>
> >>>
> >>> The difference is that UTM(Infinite_Loop) does not halt, while UTM(Pa,Pa) does halt. That means there is no infinite loop in Pa(Pa), contrary to what Ha might think.
> >> I just looked up your profile again. I was born in Orange New Jersey.
> >> Your profile seems to indicate that you have great technical competence:
> >>
> >> "I develop primarily in C and Java, with interests in network
> >> programming, encryption, network security, and multicast."
> >>
> >> *It does not indicate any competence with the x86 language*
> >>
> >> Simulate(P,P) halts
> >> P(P) halts
> >> H1(P,P) reports 1 for halting
> >>
> >> The correctly simulated input to H(P,P) does not halt only because H and
> >> P have the following pathological relationship to each other:
> >>
> >> For any program H that might determine if programs halt, a
> >> "pathological" program P, called with some input, can pass its own
> >> source and its input to H and then specifically do the opposite of what
> >> H predicts P will do. No H can exist that handles this case.
> >> https://en.wikipedia.org/wiki/Halting_problem
> >>
> >> The execution trace of the correct simulation of the input to H(P,P)
> >> proves that it never reaches its "return" instruction and halts whether
> >> or not it is aborted.
> >>
> >> It seems that no one understands the x86 language well enough to see
> >> this, and tries to bluff through their ignorance and claim that I am
> >> incorrect anyway.
> >
> > You are claiming that no implementation of the function H can simulate the function P to completion.
> Go back and carefully read what I said and see that I already answered
> this.

On Monday, 25 July 2022 at 20:22:44 UTC+1, Mr Flibble wrote:
> How can we help Olcott understand that his "infinite recursion" is a
> property of his simulating halting decider and NOT a property of the
> input passed to his decider? His error is compounded by him
> incorrectly mapping his decider's recursion to the input being
> non-halting.
>
The input passed to the decider includes a near copy of the decider
itself. So if the decider works on the simulating principle, then
infinitely nested simulation is a property of the system, and that's
the way that a reasonably functional simulating decider will fail.
(PO is aware of this and tries to code round it, but in fact this
cannot be done).

However Linz's H_Hat doesn't require H to be a simulating halt decider.
You could also write a reasonably functional decider on the graph
anaylsis principle. Again, it will fail on some inputs, including H_Hat,
but it won't fail by getting stuck in infinitely nested simulations.
A graph analysis halt decider will probably work quite well on real
programs written by human programmers, not with the intention of
defeating the system.

On 2022-07-25 19:22:42 +0000, Mr Flibble said:

> How can we help Olcott understand that his "infinite recursion" is a
> property of his simulating halting decider and NOT a property of the
> input passed to his decider? His error is compounded by him
> incorrectly mapping his decider's recursion to the input being
> non-halting.

It would be a big effort with a small probability of success.

First you should find out what he already understands. If he
understands something and you know what you may try to expand
that understanding. Otherwise you should first teach him the
skill on understanding.

Mikko

On 7/26/2022 4:35 AM, Mikko wrote:
> On 2022-07-25 19:22:42 +0000, Mr Flibble said:
>
>> How can we help Olcott understand that his "infinite recursion" is a
>> property of his simulating halting decider and NOT a property of the
>> input passed to his decider?  His error is compounded by him
>> incorrectly mapping his decider's recursion to the input being
>> non-halting.
>
> It would be a big effort with a small probability of success.
>
> First you should find out what he already understands. If he
> understands something and you know what you may try to expand
> that understanding. Otherwise you should first teach him the
> skill on understanding.
>
> Mikko
>

*THIS IS NECESSARILY TRUE*
If a simulating halt decider continues to correctly simulate its input
until it correctly matches a non-halting behavior pattern then this SHD
is necessarily correct when it aborts its simulation and reports
non-halting.

When-so-ever the correct simulation of any input would never stop unless
aborted then the simulated input is not halting.

On 7/24/2022 6:19 PM, Paul N wrote:
> On Monday, July 25, 2022 at 12:10:34 AM UTC+1, olcott wrote:
>> If a simulating halt decider continues to correctly
>> simulate its input until it correctly matches a non-halting
>> behavior pattern then this SHD is necessarily correct when
>> it aborts its simulation and reports non-halting.
>
> Yes, *If* a simulating halt decider continues to correctly
> simulate its input until it *correctly* matches a non-
> halting behaviour pattern then this SHD is correct when it
> aborts its simulation and reports non-halting.
> [*some content snipped to stay focused on this point*]

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 7/26/2022 4:35 AM, Mikko wrote:
> On 2022-07-25 19:22:42 +0000, Mr Flibble said:
>
>> How can we help Olcott understand that his "infinite recursion" is a
>> property of his simulating halting decider and NOT a property of the
>> input passed to his decider?  His error is compounded by him
>> incorrectly mapping his decider's recursion to the input being
>> non-halting.
>
> It would be a big effort with a small probability of success.
>

The infinite recursion is a property of P in that H simulates P that
calls H. When H simulates P that calls H1 the infinite recursion goes away.

> First you should find out what he already understands. If he
> understands something and you know what you may try to expand
> that understanding. Otherwise you should first teach him the
> skill on understanding.
>
> Mikko
>

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 7/25/2022 2:22 PM, Mr Flibble wrote:
> How can we help Olcott understand that his "infinite recursion" is a
> property of his simulating halting decider and NOT a property of the
> input passed to his decider?

The infinite recursion is a property of P in that H simulates P that
calls H. When H simulates P that calls H1 the infinite recursion goes away.

> His error is compounded by him
> incorrectly mapping his decider's recursion to the input being
> non-halting.
>
> /Flibble
>

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On Mon, 25 Jul 2022 21:11:41 -0700 (PDT)
Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:

> On Monday, 25 July 2022 at 20:22:44 UTC+1, Mr Flibble wrote:
> > How can we help Olcott understand that his "infinite recursion" is
> > a property of his simulating halting decider and NOT a property of
> > the input passed to his decider? His error is compounded by him
> > incorrectly mapping his decider's recursion to the input being
> > non-halting.
> >
> The input passed to the decider includes a near copy of the decider
> itself. So if the decider works on the simulating principle, then
> infinitely nested simulation is a property of the system, and that's
> the way that a reasonably functional simulating decider will fail.

Not true: I have designed a simulating decider that is not recursive in
nature:

https://github.com/i42output/halting-problem#readme

/Flibble

On 7/25/2022 11:11 PM, Malcolm McLean wrote:
> On Monday, 25 July 2022 at 20:22:44 UTC+1, Mr Flibble wrote:
>> How can we help Olcott understand that his "infinite recursion" is a
>> property of his simulating halting decider and NOT a property of the
>> input passed to his decider? His error is compounded by him
>> incorrectly mapping his decider's recursion to the input being
>> non-halting.
>>
> The input passed to the decider includes a near copy of the decider
> itself. So if the decider works on the simulating principle, then
> infinitely nested simulation is a property of the system, and that's
> the way that a reasonably functional simulating decider will fail.
> (PO is aware of this and tries to code round it, but in fact this
> cannot be done).
>

We can know that it is P that specifies the infinite recursion when P
calls its own simulator H(P,P).

We can verify this by the fact that H1(P,P) returns 1 where P is not
calling its own simulator.

> However Linz's H_Hat doesn't require H to be a simulating halt decider.
> You could also write a reasonably functional decider on the graph
> anaylsis principle. Again, it will fail on some inputs, including H_Hat,
> but it won't fail by getting stuck in infinitely nested simulations.
> A graph analysis halt decider will probably work quite well on real
> programs written by human programmers, not with the intention of
> defeating the system.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 7/26/2022 11:06 AM, Mr Flibble wrote:
> On Mon, 25 Jul 2022 21:11:41 -0700 (PDT)
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>
>> On Monday, 25 July 2022 at 20:22:44 UTC+1, Mr Flibble wrote:
>>> How can we help Olcott understand that his "infinite recursion" is
>>> a property of his simulating halting decider and NOT a property of
>>> the input passed to his decider? His error is compounded by him
>>> incorrectly mapping his decider's recursion to the input being
>>> non-halting.
>>>
>> The input passed to the decider includes a near copy of the decider
>> itself. So if the decider works on the simulating principle, then
>> infinitely nested simulation is a property of the system, and that's
>> the way that a reasonably functional simulating decider will fail.
>
> Not true: I have designed a simulating decider that is not recursive in
> nature:
>
> https://github.com/i42output/halting-problem#readme
>
> /Flibble
>

You have defined a system where a function that has been called in
infinite recursion returns to its called.

Since every competent software engineer knows that no function called in
infinite recursion ever returns to its caller your system is necessarily
incorrect.

Certainly Mike and Andre know that no function called in infinite
recursion ever returns to its caller. Malcolm might know this too.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On Tue, 26 Jul 2022 11:20:31 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 7/26/2022 11:06 AM, Mr Flibble wrote:
> > On Mon, 25 Jul 2022 21:11:41 -0700 (PDT)
> > Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> >
> >> On Monday, 25 July 2022 at 20:22:44 UTC+1, Mr Flibble wrote:
> >>> How can we help Olcott understand that his "infinite recursion" is
> >>> a property of his simulating halting decider and NOT a property of
> >>> the input passed to his decider? His error is compounded by him
> >>> incorrectly mapping his decider's recursion to the input being
> >>> non-halting.
> >>>
> >> The input passed to the decider includes a near copy of the decider
> >> itself. So if the decider works on the simulating principle, then
> >> infinitely nested simulation is a property of the system, and
> >> that's the way that a reasonably functional simulating decider
> >> will fail.
> >
> > Not true: I have designed a simulating decider that is not
> > recursive in nature:
> >
> > https://github.com/i42output/halting-problem#readme
> >
> > /Flibble
> >
>
> You have defined a system where a function that has been called in
> infinite recursion returns to its called.
>
> Since every competent software engineer knows that no function called
> in infinite recursion ever returns to its caller your system is
> necessarily incorrect.
>
> Certainly Mike and Andre know that no function called in infinite
> recursion ever returns to its caller. Malcolm might know this too.
There is no requirement that an SHD must use recursion: you are making
this requirement up to try to justify your broken method.

And it seems I need to remind you yet again: the decider in [Strachey
1965] and associated proofs is NOT recursive in nature.

/Flibble

On 7/26/2022 11:24 AM, Mr Flibble wrote:
> On Tue, 26 Jul 2022 11:20:31 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 7/26/2022 11:06 AM, Mr Flibble wrote:
>>> On Mon, 25 Jul 2022 21:11:41 -0700 (PDT)
>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>>>
>>>> On Monday, 25 July 2022 at 20:22:44 UTC+1, Mr Flibble wrote:
>>>>> How can we help Olcott understand that his "infinite recursion" is
>>>>> a property of his simulating halting decider and NOT a property of
>>>>> the input passed to his decider? His error is compounded by him
>>>>> incorrectly mapping his decider's recursion to the input being
>>>>> non-halting.
>>>>>
>>>> The input passed to the decider includes a near copy of the decider
>>>> itself. So if the decider works on the simulating principle, then
>>>> infinitely nested simulation is a property of the system, and
>>>> that's the way that a reasonably functional simulating decider
>>>> will fail.
>>>
>>> Not true: I have designed a simulating decider that is not
>>> recursive in nature:
>>>
>>> https://github.com/i42output/halting-problem#readme
>>>
>>> /Flibble
>>>
>>
>> You have defined a system where a function that has been called in
>> infinite recursion returns to its called.
>>
>> Since every competent software engineer knows that no function called
>> in infinite recursion ever returns to its caller your system is
>> necessarily incorrect.
>>
>> Certainly Mike and Andre know that no function called in infinite
>> recursion ever returns to its caller. Malcolm might know this too.
>
> There is no requirement that an SHD must use recursion: you are making
> this requirement up to try to justify your broken method.
>
> And it seems I need to remind you yet again: the decider in [Strachey
> 1965] and associated proofs is NOT recursive in nature.
>
> /Flibble
>

If a simulating halt decider continues to correctly simulate its input
until it correctly matches a non-halting behavior pattern then this SHD
is necessarily correct when it aborts its simulation and reports
non-halting.

Sometimes the inputs specify recursion such as H(P,P) and sometimes they
they do not such as H1(P,P).

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On Tue, 26 Jul 2022 11:39:04 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 7/26/2022 11:24 AM, Mr Flibble wrote:
> > On Tue, 26 Jul 2022 11:20:31 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 7/26/2022 11:06 AM, Mr Flibble wrote:
> >>> On Mon, 25 Jul 2022 21:11:41 -0700 (PDT)
> >>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> >>>
> >>>> On Monday, 25 July 2022 at 20:22:44 UTC+1, Mr Flibble wrote:
> >>>>> How can we help Olcott understand that his "infinite recursion"
> >>>>> is a property of his simulating halting decider and NOT a
> >>>>> property of the input passed to his decider? His error is
> >>>>> compounded by him incorrectly mapping his decider's recursion
> >>>>> to the input being non-halting.
> >>>>>
> >>>> The input passed to the decider includes a near copy of the
> >>>> decider itself. So if the decider works on the simulating
> >>>> principle, then infinitely nested simulation is a property of
> >>>> the system, and that's the way that a reasonably functional
> >>>> simulating decider will fail.
> >>>
> >>> Not true: I have designed a simulating decider that is not
> >>> recursive in nature:
> >>>
> >>> https://github.com/i42output/halting-problem#readme
> >>>
> >>> /Flibble
> >>>
> >>
> >> You have defined a system where a function that has been called in
> >> infinite recursion returns to its called.
> >>
> >> Since every competent software engineer knows that no function
> >> called in infinite recursion ever returns to its caller your
> >> system is necessarily incorrect.
> >>
> >> Certainly Mike and Andre know that no function called in infinite
> >> recursion ever returns to its caller. Malcolm might know this too.
> >>
> >
> > There is no requirement that an SHD must use recursion: you are
> > making this requirement up to try to justify your broken method.
> >
> > And it seems I need to remind you yet again: the decider in
> > [Strachey 1965] and associated proofs is NOT recursive in nature.
> >
> > /Flibble
> >
>
> If a simulating halt decider continues to correctly simulate its
> input until it correctly matches a non-halting behavior pattern then
> this SHD is necessarily correct when it aborts its simulation and
> reports non-halting.
>
> Sometimes the inputs specify recursion such as H(P,P) and sometimes
> they they do not such as H1(P,P).

You are just copy/pasting the same old shit. I don't care what your
broken H or H1 does: *my* SHD is not recursive in nature.

/Flibble

On Monday, July 25, 2022 at 10:39:51 PM UTC+1, olcott wrote:
> On 7/25/2022 3:25 PM, Mr Flibble wrote:
> > On Mon, 25 Jul 2022 15:20:39 -0500
> > olcott <No...@NoWhere.com> wrote:
> >
> >> On 7/25/2022 3:17 PM, Mr Flibble wrote:
> >>> On Mon, 25 Jul 2022 15:14:21 -0500
> >>> olcott <No...@NoWhere.com> wrote:
> >>>
> >>>> On 7/25/2022 3:01 PM, Mr Flibble wrote:
> >>>>> On Mon, 25 Jul 2022 14:58:15 -0500
> >>>>> olcott <No...@NoWhere.com> wrote:
> >>>>>
> >>>>>> *People that don't comprehend that this is true*
> >>>>>> *don't comprehend that I am correct*
> >>>>>>
> >>>>>> In every case where the simulation would never stop unless
> >>>>>> aborted a non-halting behavior pattern is specified by the input.
> >>>>>>
> >>>>>> If a simulating halt decider continues to correctly simulate its
> >>>>>> input until it correctly matches a non-halting behavior pattern
> >>>>>> then this SHD is necessarily correct when it aborts its
> >>>>>> simulation and reports non-halting.

> main()
> {
> H(Px,Px); // simulated input is infinitely recursive.
> Px(Px); // halts
> }

> "Talent hits a target no one else can hit;
> Genius hits a target no one else can see."

Idiocy misses the target, but claims that the correct test for whether the target is hit is whether a correct simulation determines that the target is hit; claims that their simulation shows the target is hit; claims that their simulation is correct; and accuses anyone who disagrees that the target was hit of being woefully ignorant of the x86 language.

On 7/26/22 12:20 PM, olcott wrote:
> On 7/26/2022 11:06 AM, Mr Flibble wrote:
>> On Mon, 25 Jul 2022 21:11:41 -0700 (PDT)
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>>
>>> On Monday, 25 July 2022 at 20:22:44 UTC+1, Mr Flibble wrote:
>>>> How can we help Olcott understand that his "infinite recursion" is
>>>> a property of his simulating halting decider and NOT a property of
>>>> the input passed to his decider? His error is compounded by him
>>>> incorrectly mapping his decider's recursion to the input being
>>>> non-halting.
>>> The input passed to the decider includes a near copy of the decider
>>> itself. So if the decider works on the simulating principle, then
>>> infinitely nested simulation is a property of the system, and that's
>>> the way that a reasonably functional simulating decider will fail.
>>
>> Not true: I have designed a simulating decider that is not recursive in
>> nature:
>>
>> https://github.com/i42output/halting-problem#readme
>>
>> /Flibble
>>
>
> You have defined a system where a function that has been called in
> infinite recursion returns to its called.

No, he as broken the infinite recursion by being smart.

Your H either isn't smart enough to break the infinite recursion or
isn't smart enough to realiz it did and announces that it didn't

>
> Since every competent software engineer knows that no function called in
> infinite recursion ever returns to its caller your system is necessarily
> incorrect.

No, yours is by calling what ISN'T infinite recursion and infinte
recursion because you use UNSOUND logic, maybe because you have an
UNSOUND mind.

>
> Certainly Mike and Andre know that no function called in infinite
> recursion ever returns to its caller. Malcolm might know this too.
>

And no function that creates infinite recursion can ever return from ANY
equivalent call.

Thus if P(P) calling H(P,P) leads to infinite recursion, so does main
calling H(P,P).

Either BOTH are or NEITHER is.

You are just too stupid to see this, or a liar and your H isn't a
computatation.

Which are you, STUPID or a LIAR?

On 7/26/22 12:13 PM, olcott wrote:
> On 7/25/2022 11:11 PM, Malcolm McLean wrote:
>> On Monday, 25 July 2022 at 20:22:44 UTC+1, Mr Flibble wrote:
>>> How can we help Olcott understand that his "infinite recursion" is a
>>> property of his simulating halting decider and NOT a property of the
>>> input passed to his decider? His error is compounded by him
>>> incorrectly mapping his decider's recursion to the input being
>>> non-halting.
>>>
>> The input passed to the decider includes a near copy of the decider
>> itself. So if the decider works on the simulating principle, then
>> infinitely nested simulation is a property of the system, and that's
>> the way that a reasonably functional simulating decider will fail.
>> (PO is aware of this and tries to code round it, but in fact this
>> cannot be done).
>>
>
> We can know that it is P that specifies the infinite recursion when P
> calls its own simulator H(P,P).

No, it isn't calling a "simulator" it is calling a DECIDER.

>
> We can verify this by the fact that H1(P,P) returns 1 where P is not
> calling its own simulator.

Which shows that it is H that cause the problem.

>
>> However Linz's H_Hat doesn't require H to be a simulating halt decider.
>> You could also write a reasonably functional decider on the graph
>> anaylsis principle. Again, it will fail on some inputs, including H_Hat,
>> but it won't fail by getting stuck in infinitely nested simulations.
>> A graph analysis halt decider will probably work quite well on real
>> programs written by human programmers, not with the intention of
>> defeating the system.
>
>

On 7/26/2022 5:40 PM, Paul N wrote:
> On Monday, July 25, 2022 at 10:39:51 PM UTC+1, olcott wrote:
>> On 7/25/2022 3:25 PM, Mr Flibble wrote:
>>> On Mon, 25 Jul 2022 15:20:39 -0500
>>> olcott <No...@NoWhere.com> wrote:
>>>
>>>> On 7/25/2022 3:17 PM, Mr Flibble wrote:
>>>>> On Mon, 25 Jul 2022 15:14:21 -0500
>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>
>>>>>> On 7/25/2022 3:01 PM, Mr Flibble wrote:
>>>>>>> On Mon, 25 Jul 2022 14:58:15 -0500
>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> *People that don't comprehend that this is true*
>>>>>>>> *don't comprehend that I am correct*
>>>>>>>>
>>>>>>>> In every case where the simulation would never stop unless
>>>>>>>> aborted a non-halting behavior pattern is specified by the input.
>>>>>>>>
>>>>>>>> If a simulating halt decider continues to correctly simulate its
>>>>>>>> input until it correctly matches a non-halting behavior pattern
>>>>>>>> then this SHD is necessarily correct when it aborts its
>>>>>>>> simulation and reports non-halting.
>
>> main()
>> {
>> H(Px,Px); // simulated input is infinitely recursive.
>> Px(Px); // halts
>> }
>
>> "Talent hits a target no one else can hit;
>> Genius hits a target no one else can see."
>
> Idiocy misses the target, but claims that the correct test for whether the target is hit is whether a correct simulation determines that the target is hit; claims that their simulation shows the target is hit; claims that their simulation is correct; and accuses anyone who disagrees that the target was hit of being woefully ignorant of the x86 language.

So you are claiming to know the x86 language very well?

That the line-by-line execution trace of the simulated input to H(P,P)
exactly matches the line-by-line source-code conclusively proves that P
is simulated correctly. If you don't understand this then your technical
competence is woefully insufficient.

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

This earlier version of the halt decider postpones its halt status
decision until it sees:

This is main()
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
....[00001372][0010229e][00000000] 55 push ebp
....[00001373][0010229e][00000000] 8bec mov ebp,esp
....[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
....[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
....[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H

Begin Local Halt Decider Simulation Execution Trace Stored at:212352
// H emulates the first seven instructions of P
....[00001352][0021233e][00212342] 55 push ebp // enter P
....[00001353][0021233e][00212342] 8bec mov ebp,esp
....[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
....[00001358][0021233a][00001352] 50 push eax // push P
....[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
....[0000135c][00212336][00001352] 51 push ecx // push P
....[0000135d][00212332][00001362] e840feffff call 000011a2 // call H

// The emulated H emulates the first seven instructions of P
....[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
....[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
....[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
....[00001358][0025cd62][00001352] 50 push eax // push P
....[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
....[0000135c][0025cd5e][00001352] 51 push ecx // push P
....[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

*Matched infinite recursion detection criteria*
(1) P() calls H(P,P) twice in sequence.
(2) With the same arguments.
(3) With no control flow instructions in P preceding its invocation of
H(P,P) that could escape repeated simulations.

When H(P,P) correctly simulates its input the next instruction after its
call to H(P,P) is the first instruction of P at machine address:
00001352 because H simulates P again.

In the directly executed P(P) when P calls H(P,P) this is not infinite
recursion so H returns 0 to P, and P goes to its machine address 00001362.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 7/26/22 6:52 PM, olcott wrote:
> On 7/26/2022 5:40 PM, Paul N wrote:
>> On Monday, July 25, 2022 at 10:39:51 PM UTC+1, olcott wrote:
>>> On 7/25/2022 3:25 PM, Mr Flibble wrote:
>>>> On Mon, 25 Jul 2022 15:20:39 -0500
>>>> olcott <No...@NoWhere.com> wrote:
>>>>
>>>>> On 7/25/2022 3:17 PM, Mr Flibble wrote:
>>>>>> On Mon, 25 Jul 2022 15:14:21 -0500
>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>
>>>>>>> On 7/25/2022 3:01 PM, Mr Flibble wrote:
>>>>>>>> On Mon, 25 Jul 2022 14:58:15 -0500
>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>
>>>>>>>>> *People that don't comprehend that this is true*
>>>>>>>>> *don't comprehend that I am correct*
>>>>>>>>>
>>>>>>>>> In every case where the simulation would never stop unless
>>>>>>>>> aborted a non-halting behavior pattern is specified by the input.
>>>>>>>>>
>>>>>>>>> If a simulating halt decider continues to correctly simulate its
>>>>>>>>> input until it correctly matches a non-halting behavior pattern
>>>>>>>>> then this SHD is necessarily correct when it aborts its
>>>>>>>>> simulation and reports non-halting.
>>
>>> main()
>>> {
>>> H(Px,Px); // simulated input is infinitely recursive.
>>> Px(Px); // halts
>>> }
>>
>>> "Talent hits a target no one else can hit;
>>> Genius hits a target no one else can see."
>>
>> Idiocy misses the target, but claims that the correct test for whether
>> the target is hit is whether a correct simulation determines that the
>> target is hit; claims that their simulation shows the target is hit;
>> claims that their simulation is correct; and accuses anyone who
>> disagrees that the target was hit of being woefully ignorant of the
>> x86 language.
>
> So you are claiming to know the x86 language very well?
>
> That the line-by-line execution trace of the simulated input to H(P,P)
> exactly matches the line-by-line source-code conclusively proves that P
> is simulated correctly. If you don't understand this then your technical
> competence is woefully insufficient.
>
> _P()
> [00001352](01)  55              push ebp
> [00001353](02)  8bec            mov ebp,esp
> [00001355](03)  8b4508          mov eax,[ebp+08]
> [00001358](01)  50              push eax      // push P
> [00001359](03)  8b4d08          mov ecx,[ebp+08]
> [0000135c](01)  51              push ecx      // push P
> [0000135d](05)  e840feffff      call 000011a2 // call H
> [00001362](03)  83c408          add esp,+08
> [00001365](02)  85c0            test eax,eax
> [00001367](02)  7402            jz 0000136b
> [00001369](02)  ebfe            jmp 00001369
> [0000136b](01)  5d              pop ebp
> [0000136c](01)  c3              ret
> Size in bytes:(0027) [0000136c]
>
> This earlier version of the halt decider postpones its halt status
> decision until it sees:
>
>
> This is main()
>     machine   stack     stack     machine    assembly
>     address   address   data      code       language
>     ========  ========  ========  =========  =============
> ...[00001372][0010229e][00000000] 55         push ebp
> ...[00001373][0010229e][00000000] 8bec       mov ebp,esp
> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H

And here the emulation is WRONG, as the emulation of a call to H must be
followed by the code of H.

Maybe simpler, the next step after a call 000011a2 must be the
instruction AT 000011a2.

Since it isn't, your"claims" of "correct" emulation are proved to be
just a blantant LIE.

>
> Begin Local Halt Decider Simulation   Execution Trace Stored at:212352
> // H emulates the first seven instructions of P
> ...[00001352][0021233e][00212342] 55         push ebp      // enter P
> ...[00001353][0021233e][00212342] 8bec       mov ebp,esp
> ...[00001355][0021233e][00212342] 8b4508     mov eax,[ebp+08]
> ...[00001358][0021233a][00001352] 50         push eax      // push P
> ...[00001359][0021233a][00001352] 8b4d08     mov ecx,[ebp+08]
> ...[0000135c][00212336][00001352] 51         push ecx      // push P
> ...[0000135d][00212332][00001362] e840feffff call 000011a2 // call H
>

Again, the call to 000011a2 needs to be followed by the instruction at
000011a2

Your failure to do that just shows you don't know what correct emulation
means.

> // The emulated H emulates the first seven instructions of P
> ...[00001352][0025cd66][0025cd6a] 55         push ebp      // enter P
> ...[00001353][0025cd66][0025cd6a] 8bec       mov ebp,esp
> ...[00001355][0025cd66][0025cd6a] 8b4508     mov eax,[ebp+08]
> ...[00001358][0025cd62][00001352] 50         push eax      // push P
> ...[00001359][0025cd62][00001352] 8b4d08     mov ecx,[ebp+08]
> ...[0000135c][0025cd5e][00001352] 51         push ecx      // push P
> ...[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> *Matched infinite recursion detection criteria*
> (1) P() calls H(P,P) twice in sequence.
> (2) With the same arguments.
> (3) With no control flow instructions in P preceding its invocation of
> H(P,P) that could escape repeated simulations.

(3) is just WRONG. You are PROVING you are just a pathological liar or
an idiot to keep repeating it after this has been pointed out.
>
> When H(P,P) correctly simulates its input the next instruction after its
> call to H(P,P) is the first instruction of P at machine address:
> 00001352 because H simulates P again.
>
> In the directly executed P(P) when P calls H(P,P) this is not infinite
> recursion so H returns 0 to P, and P goes to its machine address 00001362.
>
>

Thus, NONE of your claims are substantiated as the simulation is NOT
correct and the logic is UNSOUND.

FAIL.

On 7/26/22 9:17 AM, olcott wrote:
> On 7/26/2022 4:35 AM, Mikko wrote:
>> On 2022-07-25 19:22:42 +0000, Mr Flibble said:
>>
>>> How can we help Olcott understand that his "infinite recursion" is a
>>> property of his simulating halting decider and NOT a property of the
>>> input passed to his decider?  His error is compounded by him
>>> incorrectly mapping his decider's recursion to the input being
>>> non-halting.
>>
>> It would be a big effort with a small probability of success.
>>
>> First you should find out what he already understands. If he
>> understands something and you know what you may try to expand
>> that understanding. Otherwise you should first teach him the
>> skill on understanding.
>>
>> Mikko
>>
>
> *THIS IS NECESSARILY TRUE*
> If a simulating halt decider continues to correctly simulate its input
> until it correctly matches a non-halting behavior pattern then this SHD
> is necessarily correct when it aborts its simulation and reports
> non-halting.

Right, and since H never finds a CORRECT non-halting pattern in its
simulation of P(P) (since any pattern it sees that it thinks is
non-halting and acts on makes P(P) Halting due to the call to H(P,P) in
P) means that H(P,P) will be non-halting or incorrect by breaking the rule.

>
> When-so-ever the correct simulation of any input would never stop unless
> aborted then the simulated input is not halting.

FALSE.

Please show your proof that uses it in that manner you do.

You are just proving you are a decietful pathological liar.
>
> On 7/24/2022 6:19 PM, Paul N wrote:
> > On Monday, July 25, 2022 at 12:10:34 AM UTC+1, olcott wrote:
> >> If a simulating halt decider continues to correctly
> >> simulate its input until it correctly matches a non-halting
> >> behavior pattern then this SHD is necessarily correct when
> >> it aborts its simulation and reports non-halting.
> >
> > Yes, *If* a simulating halt decider continues to correctly
> > simulate its input until it *correctly* matches a non-
> > halting behaviour pattern then this SHD is correct when it
> > aborts its simulation and reports non-halting.
> > [*some content snipped to stay focused on this point*]
>
>

On 7/26/22 9:21 AM, olcott wrote:
> On 7/26/2022 4:35 AM, Mikko wrote:
>> On 2022-07-25 19:22:42 +0000, Mr Flibble said:
>>
>>> How can we help Olcott understand that his "infinite recursion" is a
>>> property of his simulating halting decider and NOT a property of the
>>> input passed to his decider?  His error is compounded by him
>>> incorrectly mapping his decider's recursion to the input being
>>> non-halting.
>>
>> It would be a big effort with a small probability of success.
>>
>
> The infinite recursion is a property of P in that H simulates P that
> calls H. When H simulates P that calls H1 the infinite recursion goes away.

Nope, it is a property of H.

P isn't defined to call a "Simulator", it is defined to call a DECIDER,
which MUST return an answer in finite time.

Any "infinte recursion" is a result of H failing to meet its
requirements, and thus is a property of IT.

Get your problem definition right.

Oh, that may be the problem, you don't seeem to understand the defintion
of what a definition is, or the meaning of a lot of the words you use.

>
>> First you should find out what he already understands. If he
>> understands something and you know what you may try to expand
>> that understanding. Otherwise you should first teach him the
>> skill on understanding.
>>
>> Mikko
>>
>
>

On 7/26/22 9:21 AM, olcott wrote:
> On 7/25/2022 2:22 PM, Mr Flibble wrote:
>> How can we help Olcott understand that his "infinite recursion" is a
>> property of his simulating halting decider and NOT a property of the
>> input passed to his decider?
>
> The infinite recursion is a property of P in that H simulates P that
> calls H. When H simulates P that calls H1 the infinite recursion goes away.
>

Nope. Explained elsewhere.

You are just showing your utter ignorance.

>> His error is compounded by him
>> incorrectly mapping his decider's recursion to the input being
>> non-halting.
>>
>> /Flibble
>>
>
>

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Monday, 25 July 2022 at 20:22:44 UTC+1, Mr Flibble wrote:
>> How can we help Olcott understand that his "infinite recursion" is a
>> property of his simulating halting decider and NOT a property of the
>> input passed to his decider? His error is compounded by him
>> incorrectly mapping his decider's recursion to the input being
>> non-halting.
>>
> The input passed to the decider includes a near copy of the decider
> itself. So if the decider works on the simulating principle, then
> infinitely nested simulation is a property of the system, and that's
> the way that a reasonably functional simulating decider will fail.

This sentence is not unlike stating that if the moon is made of cheese
then halting is decidable. Or that a halt decider fails to be a halt
decider it can fail by infinitely nested simulation.

There are no halt deciders, simulating or otherwise. Nothing about them
can be recursive or non-recursive.

> (PO is aware of this and tries to code round it, but in fact this
> cannot be done).

He is not aware that there are no halt deciders, and I don't think
anyone should be encouraging that misunderstanding.

> However Linz's H_Hat doesn't require H to be a simulating halt
> decider.

He required H to an arbitrary denote a member of an empty set.

--
Ben.

On 7/27/2022 11:41 AM, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On Monday, 25 July 2022 at 20:22:44 UTC+1, Mr Flibble wrote:
>>> How can we help Olcott understand that his "infinite recursion" is a
>>> property of his simulating halting decider and NOT a property of the
>>> input passed to his decider? His error is compounded by him
>>> incorrectly mapping his decider's recursion to the input being
>>> non-halting.
>>>
>> The input passed to the decider includes a near copy of the decider
>> itself. So if the decider works on the simulating principle, then
>> infinitely nested simulation is a property of the system, and that's
>> the way that a reasonably functional simulating decider will fail.
>
> This sentence is not unlike stating that if the moon is made of cheese
> then halting is decidable. Or that a halt decider fails to be a halt
> decider it can fail by infinitely nested simulation.
>
> There are no halt deciders, simulating or otherwise. Nothing about them
> can be recursive or non-recursive.
>
>> (PO is aware of this and tries to code round it, but in fact this
>> cannot be done).
>
> He is not aware that there are no halt deciders, and I don't think
> anyone should be encouraging that misunderstanding.
>
>> However Linz's H_Hat doesn't require H to be a simulating halt
>> decider.
>
> He required H to an arbitrary denote a member of an empty set.
>

H(P,P) does correctly determine that its correct x86 emulation of its
input would never reach the C:"return" or x86:"ret" instruction of this
input because this input specifies infinitely recursive simulation to H.

*The earlier halt decider shows this more explicitly*

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

Begin Local Halt Decider Simulation Execution Trace Stored at:212352
// H emulates the first seven instructions of P
....[00001352][0021233e][00212342] 55 push ebp // enter P
....[00001353][0021233e][00212342] 8bec mov ebp,esp
....[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
....[00001358][0021233a][00001352] 50 push eax // push P
....[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
....[0000135c][00212336][00001352] 51 push ecx // push P
....[0000135d][00212332][00001362] e840feffff call 000011a2 // call H

// The emulated H emulates the first seven instructions of P
....[00001352][0025cd66][0025cd6a] 55 push ebp // enter P
....[00001353][0025cd66][0025cd6a] 8bec mov ebp,esp
....[00001355][0025cd66][0025cd6a] 8b4508 mov eax,[ebp+08]
....[00001358][0025cd62][00001352] 50 push eax // push P
....[00001359][0025cd62][00001352] 8b4d08 mov ecx,[ebp+08]
....[0000135c][0025cd5e][00001352] 51 push ecx // push P
....[0000135d][0025cd5a][00001362] e840feffff call 000011a2 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

The next instruction after P's call to H(P,P) for the correctly
simulated input to H(P,P) is at machine address: [00001352].

The next instruction after P's call to H(P,P) for the directly executed
P(P) is at machine address: [00001362] when H returns to P.

I will be working on getting this to compile under Ubuntu 1604.
I merely forgot where I put the adapted Bash script / Makefile.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On Wednesday, July 27, 2022 at 1:05:33 PM UTC-4, olcott wrote:
> On 7/27/2022 11:41 AM, Ben Bacarisse wrote:
> > Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >
> >> On Monday, 25 July 2022 at 20:22:44 UTC+1, Mr Flibble wrote:
> >>> How can we help Olcott understand that his "infinite recursion" is a
> >>> property of his simulating halting decider and NOT a property of the
> >>> input passed to his decider? His error is compounded by him
> >>> incorrectly mapping his decider's recursion to the input being
> >>> non-halting.
> >>>
> >> The input passed to the decider includes a near copy of the decider
> >> itself. So if the decider works on the simulating principle, then
> >> infinitely nested simulation is a property of the system, and that's
> >> the way that a reasonably functional simulating decider will fail.
> >
> > This sentence is not unlike stating that if the moon is made of cheese
> > then halting is decidable. Or that a halt decider fails to be a halt
> > decider it can fail by infinitely nested simulation.
> >
> > There are no halt deciders, simulating or otherwise. Nothing about them
> > can be recursive or non-recursive.
> >
> >> (PO is aware of this and tries to code round it, but in fact this
> >> cannot be done).
> >
> > He is not aware that there are no halt deciders, and I don't think
> > anyone should be encouraging that misunderstanding.
> >
> >> However Linz's H_Hat doesn't require H to be a simulating halt
> >> decider.
> >
> > He required H to an arbitrary denote a member of an empty set.
> >
> H(P,P) does correctly determine that its correct x86 emulation of its
> input would never reach the C:"return" or x86:"ret" instruction of this
> input because this input specifies infinitely recursive simulation to H.

The halting problem doesn't care that there is no implementation of the function H that can simulate the function P to a final state.

The halting problem cares if Pa(Pa) halts, which it does.

If Ha was a halt decider, Ha(Pa,Pa) would return 1. Ha(Pa,Pa) returns 0, therefore Ha is not a halt decider.

On 7/27/2022 12:14 PM, Dennis Bush wrote:
> On Wednesday, July 27, 2022 at 1:05:33 PM UTC-4, olcott wrote:
>> On 7/27/2022 11:41 AM, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>
>>>> On Monday, 25 July 2022 at 20:22:44 UTC+1, Mr Flibble wrote:
>>>>> How can we help Olcott understand that his "infinite recursion" is a
>>>>> property of his simulating halting decider and NOT a property of the
>>>>> input passed to his decider? His error is compounded by him
>>>>> incorrectly mapping his decider's recursion to the input being
>>>>> non-halting.
>>>>>
>>>> The input passed to the decider includes a near copy of the decider
>>>> itself. So if the decider works on the simulating principle, then
>>>> infinitely nested simulation is a property of the system, and that's
>>>> the way that a reasonably functional simulating decider will fail.
>>>
>>> This sentence is not unlike stating that if the moon is made of cheese
>>> then halting is decidable. Or that a halt decider fails to be a halt
>>> decider it can fail by infinitely nested simulation.
>>>
>>> There are no halt deciders, simulating or otherwise. Nothing about them
>>> can be recursive or non-recursive.
>>>
>>>> (PO is aware of this and tries to code round it, but in fact this
>>>> cannot be done).
>>>
>>> He is not aware that there are no halt deciders, and I don't think
>>> anyone should be encouraging that misunderstanding.
>>>
>>>> However Linz's H_Hat doesn't require H to be a simulating halt
>>>> decider.
>>>
>>> He required H to an arbitrary denote a member of an empty set.
>>>
>> H(P,P) does correctly determine that its correct x86 emulation of its
>> input would never reach the C:"return" or x86:"ret" instruction of this
>> input because this input specifies infinitely recursive simulation to H.
>
> The halting problem doesn't care that there is no implementation of the function H that can simulate the function P to a final state.
>
> The halting problem cares if Pa(Pa) halts, which it does.
>
> If Ha was a halt decider, Ha(Pa,Pa) would return 1. Ha(Pa,Pa) returns 0, therefore Ha is not a halt decider.
>

For any program H that might determine if programs halt, a
"pathological" program P, called with some input, can pass its own
source and its input to H and then specifically do the opposite of what
H predicts P will do. No H can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem

H(P,P) does correctly determine the halt status of the above
"pathological" input template.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer