This post assumes that you already know my work, otherwise please read
the linked paper provided below. This work is based on the x86utm
operating system that was created so that every detail of the halting
problem could be directly examined in C/x86.

void Infinite_Loop()
{ HERE: goto HERE;
}

int main()
{ Output("Input_Halts = ", H0(Infinite_Loop));
}

_Infinite_Loop()
[00001342](01) 55 push ebp
[00001343](02) 8bec mov ebp,esp
[00001345](02) ebfe jmp 00001345
[00001347](01) 5d pop ebp
[00001348](01) c3 ret
Size in bytes:(0007) [00001348]

It is totally obvious that the _Infinite_Loop() would never halt
(meaning that it terminates normally by reaching its "ret" instruction).

Equally obvious is the fact that a partial x86 emulation of this input
conclusively proves that its complete x86 emulation would never halt.

Begin Local Halt Decider Simulation Execution Trace Stored at:212343
[00001342][00212333][00212337] 55 push ebp
[00001343][00212333][00212337] 8bec mov ebp,esp
[00001345][00212333][00212337] ebfe jmp 00001345
[00001345][00212333][00212337] ebfe jmp 00001345
Local Halt Decider: Infinite Loop Detected Simulation Stopped

The exact same reasoning applies to the correctly emulated input to H(P,P):

_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]

It is completely obvious that when H(P,P) correctly emulates its input
that it must emulate the first seven instructions of P.

Because the seventh instruction repeats this process we can know with
complete certainty that the emulated P never reaches its final “ret”
instruction, thus never halts.

Halting problem undecidability and infinitely nested simulation (V5)

https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

--
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 6/3/22 6:17 PM, olcott wrote:
> This post assumes that you already know my work, otherwise please read
> the linked paper provided below. This work is based on the x86utm
> operating system that was created so that every detail of the halting
> problem could be directly examined in C/x86.
>
> void Infinite_Loop()
> {
>   HERE: goto HERE;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H0(Infinite_Loop));
> }
>
> _Infinite_Loop()
> [00001342](01)  55              push ebp
> [00001343](02)  8bec            mov ebp,esp
> [00001345](02)  ebfe            jmp 00001345
> [00001347](01)  5d              pop ebp
> [00001348](01)  c3              ret
> Size in bytes:(0007) [00001348]
>
> It is totally obvious that the _Infinite_Loop() would never halt
> (meaning that it terminates normally by reaching its "ret" instruction).
>
> Equally obvious is the fact that a partial x86 emulation of this input
> conclusively proves that its complete x86 emulation would never halt.
>
> Begin Local Halt Decider Simulation   Execution Trace Stored at:212343
> [00001342][00212333][00212337] 55         push ebp
> [00001343][00212333][00212337] 8bec       mov ebp,esp
> [00001345][00212333][00212337] ebfe       jmp 00001345
> [00001345][00212333][00212337] ebfe       jmp 00001345
> Local Halt Decider: Infinite Loop Detected Simulation Stopped
>
> The exact same reasoning applies to the correctly emulated input to H(P,P):
>
> _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]
>
> It is completely obvious that when H(P,P) correctly emulates its input
> that it must emulate the first seven instructions of P.

Maybe, but then it needs to emulate the eight instruction of the program
P which is at 000011a2, which you never show.

>
> Because the seventh instruction repeats this process we can know with
> complete certainty that the emulated P never reaches its final “ret”
> instruction, thus never halts.

Nope. You NEVER have actually shown a correct simulation of the program.

At least, the second "round" of simulation needs to be marked as "a
conditional simulation of the simulation of" the code you list.

Your example with Infinite_Loop doesn't translate to the simulation of
P(P) as there is no actual correct "infinite behavior" pattern that H
has seen, inpart because you ignore that the later rounds of simulation
are ALL conditional based on the simulated H doing its simulation
conditionally based on its halt decision rules.

This means that there actually is NO correct non-halting pattern in the
simulation it sees, so when it does abort, it does so incorrectly, or if
it never aborts, it fails to answer.

This has been explained to you many times, but you seem incapable of
actually learning by your mistakes, maybe because you have made yoursef
intentionally ignorant of the actual rules of logic, or maybe because
you are just a pathological liar.

FAIL.

>
>
>
> Halting problem undecidability and infinitely nested simulation (V5)
>
> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>
>
>

On Fri, 3 Jun 2022 17:17:12 -0500
olcott <NoOne@NoWhere.com> wrote:

> This post assumes that you already know my work, otherwise please
> read the linked paper provided below. This work is based on the
> x86utm operating system that was created so that every detail of the
> halting problem could be directly examined in C/x86.
>
> void Infinite_Loop()
> {
> HERE: goto HERE;
> }
>
> int main()
> {
> Output("Input_Halts = ", H0(Infinite_Loop));
> }
>
> _Infinite_Loop()
> [00001342](01) 55 push ebp
> [00001343](02) 8bec mov ebp,esp
> [00001345](02) ebfe jmp 00001345
> [00001347](01) 5d pop ebp
> [00001348](01) c3 ret
> Size in bytes:(0007) [00001348]
>
> It is totally obvious that the _Infinite_Loop() would never halt
> (meaning that it terminates normally by reaching its "ret"
> instruction).
>
> Equally obvious is the fact that a partial x86 emulation of this
> input conclusively proves that its complete x86 emulation would never
> halt.
>
> Begin Local Halt Decider Simulation Execution Trace Stored at:212343
> [00001342][00212333][00212337] 55 push ebp
> [00001343][00212333][00212337] 8bec mov ebp,esp
> [00001345][00212333][00212337] ebfe jmp 00001345
> [00001345][00212333][00212337] ebfe jmp 00001345
> Local Halt Decider: Infinite Loop Detected Simulation Stopped
>
> The exact same reasoning applies to the correctly emulated input to
> H(P,P):
>
> _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]
>
> It is completely obvious that when H(P,P) correctly emulates its
> input that it must emulate the first seven instructions of P.
>
> Because the seventh instruction repeats this process we can know with
> complete certainty that the emulated P never reaches its final “ret”
> instruction, thus never halts.
>
>
>
> Halting problem undecidability and infinitely nested simulation (V5)
>
> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

Unfortunately your logic is such that the decision as to whether or not
to enter the infinite loop is predicated on an infinite recursion (call
H) that is not present in the Halting Problem proofs you are attempting
to refute.

/Flibble

On Fri, 3 Jun 2022 17:17:12 -0500
olcott <NoOne@NoWhere.com> wrote:

> This post assumes that you already know my work, otherwise please
> read the linked paper provided below. This work is based on the
> x86utm operating system that was created so that every detail of the
> halting problem could be directly examined in C/x86.
>
> void Infinite_Loop()
> {
> HERE: goto HERE;
> }
>
> int main()
> {
> Output("Input_Halts = ", H0(Infinite_Loop));
> }
>
> _Infinite_Loop()
> [00001342](01) 55 push ebp
> [00001343](02) 8bec mov ebp,esp
> [00001345](02) ebfe jmp 00001345
> [00001347](01) 5d pop ebp
> [00001348](01) c3 ret
> Size in bytes:(0007) [00001348]
>
> It is totally obvious that the _Infinite_Loop() would never halt
> (meaning that it terminates normally by reaching its "ret"
> instruction).
>
> Equally obvious is the fact that a partial x86 emulation of this
> input conclusively proves that its complete x86 emulation would never
> halt.
>
> Begin Local Halt Decider Simulation Execution Trace Stored at:212343
> [00001342][00212333][00212337] 55 push ebp
> [00001343][00212333][00212337] 8bec mov ebp,esp
> [00001345][00212333][00212337] ebfe jmp 00001345
> [00001345][00212333][00212337] ebfe jmp 00001345
> Local Halt Decider: Infinite Loop Detected Simulation Stopped
>
> The exact same reasoning applies to the correctly emulated input to
> H(P,P):
>
> _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]
>
> It is completely obvious that when H(P,P) correctly emulates its
> input that it must emulate the first seven instructions of P.
>
> Because the seventh instruction repeats this process we can know with
> complete certainty that the emulated P never reaches its final “ret”
> instruction, thus never halts.
>
>
>
> Halting problem undecidability and infinitely nested simulation (V5)
>
> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

Unfortunately your logic is such that the decision as to whether or not
to enter the infinite loop is predicated on an infinite recursion (call
H) that is not present in the Halting Problem proofs you are attempting
to refute.

/Flibble

On 6/3/2022 6:35 PM, Mr Flibble wrote:
> On Fri, 3 Jun 2022 17:17:12 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> This post assumes that you already know my work, otherwise please
>> read the linked paper provided below. This work is based on the
>> x86utm operating system that was created so that every detail of the
>> halting problem could be directly examined in C/x86.
>>
>> void Infinite_Loop()
>> {
>> HERE: goto HERE;
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", H0(Infinite_Loop));
>> }
>>
>> _Infinite_Loop()
>> [00001342](01) 55 push ebp
>> [00001343](02) 8bec mov ebp,esp
>> [00001345](02) ebfe jmp 00001345
>> [00001347](01) 5d pop ebp
>> [00001348](01) c3 ret
>> Size in bytes:(0007) [00001348]
>>
>> It is totally obvious that the _Infinite_Loop() would never halt
>> (meaning that it terminates normally by reaching its "ret"
>> instruction).
>>
>> Equally obvious is the fact that a partial x86 emulation of this
>> input conclusively proves that its complete x86 emulation would never
>> halt.
>>
>> Begin Local Halt Decider Simulation Execution Trace Stored at:212343
>> [00001342][00212333][00212337] 55 push ebp
>> [00001343][00212333][00212337] 8bec mov ebp,esp
>> [00001345][00212333][00212337] ebfe jmp 00001345
>> [00001345][00212333][00212337] ebfe jmp 00001345
>> Local Halt Decider: Infinite Loop Detected Simulation Stopped
>>
>> The exact same reasoning applies to the correctly emulated input to
>> H(P,P):
>>
>> _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]
>>
>> It is completely obvious that when H(P,P) correctly emulates its
>> input that it must emulate the first seven instructions of P.
>>
>> Because the seventh instruction repeats this process we can know with
>> complete certainty that the emulated P never reaches its final “ret”
>> instruction, thus never halts.
>>
>>
>>
>> Halting problem undecidability and infinitely nested simulation (V5)
>>
>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>
> Unfortunately your logic is such that the decision as to whether or not
> to enter the infinite loop is predicated on an infinite recursion (call
> H) that is not present in the Halting Problem proofs you are attempting
> to refute.
>
> /Flibble
>

It is when a simulating halt decider is assumed.

No one ever bothered to think the otherwise "impossible" input being
analyzed by a simulating halt decider ALL THE WAY THROUGH EVER BEFORE!

On 6/2/2022 1:12 PM, Andy Walker wrote:
> http://www.cuboid.me.uk/anw/G12FCO/lect18.html
At any given moment as the emulation proceeds, we are in one of not two
but three states: the program has halted, or it is looping, or it is
still running and has not yet entered a loop. It's the third case that
kills us -- we just have to keep going, and wait for one of the other
two things to happen. The trouble is that it may be that neither of them
ever happens -- which is why `it must be in a loop' was in quotes above.

Andy Walker did provide a fundamentally flawed and totally shallow
analysis of an simulating halt decider.

At any given moment as the emulation proceeds,
we are in one of not two but three states:
(a) The program has halted,
(b) It is still running.
(c) IT HAS MATCHED AN INFINITE BEHAVIOR PATTERN

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

The above matches (c) for infinitely nested simulation.

--
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 6/3/22 7:56 PM, olcott wrote:
> On 6/3/2022 6:35 PM, Mr Flibble wrote:
>> On Fri, 3 Jun 2022 17:17:12 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> This post assumes that you already know my work, otherwise please
>>> read the linked paper provided below. This work is based on the
>>> x86utm operating system that was created so that every detail of the
>>> halting problem could be directly examined in C/x86.
>>>
>>> void Infinite_Loop()
>>> {
>>>     HERE: goto HERE;
>>> }
>>>
>>> int main()
>>> {
>>>     Output("Input_Halts = ", H0(Infinite_Loop));
>>> }
>>>
>>> _Infinite_Loop()
>>> [00001342](01)  55              push ebp
>>> [00001343](02)  8bec            mov ebp,esp
>>> [00001345](02)  ebfe            jmp 00001345
>>> [00001347](01)  5d              pop ebp
>>> [00001348](01)  c3              ret
>>> Size in bytes:(0007) [00001348]
>>>
>>> It is totally obvious that the _Infinite_Loop() would never halt
>>> (meaning that it terminates normally by reaching its "ret"
>>> instruction).
>>>
>>> Equally obvious is the fact that a partial x86 emulation of this
>>> input conclusively proves that its complete x86 emulation would never
>>> halt.
>>>
>>> Begin Local Halt Decider Simulation   Execution Trace Stored at:212343
>>> [00001342][00212333][00212337] 55         push ebp
>>> [00001343][00212333][00212337] 8bec       mov ebp,esp
>>> [00001345][00212333][00212337] ebfe       jmp 00001345
>>> [00001345][00212333][00212337] ebfe       jmp 00001345
>>> Local Halt Decider: Infinite Loop Detected Simulation Stopped
>>>
>>> The exact same reasoning applies to the correctly emulated input to
>>> H(P,P):
>>>
>>> _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]
>>>
>>> It is completely obvious that when H(P,P) correctly emulates its
>>> input that it must emulate the first seven instructions of P.
>>>
>>> Because the seventh instruction repeats this process we can know with
>>> complete certainty that the emulated P never reaches its final “ret”
>>> instruction, thus never halts.
>>>
>>>
>>>
>>> Halting problem undecidability and infinitely nested simulation (V5)
>>>
>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>
>>
>> Unfortunately your logic is such that the decision as to whether or not
>> to enter the infinite loop is predicated on an infinite recursion (call
>> H) that is not present in the Halting Problem proofs you are attempting
>> to refute.
>>
>> /Flibble
>>
>
> It is when a simulating halt decider is assumed.

But you can not assume that an actual simulating Halt Decider actually
exists.

>
> No one ever bothered to think the otherwise "impossible" input being
> analyzed by a simulating halt decider ALL THE WAY THROUGH EVER BEFORE!

>
> On 6/2/2022 1:12 PM, Andy Walker wrote:
> >  http://www.cuboid.me.uk/anw/G12FCO/lect18.html
> At any given moment as the emulation proceeds, we are in one of not two
> but three states: the program has halted, or it is looping, or it is
> still running and has not yet entered a loop. It's the third case that
> kills us -- we just have to keep going, and wait for one of the other
> two things to happen. The trouble is that it may be that neither of them
> ever happens -- which is why `it must be in a loop' was in quotes above.
>
> Andy Walker did provide a fundamentally flawed and totally shallow
> analysis of an simulating halt decider.
>
> At any given moment as the emulation proceeds,
> we are in one of not two but three states:
> (a) The program has halted,
> (b) It is still running.
> (c) IT HAS MATCHED AN INFINITE BEHAVIOR PATTERN
>
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> The above matches (c) for infinitely nested simulation.
>

Nope, you NEVER get to (C) if H can abort its simulation, since if
H(P,P) will abort its simulation and return 0, then BY DEFINITON P(P) is
Halting, and thus the CORRECT answer for H(P,P) is 1.

You can show you get to (c) if H is defined to never abort, but if H is
defined to never abort, it can't then abort and return the answer.

The problem is that when H is defined to abort on ANY finite pattern you
might imagine to be a "correct infinite behavior pattern", then that
pattern is actually proved to not be correct.

The problem is you need to do the analysis looking at the H(P,P) called
by P(P) as being able to what it actually ends up doing. Thus, if you
postulate the top level H(P,P) aborting its simulation for detecting a
pattern, you need to show that pattern actually does exist when the H
that it is simulating will do the same thing.

The pattern you are think of doesn't consider that case, but assumes
that H NEVER (and not just "Not yet") aborts its simulation, and thus is
not applicable here.

The problem appears because the trace you "show" isn't correct, but is
edited and removes the evidence of the conditionality of the "nested"
simulations.

On 6/3/2022 7:20 PM, Richard Damon wrote:
>
> On 6/3/22 7:56 PM, olcott wrote:
>> On 6/3/2022 6:35 PM, Mr Flibble wrote:
>>> On Fri, 3 Jun 2022 17:17:12 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> This post assumes that you already know my work, otherwise please
>>>> read the linked paper provided below. This work is based on the
>>>> x86utm operating system that was created so that every detail of the
>>>> halting problem could be directly examined in C/x86.
>>>>
>>>> void Infinite_Loop()
>>>> {
>>>>     HERE: goto HERE;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>     Output("Input_Halts = ", H0(Infinite_Loop));
>>>> }
>>>>
>>>> _Infinite_Loop()
>>>> [00001342](01)  55              push ebp
>>>> [00001343](02)  8bec            mov ebp,esp
>>>> [00001345](02)  ebfe            jmp 00001345
>>>> [00001347](01)  5d              pop ebp
>>>> [00001348](01)  c3              ret
>>>> Size in bytes:(0007) [00001348]
>>>>
>>>> It is totally obvious that the _Infinite_Loop() would never halt
>>>> (meaning that it terminates normally by reaching its "ret"
>>>> instruction).
>>>>
>>>> Equally obvious is the fact that a partial x86 emulation of this
>>>> input conclusively proves that its complete x86 emulation would never
>>>> halt.
>>>>
>>>> Begin Local Halt Decider Simulation   Execution Trace Stored at:212343
>>>> [00001342][00212333][00212337] 55         push ebp
>>>> [00001343][00212333][00212337] 8bec       mov ebp,esp
>>>> [00001345][00212333][00212337] ebfe       jmp 00001345
>>>> [00001345][00212333][00212337] ebfe       jmp 00001345
>>>> Local Halt Decider: Infinite Loop Detected Simulation Stopped
>>>>
>>>> The exact same reasoning applies to the correctly emulated input to
>>>> H(P,P):
>>>>
>>>> _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]
>>>>
>>>> It is completely obvious that when H(P,P) correctly emulates its
>>>> input that it must emulate the first seven instructions of P.
>>>>
>>>> Because the seventh instruction repeats this process we can know with
>>>> complete certainty that the emulated P never reaches its final “ret”
>>>> instruction, thus never halts.
>>>>
>>>>
>>>>
>>>> Halting problem undecidability and infinitely nested simulation (V5)
>>>>
>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>
>>>
>>> Unfortunately your logic is such that the decision as to whether or not
>>> to enter the infinite loop is predicated on an infinite recursion (call
>>> H) that is not present in the Halting Problem proofs you are attempting
>>> to refute.
>>>
>>> /Flibble
>>>
>>
>> It is when a simulating halt decider is assumed.
>
> But you can not assume that an actual simulating Halt Decider actually
> exists.

I proved that H(P,P)==0 is correct.

--
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 6/3/22 11:51 PM, olcott wrote:
> On 6/3/2022 7:20 PM, Richard Damon wrote:
>>
>> On 6/3/22 7:56 PM, olcott wrote:
>>> On 6/3/2022 6:35 PM, Mr Flibble wrote:
>>>> On Fri, 3 Jun 2022 17:17:12 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>
>>>>> This post assumes that you already know my work, otherwise please
>>>>> read the linked paper provided below. This work is based on the
>>>>> x86utm operating system that was created so that every detail of the
>>>>> halting problem could be directly examined in C/x86.
>>>>>
>>>>> void Infinite_Loop()
>>>>> {
>>>>>     HERE: goto HERE;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>     Output("Input_Halts = ", H0(Infinite_Loop));
>>>>> }
>>>>>
>>>>> _Infinite_Loop()
>>>>> [00001342](01)  55              push ebp
>>>>> [00001343](02)  8bec            mov ebp,esp
>>>>> [00001345](02)  ebfe            jmp 00001345
>>>>> [00001347](01)  5d              pop ebp
>>>>> [00001348](01)  c3              ret
>>>>> Size in bytes:(0007) [00001348]
>>>>>
>>>>> It is totally obvious that the _Infinite_Loop() would never halt
>>>>> (meaning that it terminates normally by reaching its "ret"
>>>>> instruction).
>>>>>
>>>>> Equally obvious is the fact that a partial x86 emulation of this
>>>>> input conclusively proves that its complete x86 emulation would never
>>>>> halt.
>>>>>
>>>>> Begin Local Halt Decider Simulation   Execution Trace Stored at:212343
>>>>> [00001342][00212333][00212337] 55         push ebp
>>>>> [00001343][00212333][00212337] 8bec       mov ebp,esp
>>>>> [00001345][00212333][00212337] ebfe       jmp 00001345
>>>>> [00001345][00212333][00212337] ebfe       jmp 00001345
>>>>> Local Halt Decider: Infinite Loop Detected Simulation Stopped
>>>>>
>>>>> The exact same reasoning applies to the correctly emulated input to
>>>>> H(P,P):
>>>>>
>>>>> _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]
>>>>>
>>>>> It is completely obvious that when H(P,P) correctly emulates its
>>>>> input that it must emulate the first seven instructions of P.
>>>>>
>>>>> Because the seventh instruction repeats this process we can know with
>>>>> complete certainty that the emulated P never reaches its final “ret”
>>>>> instruction, thus never halts.
>>>>>
>>>>>
>>>>>
>>>>> Halting problem undecidability and infinitely nested simulation (V5)
>>>>>
>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>
>>>>
>>>> Unfortunately your logic is such that the decision as to whether or not
>>>> to enter the infinite loop is predicated on an infinite recursion (call
>>>> H) that is not present in the Halting Problem proofs you are attempting
>>>> to refute.
>>>>
>>>> /Flibble
>>>>
>>>
>>> It is when a simulating halt decider is assumed.
>>
>> But you can not assume that an actual simulating Halt Decider actually
>> exists.
>
> I proved that H(P,P)==0 is correct.
>

No, not for the ACTUAL halting problem.

You have shown that H(P,P) == 0 is correct if the problem is can H
simulate its input to a final state, not does that input, when actually
run (or correctly simulate by the actual definition of correct
simulation) reach a final state.

On 6/4/2022 5:01 AM, Malcolm McLean wrote:
> On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:
>> On 6/3/2022 7:20 PM, Richard Damon wrote:
>>>
>>> On 6/3/22 7:56 PM, olcott wrote:
>>>> On 6/3/2022 6:35 PM, Mr Flibble wrote:
>>>>> On Fri, 3 Jun 2022 17:17:12 -0500
>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>
>>>>>> This post assumes that you already know my work, otherwise please
>>>>>> read the linked paper provided below. This work is based on the
>>>>>> x86utm operating system that was created so that every detail of the
>>>>>> halting problem could be directly examined in C/x86.
>>>>>>
>>>>>> void Infinite_Loop()
>>>>>> {
>>>>>> HERE: goto HERE;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> Output("Input_Halts = ", H0(Infinite_Loop));
>>>>>> }
>>>>>>
>>>>>> _Infinite_Loop()
>>>>>> [00001342](01) 55 push ebp
>>>>>> [00001343](02) 8bec mov ebp,esp
>>>>>> [00001345](02) ebfe jmp 00001345
>>>>>> [00001347](01) 5d pop ebp
>>>>>> [00001348](01) c3 ret
>>>>>> Size in bytes:(0007) [00001348]
>>>>>>
>>>>>> It is totally obvious that the _Infinite_Loop() would never halt
>>>>>> (meaning that it terminates normally by reaching its "ret"
>>>>>> instruction).
>>>>>>
>>>>>> Equally obvious is the fact that a partial x86 emulation of this
>>>>>> input conclusively proves that its complete x86 emulation would never
>>>>>> halt.
>>>>>>
>>>>>> Begin Local Halt Decider Simulation Execution Trace Stored at:212343
>>>>>> [00001342][00212333][00212337] 55 push ebp
>>>>>> [00001343][00212333][00212337] 8bec mov ebp,esp
>>>>>> [00001345][00212333][00212337] ebfe jmp 00001345
>>>>>> [00001345][00212333][00212337] ebfe jmp 00001345
>>>>>> Local Halt Decider: Infinite Loop Detected Simulation Stopped
>>>>>>
>>>>>> The exact same reasoning applies to the correctly emulated input to
>>>>>> H(P,P):
>>>>>>
>>>>>> _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]
>>>>>>
>>>>>> It is completely obvious that when H(P,P) correctly emulates its
>>>>>> input that it must emulate the first seven instructions of P.
>>>>>>
>>>>>> Because the seventh instruction repeats this process we can know with
>>>>>> complete certainty that the emulated P never reaches its final “ret”
>>>>>> instruction, thus never halts.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Halting problem undecidability and infinitely nested simulation (V5)
>>>>>>
>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>>
>>>>>
>>>>> Unfortunately your logic is such that the decision as to whether or not
>>>>> to enter the infinite loop is predicated on an infinite recursion (call
>>>>> H) that is not present in the Halting Problem proofs you are attempting
>>>>> to refute.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> It is when a simulating halt decider is assumed.
>>>
>>> But you can not assume that an actual simulating Halt Decider actually
>>> exists.
>> I proved that H(P,P)==0 is correct.
>>
> You've got nested simulations.
> If H detects them as infinitely nested, and aborts, they are no longer infinitely
> nested, so it gets the wrong answer (as happens here).

I can't understand how you can be so wrong about this. It is like you
make sure to never read anything that I say before spouting off a canned
rebuttal.

void Infinite_Loop()
{ HERE: goto HERE;
}

int main()
{ Output("Input_Halts = ", H0(Infinite_Loop));
}

_Infinite_Loop()
[00001342](01) 55 push ebp
[00001343](02) 8bec mov ebp,esp
[00001345](02) ebfe jmp 00001345
[00001347](01) 5d pop ebp
[00001348](01) c3 ret
Size in bytes:(0007) [00001348]

In the same way that H0 detects that the complete x86 emulation of
_Infinite_Loop() would never reach its final "ret" instruction H(P,P) on
the basis of a partial simulation H(P,P) detects that the complete x86
emulation of its input would never reach its final "ret" instruction.

Did you notice that I said this 500 times already?
Did you notice that I said this 500 times already?
Did you notice that I said this 500 times already?

HALTING DOES NOT MEAN STOPS RUNNING
HALTING DOES NOT MEAN STOPS RUNNING
HALTING DOES NOT MEAN STOPS RUNNING

HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY
HALTING MEANS TERMINATED NORMALLY

> If H doesn't detects them as infinitely nested, and never aborts, H simulates
> forever, because they are infinitely nested.
>
> Either way, H gets it wrong.
>

So you are saying that it is impossible for H0 to correctly detect that
_Infinite_Loop() would never reach its final "ret" instruction because
as soon _Infinite_Loop() has had its simulation aborted it magically
leaps to its "ret" instruction.

> My own view is that you've actually got something interesting here. That isn't
> shared by other posters, probably because you've put them off by claims to have
> "solved the halting problem", repeated at great length.

--
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 6/4/2022 5:27 AM, Richard Damon wrote:
> On 6/3/22 11:51 PM, olcott wrote:
>> On 6/3/2022 7:20 PM, Richard Damon wrote:
>>>
>>> On 6/3/22 7:56 PM, olcott wrote:
>>>> On 6/3/2022 6:35 PM, Mr Flibble wrote:
>>>>> On Fri, 3 Jun 2022 17:17:12 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> This post assumes that you already know my work, otherwise please
>>>>>> read the linked paper provided below. This work is based on the
>>>>>> x86utm operating system that was created so that every detail of the
>>>>>> halting problem could be directly examined in C/x86.
>>>>>>
>>>>>> void Infinite_Loop()
>>>>>> {
>>>>>>     HERE: goto HERE;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>>     Output("Input_Halts = ", H0(Infinite_Loop));
>>>>>> }
>>>>>>
>>>>>> _Infinite_Loop()
>>>>>> [00001342](01)  55              push ebp
>>>>>> [00001343](02)  8bec            mov ebp,esp
>>>>>> [00001345](02)  ebfe            jmp 00001345
>>>>>> [00001347](01)  5d              pop ebp
>>>>>> [00001348](01)  c3              ret
>>>>>> Size in bytes:(0007) [00001348]
>>>>>>
>>>>>> It is totally obvious that the _Infinite_Loop() would never halt
>>>>>> (meaning that it terminates normally by reaching its "ret"
>>>>>> instruction).
>>>>>>
>>>>>> Equally obvious is the fact that a partial x86 emulation of this
>>>>>> input conclusively proves that its complete x86 emulation would never
>>>>>> halt.
>>>>>>
>>>>>> Begin Local Halt Decider Simulation   Execution Trace Stored
>>>>>> at:212343
>>>>>> [00001342][00212333][00212337] 55         push ebp
>>>>>> [00001343][00212333][00212337] 8bec       mov ebp,esp
>>>>>> [00001345][00212333][00212337] ebfe       jmp 00001345
>>>>>> [00001345][00212333][00212337] ebfe       jmp 00001345
>>>>>> Local Halt Decider: Infinite Loop Detected Simulation Stopped
>>>>>>
>>>>>> The exact same reasoning applies to the correctly emulated input to
>>>>>> H(P,P):
>>>>>>
>>>>>> _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]
>>>>>>
>>>>>> It is completely obvious that when H(P,P) correctly emulates its
>>>>>> input that it must emulate the first seven instructions of P.
>>>>>>
>>>>>> Because the seventh instruction repeats this process we can know with
>>>>>> complete certainty that the emulated P never reaches its final “ret”
>>>>>> instruction, thus never halts.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Halting problem undecidability and infinitely nested simulation (V5)
>>>>>>
>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>>
>>>>>
>>>>> Unfortunately your logic is such that the decision as to whether or
>>>>> not
>>>>> to enter the infinite loop is predicated on an infinite recursion
>>>>> (call
>>>>> H) that is not present in the Halting Problem proofs you are
>>>>> attempting
>>>>> to refute.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> It is when a simulating halt decider is assumed.
>>>
>>> But you can not assume that an actual simulating Halt Decider
>>> actually exists.
>>
>> I proved that H(P,P)==0 is correct.
>>
>
> No, not for the ACTUAL halting problem.
>
> You have shown that H(P,P) == 0 is correct if the problem is can H
> simulate its input to a final state,

THIS IS THE ACTUAL CORRECT PROBLEM DEFINITION
H computes the mapping from its input finite strings to its accept or
reject state on the basis of the actual behavior specified by the actual
input as measured by the correct x86 emulation of this input by H.

> not does that input, when actually
> run (or correctly simulate by the actual definition of correct
> simulation) reach a final state.

int sum(int x, int y)
{ return x + y;
}

It as is nutty to say that H(P,P) must return a value that does not
correspond to its input as it is to expect sum(3,4) to return 23.

--
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 6/4/22 11:11 AM, olcott wrote:
> On 6/4/2022 5:01 AM, Malcolm McLean wrote:
>> On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:
>>> On 6/3/2022 7:20 PM, Richard Damon wrote:
>>>>
>>>> On 6/3/22 7:56 PM, olcott wrote:
>>>>> On 6/3/2022 6:35 PM, Mr Flibble wrote:
>>>>>> On Fri, 3 Jun 2022 17:17:12 -0500
>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>
>>>>>>> This post assumes that you already know my work, otherwise please
>>>>>>> read the linked paper provided below. This work is based on the
>>>>>>> x86utm operating system that was created so that every detail of the
>>>>>>> halting problem could be directly examined in C/x86.
>>>>>>>
>>>>>>> void Infinite_Loop()
>>>>>>> {
>>>>>>>      HERE: goto HERE;
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>>      Output("Input_Halts = ", H0(Infinite_Loop));
>>>>>>> }
>>>>>>>
>>>>>>> _Infinite_Loop()
>>>>>>> [00001342](01)  55              push ebp
>>>>>>> [00001343](02)  8bec            mov ebp,esp
>>>>>>> [00001345](02)  ebfe            jmp 00001345
>>>>>>> [00001347](01)  5d              pop ebp
>>>>>>> [00001348](01)  c3              ret
>>>>>>> Size in bytes:(0007) [00001348]
>>>>>>>
>>>>>>> It is totally obvious that the _Infinite_Loop() would never halt
>>>>>>> (meaning that it terminates normally by reaching its "ret"
>>>>>>> instruction).
>>>>>>>
>>>>>>> Equally obvious is the fact that a partial x86 emulation of this
>>>>>>> input conclusively proves that its complete x86 emulation would
>>>>>>> never
>>>>>>> halt.
>>>>>>>
>>>>>>> Begin Local Halt Decider Simulation   Execution Trace Stored
>>>>>>> at:212343
>>>>>>> [00001342][00212333][00212337] 55         push ebp
>>>>>>> [00001343][00212333][00212337] 8bec       mov ebp,esp
>>>>>>> [00001345][00212333][00212337] ebfe       jmp 00001345
>>>>>>> [00001345][00212333][00212337] ebfe       jmp 00001345
>>>>>>> Local Halt Decider: Infinite Loop Detected Simulation Stopped
>>>>>>>
>>>>>>> The exact same reasoning applies to the correctly emulated input to
>>>>>>> H(P,P):
>>>>>>>
>>>>>>> _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]
>>>>>>>
>>>>>>> It is completely obvious that when H(P,P) correctly emulates its
>>>>>>> input that it must emulate the first seven instructions of P.
>>>>>>>
>>>>>>> Because the seventh instruction repeats this process we can know
>>>>>>> with
>>>>>>> complete certainty that the emulated P never reaches its final “ret”
>>>>>>> instruction, thus never halts.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Halting problem undecidability and infinitely nested simulation (V5)
>>>>>>>
>>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Unfortunately your logic is such that the decision as to whether
>>>>>> or not
>>>>>> to enter the infinite loop is predicated on an infinite recursion
>>>>>> (call
>>>>>> H) that is not present in the Halting Problem proofs you are
>>>>>> attempting
>>>>>> to refute.
>>>>>>
>>>>>> /Flibble
>>>>>>
>>>>>
>>>>> It is when a simulating halt decider is assumed.
>>>>
>>>> But you can not assume that an actual simulating Halt Decider actually
>>>> exists.
>>> I proved that H(P,P)==0 is correct.
>>>
>> You've got nested simulations.
>> If H detects them as infinitely nested, and aborts, they are no longer
>> infinitely
>> nested, so it gets the wrong answer (as happens here).
>
> I can't understand how you can be so wrong about this. It is like you
> make sure to never read anything that I say before spouting off a canned
> rebuttal.
>
> void Infinite_Loop()
> {
>   HERE: goto HERE;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H0(Infinite_Loop));
> }
>
> _Infinite_Loop()
> [00001342](01)  55              push ebp
> [00001343](02)  8bec            mov ebp,esp
> [00001345](02)  ebfe            jmp 00001345
> [00001347](01)  5d              pop ebp
> [00001348](01)  c3              ret
> Size in bytes:(0007) [00001348]
>
> In the same way that H0 detects that the complete x86 emulation of
> _Infinite_Loop() would never reach its final "ret" instruction H(P,P) on
> the basis of a partial simulation H(P,P) detects that the complete x86
> emulation of its input would never reach its final "ret" instruction.
>
> Did you notice that I said this 500 times already?
> Did you notice that I said this 500 times already?
> Did you notice that I said this 500 times already?
>
> HALTING DOES NOT MEAN STOPS RUNNING
> HALTING DOES NOT MEAN STOPS RUNNING
> HALTING DOES NOT MEAN STOPS RUNNING

Right, and for the simulation of H(P,P), that is all that happen

>
> HALTING MEANS TERMINATED NORMALLY
> HALTING MEANS TERMINATED NORMALLY
> HALTING MEANS TERMINATED NORMALLY

And the input to H(P,P) does TERMINATE NORMALLY when correct simulated.

>
>> If H doesn't detects them as infinitely nested, and never aborts, H
>> simulates
>> forever, because they are infinitely nested.
>>
>> Either way, H gets it wrong.
>>
>
> So you are saying that it is impossible for H0 to correctly detect that
> _Infinite_Loop() would never reach its final "ret" instruction because
> as soon _Infinite_Loop() has had its simulation aborted it magically
> leaps to its "ret" instruction.

Nope, he NEVER said that. You apparently just can't read, and thus prove
your stupidity.

You keep on making this mistake, that when people say your H can't do
one thing about P, that you say "Are you saying it can't do it for this
other trivial program?"

You are a great example of someone using many different logical
fallicies in their arguement.

You use them SO well, it really seems to be deliberate.

All you have proved so far is that you just don't understand how to do
proper logical arguments, and are appatently way out of your depth in
what you are talking about.

>
>> My own view is that you've actually got something interesting here.
>> That isn't
>> shared by other posters, probably because you've put them off by
>> claims to have
>> "solved the halting problem", repeated at great length.
>
>

On 6/4/22 11:28 AM, olcott wrote:
> On 6/4/2022 5:27 AM, Richard Damon wrote:
>> On 6/3/22 11:51 PM, olcott wrote:
>>> On 6/3/2022 7:20 PM, Richard Damon wrote:
>>>>
>>>> On 6/3/22 7:56 PM, olcott wrote:
>>>>> On 6/3/2022 6:35 PM, Mr Flibble wrote:
>>>>>> On Fri, 3 Jun 2022 17:17:12 -0500
>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>
>>>>>>> This post assumes that you already know my work, otherwise please
>>>>>>> read the linked paper provided below. This work is based on the
>>>>>>> x86utm operating system that was created so that every detail of the
>>>>>>> halting problem could be directly examined in C/x86.
>>>>>>>
>>>>>>> void Infinite_Loop()
>>>>>>> {
>>>>>>>     HERE: goto HERE;
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>>     Output("Input_Halts = ", H0(Infinite_Loop));
>>>>>>> }
>>>>>>>
>>>>>>> _Infinite_Loop()
>>>>>>> [00001342](01)  55              push ebp
>>>>>>> [00001343](02)  8bec            mov ebp,esp
>>>>>>> [00001345](02)  ebfe            jmp 00001345
>>>>>>> [00001347](01)  5d              pop ebp
>>>>>>> [00001348](01)  c3              ret
>>>>>>> Size in bytes:(0007) [00001348]
>>>>>>>
>>>>>>> It is totally obvious that the _Infinite_Loop() would never halt
>>>>>>> (meaning that it terminates normally by reaching its "ret"
>>>>>>> instruction).
>>>>>>>
>>>>>>> Equally obvious is the fact that a partial x86 emulation of this
>>>>>>> input conclusively proves that its complete x86 emulation would
>>>>>>> never
>>>>>>> halt.
>>>>>>>
>>>>>>> Begin Local Halt Decider Simulation   Execution Trace Stored
>>>>>>> at:212343
>>>>>>> [00001342][00212333][00212337] 55         push ebp
>>>>>>> [00001343][00212333][00212337] 8bec       mov ebp,esp
>>>>>>> [00001345][00212333][00212337] ebfe       jmp 00001345
>>>>>>> [00001345][00212333][00212337] ebfe       jmp 00001345
>>>>>>> Local Halt Decider: Infinite Loop Detected Simulation Stopped
>>>>>>>
>>>>>>> The exact same reasoning applies to the correctly emulated input to
>>>>>>> H(P,P):
>>>>>>>
>>>>>>> _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]
>>>>>>>
>>>>>>> It is completely obvious that when H(P,P) correctly emulates its
>>>>>>> input that it must emulate the first seven instructions of P.
>>>>>>>
>>>>>>> Because the seventh instruction repeats this process we can know
>>>>>>> with
>>>>>>> complete certainty that the emulated P never reaches its final “ret”
>>>>>>> instruction, thus never halts.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Halting problem undecidability and infinitely nested simulation (V5)
>>>>>>>
>>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>>>
>>>>>>
>>>>>> Unfortunately your logic is such that the decision as to whether
>>>>>> or not
>>>>>> to enter the infinite loop is predicated on an infinite recursion
>>>>>> (call
>>>>>> H) that is not present in the Halting Problem proofs you are
>>>>>> attempting
>>>>>> to refute.
>>>>>>
>>>>>> /Flibble
>>>>>>
>>>>>
>>>>> It is when a simulating halt decider is assumed.
>>>>
>>>> But you can not assume that an actual simulating Halt Decider
>>>> actually exists.
>>>
>>> I proved that H(P,P)==0 is correct.
>>>
>>
>> No, not for the ACTUAL halting problem.
>>
>> You have shown that H(P,P) == 0 is correct if the problem is can H
>> simulate its input to a final state,
>
>
> THIS IS THE ACTUAL CORRECT PROBLEM DEFINITION
> H computes the mapping from its input finite strings to its accept or
> reject state on the basis of the actual behavior specified by the actual
> input as measured by the correct x86 emulation of this input by H.

Ok, since your problem statement NEVER mentions the Halting Property, I
guess that means you are admitting you aren't actually working on the
Halting Property.

Also, since the only valid defintion of a "correct x86 emulation" must
behave exactly the same that input when run by an x86 processor, the
ONLY way that H can actually DO that is to never abort until it reaches
the final state, even if that takes forever.

H also needs to be a DEFINITE piece of code, so at can only have a
single behavior for a given input.

Thus, you definition is just shown to be flawed, as H CAN'T both create
a "correct x86 emulation" of the input P,P and also compute a mapping in
finite time,

Either you H fails to correctly emulate its input by deciding early that
its input would not halt, (this can be shown by an actual correct
emulation of that input reaching the halting state), or your H fails to
map this input to an acccept or reject state.

Thus, your definition is just like the Liar's Paradox, it doesn't
actually have a truth value because it just can't exist as stated.

>
>> not does that input, when actually run (or correctly simulate by the
>> actual definition of correct simulation) reach a final state.
>
> int sum(int x, int y)
> {
>   return x + y;
> }
>
> It as is nutty to say that H(P,P) must return a value that does not
> correspond to its input as it is to expect sum(3,4) to return 23.
>

On 6/4/2022 10:38 AM, Richard Damon wrote:
> On 6/4/22 11:11 AM, olcott wrote:
>> On 6/4/2022 5:01 AM, Malcolm McLean wrote:
>>> On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:
>>>> On 6/3/2022 7:20 PM, Richard Damon wrote:
>>>>>
>>>>> On 6/3/22 7:56 PM, olcott wrote:
>>>>>> On 6/3/2022 6:35 PM, Mr Flibble wrote:
>>>>>>> On Fri, 3 Jun 2022 17:17:12 -0500
>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> This post assumes that you already know my work, otherwise please
>>>>>>>> read the linked paper provided below. This work is based on the
>>>>>>>> x86utm operating system that was created so that every detail of
>>>>>>>> the
>>>>>>>> halting problem could be directly examined in C/x86.
>>>>>>>>
>>>>>>>> void Infinite_Loop()
>>>>>>>> {
>>>>>>>>      HERE: goto HERE;
>>>>>>>> }
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>>      Output("Input_Halts = ", H0(Infinite_Loop));
>>>>>>>> }
>>>>>>>>
>>>>>>>> _Infinite_Loop()
>>>>>>>> [00001342](01)  55              push ebp
>>>>>>>> [00001343](02)  8bec            mov ebp,esp
>>>>>>>> [00001345](02)  ebfe            jmp 00001345
>>>>>>>> [00001347](01)  5d              pop ebp
>>>>>>>> [00001348](01)  c3              ret
>>>>>>>> Size in bytes:(0007) [00001348]
>>>>>>>>
>>>>>>>> It is totally obvious that the _Infinite_Loop() would never halt
>>>>>>>> (meaning that it terminates normally by reaching its "ret"
>>>>>>>> instruction).
>>>>>>>>
>>>>>>>> Equally obvious is the fact that a partial x86 emulation of this
>>>>>>>> input conclusively proves that its complete x86 emulation would
>>>>>>>> never
>>>>>>>> halt.
>>>>>>>>
>>>>>>>> Begin Local Halt Decider Simulation   Execution Trace Stored
>>>>>>>> at:212343
>>>>>>>> [00001342][00212333][00212337] 55         push ebp
>>>>>>>> [00001343][00212333][00212337] 8bec       mov ebp,esp
>>>>>>>> [00001345][00212333][00212337] ebfe       jmp 00001345
>>>>>>>> [00001345][00212333][00212337] ebfe       jmp 00001345
>>>>>>>> Local Halt Decider: Infinite Loop Detected Simulation Stopped
>>>>>>>>
>>>>>>>> The exact same reasoning applies to the correctly emulated input to
>>>>>>>> H(P,P):
>>>>>>>>
>>>>>>>> _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]
>>>>>>>>
>>>>>>>> It is completely obvious that when H(P,P) correctly emulates its
>>>>>>>> input that it must emulate the first seven instructions of P.
>>>>>>>>
>>>>>>>> Because the seventh instruction repeats this process we can know
>>>>>>>> with
>>>>>>>> complete certainty that the emulated P never reaches its final
>>>>>>>> “ret”
>>>>>>>> instruction, thus never halts.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Halting problem undecidability and infinitely nested simulation
>>>>>>>> (V5)
>>>>>>>>
>>>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Unfortunately your logic is such that the decision as to whether
>>>>>>> or not
>>>>>>> to enter the infinite loop is predicated on an infinite recursion
>>>>>>> (call
>>>>>>> H) that is not present in the Halting Problem proofs you are
>>>>>>> attempting
>>>>>>> to refute.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> It is when a simulating halt decider is assumed.
>>>>>
>>>>> But you can not assume that an actual simulating Halt Decider actually
>>>>> exists.
>>>> I proved that H(P,P)==0 is correct.
>>>>
>>> You've got nested simulations.
>>> If H detects them as infinitely nested, and aborts, they are no
>>> longer infinitely
>>> nested, so it gets the wrong answer (as happens here).
>>
>> I can't understand how you can be so wrong about this. It is like you
>> make sure to never read anything that I say before spouting off a
>> canned rebuttal.
>>
>> void Infinite_Loop()
>> {
>>    HERE: goto HERE;
>> }
>>
>> int main()
>> {
>>    Output("Input_Halts = ", H0(Infinite_Loop));
>> }
>>
>> _Infinite_Loop()
>> [00001342](01)  55              push ebp
>> [00001343](02)  8bec            mov ebp,esp
>> [00001345](02)  ebfe            jmp 00001345
>> [00001347](01)  5d              pop ebp
>> [00001348](01)  c3              ret
>> Size in bytes:(0007) [00001348]
>>
>> In the same way that H0 detects that the complete x86 emulation of
>> _Infinite_Loop() would never reach its final "ret" instruction H(P,P)
>> on the basis of a partial simulation H(P,P) detects that the complete
>> x86 emulation of its input would never reach its final "ret" instruction.
>>
>> Did you notice that I said this 500 times already?
>> Did you notice that I said this 500 times already?
>> Did you notice that I said this 500 times already?
>>
>> HALTING DOES NOT MEAN STOPS RUNNING
>> HALTING DOES NOT MEAN STOPS RUNNING
>> HALTING DOES NOT MEAN STOPS RUNNING
>
> Right, and for the simulation of H(P,P), that is all that happen
>
>
>>
>> HALTING MEANS TERMINATED NORMALLY
>> HALTING MEANS TERMINATED NORMALLY
>> HALTING MEANS TERMINATED NORMALLY
>
>
> And the input to H(P,P) does TERMINATE NORMALLY when correct simulated.
>
THIS IS WHERE YOU ARE A BRAIN DEAD MORON:

_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]

On 6/4/22 11:51 AM, olcott wrote:
> On 6/4/2022 10:38 AM, Richard Damon wrote:
>> On 6/4/22 11:11 AM, olcott wrote:
>>> On 6/4/2022 5:01 AM, Malcolm McLean wrote:
>>>> On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:
>>>>> On 6/3/2022 7:20 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 6/3/22 7:56 PM, olcott wrote:
>>>>>>> On 6/3/2022 6:35 PM, Mr Flibble wrote:
>>>>>>>> On Fri, 3 Jun 2022 17:17:12 -0500
>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>
>>>>>>>>> This post assumes that you already know my work, otherwise please
>>>>>>>>> read the linked paper provided below. This work is based on the
>>>>>>>>> x86utm operating system that was created so that every detail
>>>>>>>>> of the
>>>>>>>>> halting problem could be directly examined in C/x86.
>>>>>>>>>
>>>>>>>>> void Infinite_Loop()
>>>>>>>>> {
>>>>>>>>>      HERE: goto HERE;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> int main()
>>>>>>>>> {
>>>>>>>>>      Output("Input_Halts = ", H0(Infinite_Loop));
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> _Infinite_Loop()
>>>>>>>>> [00001342](01)  55              push ebp
>>>>>>>>> [00001343](02)  8bec            mov ebp,esp
>>>>>>>>> [00001345](02)  ebfe            jmp 00001345
>>>>>>>>> [00001347](01)  5d              pop ebp
>>>>>>>>> [00001348](01)  c3              ret
>>>>>>>>> Size in bytes:(0007) [00001348]
>>>>>>>>>
>>>>>>>>> It is totally obvious that the _Infinite_Loop() would never halt
>>>>>>>>> (meaning that it terminates normally by reaching its "ret"
>>>>>>>>> instruction).
>>>>>>>>>
>>>>>>>>> Equally obvious is the fact that a partial x86 emulation of this
>>>>>>>>> input conclusively proves that its complete x86 emulation would
>>>>>>>>> never
>>>>>>>>> halt.
>>>>>>>>>
>>>>>>>>> Begin Local Halt Decider Simulation   Execution Trace Stored
>>>>>>>>> at:212343
>>>>>>>>> [00001342][00212333][00212337] 55         push ebp
>>>>>>>>> [00001343][00212333][00212337] 8bec       mov ebp,esp
>>>>>>>>> [00001345][00212333][00212337] ebfe       jmp 00001345
>>>>>>>>> [00001345][00212333][00212337] ebfe       jmp 00001345
>>>>>>>>> Local Halt Decider: Infinite Loop Detected Simulation Stopped
>>>>>>>>>
>>>>>>>>> The exact same reasoning applies to the correctly emulated
>>>>>>>>> input to
>>>>>>>>> H(P,P):
>>>>>>>>>
>>>>>>>>> _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]
>>>>>>>>>
>>>>>>>>> It is completely obvious that when H(P,P) correctly emulates its
>>>>>>>>> input that it must emulate the first seven instructions of P.
>>>>>>>>>
>>>>>>>>> Because the seventh instruction repeats this process we can
>>>>>>>>> know with
>>>>>>>>> complete certainty that the emulated P never reaches its final
>>>>>>>>> “ret”
>>>>>>>>> instruction, thus never halts.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Halting problem undecidability and infinitely nested simulation
>>>>>>>>> (V5)
>>>>>>>>>
>>>>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Unfortunately your logic is such that the decision as to whether
>>>>>>>> or not
>>>>>>>> to enter the infinite loop is predicated on an infinite
>>>>>>>> recursion (call
>>>>>>>> H) that is not present in the Halting Problem proofs you are
>>>>>>>> attempting
>>>>>>>> to refute.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>>
>>>>>>>
>>>>>>> It is when a simulating halt decider is assumed.
>>>>>>
>>>>>> But you can not assume that an actual simulating Halt Decider
>>>>>> actually
>>>>>> exists.
>>>>> I proved that H(P,P)==0 is correct.
>>>>>
>>>> You've got nested simulations.
>>>> If H detects them as infinitely nested, and aborts, they are no
>>>> longer infinitely
>>>> nested, so it gets the wrong answer (as happens here).
>>>
>>> I can't understand how you can be so wrong about this. It is like you
>>> make sure to never read anything that I say before spouting off a
>>> canned rebuttal.
>>>
>>> void Infinite_Loop()
>>> {
>>>    HERE: goto HERE;
>>> }
>>>
>>> int main()
>>> {
>>>    Output("Input_Halts = ", H0(Infinite_Loop));
>>> }
>>>
>>> _Infinite_Loop()
>>> [00001342](01)  55              push ebp
>>> [00001343](02)  8bec            mov ebp,esp
>>> [00001345](02)  ebfe            jmp 00001345
>>> [00001347](01)  5d              pop ebp
>>> [00001348](01)  c3              ret
>>> Size in bytes:(0007) [00001348]
>>>
>>> In the same way that H0 detects that the complete x86 emulation of
>>> _Infinite_Loop() would never reach its final "ret" instruction H(P,P)
>>> on the basis of a partial simulation H(P,P) detects that the complete
>>> x86 emulation of its input would never reach its final "ret"
>>> instruction.
>>>
>>> Did you notice that I said this 500 times already?
>>> Did you notice that I said this 500 times already?
>>> Did you notice that I said this 500 times already?
>>>
>>> HALTING DOES NOT MEAN STOPS RUNNING
>>> HALTING DOES NOT MEAN STOPS RUNNING
>>> HALTING DOES NOT MEAN STOPS RUNNING
>>
>> Right, and for the simulation of H(P,P), that is all that happen
>>
>>
>>>
>>> HALTING MEANS TERMINATED NORMALLY
>>> HALTING MEANS TERMINATED NORMALLY
>>> HALTING MEANS TERMINATED NORMALLY
>>
>>
>> And the input to H(P,P) does TERMINATE NORMALLY when correct simulated.
>>
> THIS IS WHERE YOU ARE A BRAIN DEAD MORON:
>
> _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]
>
> It is completely obvious that when H(P,P) correctly emulates its input
> that it must emulate the first seven instructions of P. Because the
> seventh instruction repeats this process we can know with complete
> certainty that the emulated P never reaches its final “ret” instruction,
> thus never halts.
>
>

On 6/4/2022 3:12 AM, Muttley@dastardlyhq.com wrote:
> On Fri, 3 Jun 2022 17:17:12 -0500
> olcott <NoOne@NoWhere.com> wrote:
>> This post assumes that you already know my work, otherwise please read
>> the linked paper provided below. This work is based on the x86utm
>
> Thanks, but I need to go watch some paint dry. Maybe next time.
>
>

Until the notion of truth itself is formalized research in artificial
intelligence is hobbled.

A correct refutation of the halting problem proofs also refutes the
Tarski undefinability theorem by proxy, thus enabling the notion of
truth to be formalized.

This anchors the basis of Davidson's truth conditional semantics. This
creates the roadmap for artificial intelligence with unlimited potential.

Halting problem undecidability and infinitely nested simulation (V5)

https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5

--
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 6/4/2022 11:11 AM, Richard Damon wrote:
>
> On 6/4/22 11:51 AM, olcott wrote:
>> On 6/4/2022 10:38 AM, Richard Damon wrote:
>>> On 6/4/22 11:11 AM, olcott wrote:
>>>> On 6/4/2022 5:01 AM, Malcolm McLean wrote:
>>>>> On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:
>>>>>> On 6/3/2022 7:20 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 6/3/22 7:56 PM, olcott wrote:
>>>>>>>> On 6/3/2022 6:35 PM, Mr Flibble wrote:
>>>>>>>>> On Fri, 3 Jun 2022 17:17:12 -0500
>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>
>>>>>>>>>> This post assumes that you already know my work, otherwise please
>>>>>>>>>> read the linked paper provided below. This work is based on the
>>>>>>>>>> x86utm operating system that was created so that every detail
>>>>>>>>>> of the
>>>>>>>>>> halting problem could be directly examined in C/x86.
>>>>>>>>>>
>>>>>>>>>> void Infinite_Loop()
>>>>>>>>>> {
>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> int main()
>>>>>>>>>> {
>>>>>>>>>>      Output("Input_Halts = ", H0(Infinite_Loop));
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>> [00001342](01)  55              push ebp
>>>>>>>>>> [00001343](02)  8bec            mov ebp,esp
>>>>>>>>>> [00001345](02)  ebfe            jmp 00001345
>>>>>>>>>> [00001347](01)  5d              pop ebp
>>>>>>>>>> [00001348](01)  c3              ret
>>>>>>>>>> Size in bytes:(0007) [00001348]
>>>>>>>>>>
>>>>>>>>>> It is totally obvious that the _Infinite_Loop() would never halt
>>>>>>>>>> (meaning that it terminates normally by reaching its "ret"
>>>>>>>>>> instruction).
>>>>>>>>>>
>>>>>>>>>> Equally obvious is the fact that a partial x86 emulation of this
>>>>>>>>>> input conclusively proves that its complete x86 emulation
>>>>>>>>>> would never
>>>>>>>>>> halt.
>>>>>>>>>>
>>>>>>>>>> Begin Local Halt Decider Simulation   Execution Trace Stored
>>>>>>>>>> at:212343
>>>>>>>>>> [00001342][00212333][00212337] 55         push ebp
>>>>>>>>>> [00001343][00212333][00212337] 8bec       mov ebp,esp
>>>>>>>>>> [00001345][00212333][00212337] ebfe       jmp 00001345
>>>>>>>>>> [00001345][00212333][00212337] ebfe       jmp 00001345
>>>>>>>>>> Local Halt Decider: Infinite Loop Detected Simulation Stopped
>>>>>>>>>>
>>>>>>>>>> The exact same reasoning applies to the correctly emulated
>>>>>>>>>> input to
>>>>>>>>>> H(P,P):
>>>>>>>>>>
>>>>>>>>>> _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]
>>>>>>>>>>
>>>>>>>>>> It is completely obvious that when H(P,P) correctly emulates its
>>>>>>>>>> input that it must emulate the first seven instructions of P.
>>>>>>>>>>
>>>>>>>>>> Because the seventh instruction repeats this process we can
>>>>>>>>>> know with
>>>>>>>>>> complete certainty that the emulated P never reaches its final
>>>>>>>>>> “ret”
>>>>>>>>>> instruction, thus never halts.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Halting problem undecidability and infinitely nested
>>>>>>>>>> simulation (V5)
>>>>>>>>>>
>>>>>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Unfortunately your logic is such that the decision as to
>>>>>>>>> whether or not
>>>>>>>>> to enter the infinite loop is predicated on an infinite
>>>>>>>>> recursion (call
>>>>>>>>> H) that is not present in the Halting Problem proofs you are
>>>>>>>>> attempting
>>>>>>>>> to refute.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>
>>>>>>>> It is when a simulating halt decider is assumed.
>>>>>>>
>>>>>>> But you can not assume that an actual simulating Halt Decider
>>>>>>> actually
>>>>>>> exists.
>>>>>> I proved that H(P,P)==0 is correct.
>>>>>>
>>>>> You've got nested simulations.
>>>>> If H detects them as infinitely nested, and aborts, they are no
>>>>> longer infinitely
>>>>> nested, so it gets the wrong answer (as happens here).
>>>>
>>>> I can't understand how you can be so wrong about this. It is like
>>>> you make sure to never read anything that I say before spouting off
>>>> a canned rebuttal.
>>>>
>>>> void Infinite_Loop()
>>>> {
>>>>    HERE: goto HERE;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>    Output("Input_Halts = ", H0(Infinite_Loop));
>>>> }
>>>>
>>>> _Infinite_Loop()
>>>> [00001342](01)  55              push ebp
>>>> [00001343](02)  8bec            mov ebp,esp
>>>> [00001345](02)  ebfe            jmp 00001345
>>>> [00001347](01)  5d              pop ebp
>>>> [00001348](01)  c3              ret
>>>> Size in bytes:(0007) [00001348]
>>>>
>>>> In the same way that H0 detects that the complete x86 emulation of
>>>> _Infinite_Loop() would never reach its final "ret" instruction
>>>> H(P,P) on the basis of a partial simulation H(P,P) detects that the
>>>> complete x86 emulation of its input would never reach its final
>>>> "ret" instruction.
>>>>
>>>> Did you notice that I said this 500 times already?
>>>> Did you notice that I said this 500 times already?
>>>> Did you notice that I said this 500 times already?
>>>>
>>>> HALTING DOES NOT MEAN STOPS RUNNING
>>>> HALTING DOES NOT MEAN STOPS RUNNING
>>>> HALTING DOES NOT MEAN STOPS RUNNING
>>>
>>> Right, and for the simulation of H(P,P), that is all that happen
>>>
>>>
>>>>
>>>> HALTING MEANS TERMINATED NORMALLY
>>>> HALTING MEANS TERMINATED NORMALLY
>>>> HALTING MEANS TERMINATED NORMALLY
>>>
>>>
>>> And the input to H(P,P) does TERMINATE NORMALLY when correct simulated.
>>>
>> THIS IS WHERE YOU ARE A BRAIN DEAD MORON:
>>
>> _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]
>>
>> It is completely obvious that when H(P,P) correctly emulates its input
>> that it must emulate the first seven instructions of P. Because the
>> seventh instruction repeats this process we can know with complete
>> certainty that the emulated P never reaches its final “ret”
>> instruction, thus never halts.
>>
>>
>
> Right, it emulates the first seven instructions,

On 6/4/22 12:25 PM, olcott wrote:
> On 6/4/2022 11:11 AM, Richard Damon wrote:
>>
>> On 6/4/22 11:51 AM, olcott wrote:
>>> On 6/4/2022 10:38 AM, Richard Damon wrote:
>>>> On 6/4/22 11:11 AM, olcott wrote:
>>>>> On 6/4/2022 5:01 AM, Malcolm McLean wrote:
>>>>>> On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:
>>>>>>> On 6/3/2022 7:20 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> On 6/3/22 7:56 PM, olcott wrote:
>>>>>>>>> On 6/3/2022 6:35 PM, Mr Flibble wrote:
>>>>>>>>>> On Fri, 3 Jun 2022 17:17:12 -0500
>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> This post assumes that you already know my work, otherwise
>>>>>>>>>>> please
>>>>>>>>>>> read the linked paper provided below. This work is based on the
>>>>>>>>>>> x86utm operating system that was created so that every detail
>>>>>>>>>>> of the
>>>>>>>>>>> halting problem could be directly examined in C/x86.
>>>>>>>>>>>
>>>>>>>>>>> void Infinite_Loop()
>>>>>>>>>>> {
>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> int main()
>>>>>>>>>>> {
>>>>>>>>>>>      Output("Input_Halts = ", H0(Infinite_Loop));
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>> [00001342](01)  55              push ebp
>>>>>>>>>>> [00001343](02)  8bec            mov ebp,esp
>>>>>>>>>>> [00001345](02)  ebfe            jmp 00001345
>>>>>>>>>>> [00001347](01)  5d              pop ebp
>>>>>>>>>>> [00001348](01)  c3              ret
>>>>>>>>>>> Size in bytes:(0007) [00001348]
>>>>>>>>>>>
>>>>>>>>>>> It is totally obvious that the _Infinite_Loop() would never halt
>>>>>>>>>>> (meaning that it terminates normally by reaching its "ret"
>>>>>>>>>>> instruction).
>>>>>>>>>>>
>>>>>>>>>>> Equally obvious is the fact that a partial x86 emulation of this
>>>>>>>>>>> input conclusively proves that its complete x86 emulation
>>>>>>>>>>> would never
>>>>>>>>>>> halt.
>>>>>>>>>>>
>>>>>>>>>>> Begin Local Halt Decider Simulation   Execution Trace Stored
>>>>>>>>>>> at:212343
>>>>>>>>>>> [00001342][00212333][00212337] 55         push ebp
>>>>>>>>>>> [00001343][00212333][00212337] 8bec       mov ebp,esp
>>>>>>>>>>> [00001345][00212333][00212337] ebfe       jmp 00001345
>>>>>>>>>>> [00001345][00212333][00212337] ebfe       jmp 00001345
>>>>>>>>>>> Local Halt Decider: Infinite Loop Detected Simulation Stopped
>>>>>>>>>>>
>>>>>>>>>>> The exact same reasoning applies to the correctly emulated
>>>>>>>>>>> input to
>>>>>>>>>>> H(P,P):
>>>>>>>>>>>
>>>>>>>>>>> _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]
>>>>>>>>>>>
>>>>>>>>>>> It is completely obvious that when H(P,P) correctly emulates its
>>>>>>>>>>> input that it must emulate the first seven instructions of P.
>>>>>>>>>>>
>>>>>>>>>>> Because the seventh instruction repeats this process we can
>>>>>>>>>>> know with
>>>>>>>>>>> complete certainty that the emulated P never reaches its
>>>>>>>>>>> final “ret”
>>>>>>>>>>> instruction, thus never halts.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Halting problem undecidability and infinitely nested
>>>>>>>>>>> simulation (V5)
>>>>>>>>>>>
>>>>>>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Unfortunately your logic is such that the decision as to
>>>>>>>>>> whether or not
>>>>>>>>>> to enter the infinite loop is predicated on an infinite
>>>>>>>>>> recursion (call
>>>>>>>>>> H) that is not present in the Halting Problem proofs you are
>>>>>>>>>> attempting
>>>>>>>>>> to refute.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It is when a simulating halt decider is assumed.
>>>>>>>>
>>>>>>>> But you can not assume that an actual simulating Halt Decider
>>>>>>>> actually
>>>>>>>> exists.
>>>>>>> I proved that H(P,P)==0 is correct.
>>>>>>>
>>>>>> You've got nested simulations.
>>>>>> If H detects them as infinitely nested, and aborts, they are no
>>>>>> longer infinitely
>>>>>> nested, so it gets the wrong answer (as happens here).
>>>>>
>>>>> I can't understand how you can be so wrong about this. It is like
>>>>> you make sure to never read anything that I say before spouting off
>>>>> a canned rebuttal.
>>>>>
>>>>> void Infinite_Loop()
>>>>> {
>>>>>    HERE: goto HERE;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>    Output("Input_Halts = ", H0(Infinite_Loop));
>>>>> }
>>>>>
>>>>> _Infinite_Loop()
>>>>> [00001342](01)  55              push ebp
>>>>> [00001343](02)  8bec            mov ebp,esp
>>>>> [00001345](02)  ebfe            jmp 00001345
>>>>> [00001347](01)  5d              pop ebp
>>>>> [00001348](01)  c3              ret
>>>>> Size in bytes:(0007) [00001348]
>>>>>
>>>>> In the same way that H0 detects that the complete x86 emulation of
>>>>> _Infinite_Loop() would never reach its final "ret" instruction
>>>>> H(P,P) on the basis of a partial simulation H(P,P) detects that the
>>>>> complete x86 emulation of its input would never reach its final
>>>>> "ret" instruction.
>>>>>
>>>>> Did you notice that I said this 500 times already?
>>>>> Did you notice that I said this 500 times already?
>>>>> Did you notice that I said this 500 times already?
>>>>>
>>>>> HALTING DOES NOT MEAN STOPS RUNNING
>>>>> HALTING DOES NOT MEAN STOPS RUNNING
>>>>> HALTING DOES NOT MEAN STOPS RUNNING
>>>>
>>>> Right, and for the simulation of H(P,P), that is all that happen
>>>>
>>>>
>>>>>
>>>>> HALTING MEANS TERMINATED NORMALLY
>>>>> HALTING MEANS TERMINATED NORMALLY
>>>>> HALTING MEANS TERMINATED NORMALLY
>>>>
>>>>
>>>> And the input to H(P,P) does TERMINATE NORMALLY when correct simulated.
>>>>
>>> THIS IS WHERE YOU ARE A BRAIN DEAD MORON:
>>>
>>> _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]
>>>
>>> It is completely obvious that when H(P,P) correctly emulates its
>>> input that it must emulate the first seven instructions of P. Because
>>> the seventh instruction repeats this process we can know with
>>> complete certainty that the emulated P never reaches its final “ret”
>>> instruction, thus never halts.
>>>
>>>
>>
>> Right, it emulates the first seven instructions,
>
> BRAIN DEAD MORONS DON'T GET THIS:
> Because we verified that H(P,P) emulates the first seven instructions of
> P we know that it will keep doing this every time that H(P,P) is invoked
> as long as the simulation continues.

On 6/4/2022 12:15 PM, Richard Damon wrote:
> On 6/4/22 12:25 PM, olcott wrote:
>> On 6/4/2022 11:11 AM, Richard Damon wrote:
>>>
>>> On 6/4/22 11:51 AM, olcott wrote:
>>>> On 6/4/2022 10:38 AM, Richard Damon wrote:
>>>>> On 6/4/22 11:11 AM, olcott wrote:
>>>>>> On 6/4/2022 5:01 AM, Malcolm McLean wrote:
>>>>>>> On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:
>>>>>>>> On 6/3/2022 7:20 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 6/3/22 7:56 PM, olcott wrote:
>>>>>>>>>> On 6/3/2022 6:35 PM, Mr Flibble wrote:
>>>>>>>>>>> On Fri, 3 Jun 2022 17:17:12 -0500
>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> This post assumes that you already know my work, otherwise
>>>>>>>>>>>> please
>>>>>>>>>>>> read the linked paper provided below. This work is based on the
>>>>>>>>>>>> x86utm operating system that was created so that every
>>>>>>>>>>>> detail of the
>>>>>>>>>>>> halting problem could be directly examined in C/x86.
>>>>>>>>>>>>
>>>>>>>>>>>> void Infinite_Loop()
>>>>>>>>>>>> {
>>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> int main()
>>>>>>>>>>>> {
>>>>>>>>>>>>      Output("Input_Halts = ", H0(Infinite_Loop));
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>> [00001342](01)  55              push ebp
>>>>>>>>>>>> [00001343](02)  8bec            mov ebp,esp
>>>>>>>>>>>> [00001345](02)  ebfe            jmp 00001345
>>>>>>>>>>>> [00001347](01)  5d              pop ebp
>>>>>>>>>>>> [00001348](01)  c3              ret
>>>>>>>>>>>> Size in bytes:(0007) [00001348]
>>>>>>>>>>>>
>>>>>>>>>>>> It is totally obvious that the _Infinite_Loop() would never
>>>>>>>>>>>> halt
>>>>>>>>>>>> (meaning that it terminates normally by reaching its "ret"
>>>>>>>>>>>> instruction).
>>>>>>>>>>>>
>>>>>>>>>>>> Equally obvious is the fact that a partial x86 emulation of
>>>>>>>>>>>> this
>>>>>>>>>>>> input conclusively proves that its complete x86 emulation
>>>>>>>>>>>> would never
>>>>>>>>>>>> halt.
>>>>>>>>>>>>
>>>>>>>>>>>> Begin Local Halt Decider Simulation   Execution Trace Stored
>>>>>>>>>>>> at:212343
>>>>>>>>>>>> [00001342][00212333][00212337] 55         push ebp
>>>>>>>>>>>> [00001343][00212333][00212337] 8bec       mov ebp,esp
>>>>>>>>>>>> [00001345][00212333][00212337] ebfe       jmp 00001345
>>>>>>>>>>>> [00001345][00212333][00212337] ebfe       jmp 00001345
>>>>>>>>>>>> Local Halt Decider: Infinite Loop Detected Simulation Stopped
>>>>>>>>>>>>
>>>>>>>>>>>> The exact same reasoning applies to the correctly emulated
>>>>>>>>>>>> input to
>>>>>>>>>>>> H(P,P):
>>>>>>>>>>>>
>>>>>>>>>>>> _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]
>>>>>>>>>>>>
>>>>>>>>>>>> It is completely obvious that when H(P,P) correctly emulates
>>>>>>>>>>>> its
>>>>>>>>>>>> input that it must emulate the first seven instructions of P.
>>>>>>>>>>>>
>>>>>>>>>>>> Because the seventh instruction repeats this process we can
>>>>>>>>>>>> know with
>>>>>>>>>>>> complete certainty that the emulated P never reaches its
>>>>>>>>>>>> final “ret”
>>>>>>>>>>>> instruction, thus never halts.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Halting problem undecidability and infinitely nested
>>>>>>>>>>>> simulation (V5)
>>>>>>>>>>>>
>>>>>>>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Unfortunately your logic is such that the decision as to
>>>>>>>>>>> whether or not
>>>>>>>>>>> to enter the infinite loop is predicated on an infinite
>>>>>>>>>>> recursion (call
>>>>>>>>>>> H) that is not present in the Halting Problem proofs you are
>>>>>>>>>>> attempting
>>>>>>>>>>> to refute.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> It is when a simulating halt decider is assumed.
>>>>>>>>>
>>>>>>>>> But you can not assume that an actual simulating Halt Decider
>>>>>>>>> actually
>>>>>>>>> exists.
>>>>>>>> I proved that H(P,P)==0 is correct.
>>>>>>>>
>>>>>>> You've got nested simulations.
>>>>>>> If H detects them as infinitely nested, and aborts, they are no
>>>>>>> longer infinitely
>>>>>>> nested, so it gets the wrong answer (as happens here).
>>>>>>
>>>>>> I can't understand how you can be so wrong about this. It is like
>>>>>> you make sure to never read anything that I say before spouting
>>>>>> off a canned rebuttal.
>>>>>>
>>>>>> void Infinite_Loop()
>>>>>> {
>>>>>>    HERE: goto HERE;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>>    Output("Input_Halts = ", H0(Infinite_Loop));
>>>>>> }
>>>>>>
>>>>>> _Infinite_Loop()
>>>>>> [00001342](01)  55              push ebp
>>>>>> [00001343](02)  8bec            mov ebp,esp
>>>>>> [00001345](02)  ebfe            jmp 00001345
>>>>>> [00001347](01)  5d              pop ebp
>>>>>> [00001348](01)  c3              ret
>>>>>> Size in bytes:(0007) [00001348]
>>>>>>
>>>>>> In the same way that H0 detects that the complete x86 emulation of
>>>>>> _Infinite_Loop() would never reach its final "ret" instruction
>>>>>> H(P,P) on the basis of a partial simulation H(P,P) detects that
>>>>>> the complete x86 emulation of its input would never reach its
>>>>>> final "ret" instruction.
>>>>>>
>>>>>> Did you notice that I said this 500 times already?
>>>>>> Did you notice that I said this 500 times already?
>>>>>> Did you notice that I said this 500 times already?
>>>>>>
>>>>>> HALTING DOES NOT MEAN STOPS RUNNING
>>>>>> HALTING DOES NOT MEAN STOPS RUNNING
>>>>>> HALTING DOES NOT MEAN STOPS RUNNING
>>>>>
>>>>> Right, and for the simulation of H(P,P), that is all that happen
>>>>>
>>>>>
>>>>>>
>>>>>> HALTING MEANS TERMINATED NORMALLY
>>>>>> HALTING MEANS TERMINATED NORMALLY
>>>>>> HALTING MEANS TERMINATED NORMALLY
>>>>>
>>>>>
>>>>> And the input to H(P,P) does TERMINATE NORMALLY when correct
>>>>> simulated.
>>>>>
>>>> THIS IS WHERE YOU ARE A BRAIN DEAD MORON:
>>>>
>>>> _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]
>>>>
>>>> It is completely obvious that when H(P,P) correctly emulates its
>>>> input that it must emulate the first seven instructions of P.
>>>> Because the seventh instruction repeats this process we can know
>>>> with complete certainty that the emulated P never reaches its final
>>>> “ret” instruction, thus never halts.
>>>>
>>>>
>>>
>>> Right, it emulates the first seven instructions,
>>
>> BRAIN DEAD MORONS DON'T GET THIS:
>> Because we verified that H(P,P) emulates the first seven instructions
>> of P we know that it will keep doing this every time that H(P,P) is
>> invoked as long as the simulation continues.
>
> Nope, different invocations of H's so not part of the same trace.
That is what a brain dead moron (or a despicable liar) would say.

On 6/4/22 1:23 PM, olcott wrote:
> On 6/4/2022 12:15 PM, Richard Damon wrote:
>> On 6/4/22 12:25 PM, olcott wrote:
>>> On 6/4/2022 11:11 AM, Richard Damon wrote:
>>>>
>>>> On 6/4/22 11:51 AM, olcott wrote:
>>>>> On 6/4/2022 10:38 AM, Richard Damon wrote:
>>>>>> On 6/4/22 11:11 AM, olcott wrote:
>>>>>>> On 6/4/2022 5:01 AM, Malcolm McLean wrote:
>>>>>>>> On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:
>>>>>>>>> On 6/3/2022 7:20 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 6/3/22 7:56 PM, olcott wrote:
>>>>>>>>>>> On 6/3/2022 6:35 PM, Mr Flibble wrote:
>>>>>>>>>>>> On Fri, 3 Jun 2022 17:17:12 -0500
>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> This post assumes that you already know my work, otherwise
>>>>>>>>>>>>> please
>>>>>>>>>>>>> read the linked paper provided below. This work is based on
>>>>>>>>>>>>> the
>>>>>>>>>>>>> x86utm operating system that was created so that every
>>>>>>>>>>>>> detail of the
>>>>>>>>>>>>> halting problem could be directly examined in C/x86.
>>>>>>>>>>>>>
>>>>>>>>>>>>> void Infinite_Loop()
>>>>>>>>>>>>> {
>>>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> int main()
>>>>>>>>>>>>> {
>>>>>>>>>>>>>      Output("Input_Halts = ", H0(Infinite_Loop));
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>> [00001342](01)  55              push ebp
>>>>>>>>>>>>> [00001343](02)  8bec            mov ebp,esp
>>>>>>>>>>>>> [00001345](02)  ebfe            jmp 00001345
>>>>>>>>>>>>> [00001347](01)  5d              pop ebp
>>>>>>>>>>>>> [00001348](01)  c3              ret
>>>>>>>>>>>>> Size in bytes:(0007) [00001348]
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is totally obvious that the _Infinite_Loop() would never
>>>>>>>>>>>>> halt
>>>>>>>>>>>>> (meaning that it terminates normally by reaching its "ret"
>>>>>>>>>>>>> instruction).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Equally obvious is the fact that a partial x86 emulation of
>>>>>>>>>>>>> this
>>>>>>>>>>>>> input conclusively proves that its complete x86 emulation
>>>>>>>>>>>>> would never
>>>>>>>>>>>>> halt.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Begin Local Halt Decider Simulation   Execution Trace
>>>>>>>>>>>>> Stored at:212343
>>>>>>>>>>>>> [00001342][00212333][00212337] 55         push ebp
>>>>>>>>>>>>> [00001343][00212333][00212337] 8bec       mov ebp,esp
>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe       jmp 00001345
>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe       jmp 00001345
>>>>>>>>>>>>> Local Halt Decider: Infinite Loop Detected Simulation Stopped
>>>>>>>>>>>>>
>>>>>>>>>>>>> The exact same reasoning applies to the correctly emulated
>>>>>>>>>>>>> input to
>>>>>>>>>>>>> H(P,P):
>>>>>>>>>>>>>
>>>>>>>>>>>>> _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]
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is completely obvious that when H(P,P) correctly
>>>>>>>>>>>>> emulates its
>>>>>>>>>>>>> input that it must emulate the first seven instructions of P.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Because the seventh instruction repeats this process we can
>>>>>>>>>>>>> know with
>>>>>>>>>>>>> complete certainty that the emulated P never reaches its
>>>>>>>>>>>>> final “ret”
>>>>>>>>>>>>> instruction, thus never halts.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Halting problem undecidability and infinitely nested
>>>>>>>>>>>>> simulation (V5)
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Unfortunately your logic is such that the decision as to
>>>>>>>>>>>> whether or not
>>>>>>>>>>>> to enter the infinite loop is predicated on an infinite
>>>>>>>>>>>> recursion (call
>>>>>>>>>>>> H) that is not present in the Halting Problem proofs you are
>>>>>>>>>>>> attempting
>>>>>>>>>>>> to refute.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> It is when a simulating halt decider is assumed.
>>>>>>>>>>
>>>>>>>>>> But you can not assume that an actual simulating Halt Decider
>>>>>>>>>> actually
>>>>>>>>>> exists.
>>>>>>>>> I proved that H(P,P)==0 is correct.
>>>>>>>>>
>>>>>>>> You've got nested simulations.
>>>>>>>> If H detects them as infinitely nested, and aborts, they are no
>>>>>>>> longer infinitely
>>>>>>>> nested, so it gets the wrong answer (as happens here).
>>>>>>>
>>>>>>> I can't understand how you can be so wrong about this. It is like
>>>>>>> you make sure to never read anything that I say before spouting
>>>>>>> off a canned rebuttal.
>>>>>>>
>>>>>>> void Infinite_Loop()
>>>>>>> {
>>>>>>>    HERE: goto HERE;
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>>    Output("Input_Halts = ", H0(Infinite_Loop));
>>>>>>> }
>>>>>>>
>>>>>>> _Infinite_Loop()
>>>>>>> [00001342](01)  55              push ebp
>>>>>>> [00001343](02)  8bec            mov ebp,esp
>>>>>>> [00001345](02)  ebfe            jmp 00001345
>>>>>>> [00001347](01)  5d              pop ebp
>>>>>>> [00001348](01)  c3              ret
>>>>>>> Size in bytes:(0007) [00001348]
>>>>>>>
>>>>>>> In the same way that H0 detects that the complete x86 emulation
>>>>>>> of _Infinite_Loop() would never reach its final "ret" instruction
>>>>>>> H(P,P) on the basis of a partial simulation H(P,P) detects that
>>>>>>> the complete x86 emulation of its input would never reach its
>>>>>>> final "ret" instruction.
>>>>>>>
>>>>>>> Did you notice that I said this 500 times already?
>>>>>>> Did you notice that I said this 500 times already?
>>>>>>> Did you notice that I said this 500 times already?
>>>>>>>
>>>>>>> HALTING DOES NOT MEAN STOPS RUNNING
>>>>>>> HALTING DOES NOT MEAN STOPS RUNNING
>>>>>>> HALTING DOES NOT MEAN STOPS RUNNING
>>>>>>
>>>>>> Right, and for the simulation of H(P,P), that is all that happen
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> HALTING MEANS TERMINATED NORMALLY
>>>>>>> HALTING MEANS TERMINATED NORMALLY
>>>>>>> HALTING MEANS TERMINATED NORMALLY
>>>>>>
>>>>>>
>>>>>> And the input to H(P,P) does TERMINATE NORMALLY when correct
>>>>>> simulated.
>>>>>>
>>>>> THIS IS WHERE YOU ARE A BRAIN DEAD MORON:
>>>>>
>>>>> _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]
>>>>>
>>>>> It is completely obvious that when H(P,P) correctly emulates its
>>>>> input that it must emulate the first seven instructions of P.
>>>>> Because the seventh instruction repeats this process we can know
>>>>> with complete certainty that the emulated P never reaches its final
>>>>> “ret” instruction, thus never halts.
>>>>>
>>>>>
>>>>
>>>> Right, it emulates the first seven instructions,
>>>
>>> BRAIN DEAD MORONS DON'T GET THIS:
>>> Because we verified that H(P,P) emulates the first seven instructions
>>> of P we know that it will keep doing this every time that H(P,P) is
>>> invoked as long as the simulation continues.
>>
>> Nope, different invocations of H's so not part of the same trace.
> That is what a brain dead moron (or a despicable liar) would say.
>
> The whole point is whether or not the correct x86 emulation of the
> original input would ever reach its final "ret" instruction.
>

On 6/4/2022 1:09 PM, Richard Damon wrote:
> On 6/4/22 1:23 PM, olcott wrote:
>> On 6/4/2022 12:15 PM, Richard Damon wrote:
>>> On 6/4/22 12:25 PM, olcott wrote:
>>>> On 6/4/2022 11:11 AM, Richard Damon wrote:
>>>>>
>>>>> On 6/4/22 11:51 AM, olcott wrote:
>>>>>> On 6/4/2022 10:38 AM, Richard Damon wrote:
>>>>>>> On 6/4/22 11:11 AM, olcott wrote:
>>>>>>>> On 6/4/2022 5:01 AM, Malcolm McLean wrote:
>>>>>>>>> On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:
>>>>>>>>>> On 6/3/2022 7:20 PM, Richard Damon wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 6/3/22 7:56 PM, olcott wrote:
>>>>>>>>>>>> On 6/3/2022 6:35 PM, Mr Flibble wrote:
>>>>>>>>>>>>> On Fri, 3 Jun 2022 17:17:12 -0500
>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> This post assumes that you already know my work, otherwise
>>>>>>>>>>>>>> please
>>>>>>>>>>>>>> read the linked paper provided below. This work is based
>>>>>>>>>>>>>> on the
>>>>>>>>>>>>>> x86utm operating system that was created so that every
>>>>>>>>>>>>>> detail of the
>>>>>>>>>>>>>> halting problem could be directly examined in C/x86.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> void Infinite_Loop()
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>      Output("Input_Halts = ", H0(Infinite_Loop));
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>> [00001342](01)  55              push ebp
>>>>>>>>>>>>>> [00001343](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>> [00001345](02)  ebfe            jmp 00001345
>>>>>>>>>>>>>> [00001347](01)  5d              pop ebp
>>>>>>>>>>>>>> [00001348](01)  c3              ret
>>>>>>>>>>>>>> Size in bytes:(0007) [00001348]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is totally obvious that the _Infinite_Loop() would
>>>>>>>>>>>>>> never halt
>>>>>>>>>>>>>> (meaning that it terminates normally by reaching its "ret"
>>>>>>>>>>>>>> instruction).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Equally obvious is the fact that a partial x86 emulation
>>>>>>>>>>>>>> of this
>>>>>>>>>>>>>> input conclusively proves that its complete x86 emulation
>>>>>>>>>>>>>> would never
>>>>>>>>>>>>>> halt.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Begin Local Halt Decider Simulation   Execution Trace
>>>>>>>>>>>>>> Stored at:212343
>>>>>>>>>>>>>> [00001342][00212333][00212337] 55         push ebp
>>>>>>>>>>>>>> [00001343][00212333][00212337] 8bec       mov ebp,esp
>>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe       jmp 00001345
>>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe       jmp 00001345
>>>>>>>>>>>>>> Local Halt Decider: Infinite Loop Detected Simulation Stopped
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The exact same reasoning applies to the correctly emulated
>>>>>>>>>>>>>> input to
>>>>>>>>>>>>>> H(P,P):
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _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]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is completely obvious that when H(P,P) correctly
>>>>>>>>>>>>>> emulates its
>>>>>>>>>>>>>> input that it must emulate the first seven instructions of P.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Because the seventh instruction repeats this process we
>>>>>>>>>>>>>> can know with
>>>>>>>>>>>>>> complete certainty that the emulated P never reaches its
>>>>>>>>>>>>>> final “ret”
>>>>>>>>>>>>>> instruction, thus never halts.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Halting problem undecidability and infinitely nested
>>>>>>>>>>>>>> simulation (V5)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Unfortunately your logic is such that the decision as to
>>>>>>>>>>>>> whether or not
>>>>>>>>>>>>> to enter the infinite loop is predicated on an infinite
>>>>>>>>>>>>> recursion (call
>>>>>>>>>>>>> H) that is not present in the Halting Problem proofs you
>>>>>>>>>>>>> are attempting
>>>>>>>>>>>>> to refute.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> It is when a simulating halt decider is assumed.
>>>>>>>>>>>
>>>>>>>>>>> But you can not assume that an actual simulating Halt Decider
>>>>>>>>>>> actually
>>>>>>>>>>> exists.
>>>>>>>>>> I proved that H(P,P)==0 is correct.
>>>>>>>>>>
>>>>>>>>> You've got nested simulations.
>>>>>>>>> If H detects them as infinitely nested, and aborts, they are no
>>>>>>>>> longer infinitely
>>>>>>>>> nested, so it gets the wrong answer (as happens here).
>>>>>>>>
>>>>>>>> I can't understand how you can be so wrong about this. It is
>>>>>>>> like you make sure to never read anything that I say before
>>>>>>>> spouting off a canned rebuttal.
>>>>>>>>
>>>>>>>> void Infinite_Loop()
>>>>>>>> {
>>>>>>>>    HERE: goto HERE;
>>>>>>>> }
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>>    Output("Input_Halts = ", H0(Infinite_Loop));
>>>>>>>> }
>>>>>>>>
>>>>>>>> _Infinite_Loop()
>>>>>>>> [00001342](01)  55              push ebp
>>>>>>>> [00001343](02)  8bec            mov ebp,esp
>>>>>>>> [00001345](02)  ebfe            jmp 00001345
>>>>>>>> [00001347](01)  5d              pop ebp
>>>>>>>> [00001348](01)  c3              ret
>>>>>>>> Size in bytes:(0007) [00001348]
>>>>>>>>
>>>>>>>> In the same way that H0 detects that the complete x86 emulation
>>>>>>>> of _Infinite_Loop() would never reach its final "ret"
>>>>>>>> instruction H(P,P) on the basis of a partial simulation H(P,P)
>>>>>>>> detects that the complete x86 emulation of its input would never
>>>>>>>> reach its final "ret" instruction.
>>>>>>>>
>>>>>>>> Did you notice that I said this 500 times already?
>>>>>>>> Did you notice that I said this 500 times already?
>>>>>>>> Did you notice that I said this 500 times already?
>>>>>>>>
>>>>>>>> HALTING DOES NOT MEAN STOPS RUNNING
>>>>>>>> HALTING DOES NOT MEAN STOPS RUNNING
>>>>>>>> HALTING DOES NOT MEAN STOPS RUNNING
>>>>>>>
>>>>>>> Right, and for the simulation of H(P,P), that is all that happen
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> HALTING MEANS TERMINATED NORMALLY
>>>>>>>> HALTING MEANS TERMINATED NORMALLY
>>>>>>>> HALTING MEANS TERMINATED NORMALLY
>>>>>>>
>>>>>>>
>>>>>>> And the input to H(P,P) does TERMINATE NORMALLY when correct
>>>>>>> simulated.
>>>>>>>
>>>>>> THIS IS WHERE YOU ARE A BRAIN DEAD MORON:
>>>>>>
>>>>>> _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]
>>>>>>
>>>>>> It is completely obvious that when H(P,P) correctly emulates its
>>>>>> input that it must emulate the first seven instructions of P.
>>>>>> Because the seventh instruction repeats this process we can know
>>>>>> with complete certainty that the emulated P never reaches its
>>>>>> final “ret” instruction, thus never halts.
>>>>>>
>>>>>>
>>>>>
>>>>> Right, it emulates the first seven instructions,
>>>>
>>>> BRAIN DEAD MORONS DON'T GET THIS:
>>>> Because we verified that H(P,P) emulates the first seven
>>>> instructions of P we know that it will keep doing this every time
>>>> that H(P,P) is invoked as long as the simulation continues.
>>>
>>> Nope, different invocations of H's so not part of the same trace.
>> That is what a brain dead moron (or a despicable liar) would say.
>>
>> The whole point is whether or not the correct x86 emulation of the
>> original input would ever reach its final "ret" instruction.
>>
>
> Right, the correct x86 emulation of the ORIGINAL input. The second layer
> of simulation is

[ Followup-To: set ]

In comp.theory olcott <NoOne@nowhere.com> wrote:
> On 6/4/2022 5:01 AM, Malcolm McLean wrote:
>> On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:
>>> On 6/3/2022 7:20 PM, Richard Damon wrote:

>>>> On 6/3/22 7:56 PM, olcott wrote:
>>>>> On 6/3/2022 6:35 PM, Mr Flibble wrote:
>>>>>> On Fri, 3 Jun 2022 17:17:12 -0500
>>>>>> olcott <No...@NoWhere.com> wrote:

[ .... ]

>> You've got nested simulations.
>> If H detects them as infinitely nested, and aborts, they are no longer
>> infinitely nested, so it gets the wrong answer (as happens here).

> I can't understand how you can be so wrong about this. It is like you
> make sure to never read anything that I say before spouting off a canned
> rebuttal.

I frequently read what you say. It's dull and repetitive. And wrong.

> void Infinite_Loop()
> {
> HERE: goto HERE;
> }

> int main()
> {
> Output("Input_Halts = ", H0(Infinite_Loop));
> }

> _Infinite_Loop()
> [00001342](01) 55 push ebp
> [00001343](02) 8bec mov ebp,esp
> [00001345](02) ebfe jmp 00001345
> [00001347](01) 5d pop ebp
> [00001348](01) c3 ret
> Size in bytes:(0007) [00001348]

> In the same way that H0 detects .....

We don't know what H0 detects, since its code is secret, and probably
doesn't exist.

> .... that the complete x86 emulation of _Infinite_Loop() would never
> reach its final "ret" instruction H(P,P) on the basis of a partial
> simulation H(P,P) detects that the complete x86 emulation of its input
> would never reach its final "ret" instruction.

> Did you notice that I said this 500 times already?
> Did you notice that I said this 500 times already?
> Did you notice that I said this 500 times already?

Yes. It's dull and repetitive and wrong. If it were correct, you would
only need to say it once, and it would be accepted and acknowledged by
the experts in this group.

> HALTING DOES NOT MEAN STOPS RUNNING
> HALTING DOES NOT MEAN STOPS RUNNING
> HALTING DOES NOT MEAN STOPS RUNNING

In this context, it does.

> HALTING MEANS TERMINATED NORMALLY
> HALTING MEANS TERMINATED NORMALLY
> HALTING MEANS TERMINATED NORMALLY

A turing machine runs until it halts. Terminated "normally" has no
meaning. That is one reason you avoid turing machines. They make things
too clear and well defined, leaving you no room to argue stupidities like
"halting doesn't mean stops running".

>> If H doesn't detects them as infinitely nested, and never aborts, H
>> simulates forever, because they are infinitely nested.

>> Either way, H gets it wrong.

> So you are saying that it is impossible for H0 to correctly detect that
> _Infinite_Loop() would never reach its final "ret" instruction because
> as soon _Infinite_Loop() has had its simulation aborted it magically
> leaps to its "ret" instruction.

Wrong. That is not what he is saying. He is saying that H gets it
wrong, explaining why.

[ .... ]

> --
> Copyright 2022 Pete Olcott

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

--
Alan Mackenzie (Nuremberg, Germany).

On 6/4/22 2:14 PM, olcott wrote:
> On 6/4/2022 1:09 PM, Richard Damon wrote:
>> On 6/4/22 1:23 PM, olcott wrote:
>>> On 6/4/2022 12:15 PM, Richard Damon wrote:
>>>> On 6/4/22 12:25 PM, olcott wrote:
>>>>> On 6/4/2022 11:11 AM, Richard Damon wrote:
>>>>>>
>>>>>> On 6/4/22 11:51 AM, olcott wrote:
>>>>>>> On 6/4/2022 10:38 AM, Richard Damon wrote:
>>>>>>>> On 6/4/22 11:11 AM, olcott wrote:
>>>>>>>>> On 6/4/2022 5:01 AM, Malcolm McLean wrote:
>>>>>>>>>> On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:
>>>>>>>>>>> On 6/3/2022 7:20 PM, Richard Damon wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 6/3/22 7:56 PM, olcott wrote:
>>>>>>>>>>>>> On 6/3/2022 6:35 PM, Mr Flibble wrote:
>>>>>>>>>>>>>> On Fri, 3 Jun 2022 17:17:12 -0500
>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This post assumes that you already know my work,
>>>>>>>>>>>>>>> otherwise please
>>>>>>>>>>>>>>> read the linked paper provided below. This work is based
>>>>>>>>>>>>>>> on the
>>>>>>>>>>>>>>> x86utm operating system that was created so that every
>>>>>>>>>>>>>>> detail of the
>>>>>>>>>>>>>>> halting problem could be directly examined in C/x86.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> void Infinite_Loop()
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>      Output("Input_Halts = ", H0(Infinite_Loop));
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>> [00001342](01)  55              push ebp
>>>>>>>>>>>>>>> [00001343](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>> [00001345](02)  ebfe            jmp 00001345
>>>>>>>>>>>>>>> [00001347](01)  5d              pop ebp
>>>>>>>>>>>>>>> [00001348](01)  c3              ret
>>>>>>>>>>>>>>> Size in bytes:(0007) [00001348]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is totally obvious that the _Infinite_Loop() would
>>>>>>>>>>>>>>> never halt
>>>>>>>>>>>>>>> (meaning that it terminates normally by reaching its "ret"
>>>>>>>>>>>>>>> instruction).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Equally obvious is the fact that a partial x86 emulation
>>>>>>>>>>>>>>> of this
>>>>>>>>>>>>>>> input conclusively proves that its complete x86 emulation
>>>>>>>>>>>>>>> would never
>>>>>>>>>>>>>>> halt.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Begin Local Halt Decider Simulation   Execution Trace
>>>>>>>>>>>>>>> Stored at:212343
>>>>>>>>>>>>>>> [00001342][00212333][00212337] 55         push ebp
>>>>>>>>>>>>>>> [00001343][00212333][00212337] 8bec       mov ebp,esp
>>>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe       jmp 00001345
>>>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe       jmp 00001345
>>>>>>>>>>>>>>> Local Halt Decider: Infinite Loop Detected Simulation
>>>>>>>>>>>>>>> Stopped
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The exact same reasoning applies to the correctly
>>>>>>>>>>>>>>> emulated input to
>>>>>>>>>>>>>>> H(P,P):
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _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]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is completely obvious that when H(P,P) correctly
>>>>>>>>>>>>>>> emulates its
>>>>>>>>>>>>>>> input that it must emulate the first seven instructions
>>>>>>>>>>>>>>> of P.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Because the seventh instruction repeats this process we
>>>>>>>>>>>>>>> can know with
>>>>>>>>>>>>>>> complete certainty that the emulated P never reaches its
>>>>>>>>>>>>>>> final “ret”
>>>>>>>>>>>>>>> instruction, thus never halts.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Halting problem undecidability and infinitely nested
>>>>>>>>>>>>>>> simulation (V5)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Unfortunately your logic is such that the decision as to
>>>>>>>>>>>>>> whether or not
>>>>>>>>>>>>>> to enter the infinite loop is predicated on an infinite
>>>>>>>>>>>>>> recursion (call
>>>>>>>>>>>>>> H) that is not present in the Halting Problem proofs you
>>>>>>>>>>>>>> are attempting
>>>>>>>>>>>>>> to refute.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is when a simulating halt decider is assumed.
>>>>>>>>>>>>
>>>>>>>>>>>> But you can not assume that an actual simulating Halt
>>>>>>>>>>>> Decider actually
>>>>>>>>>>>> exists.
>>>>>>>>>>> I proved that H(P,P)==0 is correct.
>>>>>>>>>>>
>>>>>>>>>> You've got nested simulations.
>>>>>>>>>> If H detects them as infinitely nested, and aborts, they are
>>>>>>>>>> no longer infinitely
>>>>>>>>>> nested, so it gets the wrong answer (as happens here).
>>>>>>>>>
>>>>>>>>> I can't understand how you can be so wrong about this. It is
>>>>>>>>> like you make sure to never read anything that I say before
>>>>>>>>> spouting off a canned rebuttal.
>>>>>>>>>
>>>>>>>>> void Infinite_Loop()
>>>>>>>>> {
>>>>>>>>>    HERE: goto HERE;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> int main()
>>>>>>>>> {
>>>>>>>>>    Output("Input_Halts = ", H0(Infinite_Loop));
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> _Infinite_Loop()
>>>>>>>>> [00001342](01)  55              push ebp
>>>>>>>>> [00001343](02)  8bec            mov ebp,esp
>>>>>>>>> [00001345](02)  ebfe            jmp 00001345
>>>>>>>>> [00001347](01)  5d              pop ebp
>>>>>>>>> [00001348](01)  c3              ret
>>>>>>>>> Size in bytes:(0007) [00001348]
>>>>>>>>>
>>>>>>>>> In the same way that H0 detects that the complete x86 emulation
>>>>>>>>> of _Infinite_Loop() would never reach its final "ret"
>>>>>>>>> instruction H(P,P) on the basis of a partial simulation H(P,P)
>>>>>>>>> detects that the complete x86 emulation of its input would
>>>>>>>>> never reach its final "ret" instruction.
>>>>>>>>>
>>>>>>>>> Did you notice that I said this 500 times already?
>>>>>>>>> Did you notice that I said this 500 times already?
>>>>>>>>> Did you notice that I said this 500 times already?
>>>>>>>>>
>>>>>>>>> HALTING DOES NOT MEAN STOPS RUNNING
>>>>>>>>> HALTING DOES NOT MEAN STOPS RUNNING
>>>>>>>>> HALTING DOES NOT MEAN STOPS RUNNING
>>>>>>>>
>>>>>>>> Right, and for the simulation of H(P,P), that is all that happen
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> HALTING MEANS TERMINATED NORMALLY
>>>>>>>>> HALTING MEANS TERMINATED NORMALLY
>>>>>>>>> HALTING MEANS TERMINATED NORMALLY
>>>>>>>>
>>>>>>>>
>>>>>>>> And the input to H(P,P) does TERMINATE NORMALLY when correct
>>>>>>>> simulated.
>>>>>>>>
>>>>>>> THIS IS WHERE YOU ARE A BRAIN DEAD MORON:
>>>>>>>
>>>>>>> _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]
>>>>>>>
>>>>>>> It is completely obvious that when H(P,P) correctly emulates its
>>>>>>> input that it must emulate the first seven instructions of P.
>>>>>>> Because the seventh instruction repeats this process we can know
>>>>>>> with complete certainty that the emulated P never reaches its
>>>>>>> final “ret” instruction, thus never halts.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Right, it emulates the first seven instructions,
>>>>>
>>>>> BRAIN DEAD MORONS DON'T GET THIS:
>>>>> Because we verified that H(P,P) emulates the first seven
>>>>> instructions of P we know that it will keep doing this every time
>>>>> that H(P,P) is invoked as long as the simulation continues.
>>>>
>>>> Nope, different invocations of H's so not part of the same trace.
>>> That is what a brain dead moron (or a despicable liar) would say.
>>>
>>> The whole point is whether or not the correct x86 emulation of the
>>> original input would ever reach its final "ret" instruction.
>>>
>>
>> Right, the correct x86 emulation of the ORIGINAL input. The second
>> layer of simulation is
>
> invoked in the same execution chain that invokes the first layer and is
> thus a subordinate aspect of this first emulation.
>

On 6/4/2022 1:17 PM, Alan Mackenzie wrote:
> [ Followup-To: set ]
>
> In comp.theory olcott <NoOne@nowhere.com> wrote:
>> On 6/4/2022 5:01 AM, Malcolm McLean wrote:
>>> On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:
>>>> On 6/3/2022 7:20 PM, Richard Damon wrote:
>
>>>>> On 6/3/22 7:56 PM, olcott wrote:
>>>>>> On 6/3/2022 6:35 PM, Mr Flibble wrote:
>>>>>>> On Fri, 3 Jun 2022 17:17:12 -0500
>>>>>>> olcott <No...@NoWhere.com> wrote:
>
> [ .... ]
>
>>> You've got nested simulations.
>>> If H detects them as infinitely nested, and aborts, they are no longer
>>> infinitely nested, so it gets the wrong answer (as happens here).
>
>> I can't understand how you can be so wrong about this. It is like you
>> make sure to never read anything that I say before spouting off a canned
>> rebuttal.
>
> I frequently read what you say. It's dull and repetitive. And wrong.
>
>> void Infinite_Loop()
>> {
>> HERE: goto HERE;
>> }
>
>> int main()
>> {
>> Output("Input_Halts = ", H0(Infinite_Loop));
>> }
>
>> _Infinite_Loop()
>> [00001342](01) 55 push ebp
>> [00001343](02) 8bec mov ebp,esp
>> [00001345](02) ebfe jmp 00001345
>> [00001347](01) 5d pop ebp
>> [00001348](01) c3 ret
>> Size in bytes:(0007) [00001348]
>
>> In the same way that H0 detects .....
>
> We don't know what H0 detects, since its code is secret, and probably
> doesn't exist.
>

That software engineering confirms that such an H0 could exist is
sufficient proof that H0 does exist whether or not it is encoded.
It is encoded.

>> .... that the complete x86 emulation of _Infinite_Loop() would never
>> reach its final "ret" instruction H(P,P) on the basis of a partial
>> simulation H(P,P) detects that the complete x86 emulation of its input
>> would never reach its final "ret" instruction.
>
>> Did you notice that I said this 500 times already?
>> Did you notice that I said this 500 times already?
>> Did you notice that I said this 500 times already?
>
> Yes. It's dull and repetitive and wrong. If it were correct, you would
> only need to say it once, and it would be accepted and acknowledged by
> the experts in this group.

Not with the damned liars on this forum that are only interested in
rebuttal and don't give a rat's ass about the truth.

>
>> HALTING DOES NOT MEAN STOPS RUNNING
>> HALTING DOES NOT MEAN STOPS RUNNING
>> HALTING DOES NOT MEAN STOPS RUNNING
>
> In this context, it does.
>
>> HALTING MEANS TERMINATED NORMALLY
>> HALTING MEANS TERMINATED NORMALLY
>> HALTING MEANS TERMINATED NORMALLY
>
> A turing machine runs until it halts. Terminated "normally" has no
> meaning.

So you are saying that the term "terminated normally" is complete
gibberish to every software engineer? Why do you lie about this?

> That is one reason you avoid turing machines. They make things
> too clear and well defined, leaving you no room to argue stupidities like
> "halting doesn't mean stops running".

Computation that halts ... the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)

Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company.

--
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 6/4/2022 1:31 PM, Richard Damon wrote:
> On 6/4/22 2:14 PM, olcott wrote:
>> On 6/4/2022 1:09 PM, Richard Damon wrote:
>>> On 6/4/22 1:23 PM, olcott wrote:
>>>> On 6/4/2022 12:15 PM, Richard Damon wrote:
>>>>> On 6/4/22 12:25 PM, olcott wrote:
>>>>>> On 6/4/2022 11:11 AM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 6/4/22 11:51 AM, olcott wrote:
>>>>>>>> On 6/4/2022 10:38 AM, Richard Damon wrote:
>>>>>>>>> On 6/4/22 11:11 AM, olcott wrote:
>>>>>>>>>> On 6/4/2022 5:01 AM, Malcolm McLean wrote:
>>>>>>>>>>> On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:
>>>>>>>>>>>> On 6/3/2022 7:20 PM, Richard Damon wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 6/3/22 7:56 PM, olcott wrote:
>>>>>>>>>>>>>> On 6/3/2022 6:35 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>> On Fri, 3 Jun 2022 17:17:12 -0500
>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This post assumes that you already know my work,
>>>>>>>>>>>>>>>> otherwise please
>>>>>>>>>>>>>>>> read the linked paper provided below. This work is based
>>>>>>>>>>>>>>>> on the
>>>>>>>>>>>>>>>> x86utm operating system that was created so that every
>>>>>>>>>>>>>>>> detail of the
>>>>>>>>>>>>>>>> halting problem could be directly examined in C/x86.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> void Infinite_Loop()
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>      Output("Input_Halts = ", H0(Infinite_Loop));
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>> [00001342](01)  55              push ebp
>>>>>>>>>>>>>>>> [00001343](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>>> [00001345](02)  ebfe            jmp 00001345
>>>>>>>>>>>>>>>> [00001347](01)  5d              pop ebp
>>>>>>>>>>>>>>>> [00001348](01)  c3              ret
>>>>>>>>>>>>>>>> Size in bytes:(0007) [00001348]
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It is totally obvious that the _Infinite_Loop() would
>>>>>>>>>>>>>>>> never halt
>>>>>>>>>>>>>>>> (meaning that it terminates normally by reaching its "ret"
>>>>>>>>>>>>>>>> instruction).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Equally obvious is the fact that a partial x86 emulation
>>>>>>>>>>>>>>>> of this
>>>>>>>>>>>>>>>> input conclusively proves that its complete x86
>>>>>>>>>>>>>>>> emulation would never
>>>>>>>>>>>>>>>> halt.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Begin Local Halt Decider Simulation   Execution Trace
>>>>>>>>>>>>>>>> Stored at:212343
>>>>>>>>>>>>>>>> [00001342][00212333][00212337] 55         push ebp
>>>>>>>>>>>>>>>> [00001343][00212333][00212337] 8bec       mov ebp,esp
>>>>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe       jmp 00001345
>>>>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe       jmp 00001345
>>>>>>>>>>>>>>>> Local Halt Decider: Infinite Loop Detected Simulation
>>>>>>>>>>>>>>>> Stopped
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The exact same reasoning applies to the correctly
>>>>>>>>>>>>>>>> emulated input to
>>>>>>>>>>>>>>>> H(P,P):
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> _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]
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It is completely obvious that when H(P,P) correctly
>>>>>>>>>>>>>>>> emulates its
>>>>>>>>>>>>>>>> input that it must emulate the first seven instructions
>>>>>>>>>>>>>>>> of P.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Because the seventh instruction repeats this process we
>>>>>>>>>>>>>>>> can know with
>>>>>>>>>>>>>>>> complete certainty that the emulated P never reaches its
>>>>>>>>>>>>>>>> final “ret”
>>>>>>>>>>>>>>>> instruction, thus never halts.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Halting problem undecidability and infinitely nested
>>>>>>>>>>>>>>>> simulation (V5)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Unfortunately your logic is such that the decision as to
>>>>>>>>>>>>>>> whether or not
>>>>>>>>>>>>>>> to enter the infinite loop is predicated on an infinite
>>>>>>>>>>>>>>> recursion (call
>>>>>>>>>>>>>>> H) that is not present in the Halting Problem proofs you
>>>>>>>>>>>>>>> are attempting
>>>>>>>>>>>>>>> to refute.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is when a simulating halt decider is assumed.
>>>>>>>>>>>>>
>>>>>>>>>>>>> But you can not assume that an actual simulating Halt
>>>>>>>>>>>>> Decider actually
>>>>>>>>>>>>> exists.
>>>>>>>>>>>> I proved that H(P,P)==0 is correct.
>>>>>>>>>>>>
>>>>>>>>>>> You've got nested simulations.
>>>>>>>>>>> If H detects them as infinitely nested, and aborts, they are
>>>>>>>>>>> no longer infinitely
>>>>>>>>>>> nested, so it gets the wrong answer (as happens here).
>>>>>>>>>>
>>>>>>>>>> I can't understand how you can be so wrong about this. It is
>>>>>>>>>> like you make sure to never read anything that I say before
>>>>>>>>>> spouting off a canned rebuttal.
>>>>>>>>>>
>>>>>>>>>> void Infinite_Loop()
>>>>>>>>>> {
>>>>>>>>>>    HERE: goto HERE;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> int main()
>>>>>>>>>> {
>>>>>>>>>>    Output("Input_Halts = ", H0(Infinite_Loop));
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>> [00001342](01)  55              push ebp
>>>>>>>>>> [00001343](02)  8bec            mov ebp,esp
>>>>>>>>>> [00001345](02)  ebfe            jmp 00001345
>>>>>>>>>> [00001347](01)  5d              pop ebp
>>>>>>>>>> [00001348](01)  c3              ret
>>>>>>>>>> Size in bytes:(0007) [00001348]
>>>>>>>>>>
>>>>>>>>>> In the same way that H0 detects that the complete x86
>>>>>>>>>> emulation of _Infinite_Loop() would never reach its final
>>>>>>>>>> "ret" instruction H(P,P) on the basis of a partial simulation
>>>>>>>>>> H(P,P) detects that the complete x86 emulation of its input
>>>>>>>>>> would never reach its final "ret" instruction.
>>>>>>>>>>
>>>>>>>>>> Did you notice that I said this 500 times already?
>>>>>>>>>> Did you notice that I said this 500 times already?
>>>>>>>>>> Did you notice that I said this 500 times already?
>>>>>>>>>>
>>>>>>>>>> HALTING DOES NOT MEAN STOPS RUNNING
>>>>>>>>>> HALTING DOES NOT MEAN STOPS RUNNING
>>>>>>>>>> HALTING DOES NOT MEAN STOPS RUNNING
>>>>>>>>>
>>>>>>>>> Right, and for the simulation of H(P,P), that is all that happen
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> HALTING MEANS TERMINATED NORMALLY
>>>>>>>>>> HALTING MEANS TERMINATED NORMALLY
>>>>>>>>>> HALTING MEANS TERMINATED NORMALLY
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> And the input to H(P,P) does TERMINATE NORMALLY when correct
>>>>>>>>> simulated.
>>>>>>>>>
>>>>>>>> THIS IS WHERE YOU ARE A BRAIN DEAD MORON:
>>>>>>>>
>>>>>>>> _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]
>>>>>>>>
>>>>>>>> It is completely obvious that when H(P,P) correctly emulates its
>>>>>>>> input that it must emulate the first seven instructions of P.
>>>>>>>> Because the seventh instruction repeats this process we can know
>>>>>>>> with complete certainty that the emulated P never reaches its
>>>>>>>> final “ret” instruction, thus never halts.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Right, it emulates the first seven instructions,
>>>>>>
>>>>>> BRAIN DEAD MORONS DON'T GET THIS:
>>>>>> Because we verified that H(P,P) emulates the first seven
>>>>>> instructions of P we know that it will keep doing this every time
>>>>>> that H(P,P) is invoked as long as the simulation continues.
>>>>>
>>>>> Nope, different invocations of H's so not part of the same trace.
>>>> That is what a brain dead moron (or a despicable liar) would say.
>>>>
>>>> The whole point is whether or not the correct x86 emulation of the
>>>> original input would ever reach its final "ret" instruction.
>>>>
>>>
>>> Right, the correct x86 emulation of the ORIGINAL input. The second
>>> layer of simulation is
>>
>> invoked in the same execution chain that invokes the first layer and
>> is thus a subordinate aspect of this first emulation.
>>
>
> Nope, the execution of that is NOT part of the actual execution trace of
> the original input.

On 6/4/22 2:39 PM, olcott wrote:
> On 6/4/2022 1:31 PM, Richard Damon wrote:
>> On 6/4/22 2:14 PM, olcott wrote:
>>> On 6/4/2022 1:09 PM, Richard Damon wrote:
>>>> On 6/4/22 1:23 PM, olcott wrote:
>>>>> On 6/4/2022 12:15 PM, Richard Damon wrote:
>>>>>> On 6/4/22 12:25 PM, olcott wrote:
>>>>>>> On 6/4/2022 11:11 AM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> On 6/4/22 11:51 AM, olcott wrote:
>>>>>>>>> On 6/4/2022 10:38 AM, Richard Damon wrote:
>>>>>>>>>> On 6/4/22 11:11 AM, olcott wrote:
>>>>>>>>>>> On 6/4/2022 5:01 AM, Malcolm McLean wrote:
>>>>>>>>>>>> On Saturday, 4 June 2022 at 04:51:16 UTC+1, olcott wrote:
>>>>>>>>>>>>> On 6/3/2022 7:20 PM, Richard Damon wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 6/3/22 7:56 PM, olcott wrote:
>>>>>>>>>>>>>>> On 6/3/2022 6:35 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>> On Fri, 3 Jun 2022 17:17:12 -0500
>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This post assumes that you already know my work,
>>>>>>>>>>>>>>>>> otherwise please
>>>>>>>>>>>>>>>>> read the linked paper provided below. This work is
>>>>>>>>>>>>>>>>> based on the
>>>>>>>>>>>>>>>>> x86utm operating system that was created so that every
>>>>>>>>>>>>>>>>> detail of the
>>>>>>>>>>>>>>>>> halting problem could be directly examined in C/x86.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> void Infinite_Loop()
>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>      Output("Input_Halts = ", H0(Infinite_Loop));
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>>>>>>>> [00001342](01)  55              push ebp
>>>>>>>>>>>>>>>>> [00001343](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>>>> [00001345](02)  ebfe            jmp 00001345
>>>>>>>>>>>>>>>>> [00001347](01)  5d              pop ebp
>>>>>>>>>>>>>>>>> [00001348](01)  c3              ret
>>>>>>>>>>>>>>>>> Size in bytes:(0007) [00001348]
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It is totally obvious that the _Infinite_Loop() would
>>>>>>>>>>>>>>>>> never halt
>>>>>>>>>>>>>>>>> (meaning that it terminates normally by reaching its "ret"
>>>>>>>>>>>>>>>>> instruction).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Equally obvious is the fact that a partial x86
>>>>>>>>>>>>>>>>> emulation of this
>>>>>>>>>>>>>>>>> input conclusively proves that its complete x86
>>>>>>>>>>>>>>>>> emulation would never
>>>>>>>>>>>>>>>>> halt.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Begin Local Halt Decider Simulation   Execution Trace
>>>>>>>>>>>>>>>>> Stored at:212343
>>>>>>>>>>>>>>>>> [00001342][00212333][00212337] 55         push ebp
>>>>>>>>>>>>>>>>> [00001343][00212333][00212337] 8bec       mov ebp,esp
>>>>>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe       jmp 00001345
>>>>>>>>>>>>>>>>> [00001345][00212333][00212337] ebfe       jmp 00001345
>>>>>>>>>>>>>>>>> Local Halt Decider: Infinite Loop Detected Simulation
>>>>>>>>>>>>>>>>> Stopped
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The exact same reasoning applies to the correctly
>>>>>>>>>>>>>>>>> emulated input to
>>>>>>>>>>>>>>>>> H(P,P):
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> _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]
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It is completely obvious that when H(P,P) correctly
>>>>>>>>>>>>>>>>> emulates its
>>>>>>>>>>>>>>>>> input that it must emulate the first seven instructions
>>>>>>>>>>>>>>>>> of P.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Because the seventh instruction repeats this process we
>>>>>>>>>>>>>>>>> can know with
>>>>>>>>>>>>>>>>> complete certainty that the emulated P never reaches
>>>>>>>>>>>>>>>>> its final “ret”
>>>>>>>>>>>>>>>>> instruction, thus never halts.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Halting problem undecidability and infinitely nested
>>>>>>>>>>>>>>>>> simulation (V5)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Unfortunately your logic is such that the decision as to
>>>>>>>>>>>>>>>> whether or not
>>>>>>>>>>>>>>>> to enter the infinite loop is predicated on an infinite
>>>>>>>>>>>>>>>> recursion (call
>>>>>>>>>>>>>>>> H) that is not present in the Halting Problem proofs you
>>>>>>>>>>>>>>>> are attempting
>>>>>>>>>>>>>>>> to refute.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is when a simulating halt decider is assumed.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> But you can not assume that an actual simulating Halt
>>>>>>>>>>>>>> Decider actually
>>>>>>>>>>>>>> exists.
>>>>>>>>>>>>> I proved that H(P,P)==0 is correct.
>>>>>>>>>>>>>
>>>>>>>>>>>> You've got nested simulations.
>>>>>>>>>>>> If H detects them as infinitely nested, and aborts, they are
>>>>>>>>>>>> no longer infinitely
>>>>>>>>>>>> nested, so it gets the wrong answer (as happens here).
>>>>>>>>>>>
>>>>>>>>>>> I can't understand how you can be so wrong about this. It is
>>>>>>>>>>> like you make sure to never read anything that I say before
>>>>>>>>>>> spouting off a canned rebuttal.
>>>>>>>>>>>
>>>>>>>>>>> void Infinite_Loop()
>>>>>>>>>>> {
>>>>>>>>>>>    HERE: goto HERE;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> int main()
>>>>>>>>>>> {
>>>>>>>>>>>    Output("Input_Halts = ", H0(Infinite_Loop));
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> _Infinite_Loop()
>>>>>>>>>>> [00001342](01)  55              push ebp
>>>>>>>>>>> [00001343](02)  8bec            mov ebp,esp
>>>>>>>>>>> [00001345](02)  ebfe            jmp 00001345
>>>>>>>>>>> [00001347](01)  5d              pop ebp
>>>>>>>>>>> [00001348](01)  c3              ret
>>>>>>>>>>> Size in bytes:(0007) [00001348]
>>>>>>>>>>>
>>>>>>>>>>> In the same way that H0 detects that the complete x86
>>>>>>>>>>> emulation of _Infinite_Loop() would never reach its final
>>>>>>>>>>> "ret" instruction H(P,P) on the basis of a partial simulation
>>>>>>>>>>> H(P,P) detects that the complete x86 emulation of its input
>>>>>>>>>>> would never reach its final "ret" instruction.
>>>>>>>>>>>
>>>>>>>>>>> Did you notice that I said this 500 times already?
>>>>>>>>>>> Did you notice that I said this 500 times already?
>>>>>>>>>>> Did you notice that I said this 500 times already?
>>>>>>>>>>>
>>>>>>>>>>> HALTING DOES NOT MEAN STOPS RUNNING
>>>>>>>>>>> HALTING DOES NOT MEAN STOPS RUNNING
>>>>>>>>>>> HALTING DOES NOT MEAN STOPS RUNNING
>>>>>>>>>>
>>>>>>>>>> Right, and for the simulation of H(P,P), that is all that happen
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> HALTING MEANS TERMINATED NORMALLY
>>>>>>>>>>> HALTING MEANS TERMINATED NORMALLY
>>>>>>>>>>> HALTING MEANS TERMINATED NORMALLY
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> And the input to H(P,P) does TERMINATE NORMALLY when correct
>>>>>>>>>> simulated.
>>>>>>>>>>
>>>>>>>>> THIS IS WHERE YOU ARE A BRAIN DEAD MORON:
>>>>>>>>>
>>>>>>>>> _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]
>>>>>>>>>
>>>>>>>>> It is completely obvious that when H(P,P) correctly emulates
>>>>>>>>> its input that it must emulate the first seven instructions of
>>>>>>>>> P. Because the seventh instruction repeats this process we can
>>>>>>>>> know with complete certainty that the emulated P never reaches
>>>>>>>>> its final “ret” instruction, thus never halts.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Right, it emulates the first seven instructions,
>>>>>>>
>>>>>>> BRAIN DEAD MORONS DON'T GET THIS:
>>>>>>> Because we verified that H(P,P) emulates the first seven
>>>>>>> instructions of P we know that it will keep doing this every time
>>>>>>> that H(P,P) is invoked as long as the simulation continues.
>>>>>>
>>>>>> Nope, different invocations of H's so not part of the same trace.
>>>>> That is what a brain dead moron (or a despicable liar) would say.
>>>>>
>>>>> The whole point is whether or not the correct x86 emulation of the
>>>>> original input would ever reach its final "ret" instruction.
>>>>>
>>>>
>>>> Right, the correct x86 emulation of the ORIGINAL input. The second
>>>> layer of simulation is
>>>
>>> invoked in the same execution chain that invokes the first layer and
>>> is thus a subordinate aspect of this first emulation.
>>>
>>
>> Nope, the execution of that is NOT part of the actual execution trace
>> of the original input.
>
> When you start denying easily verifiable facts I quit even glancing at
> what you say for at least a week.
>