On 6/3/22 5:08 PM, olcott wrote:
> On 6/2/2022 9:41 PM, Richard Damon wrote:
>> On 6/2/22 7:45 PM, olcott wrote:
>>> On 6/2/2022 6:38 PM, Mr Flibble wrote:
>>>> On Thu, 2 Jun 2022 15:47:22 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>
>>>>> On 6/2/2022 1:12 PM, Andy Walker wrote:
>>>>>> On 02/06/2022 17:21, Ben wrote:
>>>>>>> [...]  We know simulation can't be
>>>>>>> used to decide halting, and we know that there are only two ways a
>>>>>>> decider that tries to do so can be wrong.  Both come up every time
>>>>>>> this is taught to a class of programmers.  (I've never taught it
>>>>>>> to a class of mathematicians but I suspect the discussion would be
>>>>>>> very different.)
>>>>>>
>>>>>>       My first thought was "no, it's the same", but on reflexion,
>>>>>> and AFAIR, our mathematicians simply accepted what I told them,
>>>>>> which is essentially what
>>>>>> is at
>>>>>>
>>>>>>       http://www.cuboid.me.uk/anw/G12FCO/lect17.html
>>>>>>
>>>>>> [second half, but see esp the last paragraph] and
>>>>>>
>>>>>>       http://www.cuboid.me.uk/anw/G12FCO/lect18.html
>>>>>
>>>>>
>>>>> For these cases, we can turn to our second weapon -- emulation. We
>>>>> want to know whether a program halts, so we try it. If it halts, then
>>>>> we know the answer. If it doesn't halt, then `it must be in a loop',
>>>>> so we monitor its state and `detect the loop'. Sadly, although this
>>>>> is in one sense correct, it is a false dichotomy. 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.
>>>>>
>>>>> It is not considered correctly.
>>>>> (a) the program has halted
>>>>> (b) the program is still running
>>>>> (c) the program matched an infinite behavior pattern
>>>>>
>>>>>        For any program H that might determine if programs halt, a
>>>>> "pathological"
>>>>>        program P, called with some input, can pass its own source and
>>>>> its input to
>>>>>        H and then specifically do the opposite of what H predicts P
>>>>> will do. No H
>>>>>        can exist that handles this case.
>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>
>>>>> Any competent software engineer can verify that H(P,P)==0
>>>>> for the above behavior pattern. (The entire research scope)
>>>>> As detailed in my paper:
>>>>>
>>>>> Halting problem undecidability and infinitely nested simulation (V5)
>>>>>
>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>
>>>>>
>>>>
>>>> The proofs you are attempting to refute do not contain the infinite
>>>> behaviour pattern you describe;
>>>
>>> The correctly simulated input to a simulating halt decider never
>>> reaches the final instruction of this simulated input thus is
>>> unequivocally non-halting.
>>
>> You keep on saying that, but it isn't actually true for the PROPER
>> definition of "correct simulation", that being, the simulation of the
>> input by a UTM equiavlent. (or an x86 processor for your x86 code).
>>
>> What you want to call "correct simulation" is the partial simulation
>> by a particular H, but partial simulation are NEVER "correct" because
>> they are, by definitin=on, INCOMPLETE.
> 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 other words you keep saying the same cockamamy bullshit that it is
> utterly impossible to correctly determine what a complete simulation
> would be from a partial simulation.
>
> This is the exactly same numbskull idea that it is utterly impossible to
> determine that a loop is infinite until after waiting forever to see if
> it stops running.  *Why are you such a jackass?*
>

No, that isn't what I said.

I said that H can not generate a correct simulation of that input,
because it will generate only a partial simulation of it, and that by
definition is NOT correct.

Note, sometimes you can derive a correct halting answer from a partial
simulation, because the partial simulation actually does show a pattern
that correctly detects the non-halting behavior.

The fact that you have made this exact same mistake several times just
shows that you seem to have a learning disability and are unable to
learn from your mistakes, so you are doomed to keep repeating them.

Maybe if you would actually read what people say, you might be able to
undertand what is happening.

It might be that you are just too ignorant of the terminology that even
these simple statements are beyond you understanding, or maybe the
problem is you just don't actually care what is actually true, but just
want to "steamroller" your false ideas.

On 6/3/22 5:55 PM, olcott wrote:
> On 6/3/2022 4:47 PM, Mr Flibble wrote:
>> On Fri, 3 Jun 2022 16:08:34 -0500
>> olcott <polcott2@gmail.com> wrote:
>>
>>> On 6/2/2022 9:41 PM, Richard Damon wrote:
>>>> On 6/2/22 7:45 PM, olcott wrote:
>>>>> On 6/2/2022 6:38 PM, Mr Flibble wrote:
>>>>>> On Thu, 2 Jun 2022 15:47:22 -0500
>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>> On 6/2/2022 1:12 PM, Andy Walker wrote:
>>>>>>>> On 02/06/2022 17:21, Ben wrote:
>>>>>>>>> [...]  We know simulation can't be
>>>>>>>>> used to decide halting, and we know that there are only two
>>>>>>>>> ways a decider that tries to do so can be wrong.  Both come up
>>>>>>>>> every time this is taught to a class of programmers.  (I've
>>>>>>>>> never taught it to a class of mathematicians but I suspect the
>>>>>>>>> discussion would be very different.)
>>>>>>>>
>>>>>>>>        My first thought was "no, it's the same", but on
>>>>>>>> reflexion, and AFAIR, our mathematicians simply accepted what I
>>>>>>>> told them, which is essentially what
>>>>>>>> is at
>>>>>>>>
>>>>>>>>        http://www.cuboid.me.uk/anw/G12FCO/lect17.html
>>>>>>>>
>>>>>>>> [second half, but see esp the last paragraph] and
>>>>>>>>
>>>>>>>>        http://www.cuboid.me.uk/anw/G12FCO/lect18.html
>>>>>>>
>>>>>>>
>>>>>>> For these cases, we can turn to our second weapon -- emulation.
>>>>>>> We want to know whether a program halts, so we try it. If it
>>>>>>> halts, then we know the answer. If it doesn't halt, then `it
>>>>>>> must be in a loop', so we monitor its state and `detect the
>>>>>>> loop'. Sadly, although this is in one sense correct, it is a
>>>>>>> false dichotomy. 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.
>>>>>>>
>>>>>>> It is not considered correctly.
>>>>>>> (a) the program has halted
>>>>>>> (b) the program is still running
>>>>>>> (c) the program matched an infinite behavior pattern
>>>>>>>
>>>>>>>         For any program H that might determine if programs halt, a
>>>>>>> "pathological"
>>>>>>>         program P, called with some input, can pass its own
>>>>>>> source and its input to
>>>>>>>         H and then specifically do the opposite of what H
>>>>>>> predicts P will do. No H
>>>>>>>         can exist that handles this case.
>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>
>>>>>>> Any competent software engineer can verify that H(P,P)==0
>>>>>>> for the above behavior pattern. (The entire research scope)
>>>>>>> As detailed in my paper:
>>>>>>>
>>>>>>> Halting problem undecidability and infinitely nested simulation
>>>>>>> (V5)
>>>>>>>
>>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> The proofs you are attempting to refute do not contain the
>>>>>> infinite behaviour pattern you describe;
>>>>>
>>>>> The correctly simulated input to a simulating halt decider never
>>>>> reaches the final instruction of this simulated input thus is
>>>>> unequivocally non-halting.
>>>>
>>>> You keep on saying that, but it isn't actually true for the PROPER
>>>> definition of "correct simulation", that being, the simulation of
>>>> the input by a UTM equiavlent. (or an x86 processor for your x86
>>>> code).
>>>>
>>>> What you want to call "correct simulation" is the partial
>>>> simulation by a particular H, but partial simulation are NEVER
>>>> "correct" because they are, by definitin=on, INCOMPLETE.
>>> 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 other words you keep saying the same cockamamy bullshit that it is
>>> utterly impossible to correctly determine what a complete simulation
>>> would be from a partial simulation.
>>>
>>> This is the exactly same numbskull idea that it is utterly impossible
>>> to determine that a loop is infinite until after waiting forever to
>>> see if it stops running.  *Why are you such a jackass?*
>>
>> Your "infinite loop" only starts if an infinite recursion is detected
>> however the proofs you are attempting to refute contain no such
>> infinite recursion so your "infinite loop" is irrelevant.
>>
>> /Flibble
>>
>>
>
> That you can't comprehend that the full correct x86 emulation of the
> input to H(P,P) by H would never stop running shows that your software
> engineering skills are woefully insufficient to evalulate my work.
>

No, you LIE here, as has been shown before. The correct simulation of
the input of H(P,P) does reach the ret instruction as long as the H you
have defined returns the value 0 to H(P,P).

Even YOU have provided such a trace.

What can't reach that point is a simulation by H itself. Either that H
is one of your definitions that uses faulty logic and aborts its
simulation after incorrectly deciding that the correct simulation of its
input would never halt, and returns 0, which make the actual correct
simulation (as done by a pure simulator that never aborts, and thus NOT
just a copy of H) reach the ret istruction after it simulates through
all the code of H that makes that decision and return 0.

The other option is that you are in the totally other case, where H is
defined to be a machine that NEVER aborts its simulation of its input to
H(P,P), and such a H fails to answer at all. Yes, in THAT case P(P) is
non-halting, but H, by definition, never aborts so never gives that answer.

Note, if your definition of "Correct Simulation" does NOT match that
definiton the you don't have a valid defiition of Halting and have done
an INVALID transformation, as the transform from looking that the
behavior of the ACTUAL MACHINE, to a CORRECT SIMULATION, is ONLY valid
if "CORRECT SIMULATION" means a simulation that behaves exactly like the
actual machine.

To claim otherwise is to just be lying.

> _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]
>
> Like H0(Infinite_Loop) does not need to perform a complete x86 emulation
> of its input to correctly determine the behavior of a complete emulation
> H(P,P) correctly determines that its input would never halt.
>

On 6/3/2022 5:31 PM, Richard Damon wrote:
> On 6/3/22 5:08 PM, olcott wrote:
>> On 6/2/2022 9:41 PM, Richard Damon wrote:
>>> On 6/2/22 7:45 PM, olcott wrote:
>>>> On 6/2/2022 6:38 PM, Mr Flibble wrote:
>>>>> On Thu, 2 Jun 2022 15:47:22 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 6/2/2022 1:12 PM, Andy Walker wrote:
>>>>>>> On 02/06/2022 17:21, Ben wrote:
>>>>>>>> [...]  We know simulation can't be
>>>>>>>> used to decide halting, and we know that there are only two ways a
>>>>>>>> decider that tries to do so can be wrong.  Both come up every time
>>>>>>>> this is taught to a class of programmers.  (I've never taught it
>>>>>>>> to a class of mathematicians but I suspect the discussion would be
>>>>>>>> very different.)
>>>>>>>
>>>>>>>       My first thought was "no, it's the same", but on reflexion,
>>>>>>> and AFAIR, our mathematicians simply accepted what I told them,
>>>>>>> which is essentially what
>>>>>>> is at
>>>>>>>
>>>>>>>       http://www.cuboid.me.uk/anw/G12FCO/lect17.html
>>>>>>>
>>>>>>> [second half, but see esp the last paragraph] and
>>>>>>>
>>>>>>>       http://www.cuboid.me.uk/anw/G12FCO/lect18.html
>>>>>>
>>>>>>
>>>>>> For these cases, we can turn to our second weapon -- emulation. We
>>>>>> want to know whether a program halts, so we try it. If it halts, then
>>>>>> we know the answer. If it doesn't halt, then `it must be in a loop',
>>>>>> so we monitor its state and `detect the loop'. Sadly, although this
>>>>>> is in one sense correct, it is a false dichotomy. 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.
>>>>>>
>>>>>> It is not considered correctly.
>>>>>> (a) the program has halted
>>>>>> (b) the program is still running
>>>>>> (c) the program matched an infinite behavior pattern
>>>>>>
>>>>>>        For any program H that might determine if programs halt, a
>>>>>> "pathological"
>>>>>>        program P, called with some input, can pass its own source and
>>>>>> its input to
>>>>>>        H and then specifically do the opposite of what H predicts P
>>>>>> will do. No H
>>>>>>        can exist that handles this case.
>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>
>>>>>> Any competent software engineer can verify that H(P,P)==0
>>>>>> for the above behavior pattern. (The entire research scope)
>>>>>> As detailed in my paper:
>>>>>>
>>>>>> Halting problem undecidability and infinitely nested simulation (V5)
>>>>>>
>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>>
>>>>>>
>>>>>
>>>>> The proofs you are attempting to refute do not contain the infinite
>>>>> behaviour pattern you describe;
>>>>
>>>> The correctly simulated input to a simulating halt decider never
>>>> reaches the final instruction of this simulated input thus is
>>>> unequivocally non-halting.
>>>
>>> You keep on saying that, but it isn't actually true for the PROPER
>>> definition of "correct simulation", that being, the simulation of the
>>> input by a UTM equiavlent. (or an x86 processor for your x86 code).
>>>
>>> What you want to call "correct simulation" is the partial simulation
>>> by a particular H, but partial simulation are NEVER "correct" because
>>> they are, by definitin=on, INCOMPLETE.
>> 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 other words you keep saying the same cockamamy bullshit that it is
>> utterly impossible to correctly determine what a complete simulation
>> would be from a partial simulation.
>>
>> This is the exactly same numbskull idea that it is utterly impossible
>> to determine that a loop is infinite until after waiting forever to
>> see if it stops running.  *Why are you such a jackass?*
>>
>
> No, that isn't what I said.
>
> I said that H can not generate a correct simulation of that input,
> because it will generate only a partial simulation of it, and that by
> definition is NOT correct.
BECAUSE YOU ALREADY KNOW THAT A PARTIAL SIMULATION DOES CORRECTLY
PREDICT A COMPLETE SIMULATION WHAT ARE YOU SUCH A JACKASS?

BECAUSE YOU ALREADY KNOW THAT A PARTIAL SIMULATION DOES CORRECTLY
PREDICT A COMPLETE SIMULATION WHAT ARE YOU SUCH A JACKASS?

BECAUSE YOU ALREADY KNOW THAT A PARTIAL SIMULATION DOES CORRECTLY
PREDICT A COMPLETE SIMULATION WHAT ARE YOU SUCH A JACKASS?

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:01 PM, olcott wrote:
> On 6/3/2022 4:47 PM, Mr Flibble wrote:
>> On Fri, 3 Jun 2022 16:08:34 -0500
>> olcott <polcott2@gmail.com> wrote:
>>
>>> On 6/2/2022 9:41 PM, Richard Damon wrote:
>>>> On 6/2/22 7:45 PM, olcott wrote:
>>>>> On 6/2/2022 6:38 PM, Mr Flibble wrote:
>>>>>> On Thu, 2 Jun 2022 15:47:22 -0500
>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>> On 6/2/2022 1:12 PM, Andy Walker wrote:
>>>>>>>> On 02/06/2022 17:21, Ben wrote:
>>>>>>>>> [...]  We know simulation can't be
>>>>>>>>> used to decide halting, and we know that there are only two
>>>>>>>>> ways a decider that tries to do so can be wrong.  Both come up
>>>>>>>>> every time this is taught to a class of programmers.  (I've
>>>>>>>>> never taught it to a class of mathematicians but I suspect the
>>>>>>>>> discussion would be very different.)
>>>>>>>>
>>>>>>>>        My first thought was "no, it's the same", but on
>>>>>>>> reflexion, and AFAIR, our mathematicians simply accepted what I
>>>>>>>> told them, which is essentially what
>>>>>>>> is at
>>>>>>>>
>>>>>>>>        http://www.cuboid.me.uk/anw/G12FCO/lect17.html
>>>>>>>>
>>>>>>>> [second half, but see esp the last paragraph] and
>>>>>>>>
>>>>>>>>        http://www.cuboid.me.uk/anw/G12FCO/lect18.html
>>>>>>>
>>>>>>>
>>>>>>> For these cases, we can turn to our second weapon -- emulation.
>>>>>>> We want to know whether a program halts, so we try it. If it
>>>>>>> halts, then we know the answer. If it doesn't halt, then `it
>>>>>>> must be in a loop', so we monitor its state and `detect the
>>>>>>> loop'. Sadly, although this is in one sense correct, it is a
>>>>>>> false dichotomy. 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.
>>>>>>>
>>>>>>> It is not considered correctly.
>>>>>>> (a) the program has halted
>>>>>>> (b) the program is still running
>>>>>>> (c) the program matched an infinite behavior pattern
>>>>>>>
>>>>>>>         For any program H that might determine if programs halt, a
>>>>>>> "pathological"
>>>>>>>         program P, called with some input, can pass its own
>>>>>>> source and its input to
>>>>>>>         H and then specifically do the opposite of what H
>>>>>>> predicts P will do. No H
>>>>>>>         can exist that handles this case.
>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>
>>>>>>> Any competent software engineer can verify that H(P,P)==0
>>>>>>> for the above behavior pattern. (The entire research scope)
>>>>>>> As detailed in my paper:
>>>>>>>
>>>>>>> Halting problem undecidability and infinitely nested simulation
>>>>>>> (V5)
>>>>>>>
>>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> The proofs you are attempting to refute do not contain the
>>>>>> infinite behaviour pattern you describe;
>>>>>
>>>>> The correctly simulated input to a simulating halt decider never
>>>>> reaches the final instruction of this simulated input thus is
>>>>> unequivocally non-halting.
>>>>
>>>> You keep on saying that, but it isn't actually true for the PROPER
>>>> definition of "correct simulation", that being, the simulation of
>>>> the input by a UTM equiavlent. (or an x86 processor for your x86
>>>> code).
>>>>
>>>> What you want to call "correct simulation" is the partial
>>>> simulation by a particular H, but partial simulation are NEVER
>>>> "correct" because they are, by definitin=on, INCOMPLETE.
>>> 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 other words you keep saying the same cockamamy bullshit that it is
>>> utterly impossible to correctly determine what a complete simulation
>>> would be from a partial simulation.
>>>
>>> This is the exactly same numbskull idea that it is utterly impossible
>>> to determine that a loop is infinite until after waiting forever to
>>> see if it stops running.  *Why are you such a jackass?*
>>
>> Your "infinite loop" only starts if an infinite recursion is detected
>> however the proofs you are attempting to refute contain no such
>> infinite recursion so your "infinite loop" is irrelevant.
>>
>> /Flibble
>>
>>
>
> That you can't comprehend that the full correct x86 emulation of the
> input to H(P,P) by H would never stop running shows that your software
> engineering skills are woefully insufficient to evaluate my work.
>
> _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.
>
> Like H0(Infinite_Loop) does not need to perform a complete x86 emulation
> of its input to correctly determine the behavior of a complete emulation
> H(P,P) correctly determines that its input would never halt.
>
>

WRONG, FAIL, explained in other reply.

You are just being an idiot.

On 6/3/22 6:40 PM, olcott wrote:
> On 6/3/2022 5:31 PM, Richard Damon wrote:
>> On 6/3/22 5:08 PM, olcott wrote:
>>> On 6/2/2022 9:41 PM, Richard Damon wrote:
>>>> On 6/2/22 7:45 PM, olcott wrote:
>>>>> On 6/2/2022 6:38 PM, Mr Flibble wrote:
>>>>>> On Thu, 2 Jun 2022 15:47:22 -0500
>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>
>>>>>>> On 6/2/2022 1:12 PM, Andy Walker wrote:
>>>>>>>> On 02/06/2022 17:21, Ben wrote:
>>>>>>>>> [...]  We know simulation can't be
>>>>>>>>> used to decide halting, and we know that there are only two ways a
>>>>>>>>> decider that tries to do so can be wrong.  Both come up every time
>>>>>>>>> this is taught to a class of programmers.  (I've never taught it
>>>>>>>>> to a class of mathematicians but I suspect the discussion would be
>>>>>>>>> very different.)
>>>>>>>>
>>>>>>>>       My first thought was "no, it's the same", but on reflexion,
>>>>>>>> and AFAIR, our mathematicians simply accepted what I told them,
>>>>>>>> which is essentially what
>>>>>>>> is at
>>>>>>>>
>>>>>>>>       http://www.cuboid.me.uk/anw/G12FCO/lect17.html
>>>>>>>>
>>>>>>>> [second half, but see esp the last paragraph] and
>>>>>>>>
>>>>>>>>       http://www.cuboid.me.uk/anw/G12FCO/lect18.html
>>>>>>>
>>>>>>>
>>>>>>> For these cases, we can turn to our second weapon -- emulation. We
>>>>>>> want to know whether a program halts, so we try it. If it halts,
>>>>>>> then
>>>>>>> we know the answer. If it doesn't halt, then `it must be in a loop',
>>>>>>> so we monitor its state and `detect the loop'. Sadly, although this
>>>>>>> is in one sense correct, it is a false dichotomy. 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.
>>>>>>>
>>>>>>> It is not considered correctly.
>>>>>>> (a) the program has halted
>>>>>>> (b) the program is still running
>>>>>>> (c) the program matched an infinite behavior pattern
>>>>>>>
>>>>>>>        For any program H that might determine if programs halt, a
>>>>>>> "pathological"
>>>>>>>        program P, called with some input, can pass its own source
>>>>>>> and
>>>>>>> its input to
>>>>>>>        H and then specifically do the opposite of what H predicts P
>>>>>>> will do. No H
>>>>>>>        can exist that handles this case.
>>>>>>> https://en.wikipedia.org/wiki/Halting_problem
>>>>>>>
>>>>>>> Any competent software engineer can verify that H(P,P)==0
>>>>>>> for the above behavior pattern. (The entire research scope)
>>>>>>> As detailed in my paper:
>>>>>>>
>>>>>>> Halting problem undecidability and infinitely nested simulation (V5)
>>>>>>>
>>>>>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> The proofs you are attempting to refute do not contain the infinite
>>>>>> behaviour pattern you describe;
>>>>>
>>>>> The correctly simulated input to a simulating halt decider never
>>>>> reaches the final instruction of this simulated input thus is
>>>>> unequivocally non-halting.
>>>>
>>>> You keep on saying that, but it isn't actually true for the PROPER
>>>> definition of "correct simulation", that being, the simulation of
>>>> the input by a UTM equiavlent. (or an x86 processor for your x86 code).
>>>>
>>>> What you want to call "correct simulation" is the partial simulation
>>>> by a particular H, but partial simulation are NEVER "correct"
>>>> because they are, by definitin=on, INCOMPLETE.
>>> 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 other words you keep saying the same cockamamy bullshit that it is
>>> utterly impossible to correctly determine what a complete simulation
>>> would be from a partial simulation.
>>>
>>> This is the exactly same numbskull idea that it is utterly impossible
>>> to determine that a loop is infinite until after waiting forever to
>>> see if it stops running.  *Why are you such a jackass?*
>>>
>>
>> No, that isn't what I said.
>>
>> I said that H can not generate a correct simulation of that input,
>> because it will generate only a partial simulation of it, and that by
>> definition is NOT correct.
> BECAUSE YOU ALREADY KNOW THAT A PARTIAL SIMULATION DOES CORRECTLY
> PREDICT A COMPLETE SIMULATION WHAT ARE YOU SUCH A JACKASS?
>
> BECAUSE YOU ALREADY KNOW THAT A PARTIAL SIMULATION DOES CORRECTLY
> PREDICT A COMPLETE SIMULATION WHAT ARE YOU SUCH A JACKASS?
>
> BECAUSE YOU ALREADY KNOW THAT A PARTIAL SIMULATION DOES CORRECTLY
> PREDICT A COMPLETE SIMULATION WHAT ARE YOU SUCH A JACKASS?

Except it doesn't in the case of H(P,P) because H uses FAULTY logic to
decide to abort.

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

Yes, there IS an infinite behavior pattern in Infinite_Loop to prove
that it will not halt.

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

On 6/2/2022 1:12 PM, Andy Walker wrote:
> On 02/06/2022 17:21, Ben wrote:
>> [...]  We know simulation can't be
>> used to decide halting, and we know that there are only two ways a
>> decider that tries to do so can be wrong.  Both come up every time this
>> is taught to a class of programmers.  (I've never taught it to a class
>> of mathematicians but I suspect the discussion would be very different.)
>
>     My first thought was "no, it's the same", but on reflexion, and AFAIR,
> our mathematicians simply accepted what I told them, which is
> essentially what
> is at
>
>     http://www.cuboid.me.uk/anw/G12FCO/lect17.html
>
> [second half, but see esp the last paragraph] and
>
>     http://www.cuboid.me.uk/anw/G12FCO/lect18.html
>
> [both lectures from a module that I gave many moons ago].  We got pretty
> bright students, among the top four or five cohorts in the UK at that time
> [1990s] [but that was our high point, even beating Oxford one year], and of
> course many of them went into IT as a career.  They found NP-completeness
> much harder than UTMs, HP and related stuff.
>
>     [The code G12FCO means G1 -- maths, 2 -- second year, FCO -- Formal
> Computation.]
>

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 9:15 PM, olcott wrote:
> On 6/2/2022 1:12 PM, Andy Walker wrote:
>> On 02/06/2022 17:21, Ben wrote:
>>> [...]  We know simulation can't be
>>> used to decide halting, and we know that there are only two ways a
>>> decider that tries to do so can be wrong.  Both come up every time this
>>> is taught to a class of programmers.  (I've never taught it to a class
>>> of mathematicians but I suspect the discussion would be very different.)
>>
>>      My first thought was "no, it's the same", but on reflexion, and
>> AFAIR,
>> our mathematicians simply accepted what I told them, which is
>> essentially what
>> is at
>>
>>      http://www.cuboid.me.uk/anw/G12FCO/lect17.html
>>
>> [second half, but see esp the last paragraph] and
>>
>>      http://www.cuboid.me.uk/anw/G12FCO/lect18.html
>>
>> [both lectures from a module that I gave many moons ago].  We got pretty
>> bright students, among the top four or five cohorts in the UK at that
>> time
>> [1990s] [but that was our high point, even beating Oxford one year],
>> and of
>> course many of them went into IT as a career.  They found NP-completeness
>> much harder than UTMs, HP and related stuff.
>>
>>      [The code G12FCO means G1 -- maths, 2 -- second year, FCO -- Formal
>> Computation.]
>>
>
> 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.
>

No, it matches (B) unless H will NEVER abort its simulation. This is
true because if H WILL abort its simulation, then this P will obviously
Halt when H returns 0.

Remember, H is a DEFINITE algorithm, so BY DEFINITION it WILL Either
abort this input or it won't.

If it does, then we never get to (c), because P will eventually get to (a).

If it never get there, then yes P has entered (c), but H, because it
never aborts its simulation, can never answer 0, so fails to be a decider.

Only by LYING by claiming that H won't abort, to claim (c) and then
aborting can you INCORRRECTLY, and by UNSOUND logic, claim that H was
correct.

On 5/29/2022 4:34 AM, Malcolm McLean wrote:
> On Sunday, 29 May 2022 at 03:43:14 UTC+1, olcott wrote:
>> On 5/28/2022 7:22 PM, Mike Terry wrote:
>>> On 27/05/2022 22:32, Richard Damon wrote:
>>>> On 5/27/22 5:21 PM, André G. Isaak wrote:
>>>>> On 2022-05-27 14:38, olcott wrote:
>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>>>> The input to H is NOT a "sequence of configuratios", but the
>>>>>>>>>>> representation of an algorithm and its input.
>>>>>>>>>>
>>>>>>>>>> The finite string inputs to a halt decider specify (rather then
>>>>>>>>>> merely represent) a sequence of configurations that may or may
>>>>>>>>>> not reach their own final state.
>>>>>>>>>
>>>>>>>>> I really don't think you have any idea what terms like
>>>>>>>>> 'represent', 'specify', or 'sequence of configurations' mean.
>>>>>>>>> Richard is perfectly correct. You, as usual, are not.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The distinction that I make between represent and specify is that
>>>>>>>> the x86 source-code for P represents P(P) whereas the actual
>>>>>>>> correct x86 emulation of the input to H(P,P) specifies the actual
>>>>>>>> behavior of this input. This is not the same behavior as the
>>>>>>>> behavior specified by P(P).
>>>>>>>>
>>>>>>>> A sequence of configurations means a list of x86 program steps
>>>>>>>> executed or emulated in the order that their source-code specifies.
>>>>>>>>
>>>>>>>> Likewise with a TM or the UTM simulation of a TM description
>>>>>>>> specifies a sequence of state transitions.
>>>>>>>
>>>>>>> And this decidedly is *not* what a halt decider is given as its
>>>>>>> input. It is not given a sequence of state transitions. It is given
>>>>>>> a representation of a computation.
>>>>>>>
>>>>>>
>>>>>> No it is not and you know that it is not. A halt decider is given a
>>>>>> finite string TM description that specifies a sequence of
>>>>>> configurations.
>>>>>
>>>>> A TM description and a sequence of configurations are entirely
>>>>> different things (and the former certainly does not 'specify' the
>>>>> latter). It's given either one or the other. Make up your mind.
>>>>>
>>>>> André
>>>>>
>>>>
>>>> Well, a TM description, and a description of an input to that TM, does
>>>> specify a "sequence of configurations" based on what running that TM
>>>> on that input would do.
>>>
>>> "Specify" is not the word I'd use. (If I write a shopping list I
>>> specify what I'm going to get when I go shopping: one loaf of bread and
>>> 4oz jar of strawberry jam. I don't write various clues which can
>>> together be used to generate what I want by applying some algorithm.)
>>>
>>> For your scenario, "determine" seems accurate. But PO also says that
>>> P(P) "specifies non-halting behaviour", and that computation halts. I
>>> think that this use just means "matches PO's abort test".
>>>
>> I never said that: "P(P) specifies non-halting behaviour".
>> Your term "determine" is better than my term "specify".
>>
> In Linz's system, a Turing machine which is purportedly a halt decider reads
> the description of another machine, together with the input to that
> machine.
> In PO's system, a fucntion works on the physical machine code which is the
> "machine" under test. The most important difference is that there is no
> dustinction between H and the representation of H embedded in H_Hat.
> They are the identical transistors that hold the machine code of H.
>
> This isn't really important, but it means that terminology can get confused.
>

Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would reach its own final
state of ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩.

Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would never reach its own
final state of ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩.

Makes the behavior of the emulated input to H(P,P) the same as the
behavior of the simulated input to H ⟨Ĥ⟩ ⟨Ĥ⟩.

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 5/29/22 10:07 AM, olcott wrote:
> On 5/29/2022 4:34 AM, Malcolm McLean wrote:
>> On Sunday, 29 May 2022 at 03:43:14 UTC+1, olcott wrote:
>>> On 5/28/2022 7:22 PM, Mike Terry wrote:
>>>> On 27/05/2022 22:32, Richard Damon wrote:
>>>>> On 5/27/22 5:21 PM, André G. Isaak wrote:
>>>>>> On 2022-05-27 14:38, olcott wrote:
>>>>>>> On 5/27/2022 3:06 PM, André G. Isaak wrote:
>>>>>>>> On 2022-05-27 13:41, olcott wrote:
>>>>>>>>> On 5/27/2022 2:10 PM, André G. Isaak wrote:
>>>>>>>>>> On 2022-05-27 13:01, olcott wrote:
>>>>>>>>>>> On 5/27/2022 1:57 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>>>> The input to H is NOT a "sequence of configuratios", but the
>>>>>>>>>>>> representation of an algorithm and its input.
>>>>>>>>>>>
>>>>>>>>>>> The finite string inputs to a halt decider specify (rather then
>>>>>>>>>>> merely represent) a sequence of configurations that may or may
>>>>>>>>>>> not reach their own final state.
>>>>>>>>>>
>>>>>>>>>> I really don't think you have any idea what terms like
>>>>>>>>>> 'represent', 'specify', or 'sequence of configurations' mean.
>>>>>>>>>> Richard is perfectly correct. You, as usual, are not.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The distinction that I make between represent and specify is that
>>>>>>>>> the x86 source-code for P represents P(P) whereas the actual
>>>>>>>>> correct x86 emulation of the input to H(P,P) specifies the actual
>>>>>>>>> behavior of this input. This is not the same behavior as the
>>>>>>>>> behavior specified by P(P).
>>>>>>>>>
>>>>>>>>> A sequence of configurations means a list of x86 program steps
>>>>>>>>> executed or emulated in the order that their source-code
>>>>>>>>> specifies.
>>>>>>>>>
>>>>>>>>> Likewise with a TM or the UTM simulation of a TM description
>>>>>>>>> specifies a sequence of state transitions.
>>>>>>>>
>>>>>>>> And this decidedly is *not* what a halt decider is given as its
>>>>>>>> input. It is not given a sequence of state transitions. It is given
>>>>>>>> a representation of a computation.
>>>>>>>>
>>>>>>>
>>>>>>> No it is not and you know that it is not. A halt decider is given a
>>>>>>> finite string TM description that specifies a sequence of
>>>>>>> configurations.
>>>>>>
>>>>>> A TM description and a sequence of configurations are entirely
>>>>>> different things (and the former certainly does not 'specify' the
>>>>>> latter). It's given either one or the other. Make up your mind.
>>>>>>
>>>>>> André
>>>>>>
>>>>>
>>>>> Well, a TM description, and a description of an input to that TM, does
>>>>> specify a "sequence of configurations" based on what running that TM
>>>>> on that input would do.
>>>>
>>>> "Specify" is not the word I'd use.  (If I write a shopping list I
>>>> specify what I'm going to get when I go shopping: one loaf of bread and
>>>> 4oz jar of strawberry jam.  I don't write various clues which can
>>>> together be used to generate what I want by applying some algorithm.)
>>>>
>>>> For your scenario, "determine" seems accurate.  But PO also says that
>>>> P(P) "specifies non-halting behaviour", and that computation halts.  I
>>>> think that this use just means "matches PO's abort test".
>>>>
>>> I never said that: "P(P) specifies non-halting behaviour".
>>> Your term "determine" is better than my term "specify".
>>>
>> In Linz's system, a Turing machine which is purportedly a halt decider
>> reads
>> the description of another machine, together with the input to that
>> machine.
>> In PO's system, a fucntion works on the physical machine code which is
>> the
>> "machine" under test. The most important difference is that there is no
>> dustinction between H and the representation of H embedded in H_Hat.
>> They are the identical transistors that hold the machine code of H.
>>
>> This isn't really important, but it means that terminology can get
>> confused.
>>
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would reach its own final
> state of ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩.

Nope, if H^ applied to <H^> would Halt.

If you want to say "Correctly Simulated", you need to use the OFFICIAL
definiton, which is if UTM applied to <H^> <H^> would halt.

Since you use an INCORRECT definition of "Correct Simualtion", you can
not make that transformation.

>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would never reach its own
> final state of ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩.
>
Nope, if H^ applied to <H^> would never halt.

If you want to say "Correctly Simulated", you need to use the OFFICIAL
definiton, which is if UTM applied to <H^> <H^> would never halt.

Since you use an INCORRECT definition of "Correct Simualtion", you can
not make that transformation.

> Makes the behavior of the emulated input to H(P,P) the same as the
> behavior of the simulated input to H ⟨Ĥ⟩ ⟨Ĥ⟩.
>

But you don't use the actual correct definition of "correctly
simulated", sp you can use that.

You actually need to use P(P), not "correctly simulated" since your
co"correctly simulated" is not actually correctly simulated.

You have given your meaning of "Correctly Simulated", and for YOUR
definiton, the conversion of Direct Exectution to Correct Simulation
does not apply, so you can not make the transformation.

One problem about stipulating meaning for official terms is you lose the
official aspects of those terms.

Since you "Correct Simulation" is not long identical to the simulation
by a UTM, you can't make the transformation.

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

BUNCH OF LIES.