When we examine pages 4 and 5 and hypothesize
that H is merely a pure simulator we can see
that when P calls H at its machine address 0xc41
that this **is** infinitely nested simulation
such that P never reaches its final state.

The only other possibility is that H is a halt
decider that aborts its simulation of P at the
machine address 0xc41 of P. In this case P also
never reaches is final state at machine address
0xc50. Thus in every possibility P never reaches
its final state and thus never halts.

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

--
Copyright 2021 Pete Olcott

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

On Sunday, 31 October 2021 at 10:45:03 UTC+8, olcott wrote:
> When we examine pages 4 and 5 and hypothesize
> that H is merely a pure simulator we can see
> that when P calls H at its machine address 0xc41
> that this **is** infinitely nested simulation
> such that P never reaches its final state.
>
> The only other possibility is that H is a halt
> decider that aborts its simulation of P at the
> machine address 0xc41 of P. In this case P also
> never reaches is final state at machine address
> 0xc50. Thus in every possibility P never reaches
> its final state and thus never halts.
>
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
>
> --
> Copyright 2021 Pete Olcott
>
> "Great spirits have always encountered violent opposition from mediocre
> minds." Einstein

P exists only after the existence of H. No H, no P.
Your H is specific for some 'P' already existent before H.
Your understanding and implement are not what you think.

GUR dictates that:
....
No function f can decide the property of another function g that g can defy.
GUR(v4) https://groups.google.com/g/comp.theory/c/_tbCYyMox9M
....

On 10/30/21 10:44 PM, olcott wrote:
> When we examine pages 4 and 5 and hypothesize
> that H is merely a pure simulator we can see
> that when P calls H at its machine address 0xc41
> that this **is** infinitely nested simulation
> such that P never reaches its final state.
>
> The only other possibility is that H is a halt
> decider that aborts its simulation of P at the
> machine address 0xc41 of P. In this case P also
> never reaches is final state at machine address
> 0xc50. Thus in every possibility P never reaches
> its final state and thus never halts.
>
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
>

Yes, if H IS a 'pure simulator', then H^/P will be non-halting. But H
doesn't get this case right, as H never answers.

This fact ONLY applies if H is actually a Pure Simulator, and in no
other case.

In your second case, yes, the partial simulation by H of P does not
reach a halting state, but that does NOT show that P is non-halting, to
claim it does is a logical failicy.

We do see that if H aborts its simulation of a copy of P and returns
non-halting, then another copy of P that uses a copy of this H will get
that non-halting answer and then Halt, showing us that P(P) is actually
a Halting Computation.

You mistaken claim that a partial simulation shows non-halting or that
you can use different Hs when running P by itself vs what the halt
decider is.

Note, your claim that you can replace the simulation of a machine with
the direct execution of that machine ONLY applies if the simulation is
truely 'pure' or never aborted, so using that model implies that H can
only be that real pure simulator that we have shown never answers H(P,P)
and thus fails to meet the basic requirements of a halt decider.

The transform does NOT apply to a 'pure simulator until...' machine.

On 10/30/2021 11:01 PM, wij wrote:
> On Sunday, 31 October 2021 at 10:45:03 UTC+8, olcott wrote:
>> When we examine pages 4 and 5 and hypothesize
>> that H is merely a pure simulator we can see
>> that when P calls H at its machine address 0xc41
>> that this **is** infinitely nested simulation
>> such that P never reaches its final state.
>>
>> The only other possibility is that H is a halt
>> decider that aborts its simulation of P at the
>> machine address 0xc41 of P. In this case P also
>> never reaches is final state at machine address
>> 0xc50. Thus in every possibility P never reaches
>> its final state and thus never halts.
>>
>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>
>>
>> --
>> Copyright 2021 Pete Olcott
>>
>> "Great spirits have always encountered violent opposition from mediocre
>> minds." Einstein
>
> P exists only after the existence of H. No H, no P.
> Your H is specific for some 'P' already existent before H.
> Your understanding and implement are not what you think.
>
> GUR dictates that:
> ...
> No function f can decide the property of another function g that g can defy.
> GUR(v4) https://groups.google.com/g/comp.theory/c/_tbCYyMox9M
> ...
>

I show all of the details of how we can know that when H(P,P) does not
abort its simulation of its input then its input never reaches its final
state. We can also see that its input never reaches its final state even
if H(P,P) aborts its input therefore we can know that under all possible
conditions the input to H(P,P) does not halt.

You have to exactly look at pages 4 and 5 to see this:
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

--
Copyright 2021 Pete Olcott

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

On 10/31/2021 6:00 AM, Richard Damon wrote:
>
> On 10/30/21 10:44 PM, olcott wrote:
>> When we examine pages 4 and 5 and hypothesize
>> that H is merely a pure simulator we can see
>> that when P calls H at its machine address 0xc41
>> that this **is** infinitely nested simulation
>> such that P never reaches its final state.
>>
>> The only other possibility is that H is a halt
>> decider that aborts its simulation of P at the
>> machine address 0xc41 of P. In this case P also
>> never reaches is final state at machine address
>> 0xc50. Thus in every possibility P never reaches
>> its final state and thus never halts.
>>
>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>
>>
>
> Yes, if H IS a 'pure simulator', then H^/P will be non-halting. But H
> doesn't get this case right, as H never answers.
>
> This fact ONLY applies if H is actually a Pure Simulator, and in no
> other case.
>

// Simplified Linz Ĥ (Linz:1990:319)
// Strachey(1965) CPL translated to C
void P(u32 x)
{ if (H(x, x))
HERE: goto HERE;
}

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

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

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

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00000c56][0010172a][00000000] 55 push ebp
[00000c57][0010172a][00000000] 8bec mov ebp,esp
[00000c59][00101726][00000c36] 68360c0000 push 00000c36 // push P
[00000c5e][00101722][00000c36] 68360c0000 push 00000c36 // push P
[00000c63][0010171e][00000c68] e8fefcffff call 00000966 // call H(P,P)

Begin Local Halt Decider Simulation at Machine Address:c36
[00000c36][002117ca][002117ce] 55 push ebp
[00000c37][002117ca][002117ce] 8bec mov ebp,esp
[00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08]
[00000c3c][002117c6][00000c36] 50 push eax // push P
[00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][002117c2][00000c36] 51 push ecx // push P
[00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P)

[00000c36][0025c1f2][0025c1f6] 55 push ebp
[00000c37][0025c1f2][0025c1f6] 8bec mov ebp,esp
[00000c39][0025c1f2][0025c1f6] 8b4508 mov eax,[ebp+08]
[00000c3c][0025c1ee][00000c36] 50 push eax // push P
[00000c3d][0025c1ee][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][0025c1ea][00000c36] 51 push ecx // push P
[00000c41][0025c1e6][00000c46] e820fdffff call 00000966 // call H(P,P)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

The input to H(P,P) never reaches its final state at its machine address
0xc50 whether or not H(P,P) aborts the simulation of this input
therefore we can definitely conclude that the input to H(P,P) never halts.

> In your second case, yes, the partial simulation by H of P does not
> reach a halting state, but that does NOT show that P is non-halting, to
> claim it does is a logical failicy.
>

If we examine every possible case and find that the input to H(P,P)
never reaches its final state in any of them then it is necessarily true
that the input to H(P,P) never halts.

> We do see that if H aborts its simulation of a copy of P and returns
> non-halting, then another copy of P that uses a copy of this H will get
> that non-halting answer and then Halt,

Not in the above case.

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

H(P,P) is simulating its input. P invokes another instance of H to
simulate itself. When this second P is about to invoke another instance
of H, the outermost H aborts its outermost P thus terminating the entire
simulation hierarchy.

So the question comes down to this:
(a) If H(P,P) never aborts the simulation of its input then its input
never reaches its final state.
(b) If H(P,P) aborts the simulation of its input then its input never
reaches its final state.

If H aborts the simulation of its input then the whole simulation
hierarchy has been aborted because the whole simulation hierarchy
depends on the execution of the outermost P.

> showing us that P(P) is actually
> a Halting Computation.
>
> You mistaken claim that a partial simulation shows non-halting or that
> you can use different Hs when running P by itself vs what the halt
> decider is.
>

I have shown that the input to H(P,P) never reaches its final state in
every possible case therefore it is necessarily correct that the input
to H(P,P) never halts.

> Note, your claim that you can replace the simulation of a machine with
> the direct execution of that machine ONLY applies if the simulation is
> truely 'pure' or never aborted, so using that model implies that H can
> only be that real pure simulator that we have shown never answers H(P,P)
> and thus fails to meet the basic requirements of a halt decider.
>
> The transform does NOT apply to a 'pure simulator until...' machine.

--
Copyright 2021 Pete Olcott

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

olcott <NoOne@NoWhere.com> writes:

> The only other possibility is that H is a halt
> decider that aborts its simulation of P at the
> machine address 0xc41 of P. In this case P also
> never reaches is final state at machine address
> 0xc50. Thus in every possibility P never reaches
> its final state and thus never halts.

So having lost the argument in relation to Turing machines, you have
returned to your hidden code that gets the wrong answer? Or do you now
accept that H(P,P) == false is wrong if P(P) halts? To get any traction
you really do have to admit that defining the wrong answer to be the
right one simply did not cut it!

By playing tricks (which will remain as hidden as your code) you can
arrange for H(P,P) == true when P(P) halts which would be a welcome
change of heart.

--
Ben.

On Sunday, 31 October 2021 at 22:14:07 UTC+8, olcott wrote:
> On 10/30/2021 11:01 PM, wij wrote:
> > On Sunday, 31 October 2021 at 10:45:03 UTC+8, olcott wrote:
> >> When we examine pages 4 and 5 and hypothesize
> >> that H is merely a pure simulator we can see
> >> that when P calls H at its machine address 0xc41
> >> that this **is** infinitely nested simulation
> >> such that P never reaches its final state.
> >>
> >> The only other possibility is that H is a halt
> >> decider that aborts its simulation of P at the
> >> machine address 0xc41 of P. In this case P also
> >> never reaches is final state at machine address
> >> 0xc50. Thus in every possibility P never reaches
> >> its final state and thus never halts.
> >>
> >> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
> >>
> >>
> >> --
> >> Copyright 2021 Pete Olcott
> >>
> >> "Great spirits have always encountered violent opposition from mediocre
> >> minds." Einstein
> >
> > P exists only after the existence of H. No H, no P.
> > Your H is specific for some 'P' already existent before H.
> > Your understanding and implement are not what you think.
> >
> > GUR dictates that:
> > ...
> > No function f can decide the property of another function g that g can defy.
> > GUR(v4) https://groups.google.com/g/comp.theory/c/_tbCYyMox9M
> > ...
> >
> I show all of the details of how we can know that when H(P,P) does not
> abort its simulation of its input then its input never reaches its final
> state. We can also see that its input never reaches its final state even
> if H(P,P) aborts its input therefore we can know that under all possible
> conditions the input to H(P,P) does not halt.
>
> You have to exactly look at pages 4 and 5 to see this:
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
> --
> Copyright 2021 Pete Olcott
>
> "Great spirits have always encountered violent opposition from mediocre
> minds." Einstein

On page 4:
The word 'partial' in the title "Simulating partial halt decider H correctly decides that P(P) never halts (V1)" bugged me.

On page 5:
1. Your H does not actually take any 'given input'.
2. What language (or model) C, x86 assembly, or TM are you using?
None of these three languages are easy to take 'machine description' as input.
You chose a hard(impossible, by GUR) way to tackle the problem.

If I understand correctly, you seem to emphasize the fact that H can correctly
decide whether its P will halt or not. I have no doubt of your case.
But, for the conventional HP, P does not exist before H is created. Hard coding
P into H is simply wrong. It is not a decider of any given real program.

On 10/31/2021 10:11 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> The only other possibility is that H is a halt
>> decider that aborts its simulation of P at the
>> machine address 0xc41 of P. In this case P also
>> never reaches is final state at machine address
>> 0xc50. Thus in every possibility P never reaches
>> its final state and thus never halts.
>
> So having lost the argument in relation to Turing machines, you have
> returned to your hidden code that gets the wrong answer?

(1) I haven't lost the argument on Turing Machines.

(2) I conclusively prove that the input to H(P,P) never halts in
Message-ID: <hIednR1p-IK1NuP8nZ2dnUU7-ePNnZ2d@giganews.com>
Giganews posted this message to other groups and skipped itself.

> Or do you now
> accept that H(P,P) == false is wrong if P(P) halts? To get any traction
> you really do have to admit that defining the wrong answer to be the
> right one simply did not cut it!
>
> By playing tricks (which will remain as hidden as your code) you can
> arrange for H(P,P) == true when P(P) halts which would be a welcome
> change of heart.
>

// Simplified Linz Ĥ (Linz:1990:319)
// Strachey(1965) CPL translated to C
void P(u32 x)
{ if (H(x, x))
HERE: goto HERE;
}

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

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

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

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00000c56][0010172a][00000000] 55 push ebp
[00000c57][0010172a][00000000] 8bec mov ebp,esp
[00000c59][00101726][00000c36] 68360c0000 push 00000c36 // push P
[00000c5e][00101722][00000c36] 68360c0000 push 00000c36 // push P
[00000c63][0010171e][00000c68] e8fefcffff call 00000966 // call H(P,P)

Begin Local Halt Decider Simulation at Machine Address:c36
[00000c36][002117ca][002117ce] 55 push ebp
[00000c37][002117ca][002117ce] 8bec mov ebp,esp
[00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08]
[00000c3c][002117c6][00000c36] 50 push eax // push P
[00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][002117c2][00000c36] 51 push ecx // push P
[00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P)

[00000c36][0025c1f2][0025c1f6] 55 push ebp
[00000c37][0025c1f2][0025c1f6] 8bec mov ebp,esp
[00000c39][0025c1f2][0025c1f6] 8b4508 mov eax,[ebp+08]
[00000c3c][0025c1ee][00000c36] 50 push eax // push P
[00000c3d][0025c1ee][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][0025c1ea][00000c36] 51 push ecx // push P
[00000c41][0025c1e6][00000c46] e820fdffff call 00000966 // call H(P,P)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

The above is from pages 4 and 5 of this paper:
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

There are no tricks. There are only two possible cases:
(1) H(P,P) aborts its simulation and P never reaches its final state at
0xc50

(2) H(P,P) does not abort its simulation and P never reaches its final
state at 0xc50

Therefore when H(P,P) decides that its input never halts H is
necessarily correct.

--
Copyright 2021 Pete Olcott

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

olcott <NoOne@NoWhere.com> writes:

> I show all of the details of how we can know that when H(P,P) does not
> abort its simulation of its input then its input never reaches its
> final state.

That's a teeny, tiny fib, isn't it, because you don't show /all/ the
details. The most important details -- in the code for H -- are going
to remain hidden forever.

--
Ben.

On 10/31/2021 10:47 AM, wij wrote:
> On Sunday, 31 October 2021 at 22:14:07 UTC+8, olcott wrote:
>> On 10/30/2021 11:01 PM, wij wrote:
>>> On Sunday, 31 October 2021 at 10:45:03 UTC+8, olcott wrote:
>>>> When we examine pages 4 and 5 and hypothesize
>>>> that H is merely a pure simulator we can see
>>>> that when P calls H at its machine address 0xc41
>>>> that this **is** infinitely nested simulation
>>>> such that P never reaches its final state.
>>>>
>>>> The only other possibility is that H is a halt
>>>> decider that aborts its simulation of P at the
>>>> machine address 0xc41 of P. In this case P also
>>>> never reaches is final state at machine address
>>>> 0xc50. Thus in every possibility P never reaches
>>>> its final state and thus never halts.
>>>>
>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>
>>>>
>>>> --
>>>> Copyright 2021 Pete Olcott
>>>>
>>>> "Great spirits have always encountered violent opposition from mediocre
>>>> minds." Einstein
>>>
>>> P exists only after the existence of H. No H, no P.
>>> Your H is specific for some 'P' already existent before H.
>>> Your understanding and implement are not what you think.
>>>
>>> GUR dictates that:
>>> ...
>>> No function f can decide the property of another function g that g can defy.
>>> GUR(v4) https://groups.google.com/g/comp.theory/c/_tbCYyMox9M
>>> ...
>>>
>> I show all of the details of how we can know that when H(P,P) does not
>> abort its simulation of its input then its input never reaches its final
>> state. We can also see that its input never reaches its final state even
>> if H(P,P) aborts its input therefore we can know that under all possible
>> conditions the input to H(P,P) does not halt.
>>
>> You have to exactly look at pages 4 and 5 to see this:
>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>
>> --
>> Copyright 2021 Pete Olcott
>>
>> "Great spirits have always encountered violent opposition from mediocre
>> minds." Einstein
>
> On page 4:
> The word 'partial' in the title "Simulating partial halt decider H correctly decides that P(P) never halts (V1)" bugged me.
>

The "partial" halt decider takes every COFF object file that has
been generated by the Microsoft C compiler. There are a limited
number of non-halting behavior patterns that H can recognize.

As soon as it recognizes one of these patterns in its simulated input
it aborts the simulation of this input and reports non-halting. H
merely waits for its input to halt in all other cases. Some of these
cases are inputs that never halt where it does not recognize the
non-halting behavior pattern.

> On page 5:
> 1. Your H does not actually take any 'given input'.
> 2. What language (or model) C, x86 assembly, or TM are you using?
> None of these three languages are easy to take 'machine description' as input.
> You chose a hard(impossible, by GUR) way to tackle the problem.
>
> If I understand correctly, you seem to emphasize the fact that H can correctly
> decide whether its P will halt or not. I have no doubt of your case.
> But, for the conventional HP, P does not exist before H is created. Hard coding
> P into H is simply wrong. It is not a decider of any given real program.
>

H correctly decides the halt status of:
(a) Simple Infinitely nested simulation
(b) Simple Infinite recursion
(c) Simple Infinite loops

H(P,P) can see that its input never reaches its final state whether or
not H aborts the simulation of this input (thus all possible cases)
therefore H is necessarily correct when it aborts the simulation of this
input and reports non-halting.

--
Copyright 2021 Pete Olcott

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

On 10/31/2021 11:25 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> I show all of the details of how we can know that when H(P,P) does not
>> abort its simulation of its input then its input never reaches its
>> final state.
>
> That's a teeny, tiny fib, isn't it, because you don't show /all/ the
> details. The most important details -- in the code for H -- are going
> to remain hidden forever.
>

If H is a pure simulator of its input then the function call to H at the
machine address 0xc41 of P specifies infinitely nested simulation
preventing P from ever reaching its final state of machine address 0xc50.

If H aborts its simulation of P at the machine address of P of 0xc41
then P never reaches its final state of machine address 0xc50.

Therefore in all possible cases:
(a) H(P,P) aborts its simulation of its input
(b) H(P,P) does not abort its simulation of its input
P never reaches its final state at machine address 0xc50.

Details shown below:

// Simplified Linz Ĥ (Linz:1990:319)
// Strachey(1965) CPL translated to C
void P(u32 x)
{ if (H(x, x))
HERE: goto HERE;
}

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

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

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

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00000c56][0010172a][00000000] 55 push ebp
[00000c57][0010172a][00000000] 8bec mov ebp,esp
[00000c59][00101726][00000c36] 68360c0000 push 00000c36 // push P
[00000c5e][00101722][00000c36] 68360c0000 push 00000c36 // push P
[00000c63][0010171e][00000c68] e8fefcffff call 00000966 // call H(P,P)

Begin Local Halt Decider Simulation at Machine Address:c36
[00000c36][002117ca][002117ce] 55 push ebp
[00000c37][002117ca][002117ce] 8bec mov ebp,esp
[00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08]
[00000c3c][002117c6][00000c36] 50 push eax // push P
[00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][002117c2][00000c36] 51 push ecx // push P
[00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P)

[00000c36][0025c1f2][0025c1f6] 55 push ebp
[00000c37][0025c1f2][0025c1f6] 8bec mov ebp,esp
[00000c39][0025c1f2][0025c1f6] 8b4508 mov eax,[ebp+08]
[00000c3c][0025c1ee][00000c36] 50 push eax // push P
[00000c3d][0025c1ee][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][0025c1ea][00000c36] 51 push ecx // push P
[00000c41][0025c1e6][00000c46] e820fdffff call 00000966 // call H(P,P)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

--
Copyright 2021 Pete Olcott

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

On 31/10/2021 15:51, olcott wrote:
> On 10/31/2021 10:11 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> The only other possibility is that H is a halt
>>> decider that aborts its simulation of P at the
>>> machine address 0xc41 of P. In this case P also
>>> never reaches is final state at machine address
>>> 0xc50. Thus in every possibility P never reaches
>>> its final state and thus never halts.
>>
>> So having lost the argument in relation to Turing machines, you have
>> returned to your hidden code that gets the wrong answer?
>
> (1) I haven't lost the argument on Turing Machines.
>
> (2) I conclusively prove that the input to H(P,P) never halts in
> Message-ID: <hIednR1p-IK1NuP8nZ2dnUU7-ePNnZ2d@giganews.com>
> Giganews posted this message to other groups and skipped itself.
>

Ignoring the blatent false claim that you have proved anything, you have
fallen foul of the Giganews "delayed publishing" feature/bug. (That's
my name for it.)

This isn't a rare event, I'd say anything from 5%-40% of articles hit
this problem. What happens is that Giganews receives an article and
assigns article numbers for it, in its normal sequence for the groups.
Then Giganews decides "hey, I'm not going to "publish" that article for
a few hours!" So the article id is skipped in NNTP responses that list
article ids and doesn't appear in news readers. Most often I notice
this when I see responses to articles that haven't appeared.

A few hours later, Giganews decides "hey, I think I've pissed off my
paying customers enough now, so I'll finally "publish" that old article
I received". At this point it starts listing the article id in group
listings so that news reader clients pick it up. (Except that by now
many clients may have just decided the article id is simply invalid, and
may never retrieve it, and even if they do retrieve it, there may well
have been "mysterious" responses to it retrieved out of order.)

I've not seen any of the free news servers behaving like this, so what
does that say about Giganews?

Anyway I predict your post will mysteriously appear in a few hours time.
We'll see. (On my Giganews server your article appears to have been
allocated id 107792 but hasn't been "published" as such yet. Grr.)

Mike.

On 10/31/2021 11:48 AM, Mike Terry wrote:
> On 31/10/2021 15:51, olcott wrote:
>> On 10/31/2021 10:11 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> The only other possibility is that H is a halt
>>>> decider that aborts its simulation of P at the
>>>> machine address 0xc41 of P. In this case P also
>>>> never reaches is final state at machine address
>>>> 0xc50. Thus in every possibility P never reaches
>>>> its final state and thus never halts.
>>>
>>> So having lost the argument in relation to Turing machines, you have
>>> returned to your hidden code that gets the wrong answer?
>>
>> (1) I haven't lost the argument on Turing Machines.
>>
>> (2) I conclusively prove that the input to H(P,P) never halts in
>> Message-ID: <hIednR1p-IK1NuP8nZ2dnUU7-ePNnZ2d@giganews.com>
>> Giganews posted this message to other groups and skipped itself.
>>
>
> Ignoring the blatent false claim that you have proved anything,

That you simply ignore my proof does not actually count as any rebuttal
at all. Because of my poor communication skills I can see immediately
when I have proved my claim, yet it takes many many iterations of review
until I can finally find clear enough words so that others can also see
that I proved my claim.

I have just now proved that the input to H(P,P) never halts using clear
enough words that are backed up my code. I am not going to repeat that
proof here.

you have
> fallen foul of the Giganews "delayed publishing" feature/bug.  (That's
> my name for it.)
>
> This isn't a rare event, I'd say anything from 5%-40% of articles hit
> this problem.  What happens is that Giganews receives an article and
> assigns article numbers for it, in its normal sequence for the groups.
> Then Giganews decides "hey, I'm not going to "publish" that article for
> a few hours!"  So the article id is skipped in NNTP responses that list
> article ids and doesn't appear in news readers.  Most often I notice
> this when I see responses to articles that haven't appeared.
>
> A few hours later, Giganews decides "hey, I think I've pissed off my
> paying customers enough now, so I'll finally "publish" that old article
> I received".  At this point it starts listing the article id in group
> listings so that news reader clients pick it up.  (Except that by now
> many clients may have just decided the article id is simply invalid, and
> may never retrieve it, and even if they do retrieve it, there may well
> have been "mysterious" responses to it retrieved out of order.)
>
> I've not seen any of the free news servers behaving like this, so what
> does that say about Giganews?
>
> Anyway I predict your post will mysteriously appear in a few hours time.
>  We'll see.  (On my Giganews server your article appears to have been
> allocated id 107792 but hasn't been "published" as such yet. Grr.)
>
> Mike.

The weird (and good) aspect of this is that they show up right away in
other groups when posted to Giganews. I contacted them about this issue.

--
Copyright 2021 Pete Olcott

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

On 10/31/21 10:41 AM, olcott wrote:
> On 10/31/2021 6:00 AM, Richard Damon wrote:
>>
>> On 10/30/21 10:44 PM, olcott wrote:
>>> When we examine pages 4 and 5 and hypothesize
>>> that H is merely a pure simulator we can see
>>> that when P calls H at its machine address 0xc41
>>> that this **is** infinitely nested simulation
>>> such that P never reaches its final state.
>>>
>>> The only other possibility is that H is a halt
>>> decider that aborts its simulation of P at the
>>> machine address 0xc41 of P. In this case P also
>>> never reaches is final state at machine address
>>> 0xc50. Thus in every possibility P never reaches
>>> its final state and thus never halts.
>>>
>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>
>>>
>>
>> Yes, if H IS a 'pure simulator', then H^/P will be non-halting. But H
>> doesn't get this case right, as H never answers.
>>
>> This fact ONLY applies if H is actually a Pure Simulator, and in no
>> other case.
>>
>
> // Simplified Linz Ĥ (Linz:1990:319)
> // Strachey(1965) CPL translated to C
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H((u32)P, (u32)P));
> }
>
> _P()
> [00000c36](01)  55          push ebp
> [00000c37](02)  8bec        mov ebp,esp
> [00000c39](03)  8b4508      mov eax,[ebp+08] // 2nd Param
> [00000c3c](01)  50          push eax
> [00000c3d](03)  8b4d08      mov ecx,[ebp+08] // 1st Param
> [00000c40](01)  51          push ecx
> [00000c41](05)  e820fdffff  call 00000966    // call H
> [00000c46](03)  83c408      add esp,+08
> [00000c49](02)  85c0        test eax,eax
> [00000c4b](02)  7402        jz 00000c4f
> [00000c4d](02)  ebfe        jmp 00000c4d
> [00000c4f](01)  5d          pop ebp
> [00000c50](01)  c3          ret
> Size in bytes:(0027) [00000c50]
>
> _main()
> [00000c56](01)  55          push ebp
> [00000c57](02)  8bec        mov ebp,esp
> [00000c59](05)  68360c0000  push 00000c36    // push P
> [00000c5e](05)  68360c0000  push 00000c36    // push P
> [00000c63](05)  e8fefcffff  call 00000966    // call H(P,P)
> [00000c68](03)  83c408      add esp,+08
> [00000c6b](01)  50          push eax
> [00000c6c](05)  6857030000  push 00000357
> [00000c71](05)  e810f7ffff  call 00000386
> [00000c76](03)  83c408      add esp,+08
> [00000c79](02)  33c0        xor eax,eax
> [00000c7b](01)  5d          pop ebp
> [00000c7c](01)  c3          ret
> Size in bytes:(0039) [00000c7c]
>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> [00000c56][0010172a][00000000] 55          push ebp
> [00000c57][0010172a][00000000] 8bec        mov ebp,esp
> [00000c59][00101726][00000c36] 68360c0000  push 00000c36 // push P
> [00000c5e][00101722][00000c36] 68360c0000  push 00000c36 // push P
> [00000c63][0010171e][00000c68] e8fefcffff  call 00000966 // call H(P,P)
>
> Begin Local Halt Decider Simulation at Machine Address:c36
> [00000c36][002117ca][002117ce] 55          push ebp
> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
> [00000c3c][002117c6][00000c36] 50          push eax       // push P
> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
> [00000c40][002117c2][00000c36] 51          push ecx       // push P
> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call H(P,P)
>
> [00000c36][0025c1f2][0025c1f6] 55          push ebp
> [00000c37][0025c1f2][0025c1f6] 8bec        mov ebp,esp
> [00000c39][0025c1f2][0025c1f6] 8b4508      mov eax,[ebp+08]
> [00000c3c][0025c1ee][00000c36] 50          push eax       // push P
> [00000c3d][0025c1ee][00000c36] 8b4d08      mov ecx,[ebp+08]
> [00000c40][0025c1ea][00000c36] 51          push ecx       // push P
> [00000c41][0025c1e6][00000c46] e820fdffff  call 00000966  // call H(P,P)
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> The input to H(P,P) never reaches its final state at its machine address
> 0xc50 whether or not H(P,P) aborts the simulation of this input
> therefore we can definitely conclude that the input to H(P,P) never halts.

Irrelevant.

If H does abort its simulation and return the non-halting answer then
this partial simulation is NOT proof of non-halting, and if we give this
exact same input to a real UTM we we see that the UTM's simulation does
reach a halting state.

If H doesn't abort its simulation, then H never returns an answer to the
question of H(P,P) so this H also fails to be the proper decider.

Since the defintion of the computaiton P depend on the definiton of H,
you can't mix these two cases and have sound logic.

The proper answer is NOT what the simulation in H does, but what a
simulation by a REAL UTM does. You have even said that a few times.

>
>> In your second case, yes, the partial simulation by H of P does not
>> reach a halting state, but that does NOT show that P is non-halting,
>> to claim it does is a logical failicy.
>>
>
> If we examine every possible case and find that the input to H(P,P)
> never reaches its final state in any of them then it is necessarily true
> that the input to H(P,P) never halts.

Nope. UNSOUND LOGIC.

The simulation by H is NOT the definition of the right answer, but the
simulation of that exact same input by a REAL UTM, i.e. an Unconditional
Simulator.

All that you have proved is that no H of your form can ever prove that H
is Halting, not that H is not Halting.

>
>> We do see that if H aborts its simulation of a copy of P and returns
>> non-halting, then another copy of P that uses a copy of this H will
>> get that non-halting answer and then Halt,
>
> Not in the above case.
>
> [00000c68][0010172a][00000000] 83c408      add esp,+08
> [00000c6b][00101726][00000000] 50          push eax
> [00000c6c][00101722][00000357] 6857030000  push 00000357
> [00000c71][00101722][00000357] e810f7ffff  call 00000386
> Input_Halts = 0
> [00000c76][0010172a][00000000] 83c408      add esp,+08
> [00000c79][0010172a][00000000] 33c0        xor eax,eax
> [00000c7b][0010172e][00100000] 5d          pop ebp
> [00000c7c][00101732][00000068] c3          ret
> Number_of_User_Instructions(27)
>
> H(P,P) is simulating its input. P invokes another instance of H to
> simulate itself. When this second P is about to invoke another instance
> of H, the outermost H aborts its outermost P thus terminating the entire
> simulation hierarchy.
>
> So the question comes down to this:
> (a) If H(P,P) never aborts the simulation of its input then its input
> never reaches its final state.

Bad Logic, if H is defined to actually abort the simulation at this
point, asking about what happens if it did something different is
irrelevent.

> (b) If H(P,P) aborts the simulation of its input then its input never
> reaches its final state.

And there is nothing wrong with an aborted simulation never getting to a
fianl halting state. That does NOT show that an unaborted simulation by
a real UTM of this exact same input would not halt.

Your (a) case is NOT that, because you change the global defintion of H
which changed the machine being decided.

All you have shown is that Ha, the H that aborts its simulation, can
correctly decide that Pn(Pn) based on the Hn that doesn't abort its
simulation doesn't halt

THis says NOTHING about the Pa that it needs to get right to counter Linz.

>
> If H aborts the simulation of its input then the whole simulation
> hierarchy has been aborted because the whole simulation hierarchy
> depends on the execution of the outermost P.

An H that abort can only abort the simulations that it is doing, is can
NOT abort any machine that it is part of. To do that means it fails to
be a computation that answers the question it was given.

Thus, the P (P) that calls H(P,P) can be correctly proved to Halt if we
can show that H(P,P) returns non-halting, and because of that, we can
show that H geve the WRONG answer.

On 10/31/21 11:51 AM, olcott wrote:
> On 10/31/2021 10:11 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> The only other possibility is that H is a halt
>>> decider that aborts its simulation of P at the
>>> machine address 0xc41 of P. In this case P also
>>> never reaches is final state at machine address
>>> 0xc50. Thus in every possibility P never reaches
>>> its final state and thus never halts.
>>
>> So having lost the argument in relation to Turing machines, you have
>> returned to your hidden code that gets the wrong answer?
>
> (1) I haven't lost the argument on Turing Machines.

Only because you haven't actually made a real arguemnt on Turing Machines.

>
> (2) I conclusively prove that the input to H(P,P) never halts in
> Message-ID: <hIednR1p-IK1NuP8nZ2dnUU7-ePNnZ2d@giganews.com>
> Giganews posted this message to other groups and skipped itself.

Except that is a meaningless statement.

'Inputs' don't halt. Machines Halt.

When the input <H^><H^> is given to a UTM, that computation Halts, which
is one of the ways to look at the definition of the Halting Problem.

Yes, H's aborted simulation of <H^><H^> never reached a final halting
state, but aborted simulation NEVER, in themselves, prove non-halting
(or Halting). So you are arguing about meaningless behavior trying to
claim that it actually means something by using bad terminology.

>
>>  Or do you now
>> accept that H(P,P) == false is wrong if P(P) halts?  To get any traction
>> you really do have to admit that defining the wrong answer to be the
>> right one simply did not cut it!
>>
>> By playing tricks (which will remain as hidden as your code) you can
>> arrange for H(P,P) == true when P(P) halts which would be a welcome
>> change of heart.
>>
>
> // Simplified Linz Ĥ (Linz:1990:319)
> // Strachey(1965) CPL translated to C
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H((u32)P, (u32)P));
> }
>
> _P()
> [00000c36](01)  55          push ebp
> [00000c37](02)  8bec        mov ebp,esp
> [00000c39](03)  8b4508      mov eax,[ebp+08] // 2nd Param
> [00000c3c](01)  50          push eax
> [00000c3d](03)  8b4d08      mov ecx,[ebp+08] // 1st Param
> [00000c40](01)  51          push ecx
> [00000c41](05)  e820fdffff  call 00000966    // call H
> [00000c46](03)  83c408      add esp,+08
> [00000c49](02)  85c0        test eax,eax
> [00000c4b](02)  7402        jz 00000c4f
> [00000c4d](02)  ebfe        jmp 00000c4d
> [00000c4f](01)  5d          pop ebp
> [00000c50](01)  c3          ret
> Size in bytes:(0027) [00000c50]
>
> _main()
> [00000c56](01)  55          push ebp
> [00000c57](02)  8bec        mov ebp,esp
> [00000c59](05)  68360c0000  push 00000c36    // push P
> [00000c5e](05)  68360c0000  push 00000c36    // push P
> [00000c63](05)  e8fefcffff  call 00000966    // call H(P,P)
> [00000c68](03)  83c408      add esp,+08
> [00000c6b](01)  50          push eax
> [00000c6c](05)  6857030000  push 00000357
> [00000c71](05)  e810f7ffff  call 00000386
> [00000c76](03)  83c408      add esp,+08
> [00000c79](02)  33c0        xor eax,eax
> [00000c7b](01)  5d          pop ebp
> [00000c7c](01)  c3          ret
> Size in bytes:(0039) [00000c7c]
>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> [00000c56][0010172a][00000000] 55          push ebp
> [00000c57][0010172a][00000000] 8bec        mov ebp,esp
> [00000c59][00101726][00000c36] 68360c0000  push 00000c36 // push P
> [00000c5e][00101722][00000c36] 68360c0000  push 00000c36 // push P
> [00000c63][0010171e][00000c68] e8fefcffff  call 00000966 // call H(P,P)
>
> Begin Local Halt Decider Simulation at Machine Address:c36
> [00000c36][002117ca][002117ce] 55          push ebp
> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
> [00000c3c][002117c6][00000c36] 50          push eax       // push P
> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
> [00000c40][002117c2][00000c36] 51          push ecx       // push P
> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call H(P,P)
>
> [00000c36][0025c1f2][0025c1f6] 55          push ebp
> [00000c37][0025c1f2][0025c1f6] 8bec        mov ebp,esp
> [00000c39][0025c1f2][0025c1f6] 8b4508      mov eax,[ebp+08]
> [00000c3c][0025c1ee][00000c36] 50          push eax       // push P
> [00000c3d][0025c1ee][00000c36] 8b4d08      mov ecx,[ebp+08]
> [00000c40][0025c1ea][00000c36] 51          push ecx       // push P
> [00000c41][0025c1e6][00000c46] e820fdffff  call 00000966  // call H(P,P)
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> The above is from pages 4 and 5 of this paper:
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
>
> There are no tricks. There are only two possible cases:
> (1) H(P,P) aborts its simulation and P never reaches its final state at
> 0xc50
>
> (2) H(P,P) does not abort its simulation and P never reaches its final
> state at 0xc50
>
> Therefore when H(P,P) decides that its input never halts H is
> necessarily correct.
>

You are just arguing POOP.

The fact that H doesn't reach the halting state is irrelevent to the
halting problem.

The fact that if Main calls P(P) it will halt shows that H is wrong. PERIOD.

olcott <NoOne@NoWhere.com> writes:

> On 10/31/2021 10:11 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> The only other possibility is that H is a halt
>>> decider that aborts its simulation of P at the
>>> machine address 0xc41 of P. In this case P also
>>> never reaches is final state at machine address
>>> 0xc50. Thus in every possibility P never reaches
>>> its final state and thus never halts.
>> So having lost the argument in relation to Turing machines, you have
>> returned to your hidden code that gets the wrong answer?
>
> (1) I haven't lost the argument on Turing Machines.
>
> (2) I conclusively prove that the input to H(P,P) never halts in
> Message-ID: <hIednR1p-IK1NuP8nZ2dnUU7-ePNnZ2d@giganews.com>
> Giganews posted this message to other groups and skipped itself.

The input to H represents the computation P(P). At least up until
recently you asserted that P(P) halts and you spent a lot of time trying
to hand-wave away the wrong answer from H.

>> Or do you now
>> accept that H(P,P) == false is wrong if P(P) halts? To get any traction
>> you really do have to admit that defining the wrong answer to be the
>> right one simply did not cut it!
>> By playing tricks (which will remain as hidden as your code) you can
>> arrange for H(P,P) == true when P(P) halts which would be a welcome
>> change of heart.

> There are no tricks.

Good. That means you can't have H(P,P) == true iff P(P) halts.

> There are only two possible cases:
> (1) H(P,P) aborts its simulation and P never reaches its final state
> at 0xc50
>
> (2) H(P,P) does not abort its simulation and P never reaches its final
> state at 0xc50
>
> Therefore when H(P,P) decides that its input never halts H is
> necessarily correct.

I can see you don't want to answer. I was asking if you have changed
your mind, and I know that's very hard for someone in your position to
admit. Here's the key question: do you still assert that H(P,P) ==
false is the "correct" answer even though P(P) halts? If you won't say,
nothing you do say about what is "correct" (necessarily or otherwise) is
pointless.

Of course, it's likely you have no changed you mind and you are still
searching for words to make the wrong answer seems less obviously
wrong. Not answering my question is a key part of that strategy so I
don't expect an answer.

--
Ben.

On 10/31/2021 12:36 PM, Richard Damon wrote:
> On 10/31/21 11:51 AM, olcott wrote:
>> On 10/31/2021 10:11 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> The only other possibility is that H is a halt
>>>> decider that aborts its simulation of P at the
>>>> machine address 0xc41 of P. In this case P also
>>>> never reaches is final state at machine address
>>>> 0xc50. Thus in every possibility P never reaches
>>>> its final state and thus never halts.
>>>
>>> So having lost the argument in relation to Turing machines, you have
>>> returned to your hidden code that gets the wrong answer?
>>
>> (1) I haven't lost the argument on Turing Machines.
>
> Only because you haven't actually made a real arguemnt on Turing Machines.
>
>>
>> (2) I conclusively prove that the input to H(P,P) never halts in
>> Message-ID: <hIednR1p-IK1NuP8nZ2dnUU7-ePNnZ2d@giganews.com>
>> Giganews posted this message to other groups and skipped itself.
>
> Except that is a meaningless statement.
>
> 'Inputs' don't halt. Machines Halt.
>
> When the input <H^><H^> is given to a UTM, that computation Halts, which
> is one of the ways to look at the definition of the Halting Problem.
>
> Yes, H's aborted simulation of <H^><H^> never reached a final halting
> state, but aborted simulation NEVER, in themselves, prove non-halting
> (or Halting). So you are arguing about meaningless behavior trying to
> claim that it actually means something by using bad terminology.
>
>>
>>>  Or do you now
>>> accept that H(P,P) == false is wrong if P(P) halts?  To get any traction
>>> you really do have to admit that defining the wrong answer to be the
>>> right one simply did not cut it!
>>>
>>> By playing tricks (which will remain as hidden as your code) you can
>>> arrange for H(P,P) == true when P(P) halts which would be a welcome
>>> change of heart.
>>>
>>
>> // Simplified Linz Ĥ (Linz:1990:319)
>> // Strachey(1965) CPL translated to C
>> void P(u32 x)
>> {
>>    if (H(x, x))
>>      HERE: goto HERE;
>> }
>>
>> int main()
>> {
>>    Output("Input_Halts = ", H((u32)P, (u32)P));
>> }
>>
>> _P()
>> [00000c36](01)  55          push ebp
>> [00000c37](02)  8bec        mov ebp,esp
>> [00000c39](03)  8b4508      mov eax,[ebp+08] // 2nd Param
>> [00000c3c](01)  50          push eax
>> [00000c3d](03)  8b4d08      mov ecx,[ebp+08] // 1st Param
>> [00000c40](01)  51          push ecx
>> [00000c41](05)  e820fdffff  call 00000966    // call H
>> [00000c46](03)  83c408      add esp,+08
>> [00000c49](02)  85c0        test eax,eax
>> [00000c4b](02)  7402        jz 00000c4f
>> [00000c4d](02)  ebfe        jmp 00000c4d
>> [00000c4f](01)  5d          pop ebp
>> [00000c50](01)  c3          ret
>> Size in bytes:(0027) [00000c50]
>>
>> _main()
>> [00000c56](01)  55          push ebp
>> [00000c57](02)  8bec        mov ebp,esp
>> [00000c59](05)  68360c0000  push 00000c36    // push P
>> [00000c5e](05)  68360c0000  push 00000c36    // push P
>> [00000c63](05)  e8fefcffff  call 00000966    // call H(P,P)
>> [00000c68](03)  83c408      add esp,+08
>> [00000c6b](01)  50          push eax
>> [00000c6c](05)  6857030000  push 00000357
>> [00000c71](05)  e810f7ffff  call 00000386
>> [00000c76](03)  83c408      add esp,+08
>> [00000c79](02)  33c0        xor eax,eax
>> [00000c7b](01)  5d          pop ebp
>> [00000c7c](01)  c3          ret
>> Size in bytes:(0039) [00000c7c]
>>
>>   machine   stack     stack     machine    assembly
>>   address   address   data      code       language
>>   ========  ========  ========  =========  =============
>> [00000c56][0010172a][00000000] 55          push ebp
>> [00000c57][0010172a][00000000] 8bec        mov ebp,esp
>> [00000c59][00101726][00000c36] 68360c0000  push 00000c36 // push P
>> [00000c5e][00101722][00000c36] 68360c0000  push 00000c36 // push P
>> [00000c63][0010171e][00000c68] e8fefcffff  call 00000966 // call H(P,P)
>>
>> Begin Local Halt Decider Simulation at Machine Address:c36
>> [00000c36][002117ca][002117ce] 55          push ebp
>> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
>> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
>> [00000c3c][002117c6][00000c36] 50          push eax       // push P
>> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
>> [00000c40][002117c2][00000c36] 51          push ecx       // push P
>> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call H(P,P)
>>
>> [00000c36][0025c1f2][0025c1f6] 55          push ebp
>> [00000c37][0025c1f2][0025c1f6] 8bec        mov ebp,esp
>> [00000c39][0025c1f2][0025c1f6] 8b4508      mov eax,[ebp+08]
>> [00000c3c][0025c1ee][00000c36] 50          push eax       // push P
>> [00000c3d][0025c1ee][00000c36] 8b4d08      mov ecx,[ebp+08]
>> [00000c40][0025c1ea][00000c36] 51          push ecx       // push P
>> [00000c41][0025c1e6][00000c46] e820fdffff  call 00000966  // call H(P,P)
>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>
>> The above is from pages 4 and 5 of this paper:
>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>
>>
>> There are no tricks. There are only two possible cases:
>> (1) H(P,P) aborts its simulation and P never reaches its final state
>> at 0xc50
>>
>> (2) H(P,P) does not abort its simulation and P never reaches its final
>> state at 0xc50
>>
>> Therefore when H(P,P) decides that its input never halts H is
>> necessarily correct.
>>
>
> You are just arguing POOP.
>
> The fact that H doesn't reach the halting state is irrelevent to the
> halting problem.
>

I didn't say anything about H reaching its final state nitwit.
I didn't say anything about H reaching its final state nitwit.
I didn't say anything about H reaching its final state nitwit.
I didn't say anything about H reaching its final state nitwit.

H either aborts the simulation of its input or does not abort the
simulation of its input.

(1) H(P,P) aborts its simulation and 0xc50
P never reaches its final state at 0xc50
P never reaches its final state at 0xc50
P never reaches its final state at 0xc50
P never reaches its final state at 0xc50

(2) H(P,P) does not abort its simulation and
P never reaches its final state at 0xc50
P never reaches its final state at 0xc50
P never reaches its final state at 0xc50
P never reaches its final state at 0xc50

Therefore when H(P,P) decides that its input never halts H is
necessarily correct.

--
Copyright 2021 Pete Olcott

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

On 10/31/21 10:13 AM, olcott wrote:
> On 10/30/2021 11:01 PM, wij wrote:
>> On Sunday, 31 October 2021 at 10:45:03 UTC+8, olcott wrote:
>>> When we examine pages 4 and 5 and hypothesize
>>> that H is merely a pure simulator we can see
>>> that when P calls H at its machine address 0xc41
>>> that this **is** infinitely nested simulation
>>> such that P never reaches its final state.
>>>
>>> The only other possibility is that H is a halt
>>> decider that aborts its simulation of P at the
>>> machine address 0xc41 of P. In this case P also
>>> never reaches is final state at machine address
>>> 0xc50. Thus in every possibility P never reaches
>>> its final state and thus never halts.
>>>
>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>
>>>
>>>
>>> --
>>> Copyright 2021 Pete Olcott
>>>
>>> "Great spirits have always encountered violent opposition from mediocre
>>> minds." Einstein
>>
>> P exists only after the existence of H. No H, no P.
>> Your H is specific for some 'P' already existent before H.
>> Your understanding and implement are not what you think.
>>
>> GUR dictates that:
>> ...
>> No function f can decide the property of another function g that g can
>> defy.
>> GUR(v4) https://groups.google.com/g/comp.theory/c/_tbCYyMox9M
>> ...
>>
>
> I show all of the details of how we can know that when H(P,P) does not
> abort its simulation of its input then its input never reaches its final
> state. We can also see that its input never reaches its final state even
> if H(P,P) aborts its input therefore we can know that under all possible
> conditions the input to H(P,P) does not halt.
>
> You have to exactly look at pages 4 and 5 to see this:
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
>

Which makes the following FALSE statement:

> We do not see any of the x86 instructions of H in the above execution trace because we know that H is only acting as a pure simulator of its inputs until after it has made its halt status decision. This means that H cannot possibly have any effect on the behavior of its input during the above (execution trace / halt status analysis), thus H can safely ignore its own instructions in this halt status analysis.If

Since is H is only 'acting as a pure simulator of its input until
after..." then H is NOT actually a pure simualtor, since a pure
simulator, by definition, NEVER stops its simulation until it simulation
actually gets to a Halting state.

Since H is thus NOT a pure simulator, it is NOT true that it can ignore
the copy of itself inside the machine it is simulating.

Now, a lot of the words in the second part of this statement are just
badly stating things.

First, 'Inputs' don't have 'Behavior'. Inputs are static strings. The
input might represent a Computation, and that Computation has behavior.

It is a basic fact that NOTHING working off an input that is a
representation of something can have ANY affect on the behavior of the
Computation that the input is a representation, unless that thing
started of as part of the computation, then its behavior in that
computation of course affects the computation it is part of by what it
returns (but not by what it does to its own input).

Ultimately, we have that H(P,P) does some stuff that doesn't matter and
returns a non-halting results to its caller.

If that caller was P, then this makes P(P) a Halting Computation, thus
showing that H(P,P) was wrong.

The interesting point is that it is wrong because of that false logic
you used, and BECAUSE it is wrong, it returns the answer that allows
P(P) to be halting.

If H refused to make the wrong decision, then H will never aborts its
simulation, and thus P(P) will be non-halting, but H can't predict that
because it can never get to the point it could prove that, because if
ever it thinks it can prove it and return non-halting, by the structure
of P, H will ALWAYS be wrong, as P will Halt.

That is part of the genius of this proof, if there was some way for H to
appear to prove that it knows what its input will do, this particular
input will ALWAYS make it wrong. The only way that H can't give the
wrong answer is to not answer, but that makes it definitionally wrong
also, as it fails to meet the requirement to answer.

On 10/31/21 1:54 PM, olcott wrote:
> On 10/31/2021 12:36 PM, Richard Damon wrote:
>> On 10/31/21 11:51 AM, olcott wrote:
>>> On 10/31/2021 10:11 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> The only other possibility is that H is a halt
>>>>> decider that aborts its simulation of P at the
>>>>> machine address 0xc41 of P. In this case P also
>>>>> never reaches is final state at machine address
>>>>> 0xc50. Thus in every possibility P never reaches
>>>>> its final state and thus never halts.
>>>>
>>>> So having lost the argument in relation to Turing machines, you have
>>>> returned to your hidden code that gets the wrong answer?
>>>
>>> (1) I haven't lost the argument on Turing Machines.
>>
>> Only because you haven't actually made a real arguemnt on Turing
>> Machines.
>>
>>>
>>> (2) I conclusively prove that the input to H(P,P) never halts in
>>> Message-ID: <hIednR1p-IK1NuP8nZ2dnUU7-ePNnZ2d@giganews.com>
>>> Giganews posted this message to other groups and skipped itself.
>>
>> Except that is a meaningless statement.
>>
>> 'Inputs' don't halt. Machines Halt.
>>
>> When the input <H^><H^> is given to a UTM, that computation Halts,
>> which is one of the ways to look at the definition of the Halting
>> Problem.
>>
>> Yes, H's aborted simulation of <H^><H^> never reached a final halting
>> state, but aborted simulation NEVER, in themselves, prove non-halting
>> (or Halting). So you are arguing about meaningless behavior trying to
>> claim that it actually means something by using bad terminology.
>>
>>>
>>>>  Or do you now
>>>> accept that H(P,P) == false is wrong if P(P) halts?  To get any
>>>> traction
>>>> you really do have to admit that defining the wrong answer to be the
>>>> right one simply did not cut it!
>>>>
>>>> By playing tricks (which will remain as hidden as your code) you can
>>>> arrange for H(P,P) == true when P(P) halts which would be a welcome
>>>> change of heart.
>>>>
>>>
>>> // Simplified Linz Ĥ (Linz:1990:319)
>>> // Strachey(1965) CPL translated to C
>>> void P(u32 x)
>>> {
>>>    if (H(x, x))
>>>      HERE: goto HERE;
>>> }
>>>
>>> int main()
>>> {
>>>    Output("Input_Halts = ", H((u32)P, (u32)P));
>>> }
>>>
>>> _P()
>>> [00000c36](01)  55          push ebp
>>> [00000c37](02)  8bec        mov ebp,esp
>>> [00000c39](03)  8b4508      mov eax,[ebp+08] // 2nd Param
>>> [00000c3c](01)  50          push eax
>>> [00000c3d](03)  8b4d08      mov ecx,[ebp+08] // 1st Param
>>> [00000c40](01)  51          push ecx
>>> [00000c41](05)  e820fdffff  call 00000966    // call H
>>> [00000c46](03)  83c408      add esp,+08
>>> [00000c49](02)  85c0        test eax,eax
>>> [00000c4b](02)  7402        jz 00000c4f
>>> [00000c4d](02)  ebfe        jmp 00000c4d
>>> [00000c4f](01)  5d          pop ebp
>>> [00000c50](01)  c3          ret
>>> Size in bytes:(0027) [00000c50]
>>>
>>> _main()
>>> [00000c56](01)  55          push ebp
>>> [00000c57](02)  8bec        mov ebp,esp
>>> [00000c59](05)  68360c0000  push 00000c36    // push P
>>> [00000c5e](05)  68360c0000  push 00000c36    // push P
>>> [00000c63](05)  e8fefcffff  call 00000966    // call H(P,P)
>>> [00000c68](03)  83c408      add esp,+08
>>> [00000c6b](01)  50          push eax
>>> [00000c6c](05)  6857030000  push 00000357
>>> [00000c71](05)  e810f7ffff  call 00000386
>>> [00000c76](03)  83c408      add esp,+08
>>> [00000c79](02)  33c0        xor eax,eax
>>> [00000c7b](01)  5d          pop ebp
>>> [00000c7c](01)  c3          ret
>>> Size in bytes:(0039) [00000c7c]
>>>
>>>   machine   stack     stack     machine    assembly
>>>   address   address   data      code       language
>>>   ========  ========  ========  =========  =============
>>> [00000c56][0010172a][00000000] 55          push ebp
>>> [00000c57][0010172a][00000000] 8bec        mov ebp,esp
>>> [00000c59][00101726][00000c36] 68360c0000  push 00000c36 // push P
>>> [00000c5e][00101722][00000c36] 68360c0000  push 00000c36 // push P
>>> [00000c63][0010171e][00000c68] e8fefcffff  call 00000966 // call H(P,P)
>>>
>>> Begin Local Halt Decider Simulation at Machine Address:c36
>>> [00000c36][002117ca][002117ce] 55          push ebp
>>> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
>>> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
>>> [00000c3c][002117c6][00000c36] 50          push eax       // push P
>>> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
>>> [00000c40][002117c2][00000c36] 51          push ecx       // push P
>>> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call H(P,P)
>>>
>>> [00000c36][0025c1f2][0025c1f6] 55          push ebp
>>> [00000c37][0025c1f2][0025c1f6] 8bec        mov ebp,esp
>>> [00000c39][0025c1f2][0025c1f6] 8b4508      mov eax,[ebp+08]
>>> [00000c3c][0025c1ee][00000c36] 50          push eax       // push P
>>> [00000c3d][0025c1ee][00000c36] 8b4d08      mov ecx,[ebp+08]
>>> [00000c40][0025c1ea][00000c36] 51          push ecx       // push P
>>> [00000c41][0025c1e6][00000c46] e820fdffff  call 00000966  // call H(P,P)
>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>
>>> The above is from pages 4 and 5 of this paper:
>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>
>>>
>>> There are no tricks. There are only two possible cases:
>>> (1) H(P,P) aborts its simulation and P never reaches its final state
>>> at 0xc50
>>>
>>> (2) H(P,P) does not abort its simulation and P never reaches its
>>> final state at 0xc50
>>>
>>> Therefore when H(P,P) decides that its input never halts H is
>>> necessarily correct.
>>>
>>
>> You are just arguing POOP.
>>
>> The fact that H doesn't reach the halting state is irrelevent to the
>> halting problem.
>>
>
> I didn't say anything about H reaching its final state nitwit.
> I didn't say anything about H reaching its final state nitwit.
> I didn't say anything about H reaching its final state nitwit.
> I didn't say anything about H reaching its final state nitwit.
>
> H either aborts the simulation of its input or does not abort the
> simulation of its input.
>
> (1) H(P,P) aborts its simulation and 0xc50
> P never reaches its final state at 0xc50

Correction: The 'Simulation of P by H' never reaches its final state

P when run by itself WILL.

FAIL

> P never reaches its final state at 0xc50
> P never reaches its final state at 0xc50
> P never reaches its final state at 0xc50
>
> (2) H(P,P) does not abort its simulation and
> P never reaches its final state at 0xc50
> P never reaches its final state at 0xc50
> P never reaches its final state at 0xc50
> P never reaches its final state at 0xc50

If H(P,P) does not abort its simulation then H(P,P) never answers so it
fails to be a decider.

Note, case (1) and (2) have different Ps as well as different Hs so we
can't make the argueent that because the P is (2) never halts that this
says anything about the P in (1).

>
> Therefore when H(P,P) decides that its input never halts H is
> necessarily correct.
>
>

Except that P DOES reach that halting state when P is run as an actual
machine (Assuming H(P,P) answers non-halting). PERIOD.

What doesn't reach that point is H's simulation of P, but that is
irrelevent.

On 10/31/2021 12:46 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 10/31/2021 10:11 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> The only other possibility is that H is a halt
>>>> decider that aborts its simulation of P at the
>>>> machine address 0xc41 of P. In this case P also
>>>> never reaches is final state at machine address
>>>> 0xc50. Thus in every possibility P never reaches
>>>> its final state and thus never halts.
>>> So having lost the argument in relation to Turing machines, you have
>>> returned to your hidden code that gets the wrong answer?
>>
>> (1) I haven't lost the argument on Turing Machines.
>>
>> (2) I conclusively prove that the input to H(P,P) never halts in
>> Message-ID: <hIednR1p-IK1NuP8nZ2dnUU7-ePNnZ2d@giganews.com>
>> Giganews posted this message to other groups and skipped itself.
>
> The input to H represents the computation P(P). At least up until
> recently you asserted that P(P) halts and you spent a lot of time trying
> to hand-wave away the wrong answer from H.
>
>>> Or do you now
>>> accept that H(P,P) == false is wrong if P(P) halts? To get any traction
>>> you really do have to admit that defining the wrong answer to be the
>>> right one simply did not cut it!
>>> By playing tricks (which will remain as hidden as your code) you can
>>> arrange for H(P,P) == true when P(P) halts which would be a welcome
>>> change of heart.
>
>> There are no tricks.
>
> Good. That means you can't have H(P,P) == true iff P(P) halts.
>
>> There are only two possible cases:
>> (1) H(P,P) aborts its simulation and P never reaches its final state
>> at 0xc50
>>
>> (2) H(P,P) does not abort its simulation and P never reaches its final
>> state at 0xc50
>>
>> Therefore when H(P,P) decides that its input never halts H is
>> necessarily correct.
>
> I can see you don't want to answer.

I have answered, perhaps you are not smart enough to understand the answer?

> I was asking if you have changed
> your mind,

If in both possible cases where H(P,P) aborts the simulation of its
input or H(P,P) fails to abort the simulation of its input P never
reaches its final state at its own machine address of 0xc50 then we know
that P never reaches this final state.

Smart people that understand the x86 language know that when H is a pure
simulator that P does specify infinitely nested simulation at its
machine address 0xc41. Even Richard understands this part.

Smart people that understand the x86 language know that when H aborts
its simulation of P at the machine address of 0xc41 of P that the input
to H(P,P) never reaches its final state of 0xc50.

This means that the following code provides proof that the input to
H(P,P) never reaches its final state of 0xc50 in any possible case, thus
the input to H(P,P) never halts.

The following is taken from pages 4 and 5 of this paper:
Halting problem undecidability and infinitely nested simulation
May 2021 PL Olcott

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

// Simplified Linz Ĥ (Linz:1990:319)
// Strachey(1965) CPL translated to C
void P(u32 x)
{ if (H(x, x))
HERE: goto HERE;
}

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

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

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

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00000c56][0010172a][00000000] 55 push ebp
[00000c57][0010172a][00000000] 8bec mov ebp,esp
[00000c59][00101726][00000c36] 68360c0000 push 00000c36 // push P
[00000c5e][00101722][00000c36] 68360c0000 push 00000c36 // push P
[00000c63][0010171e][00000c68] e8fefcffff call 00000966 // call H(P,P)

Begin Local Halt Decider Simulation at Machine Address:c36
[00000c36][002117ca][002117ce] 55 push ebp
[00000c37][002117ca][002117ce] 8bec mov ebp,esp
[00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08]
[00000c3c][002117c6][00000c36] 50 push eax // push P
[00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][002117c2][00000c36] 51 push ecx // push P
[00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P)

[00000c36][0025c1f2][0025c1f6] 55 push ebp
[00000c37][0025c1f2][0025c1f6] 8bec mov ebp,esp
[00000c39][0025c1f2][0025c1f6] 8b4508 mov eax,[ebp+08]
[00000c3c][0025c1ee][00000c36] 50 push eax // push P
[00000c3d][0025c1ee][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][0025c1ea][00000c36] 51 push ecx // push P
[00000c41][0025c1e6][00000c46] e820fdffff call 00000966 // call H(P,P)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

> and I know that's very hard for someone in your position to
> admit. Here's the key question: do you still assert that H(P,P) ==
> false is the "correct" answer even though P(P) halts?

Yes that is the correct answer even though P(P) halts.
The fact that in all possible cases the input to H(P,P) never halts
conclusively proves that H(P,P)==0 is correct no matter what.

H1(P,P)==1 is consistent with the behavior of P(P).

The difference between H(P,P) and H1(P,P) is that the former has
pathological self-reference and the latter does not. This makes these
two computations distinct from each other and thus not equivalent.

> If you won't say,
> nothing you do say about what is "correct" (necessarily or otherwise) is
> pointless.
>
> Of course, it's likely you have no changed you mind and you are still
> searching for words to make the wrong answer seems less obviously
> wrong. Not answering my question is a key part of that strategy so I
> don't expect an answer.
>

Pathological self-reference has been my life's work. For other people
where this is not the case it would be much more difficult to
understand. The fact that H reports a halt status that is consistent
with the behavior of its input conclusively proves that H is correct.

The input to H1(P,P) has behavior that is computationally equivalent to
P(P).

The input to H(P,P) does not have behavior that is computationally
equivalent to P(P).

The difference in behavior is caused by pathological self-reference.

--
Copyright 2021 Pete Olcott

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

On 10/31/2021 1:20 PM, Richard Damon wrote:
> On 10/31/21 1:54 PM, olcott wrote:
>> On 10/31/2021 12:36 PM, Richard Damon wrote:
>>> On 10/31/21 11:51 AM, olcott wrote:
>>>> On 10/31/2021 10:11 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> The only other possibility is that H is a halt
>>>>>> decider that aborts its simulation of P at the
>>>>>> machine address 0xc41 of P. In this case P also
>>>>>> never reaches is final state at machine address
>>>>>> 0xc50. Thus in every possibility P never reaches
>>>>>> its final state and thus never halts.
>>>>>
>>>>> So having lost the argument in relation to Turing machines, you have
>>>>> returned to your hidden code that gets the wrong answer?
>>>>
>>>> (1) I haven't lost the argument on Turing Machines.
>>>
>>> Only because you haven't actually made a real arguemnt on Turing
>>> Machines.
>>>
>>>>
>>>> (2) I conclusively prove that the input to H(P,P) never halts in
>>>> Message-ID: <hIednR1p-IK1NuP8nZ2dnUU7-ePNnZ2d@giganews.com>
>>>> Giganews posted this message to other groups and skipped itself.
>>>
>>> Except that is a meaningless statement.
>>>
>>> 'Inputs' don't halt. Machines Halt.
>>>
>>> When the input <H^><H^> is given to a UTM, that computation Halts,
>>> which is one of the ways to look at the definition of the Halting
>>> Problem.
>>>
>>> Yes, H's aborted simulation of <H^><H^> never reached a final halting
>>> state, but aborted simulation NEVER, in themselves, prove non-halting
>>> (or Halting). So you are arguing about meaningless behavior trying to
>>> claim that it actually means something by using bad terminology.
>>>
>>>>
>>>>>  Or do you now
>>>>> accept that H(P,P) == false is wrong if P(P) halts?  To get any
>>>>> traction
>>>>> you really do have to admit that defining the wrong answer to be the
>>>>> right one simply did not cut it!
>>>>>
>>>>> By playing tricks (which will remain as hidden as your code) you can
>>>>> arrange for H(P,P) == true when P(P) halts which would be a welcome
>>>>> change of heart.
>>>>>
>>>>
>>>> // Simplified Linz Ĥ (Linz:1990:319)
>>>> // Strachey(1965) CPL translated to C
>>>> void P(u32 x)
>>>> {
>>>>    if (H(x, x))
>>>>      HERE: goto HERE;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>    Output("Input_Halts = ", H((u32)P, (u32)P));
>>>> }
>>>>
>>>> _P()
>>>> [00000c36](01)  55          push ebp
>>>> [00000c37](02)  8bec        mov ebp,esp
>>>> [00000c39](03)  8b4508      mov eax,[ebp+08] // 2nd Param
>>>> [00000c3c](01)  50          push eax
>>>> [00000c3d](03)  8b4d08      mov ecx,[ebp+08] // 1st Param
>>>> [00000c40](01)  51          push ecx
>>>> [00000c41](05)  e820fdffff  call 00000966    // call H
>>>> [00000c46](03)  83c408      add esp,+08
>>>> [00000c49](02)  85c0        test eax,eax
>>>> [00000c4b](02)  7402        jz 00000c4f
>>>> [00000c4d](02)  ebfe        jmp 00000c4d
>>>> [00000c4f](01)  5d          pop ebp
>>>> [00000c50](01)  c3          ret
>>>> Size in bytes:(0027) [00000c50]
>>>>
>>>> _main()
>>>> [00000c56](01)  55          push ebp
>>>> [00000c57](02)  8bec        mov ebp,esp
>>>> [00000c59](05)  68360c0000  push 00000c36    // push P
>>>> [00000c5e](05)  68360c0000  push 00000c36    // push P
>>>> [00000c63](05)  e8fefcffff  call 00000966    // call H(P,P)
>>>> [00000c68](03)  83c408      add esp,+08
>>>> [00000c6b](01)  50          push eax
>>>> [00000c6c](05)  6857030000  push 00000357
>>>> [00000c71](05)  e810f7ffff  call 00000386
>>>> [00000c76](03)  83c408      add esp,+08
>>>> [00000c79](02)  33c0        xor eax,eax
>>>> [00000c7b](01)  5d          pop ebp
>>>> [00000c7c](01)  c3          ret
>>>> Size in bytes:(0039) [00000c7c]
>>>>
>>>>   machine   stack     stack     machine    assembly
>>>>   address   address   data      code       language
>>>>   ========  ========  ========  =========  =============
>>>> [00000c56][0010172a][00000000] 55          push ebp
>>>> [00000c57][0010172a][00000000] 8bec        mov ebp,esp
>>>> [00000c59][00101726][00000c36] 68360c0000  push 00000c36 // push P
>>>> [00000c5e][00101722][00000c36] 68360c0000  push 00000c36 // push P
>>>> [00000c63][0010171e][00000c68] e8fefcffff  call 00000966 // call H(P,P)
>>>>
>>>> Begin Local Halt Decider Simulation at Machine Address:c36
>>>> [00000c36][002117ca][002117ce] 55          push ebp
>>>> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
>>>> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
>>>> [00000c3c][002117c6][00000c36] 50          push eax       // push P
>>>> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
>>>> [00000c40][002117c2][00000c36] 51          push ecx       // push P
>>>> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call
>>>> H(P,P)
>>>>
>>>> [00000c36][0025c1f2][0025c1f6] 55          push ebp
>>>> [00000c37][0025c1f2][0025c1f6] 8bec        mov ebp,esp
>>>> [00000c39][0025c1f2][0025c1f6] 8b4508      mov eax,[ebp+08]
>>>> [00000c3c][0025c1ee][00000c36] 50          push eax       // push P
>>>> [00000c3d][0025c1ee][00000c36] 8b4d08      mov ecx,[ebp+08]
>>>> [00000c40][0025c1ea][00000c36] 51          push ecx       // push P
>>>> [00000c41][0025c1e6][00000c46] e820fdffff  call 00000966  // call
>>>> H(P,P)
>>>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>>>>
>>>> The above is from pages 4 and 5 of this paper:
>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>
>>>>
>>>> There are no tricks. There are only two possible cases:
>>>> (1) H(P,P) aborts its simulation and P never reaches its final state
>>>> at 0xc50
>>>>
>>>> (2) H(P,P) does not abort its simulation and P never reaches its
>>>> final state at 0xc50
>>>>
>>>> Therefore when H(P,P) decides that its input never halts H is
>>>> necessarily correct.
>>>>
>>>
>>> You are just arguing POOP.
>>>
>>> The fact that H doesn't reach the halting state is irrelevent to the
>>> halting problem.
>>>
>>
>> I didn't say anything about H reaching its final state nitwit.
>> I didn't say anything about H reaching its final state nitwit.
>> I didn't say anything about H reaching its final state nitwit.
>> I didn't say anything about H reaching its final state nitwit.
>>
>> H either aborts the simulation of its input or does not abort the
>> simulation of its input.
>>
>> (1) H(P,P) aborts its simulation and 0xc50
>> P never reaches its final state at 0xc50
>
> Correction: The 'Simulation of P by H' never reaches its final state
>
> P when run by itself WILL.
>

H1(P,P) is computationally equivalent to P(P)
H(P,P) is NOT computationally equivalent to P(P)

--
Copyright 2021 Pete Olcott

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

On 10/31/21 2:23 PM, olcott wrote:
> On 10/31/2021 12:46 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 10/31/2021 10:11 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> The only other possibility is that H is a halt
>>>>> decider that aborts its simulation of P at the
>>>>> machine address 0xc41 of P. In this case P also
>>>>> never reaches is final state at machine address
>>>>> 0xc50. Thus in every possibility P never reaches
>>>>> its final state and thus never halts.
>>>> So having lost the argument in relation to Turing machines, you have
>>>> returned to your hidden code that gets the wrong answer?
>>>
>>> (1) I haven't lost the argument on Turing Machines.
>>>
>>> (2) I conclusively prove that the input to H(P,P) never halts in
>>> Message-ID: <hIednR1p-IK1NuP8nZ2dnUU7-ePNnZ2d@giganews.com>
>>> Giganews posted this message to other groups and skipped itself.
>>
>> The input to H represents the computation P(P).  At least up until
>> recently you asserted that P(P) halts and you spent a lot of time trying
>> to hand-wave away the wrong answer from H.
>>
>>>>   Or do you now
>>>> accept that H(P,P) == false is wrong if P(P) halts?  To get any
>>>> traction
>>>> you really do have to admit that defining the wrong answer to be the
>>>> right one simply did not cut it!
>>>> By playing tricks (which will remain as hidden as your code) you can
>>>> arrange for H(P,P) == true when P(P) halts which would be a welcome
>>>> change of heart.
>>
>>> There are no tricks.
>>
>> Good.  That means you can't have H(P,P) == true iff P(P) halts.
>>
>>> There are only two possible cases:
>>> (1) H(P,P) aborts its simulation and P never reaches its final state
>>> at 0xc50
>>>
>>> (2) H(P,P) does not abort its simulation and P never reaches its final
>>> state at 0xc50
>>>
>>> Therefore when H(P,P) decides that its input never halts H is
>>> necessarily correct.
>>
>> I can see you don't want to answer.
>
> I have answered, perhaps you are not smart enough to understand the answer?
>
>
>> I was asking if you have changed
>> your mind,
>
> If in both possible cases where H(P,P) aborts the simulation of its
> input or H(P,P) fails to abort the simulation of its input P never
> reaches its final state at its own machine address of 0xc50 then we know
> that P never reaches this final state.

Excpet it isn't that 'P never reaches it final state', that isn't what
you have shown.

You have shown that the simulation of H of P never simulated the machine
to its final state.

If H doesn't abort its simulation, then yes, this H has proved that P is
non-halting, but this H can't give the answer to the question, so it has
failed tis job.

But, if H does abort its simulation, then the fact that it hadn't
reached a halting state doesn't prove it to be right, and to perform
that test we need to give this exact same input to a UTM to see what
happens.

That UTM should get the exact same trace of P up to the point of the
abort, then the UTM will continue and see one last run of P calling an
H, then the top level H in this simulatin aborting its simulation and
returning the non-halting response to the outer most P and then P Halting.

This shows that P(P) is, and always was, a Halting Computation, and H
was just plain WRONG to decide it was non-halting.

>
> Smart people that understand the x86 language know that when H is a pure
> simulator that P does specify infinitely nested simulation at its
> machine address 0xc41. Even Richard understands this part.

Yes, if H IS a Pure Simulator, P is non-halting, and H fails to answer.
>
> Smart people that understand the x86 language know that when H aborts
> its simulation of P at the machine address of 0xc41 of P that the input
> to H(P,P) never reaches its final state of 0xc50.\

Your bad words again.

H aborting says that H's simulation of its input never reached a Halting
State, which seems to be what you mean by the 'non-sense' of 'the input
to H(P,P) never reaches its final state'. The problem is inputs don't do
anything.

The actual definition says the Computation represented by the Input, or
equivalently what happens if this input is give to a REAL UTM.

In either of these cases, the RIGHT test of this input shows that it halts.

>
> This means that the following code provides proof that the input to
> H(P,P) never reaches its final state of 0xc50 in any possible case, thus
> the input to H(P,P) never halts.

Yes, H(P,P) never reaches the halting state in its simulation.

it is still a fact that Inputs don't halt.

it is still a fact that the Computaton represented by the input (or its
simulation by a real UTM) DOES halt in every case where H returns a
non-halting response to this input, so H is WRONG.

>
> The following is taken from pages 4 and 5 of this paper:
> Halting problem undecidability and infinitely nested simulation
> May 2021 PL Olcott
>
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
>
>
> // Simplified Linz Ĥ (Linz:1990:319)
> // Strachey(1965) CPL translated to C
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H((u32)P, (u32)P));
> }
>
> _P()
> [00000c36](01)  55          push ebp
> [00000c37](02)  8bec        mov ebp,esp
> [00000c39](03)  8b4508      mov eax,[ebp+08] // 2nd Param
> [00000c3c](01)  50          push eax
> [00000c3d](03)  8b4d08      mov ecx,[ebp+08] // 1st Param
> [00000c40](01)  51          push ecx
> [00000c41](05)  e820fdffff  call 00000966    // call H
> [00000c46](03)  83c408      add esp,+08
> [00000c49](02)  85c0        test eax,eax
> [00000c4b](02)  7402        jz 00000c4f
> [00000c4d](02)  ebfe        jmp 00000c4d
> [00000c4f](01)  5d          pop ebp
> [00000c50](01)  c3          ret
> Size in bytes:(0027) [00000c50]
>
> _main()
> [00000c56](01)  55          push ebp
> [00000c57](02)  8bec        mov ebp,esp
> [00000c59](05)  68360c0000  push 00000c36    // push P
> [00000c5e](05)  68360c0000  push 00000c36    // push P
> [00000c63](05)  e8fefcffff  call 00000966    // call H(P,P)
> [00000c68](03)  83c408      add esp,+08
> [00000c6b](01)  50          push eax
> [00000c6c](05)  6857030000  push 00000357
> [00000c71](05)  e810f7ffff  call 00000386
> [00000c76](03)  83c408      add esp,+08
> [00000c79](02)  33c0        xor eax,eax
> [00000c7b](01)  5d          pop ebp
> [00000c7c](01)  c3          ret
> Size in bytes:(0039) [00000c7c]
>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> [00000c56][0010172a][00000000] 55          push ebp
> [00000c57][0010172a][00000000] 8bec        mov ebp,esp
> [00000c59][00101726][00000c36] 68360c0000  push 00000c36 // push P
> [00000c5e][00101722][00000c36] 68360c0000  push 00000c36 // push P
> [00000c63][0010171e][00000c68] e8fefcffff  call 00000966 // call H(P,P)
>
> Begin Local Halt Decider Simulation at Machine Address:c36
> [00000c36][002117ca][002117ce] 55          push ebp
> [00000c37][002117ca][002117ce] 8bec        mov ebp,esp
> [00000c39][002117ca][002117ce] 8b4508      mov eax,[ebp+08]
> [00000c3c][002117c6][00000c36] 50          push eax       // push P
> [00000c3d][002117c6][00000c36] 8b4d08      mov ecx,[ebp+08]
> [00000c40][002117c2][00000c36] 51          push ecx       // push P
> [00000c41][002117be][00000c46] e820fdffff  call 00000966  // call H(P,P)
>
> [00000c36][0025c1f2][0025c1f6] 55          push ebp
> [00000c37][0025c1f2][0025c1f6] 8bec        mov ebp,esp
> [00000c39][0025c1f2][0025c1f6] 8b4508      mov eax,[ebp+08]
> [00000c3c][0025c1ee][00000c36] 50          push eax       // push P
> [00000c3d][0025c1ee][00000c36] 8b4d08      mov ecx,[ebp+08]
> [00000c40][0025c1ea][00000c36] 51          push ecx       // push P
> [00000c41][0025c1e6][00000c46] e820fdffff  call 00000966  // call H(P,P)
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
>
>> and I know that's very hard for someone in your position to
>> admit.  Here's the key question: do you still assert that H(P,P) ==
>> false is the "correct" answer even though P(P) halts?
>
> Yes that is the correct answer even though P(P) halts.

On 10/31/21 2:47 PM, olcott wrote:
> On 10/31/2021 1:20 PM, Richard Damon wrote:
>> On 10/31/21 1:54 PM, olcott wrote:
>>> On 10/31/2021 12:36 PM, Richard Damon wrote:

>>>> You are just arguing POOP.
>>>>
>>>> The fact that H doesn't reach the halting state is irrelevent to the
>>>> halting problem.
>>>>
>>>
>>> I didn't say anything about H reaching its final state nitwit.
>>> I didn't say anything about H reaching its final state nitwit.
>>> I didn't say anything about H reaching its final state nitwit.
>>> I didn't say anything about H reaching its final state nitwit.
>>>
>>> H either aborts the simulation of its input or does not abort the
>>> simulation of its input.
>>>
>>> (1) H(P,P) aborts its simulation and 0xc50
>>> P never reaches its final state at 0xc50
>>
>> Correction: The 'Simulation of P by H' never reaches its final state
>>
>> P when run by itself WILL.
>>
>
> H1(P,P) is computationally equivalent to P(P)
> H(P,P) is NOT computationally equivalent to P(P)
>
>

??????

H and P/H^ are very distinct computations.

The ANSWER that H gives is supposed to correspond to the BEHAVIOR of
P/H^ (They are not 'computationally equivalent')

The fact that some other computation H1, gives the right answer is
irrelent, as Linz only needs that H can't give the right for H^(<H^>)

H1 will similarly fail for H1^(<H1^>)

H1 is TOTALLY meaningless as far as H failing to give the right answer.

You end up stuck in that you want H1 to be 'just like' H so you can use
it to redeam H, but if you try to claim it is close enough to do that,
then all you have done is proved that neither H or H1 is actually the
needed Computation.

On 10/31/2021 1:56 PM, Richard Damon wrote:
>
> On 10/31/21 2:23 PM, olcott wrote:
>> On 10/31/2021 12:46 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 10/31/2021 10:11 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> The only other possibility is that H is a halt
>>>>>> decider that aborts its simulation of P at the
>>>>>> machine address 0xc41 of P. In this case P also
>>>>>> never reaches is final state at machine address
>>>>>> 0xc50. Thus in every possibility P never reaches
>>>>>> its final state and thus never halts.
>>>>> So having lost the argument in relation to Turing machines, you have
>>>>> returned to your hidden code that gets the wrong answer?
>>>>
>>>> (1) I haven't lost the argument on Turing Machines.
>>>>
>>>> (2) I conclusively prove that the input to H(P,P) never halts in
>>>> Message-ID: <hIednR1p-IK1NuP8nZ2dnUU7-ePNnZ2d@giganews.com>
>>>> Giganews posted this message to other groups and skipped itself.
>>>
>>> The input to H represents the computation P(P).  At least up until
>>> recently you asserted that P(P) halts and you spent a lot of time trying
>>> to hand-wave away the wrong answer from H.
>>>
>>>>>   Or do you now
>>>>> accept that H(P,P) == false is wrong if P(P) halts?  To get any
>>>>> traction
>>>>> you really do have to admit that defining the wrong answer to be the
>>>>> right one simply did not cut it!
>>>>> By playing tricks (which will remain as hidden as your code) you can
>>>>> arrange for H(P,P) == true when P(P) halts which would be a welcome
>>>>> change of heart.
>>>
>>>> There are no tricks.
>>>
>>> Good.  That means you can't have H(P,P) == true iff P(P) halts.
>>>
>>>> There are only two possible cases:
>>>> (1) H(P,P) aborts its simulation and P never reaches its final state
>>>> at 0xc50
>>>>
>>>> (2) H(P,P) does not abort its simulation and P never reaches its final
>>>> state at 0xc50
>>>>
>>>> Therefore when H(P,P) decides that its input never halts H is
>>>> necessarily correct.
>>>
>>> I can see you don't want to answer.
>>
>> I have answered, perhaps you are not smart enough to understand the
>> answer?
>>
>>
>>> I was asking if you have changed
>>> your mind,
>>
>> If in both possible cases where H(P,P) aborts the simulation of its
>> input or H(P,P) fails to abort the simulation of its input P never
>> reaches its final state at its own machine address of 0xc50 then we
>> know that P never reaches this final state.
>
> Excpet it isn't that 'P never reaches it final state', that isn't what
> you have shown.
>

Whether or not the input to H(P,P) is aborted at machine address 0xc41
of P the simulation of P never reaches machine address 0xc50 of P.

Can you understand that a computation that is aborted at machine address
0xc41 never gets past machine address 0xc41?

--
Copyright 2021 Pete Olcott

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

On 10/31/21 3:26 PM, olcott wrote:
> On 10/31/2021 1:56 PM, Richard Damon wrote:
>>
>> On 10/31/21 2:23 PM, olcott wrote:
>>> On 10/31/2021 12:46 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 10/31/2021 10:11 AM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> The only other possibility is that H is a halt
>>>>>>> decider that aborts its simulation of P at the
>>>>>>> machine address 0xc41 of P. In this case P also
>>>>>>> never reaches is final state at machine address
>>>>>>> 0xc50. Thus in every possibility P never reaches
>>>>>>> its final state and thus never halts.
>>>>>> So having lost the argument in relation to Turing machines, you have
>>>>>> returned to your hidden code that gets the wrong answer?
>>>>>
>>>>> (1) I haven't lost the argument on Turing Machines.
>>>>>
>>>>> (2) I conclusively prove that the input to H(P,P) never halts in
>>>>> Message-ID: <hIednR1p-IK1NuP8nZ2dnUU7-ePNnZ2d@giganews.com>
>>>>> Giganews posted this message to other groups and skipped itself.
>>>>
>>>> The input to H represents the computation P(P).  At least up until
>>>> recently you asserted that P(P) halts and you spent a lot of time
>>>> trying
>>>> to hand-wave away the wrong answer from H.
>>>>
>>>>>>   Or do you now
>>>>>> accept that H(P,P) == false is wrong if P(P) halts?  To get any
>>>>>> traction
>>>>>> you really do have to admit that defining the wrong answer to be the
>>>>>> right one simply did not cut it!
>>>>>> By playing tricks (which will remain as hidden as your code) you can
>>>>>> arrange for H(P,P) == true when P(P) halts which would be a welcome
>>>>>> change of heart.
>>>>
>>>>> There are no tricks.
>>>>
>>>> Good.  That means you can't have H(P,P) == true iff P(P) halts.
>>>>
>>>>> There are only two possible cases:
>>>>> (1) H(P,P) aborts its simulation and P never reaches its final state
>>>>> at 0xc50
>>>>>
>>>>> (2) H(P,P) does not abort its simulation and P never reaches its final
>>>>> state at 0xc50
>>>>>
>>>>> Therefore when H(P,P) decides that its input never halts H is
>>>>> necessarily correct.
>>>>
>>>> I can see you don't want to answer.
>>>
>>> I have answered, perhaps you are not smart enough to understand the
>>> answer?
>>>
>>>
>>>> I was asking if you have changed
>>>> your mind,
>>>
>>> If in both possible cases where H(P,P) aborts the simulation of its
>>> input or H(P,P) fails to abort the simulation of its input P never
>>> reaches its final state at its own machine address of 0xc50 then we
>>> know that P never reaches this final state.
>>
>> Excpet it isn't that 'P never reaches it final state', that isn't what
>> you have shown.
>>
>
> Whether or not the input to H(P,P) is aborted at machine address 0xc41
> of P the simulation of P never reaches machine address 0xc50 of P.
>
> Can you understand that a computation that is aborted at machine address
> 0xc41 never gets past machine address 0xc41?
>

But, what you don't seem to be able to keep in your head is that it
doesn't matter what the simulation done by H does, but what the actual
machine does, or equivalently, a simulation by a REAL UTM.

If H does abort the simulation of P, and thus returns the non-halting
answer, then ths simulation of that exact same input but a UTM does.

Note, that when H abort its simulation, that only affects that
simulation within H, and does NOT affect any outer copy of that machine.

Thus when we run the actual computation P(P) then P(P) will call H(P,P)
and H does its simulation and aborts it at some address, say 0xC41, then
H will need to return that answer to the P that called it, and that P
will run past that address and return, showing that it halts.

PREEMPTIVE: If you want to claim that the H doing the simulation doesn't
return to the actual running P that called it, then H either isn't a
'Compuation' in the mathematical sense, or H doesn't meet the
requirements of 'answering' in the mathematical sense.

Also, if the H called by P acts differently the the H called just by
main, then we also have the fact that H has just proved itself not to be
a Computation in the Mathematical sense.