On 5/29/2022 6:24 PM, Mike Terry wrote:
> On 29/05/2022 22:56, André G. Isaak wrote:
>> On 2022-05-29 15:41, olcott wrote:
>>> On 5/29/2022 4:30 PM, André G. Isaak wrote:
>>>> On 2022-05-29 15:16, olcott wrote:
>>>>> On 5/29/2022 4:00 PM, André G. Isaak wrote:
>>>>>> On 2022-05-29 14:35, olcott wrote:
>>>>>>> On 5/29/2022 2:58 PM, André G. Isaak wrote:
>>>>>>>> On 2022-05-29 13:26, olcott wrote:
>>>>>>>>
>>>>>>>>>> Agree.  I think PO probably can't understand the proper
>>>>>>>>>> definition of halting.  That definition doesn't involve any
>>>>>>>>>> UTMs or emulation - it's just a mathematical definition, first
>>>>>>>>>> of the computation steps, then of halting in terms of there
>>>>>>>>>> being an n such that computation step n is a final state of
>>>>>>>>>> the TM.  That's TOO ABSTRACT for PO, so all he can do is
>>>>>>>>>> replace it with something he thinks he /can/ understand:
>>>>>>>>>> something more concrete - a simulation run in some "actual
>>>>>>>>>> machine" processing a TM description and tape description!
>>>>>>>>>
>>>>>>>>> HERE IS WHY ACTUAL COMPUTER SCIENTISTS WILL AGREE WITH ME
>>>>>>>>> Every decider computes the mapping from its input finite
>>>>>>>>> string(s) to an accept or reject state based on a semantic or
>>>>>>>>> syntactic property of this finite string.
>>>>>>>>
>>>>>>>> Finite strings don't have semantic properties.
>>>>>>>
>>>>>>>
>>>>>>> In computability theory, Rice's theorem states that all
>>>>>>> non-trivial semantic properties of programs are undecidable.
>>>>>>
>>>>>> And how 'bout them Mets?
>>>>>>
>>>>>>> A semantic property is one about the program's behavior (for
>>>>>>> instance, does the program terminate for all inputs),
>>>>>>>
>>>>>>> https://en.wikipedia.org/wiki/Rice%27s_theorem
>>>>>>>
>>>>>>> In formal semantics this would be the semantic property of a
>>>>>>> finite string.
>>>>>>
>>>>>> No, it would be a semantic property of the program. That program
>>>>>> might be *represented* as a string, but the string itself has no
>>>>>> semantic properties.
>>>>>>
>>>>>
>>>>> The semantic property of the string when it is interpreted as the
>>>>> description of a program.
>>>>
>>>> WHOOOSH!
>>>>
>>>> As soon you you add 'when it is interpreted as...' you are no longer
>>>> talking about the string but the thing which the string represents.
>>>>
>>>
>>> Yes. The string has no semantics on its own.
>>>
>>> The input to H(P,P) determines (Mike's word) an execution trace of
>>> x86 instructions when correctly emulated by H.
>>>
>>> The input to H1(P,P) determines (Mike's word) an execution trace of
>>> x86 instructions when correctly emulated by H1.
>>
>> And neither of those sentences make any sense. Replacing 'specifies'
>> with 'determines' doesn't make things any clearer. You need to
>> actually DEFINE your terms.
>>
>>> These execution traces are not the same.
>> Which means at least one of the above programs is *not* interpreting
>> its input in the correct way, i.e. in the way which the specification
>> of a halt decider demands.
>
> Hows about...
>
>   Computation P(P) goes through a sequence of steps, which for
> illustration I'll just refer to as <a> <b> ... <z> with <z> being the
> final (RET) step where the computation halts.  Now, H and H1 calculate
> these steps ["emulate their input"] something like this:
>
>   H1          H
>  ----        ----
>   <a>         <a>      // P(P) very first state!
>   <b>         <b>
>   <c>         <c>
>   <d>         <d>
>   <e>         <e>
>   <f>         <f>
>   <g>         <g>
>   <h>         <h>
>   <i>         <i>
>   <j>         <j>
>   <k>         <k>
>   <l>         <l>      // no divergence so far!
>   <m>         <m>
>   <n>         <n>
>   <o>         <o>
>   <p>         <p>
>   <q>         <q>
>   <r>         <r>      // H spots some pattern and stops simulating
>   <s>
>   <t>
>   <u>
>   <v>
>   <w>
>   <x>
>   <y>
>   <z>                  // P(P) final state - it halts!
>
> So in PO language "the input to H(P,P)" is (P,P), and this determines
> the steps of the computation P(P) which are being calculated by the
> emulator in H, which calculates <a>...<r> then stops calculating because
> it spotted some pattern.  [in PO terms, <a>...<r> are the x86
> instructions or their trace entries].
>
> "the input to H1(P,P)" is also (P,P), and this determines the steps of
> the computation P(P) which are being calculated by the emulator in H1,
> which calculates <a>...<r>...<z> then stops because final state [ret
> instruction] is reached.
>
> PO might try to deny that H1 calculates the same steps as H from <a> to
> <r>, or might agree.  I don't think PO really understands what's
> happening in his own program.  :)
>
> In PO language, perhaps, BOTH the above are "correct emulations" because
> the sequence of "x86 instruction transitions" <a> --> <b> etc. is
> correct on a step-by-step basis.  (That would be consistent with his
> claim repeated 1000 times, that we can check the emulation is correct by
> comparing the machine code listings and verifying that emulation is
> [doing each instruction correctly].)
>
> H's decision to stop emulating is not (IMO) part of the emulation
> itself.  (How could it be? but probably that's just a matter of agreeing
> the terms we're using.)
>
> Anyhow, he who would argue with PO would do well to pin PO down on his
> strange choice of phrases to avoid weeks or months of
> miscommunications.  And you have to start by discovering /something/ you
> agree on...  Just demanding he "defines all his terms" won't get far as
> he can't "define" anything properly.  :)
>
>
> Mike.
>

The input to H1(P,P) halts.
In this same computation the input to H(P,P)
would never reach its "ret" instruction in 1 to ∞ emulated steps.

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

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

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

_main()
[00001372](01) 55 push ebp
[00001373](02) 8bec mov ebp,esp
[00001375](05) 6852130000 push 00001352 // push P
[0000137a](05) 6852130000 push 00001352 // push P
[0000137f](05) e81efcffff call 00000fa2 // call H1
[00001384](03) 83c408 add esp,+08
[00001387](01) 50 push eax
[00001388](05) 6823040000 push 00000423
[0000138d](05) e8e0f0ffff call 00000472
[00001392](03) 83c408 add esp,+08
[00001395](02) 33c0 xor eax,eax
[00001397](01) 5d pop ebp
[00001398](01) c3 ret
Size in bytes:(0039) [00001398]

On 5/29/22 8:33 PM, olcott wrote:
> On 5/29/2022 6:24 PM, Mike Terry wrote:
>> On 29/05/2022 22:56, André G. Isaak wrote:
>>> On 2022-05-29 15:41, olcott wrote:
>>>> On 5/29/2022 4:30 PM, André G. Isaak wrote:
>>>>> On 2022-05-29 15:16, olcott wrote:
>>>>>> On 5/29/2022 4:00 PM, André G. Isaak wrote:
>>>>>>> On 2022-05-29 14:35, olcott wrote:
>>>>>>>> On 5/29/2022 2:58 PM, André G. Isaak wrote:
>>>>>>>>> On 2022-05-29 13:26, olcott wrote:
>>>>>>>>>
>>>>>>>>>>> Agree.  I think PO probably can't understand the proper
>>>>>>>>>>> definition of halting.  That definition doesn't involve any
>>>>>>>>>>> UTMs or emulation - it's just a mathematical definition,
>>>>>>>>>>> first of the computation steps, then of halting in terms of
>>>>>>>>>>> there being an n such that computation step n is a final
>>>>>>>>>>> state of the TM.  That's TOO ABSTRACT for PO, so all he can
>>>>>>>>>>> do is replace it with something he thinks he /can/
>>>>>>>>>>> understand: something more concrete - a simulation run in
>>>>>>>>>>> some "actual machine" processing a TM description and tape
>>>>>>>>>>> description!
>>>>>>>>>>
>>>>>>>>>> HERE IS WHY ACTUAL COMPUTER SCIENTISTS WILL AGREE WITH ME
>>>>>>>>>> Every decider computes the mapping from its input finite
>>>>>>>>>> string(s) to an accept or reject state based on a semantic or
>>>>>>>>>> syntactic property of this finite string.
>>>>>>>>>
>>>>>>>>> Finite strings don't have semantic properties.
>>>>>>>>
>>>>>>>>
>>>>>>>> In computability theory, Rice's theorem states that all
>>>>>>>> non-trivial semantic properties of programs are undecidable.
>>>>>>>
>>>>>>> And how 'bout them Mets?
>>>>>>>
>>>>>>>> A semantic property is one about the program's behavior (for
>>>>>>>> instance, does the program terminate for all inputs),
>>>>>>>>
>>>>>>>> https://en.wikipedia.org/wiki/Rice%27s_theorem
>>>>>>>>
>>>>>>>> In formal semantics this would be the semantic property of a
>>>>>>>> finite string.
>>>>>>>
>>>>>>> No, it would be a semantic property of the program. That program
>>>>>>> might be *represented* as a string, but the string itself has no
>>>>>>> semantic properties.
>>>>>>>
>>>>>>
>>>>>> The semantic property of the string when it is interpreted as the
>>>>>> description of a program.
>>>>>
>>>>> WHOOOSH!
>>>>>
>>>>> As soon you you add 'when it is interpreted as...' you are no
>>>>> longer talking about the string but the thing which the string
>>>>> represents.
>>>>>
>>>>
>>>> Yes. The string has no semantics on its own.
>>>>
>>>> The input to H(P,P) determines (Mike's word) an execution trace of
>>>> x86 instructions when correctly emulated by H.
>>>>
>>>> The input to H1(P,P) determines (Mike's word) an execution trace of
>>>> x86 instructions when correctly emulated by H1.
>>>
>>> And neither of those sentences make any sense. Replacing 'specifies'
>>> with 'determines' doesn't make things any clearer. You need to
>>> actually DEFINE your terms.
>>>
>>>> These execution traces are not the same.
>>> Which means at least one of the above programs is *not* interpreting
>>> its input in the correct way, i.e. in the way which the specification
>>> of a halt decider demands.
>>
>> Hows about...
>>
>>    Computation P(P) goes through a sequence of steps, which for
>> illustration I'll just refer to as <a> <b> ... <z> with <z> being the
>> final (RET) step where the computation halts.  Now, H and H1 calculate
>> these steps ["emulate their input"] something like this:
>>
>>    H1          H
>>   ----        ----
>>    <a>         <a>      // P(P) very first state!
>>    <b>         <b>
>>    <c>         <c>
>>    <d>         <d>
>>    <e>         <e>
>>    <f>         <f>
>>    <g>         <g>
>>    <h>         <h>
>>    <i>         <i>
>>    <j>         <j>
>>    <k>         <k>
>>    <l>         <l>      // no divergence so far!
>>    <m>         <m>
>>    <n>         <n>
>>    <o>         <o>
>>    <p>         <p>
>>    <q>         <q>
>>    <r>         <r>      // H spots some pattern and stops simulating
>>    <s>
>>    <t>
>>    <u>
>>    <v>
>>    <w>
>>    <x>
>>    <y>
>>    <z>                  // P(P) final state - it halts!
>>
>> So in PO language "the input to H(P,P)" is (P,P), and this determines
>> the steps of the computation P(P) which are being calculated by the
>> emulator in H, which calculates <a>...<r> then stops calculating
>> because it spotted some pattern.  [in PO terms, <a>...<r> are the x86
>> instructions or their trace entries].
>>
>> "the input to H1(P,P)" is also (P,P), and this determines the steps of
>> the computation P(P) which are being calculated by the emulator in H1,
>> which calculates <a>...<r>...<z> then stops because final state [ret
>> instruction] is reached.
>>
>> PO might try to deny that H1 calculates the same steps as H from <a>
>> to <r>, or might agree.  I don't think PO really understands what's
>> happening in his own program.  :)
>>
>> In PO language, perhaps, BOTH the above are "correct emulations"
>> because the sequence of "x86 instruction transitions" <a> --> <b> etc.
>> is correct on a step-by-step basis.  (That would be consistent with
>> his claim repeated 1000 times, that we can check the emulation is
>> correct by comparing the machine code listings and verifying that
>> emulation is [doing each instruction correctly].)
>>
>> H's decision to stop emulating is not (IMO) part of the emulation
>> itself.  (How could it be? but probably that's just a matter of
>> agreeing the terms we're using.)
>>
>> Anyhow, he who would argue with PO would do well to pin PO down on his
>> strange choice of phrases to avoid weeks or months of
>> miscommunications.  And you have to start by discovering /something/
>> you agree on...  Just demanding he "defines all his terms" won't get
>> far as he can't "define" anything properly.  :)
>>
>>
>> Mike.
>>
>
> The input to H1(P,P) halts.
> In this same computation the input to H(P,P)
> would never reach its "ret" instruction in 1 to ∞ emulated steps.
>
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H1((u32)P, (u32)P));
> }
>
> _P()
> [00001352](01)  55              push ebp
> [00001353](02)  8bec            mov ebp,esp
> [00001355](03)  8b4508          mov eax,[ebp+08]
> [00001358](01)  50              push eax
> [00001359](03)  8b4d08          mov ecx,[ebp+08]
> [0000135c](01)  51              push ecx
> [0000135d](05)  e840feffff      call 000011a2 // call H
> [00001362](03)  83c408          add esp,+08
> [00001365](02)  85c0            test eax,eax
> [00001367](02)  7402            jz 0000136b
> [00001369](02)  ebfe            jmp 00001369
> [0000136b](01)  5d              pop ebp
> [0000136c](01)  c3              ret
> Size in bytes:(0027) [0000136c]
>
> _main()
> [00001372](01)  55              push ebp
> [00001373](02)  8bec            mov ebp,esp
> [00001375](05)  6852130000      push 00001352 // push P
> [0000137a](05)  6852130000      push 00001352 // push P
> [0000137f](05)  e81efcffff      call 00000fa2 // call H1
> [00001384](03)  83c408          add esp,+08
> [00001387](01)  50              push eax
> [00001388](05)  6823040000      push 00000423
> [0000138d](05)  e8e0f0ffff      call 00000472
> [00001392](03)  83c408          add esp,+08
> [00001395](02)  33c0            xor eax,eax
> [00001397](01)  5d              pop ebp
> [00001398](01)  c3              ret
> Size in bytes:(0039) [00001398]
>
>
>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> ...[00001372][0010229e][00000000] 55              push ebp
> ...[00001373][0010229e][00000000] 8bec            mov ebp,esp
> ...[00001375][0010229a][00001352] 6852130000      push 00001352 // push P
> ...[0000137a][00102296][00001352] 6852130000      push 00001352 // push P
> ...[0000137f][00102292][00001384] e81efcffff      call 00000fa2 // call H1
>
> Begin Local Halt Decider Simulation   Execution Trace Stored at:212352
> H1_Root:1
> ...[00001352][0021233e][00212342] 55              push ebp
> ...[00001353][0021233e][00212342] 8bec            mov ebp,esp
> ...[00001355][0021233e][00212342] 8b4508          mov eax,[ebp+08]
> ...[00001358][0021233a][00001352] 50              push eax      // push P
> ...[00001359][0021233a][00001352] 8b4d08          mov ecx,[ebp+08]
> ...[0000135c][00212336][00001352] 51              push ecx      // push P
> ...[0000135d][00212332][00001362] e840feffff      call 000011a2 // call H
>
> Begin Local Halt Decider Simulation   Execution Trace Stored at:25cd7a
> ...[00001352][0025cd66][0025cd6a] 55              push ebp
> ...[00001353][0025cd66][0025cd6a] 8bec            mov ebp,esp
> ...[00001355][0025cd66][0025cd6a] 8b4508          mov eax,[ebp+08]
> ...[00001358][0025cd62][00001352] 50              push eax      // push P
> ...[00001359][0025cd62][00001352] 8b4d08          mov ecx,[ebp+08]
> ...[0000135c][0025cd5e][00001352] 51              push ecx      // push P
> ...[0000135d][0025cd5a][00001362] e840feffff      call 000011a2 // call H
> ...[00001352][002a778e][002a7792] 55              push ebp
> ...[00001353][002a778e][002a7792] 8bec            mov ebp,esp
> ...[00001355][002a778e][002a7792] 8b4508          mov eax,[ebp+08]
> ...[00001358][002a778a][00001352] 50              push eax      // push P
> ...[00001359][002a778a][00001352] 8b4d08          mov ecx,[ebp+08]
> ...[0000135c][002a7786][00001352] 51              push ecx      // push P
> ...[0000135d][002a7782][00001362] e840feffff      call 000011a2 // call H
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
> ...[00001362][0021233e][00212342] 83c408          add esp,+08
> ...[00001365][0021233e][00212342] 85c0            test eax,eax
> ...[00001367][0021233e][00212342] 7402            jz 0000136b
> ...[0000136b][00212342][0000107a] 5d              pop ebp
> ...[0000136c][00212346][00001352] c3              ret
> ...[00001384][0010229e][00000000] 83c408          add esp,+08
> ...[00001387][0010229a][00000001] 50              push eax
> ...[00001388][00102296][00000423] 6823040000      push 00000423
> ---[0000138d][00102296][00000423] e8e0f0ffff      call 00000472
> Input_Halts = 1
> ...[00001392][0010229e][00000000] 83c408          add esp,+08
> ...[00001395][0010229e][00000000] 33c0            xor eax,eax
> ...[00001397][001022a2][00100000] 5d              pop ebp
> ...[00001398][001022a6][00000004] c3              ret
> Number of Instructions Executed(398230) = 5,944 pages
>
>

On 5/29/22 8:26 PM, olcott wrote:
> On 5/29/2022 6:52 PM, Ben wrote:
>> André G. Isaak <agisaak@gm.invalid> writes:
>>
>>> On 2022-05-29 15:16, olcott wrote:
>>>> On 5/29/2022 4:00 PM, André G. Isaak wrote:
>>>>> On 2022-05-29 14:35, olcott wrote:
>>>>>> On 5/29/2022 2:58 PM, André G. Isaak wrote:
>>>>>>> On 2022-05-29 13:26, olcott wrote:
>>>>>>>
>>>>>>>>> Agree.  I think PO probably can't understand the proper
>>>>>>>>> definition of halting.  That definition doesn't involve any
>>>>>>>>> UTMs or emulation
>>>>>>>>> - it's just a mathematical definition, first of the computation
>>>>>>>>> steps, then of halting in terms of there being an n such that
>>>>>>>>> computation step n is a final state of the TM.  That's TOO
>>>>>>>>> ABSTRACT for PO, so all he can do is replace it with something he
>>>>>>>>> thinks he /can/ understand: something more concrete - a
>>>>>>>>> simulation run in some "actual machine" processing a TM
>>>>>>>>> description and tape
>>>>>>>>> description!
>>>>>>>>
>>>>>>>> HERE IS WHY ACTUAL COMPUTER SCIENTISTS WILL AGREE WITH ME
>>>>>>>> Every decider computes the mapping from its input finite
>>>>>>>> string(s) to an accept or reject state based on a semantic or
>>>>>>>> syntactic
>>>>>>>> property of this finite string.
>>>>>>>
>>>>>>> Finite strings don't have semantic properties.
>>>>>>
>>>>>>
>>>>>> In computability theory, Rice's theorem states that all
>>>>>> non-trivial semantic properties of programs are undecidable.
>>>>>
>>>>> And how 'bout them Mets?
>>>>>
>>>>>> A semantic property is one about the program's behavior (for
>>>>>> instance, does the program terminate for all inputs),
>>>>>>
>>>>>> https://en.wikipedia.org/wiki/Rice%27s_theorem
>>>>>>
>>>>>> In formal semantics this would be the semantic property of a
>>>>>> finite string.
>>>>>
>>>>> No, it would be a semantic property of the program. That program
>>>>> might be *represented* as a string, but the string itself has no
>>>>> semantic
>>>>> properties.
>>>>>
>>>> The semantic property of the string when it is interpreted as the
>>>> description of a program.
>>>
>>> WHOOOSH!
>>>
>>> As soon you you add 'when it is interpreted as...' you are no longer
>>> talking about the string but the thing which the string represents.
>>
>> One of the most frustrating things about talking to PO is that he drags
>> the discussion down to his level.  Precisely stated, Rice's theorem is
>> not about strings or semantics.  These terms just cover the discussion
>> in a sort of intellectual molasses.  Rice's theorem is about subsets of
>> ℕ and partial recursive functions that enumerate them.  It is sharp and
>> precise and involves no questions of interpretation and semantics does
>> not come into it.  All of the wriggle and waffle room PO gives himself
>> comes from operating at the level of "The Ladybird Book of
>> Computability".
>>
>> I know you know this, but I can't help noticing how effectively PO's
>> lack of knowledge and understanding ends up handicapping everyone else
>> rather then him.
>>
>
> I prove that I am correct thus there is either some disconnect in the
> relationship to the other proof or my reasoning can be adapted to the
> other proof.

Nope.

>
> It is true that H(P,P)==0

Yes, H(P,P) returns 0.

You have NOT proved this is correct, and in fact, agree to facts that
make it incorrect.

Remember, the DEFINITION of a Halt Decider is H applied the input Wm w,
Where Wm is the description of the Turing Machine M, needs to accept if
M applied to w Halts and reject if M applied to w never Halts.

THAT is the definition.

With Simulatation defined per a UTM (where UTM apploied to Wm w has the
exact same behavior as M applied to w), you can convert this to using
simulation, but NOT for any other defintion without actually PROVING it
is equivalent.

You have AGREED that P(P) Halts.

Thus H(P,P) MUST accept the input, but it rejects it.

Thus H fails to meet the requirments.

PERIOD.

> It is true that P forms the required HP proof relationship to H.

Nope.

>
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> Therefore it is true that I have refuted the HP proofs by making the
> undecidable input decidable.

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

Garbage.

You start from wrong defintions, so NOTHING you paper says has meaning
to the proof of the Theorem.

FAIL.

On 5/30/2022 2:17 PM, André G. Isaak wrote:
> On 2022-05-30 11:59, olcott wrote:
>> On 5/30/2022 11:56 AM, André G. Isaak wrote:
>
>>> A *correct* emulation of P(P) would emulate the exact same sequence
>>> of instructions that occurs when you run P(P) directly,
>>
>> This is factually incorrect.
>
> How exactly? How would *you* define "correct emulation" if not as above?
> You can propose whatever definition you want, but unless the rest of the
> world accepts your definition you're not going to get anywhere.
>
>> The first seven instructions are the same.
>> The next instructions are not the same.
>
> Yes. They diverge. That's what it MEANS to be an INcorrect emulation.
>

The x86 source-code of P proves that they must diverge.
When the executed P(P) calls H(P,P) it must return to P.

When the simulated input to H(P,P) calls H(P,P) it cannot return to P
because it keeps simulating the same first seven instructions of P until
aborted.

This would be clear to everyone with sufficient technical competence.
This would be clear to everyone with sufficient technical competence.
This would be clear to everyone with sufficient technical competence.
This would be clear to everyone with sufficient technical competence.
This would be clear to everyone with sufficient technical competence.

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

int main()
{ P(P);
}

_P()
[00001341](01) 55 push ebp
[00001342](02) 8bec mov ebp,esp
[00001344](03) 8b4508 mov eax,[ebp+08]
[00001347](01) 50 push eax
[00001348](03) 8b4d08 mov ecx,[ebp+08]
[0000134b](01) 51 push ecx
[0000134c](05) e840feffff call 00001191
[00001351](03) 83c408 add esp,+08
[00001354](02) 85c0 test eax,eax
[00001356](02) 7402 jz 0000135a
[00001358](02) ebfe jmp 00001358
[0000135a](01) 5d pop ebp
[0000135b](01) c3 ret
Size in bytes:(0027) [0000135b]

_main()
[00001361](01) 55 push ebp
[00001362](02) 8bec mov ebp,esp
[00001364](05) 6841130000 push 00001341
[00001369](05) e8d3ffffff call 00001341
[0000136e](03) 83c404 add esp,+04
[00001371](02) 33c0 xor eax,eax
[00001373](01) 5d pop ebp
[00001374](01) c3 ret
Size in bytes:(0020) [00001374]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
....[00001361][0010224a][00000000] 55 push ebp
....[00001362][0010224a][00000000] 8bec mov ebp,esp
....[00001364][00102246][00001341] 6841130000 push 00001341
....[00001369][00102242][0000136e] e8d3ffffff call 00001341
....[00001341][0010223e][0010224a] 55 push ebp
....[00001342][0010223e][0010224a] 8bec mov ebp,esp
....[00001344][0010223e][0010224a] 8b4508 mov eax,[ebp+08]
....[00001347][0010223a][00001341] 50 push eax
....[00001348][0010223a][00001341] 8b4d08 mov ecx,[ebp+08]
....[0000134b][00102236][00001341] 51 push ecx
....[0000134c][00102232][00001351] e840feffff call 00001191

Begin Local Halt Decider Simulation Execution Trace Stored at:2122fe
....[00001341][002122ea][002122ee] 55 push ebp
....[00001342][002122ea][002122ee] 8bec mov ebp,esp
....[00001344][002122ea][002122ee] 8b4508 mov eax,[ebp+08]
....[00001347][002122e6][00001341] 50 push eax
....[00001348][002122e6][00001341] 8b4d08 mov ecx,[ebp+08]
....[0000134b][002122e2][00001341] 51 push ecx
....[0000134c][002122de][00001351] e840feffff call 00001191

....[00001341][0025cd12][0025cd16] 55 push ebp
....[00001342][0025cd12][0025cd16] 8bec mov ebp,esp
....[00001344][0025cd12][0025cd16] 8b4508 mov eax,[ebp+08]
....[00001347][0025cd0e][00001341] 50 push eax
....[00001348][0025cd0e][00001341] 8b4d08 mov ecx,[ebp+08]
....[0000134b][0025cd0a][00001341] 51 push ecx
....[0000134c][0025cd06][00001351] e840feffff call 00001191
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
....[00001351][0010223e][0010224a] 83c408 add esp,+08
....[00001354][0010223e][0010224a] 85c0 test eax,eax
....[00001356][0010223e][0010224a] 7402 jz 0000135a
....[0000135a][00102242][0000136e] 5d pop ebp
....[0000135b][00102246][00001341] c3 ret
....[0000136e][0010224a][00000000] 83c404 add esp,+04
....[00001371][0010224a][00000000] 33c0 xor eax,eax
....[00001373][0010224e][00100000] 5d pop ebp
....[00001374][00102252][00000000] c3 ret
Number of Instructions Executed(15900)

--
Copyright 2022 Pete Olcott

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

On 5/30/22 6:57 PM, olcott wrote:
> On 5/30/2022 2:17 PM, André G. Isaak wrote:
>> On 2022-05-30 11:59, olcott wrote:
>>> On 5/30/2022 11:56 AM, André G. Isaak wrote:
>>
>>>> A *correct* emulation of P(P) would emulate the exact same sequence
>>>> of instructions that occurs when you run P(P) directly,
>>>
>>> This is factually incorrect.
>>
>> How exactly? How would *you* define "correct emulation" if not as
>> above? You can propose whatever definition you want, but unless the
>> rest of the world accepts your definition you're not going to get
>> anywhere.
>>
>>> The first seven instructions are the same.
>>> The next instructions are not the same.
>>
>> Yes. They diverge. That's what it MEANS to be an INcorrect emulation.
>>
>
> The x86 source-code of P proves that they must diverge.
> When the executed P(P) calls H(P,P) it must return to P.

Right.

>
> When the simulated input to H(P,P) calls H(P,P) it cannot return to P
> because it keeps simulating the same first seven instructions of P until
> aborted.

No, that presumes that the simulated H won't ever abort.

A CORRECT simulation of that input would see that H that P calls perform
its simulation, then the simulated H deciding to abort its simulaton,
and returning to P, just like the directly executed version did.

You error is presuming that H CAN correctly simulate this input and give
an answer.

If you assume an impossibility, you can get wrong answers, you need to
double check that you assumptions actually are possible.

The fact you fail to do this shows that you are a gross amateur at doing
logic. You Arguemnt begins with a false premis, that H can do a correct
simulation of its input and answer.ca

>
> This would be clear to everyone with sufficient technical competence.
> This would be clear to everyone with sufficient technical competence.
> This would be clear to everyone with sufficient technical competence.
> This would be clear to everyone with sufficient technical competence.
> This would be clear to everyone with sufficient technical competence.

No, it shows you are not technicall competent.

All it shows is that H can not correct simulate this input and deliver
ans answer at the same time.

>
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   P(P);
> }
>
> _P()
> [00001341](01)  55              push ebp
> [00001342](02)  8bec            mov ebp,esp
> [00001344](03)  8b4508          mov eax,[ebp+08]
> [00001347](01)  50              push eax
> [00001348](03)  8b4d08          mov ecx,[ebp+08]
> [0000134b](01)  51              push ecx
> [0000134c](05)  e840feffff      call 00001191
> [00001351](03)  83c408          add esp,+08
> [00001354](02)  85c0            test eax,eax
> [00001356](02)  7402            jz 0000135a
> [00001358](02)  ebfe            jmp 00001358
> [0000135a](01)  5d              pop ebp
> [0000135b](01)  c3              ret
> Size in bytes:(0027) [0000135b]
>
> _main()
> [00001361](01)  55              push ebp
> [00001362](02)  8bec            mov ebp,esp
> [00001364](05)  6841130000      push 00001341
> [00001369](05)  e8d3ffffff      call 00001341
> [0000136e](03)  83c404          add esp,+04
> [00001371](02)  33c0            xor eax,eax
> [00001373](01)  5d              pop ebp
> [00001374](01)  c3              ret
> Size in bytes:(0020) [00001374]
>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> ...[00001361][0010224a][00000000] 55              push ebp
> ...[00001362][0010224a][00000000] 8bec            mov ebp,esp
> ...[00001364][00102246][00001341] 6841130000      push 00001341
> ...[00001369][00102242][0000136e] e8d3ffffff      call 00001341
> ...[00001341][0010223e][0010224a] 55              push ebp
> ...[00001342][0010223e][0010224a] 8bec            mov ebp,esp
> ...[00001344][0010223e][0010224a] 8b4508          mov eax,[ebp+08]
> ...[00001347][0010223a][00001341] 50              push eax
> ...[00001348][0010223a][00001341] 8b4d08          mov ecx,[ebp+08]
> ...[0000134b][00102236][00001341] 51              push ecx
> ...[0000134c][00102232][00001351] e840feffff      call 00001191
>
> Begin Local Halt Decider Simulation   Execution Trace Stored at:2122fe
> ...[00001341][002122ea][002122ee] 55              push ebp
> ...[00001342][002122ea][002122ee] 8bec            mov ebp,esp
> ...[00001344][002122ea][002122ee] 8b4508          mov eax,[ebp+08]
> ...[00001347][002122e6][00001341] 50              push eax
> ...[00001348][002122e6][00001341] 8b4d08          mov ecx,[ebp+08]
> ...[0000134b][002122e2][00001341] 51              push ecx
> ...[0000134c][002122de][00001351] e840feffff      call 00001191

And here is where the simulation goes wrong. After the call to 00001191,
the next instruction simulated needs to be the instruction at 00001191

>
> ...[00001341][0025cd12][0025cd16] 55              push ebp
> ...[00001342][0025cd12][0025cd16] 8bec            mov ebp,esp
> ...[00001344][0025cd12][0025cd16] 8b4508          mov eax,[ebp+08]
> ...[00001347][0025cd0e][00001341] 50              push eax
> ...[00001348][0025cd0e][00001341] 8b4d08          mov ecx,[ebp+08]
> ...[0000134b][0025cd0a][00001341] 51              push ecx
> ...[0000134c][0025cd06][00001351] e840feffff      call 00001191
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped

And H just made an invalid conclusion because it did not use valid
inference rules, thus it got the wrong answer.

> ...[00001351][0010223e][0010224a] 83c408          add esp,+08
> ...[00001354][0010223e][0010224a] 85c0            test eax,eax
> ...[00001356][0010223e][0010224a] 7402            jz 0000135a
> ...[0000135a][00102242][0000136e] 5d              pop ebp
> ...[0000135b][00102246][00001341] c3              ret

And here we see that the correct simulation shows that P(P) halts, and
thus the CORRECT simulation of the input to H(P,P) will halt, since the
DEFINTION of the correct simulation IS what P(P) does.

> ...[0000136e][0010224a][00000000] 83c404          add esp,+04
> ...[00001371][0010224a][00000000] 33c0            xor eax,eax
> ...[00001373][0010224e][00100000] 5d              pop ebp
> ...[00001374][00102252][00000000] c3              ret
> Number of Instructions Executed(15900)
>

Thus, this above trae PROVES that P(P) Halts, and thus the correct
simulation of the input to H(P,P) Halts, and that H doesn't do a
"Correct Simulation" (at least by the rules of the Halting Problem) so
it got the wrohg answer.

On 5/31/2022 4:05 PM, Malcolm McLean wrote:
> On Tuesday, 31 May 2022 at 13:35:24 UTC+1, Malcolm McLean wrote:
>> On Monday, 30 May 2022 at 15:35:38 UTC+1, olcott wrote:
>>>
>>> When we assume a simulating halt decider then none of the simulated
>>> inputs to the conventional proofs ever reach their final state when
>>> correctly simulated by this simulating halt decider.
>>>
>>> That you don't understand this does not make it false.
>>>
>> We can't "assume a simulating halt decider" because the proof shows,
>> or at least claims to show, that a simulating halt decider can't exist.

None of the proofs bother to specifically examine simulating halt
deciders this is their big mistake. All of the proofs simply assume that
the execution trace of the input to H(P,P) reaches the
self-contradictory part. This is a provably false assumption.

--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

On 5/31/22 6:23 PM, olcott wrote:
> On 5/31/2022 4:05 PM, Malcolm McLean wrote:
>> On Tuesday, 31 May 2022 at 13:35:24 UTC+1, Malcolm McLean wrote:
>>> On Monday, 30 May 2022 at 15:35:38 UTC+1, olcott wrote:
>>>>
>>>> When we assume a simulating halt decider then none of the simulated
>>>> inputs to the conventional proofs ever reach their final state when
>>>> correctly simulated by this simulating halt decider.
>>>>
>>>> That you don't understand this does not make it false.
>>>>
>>> We can't "assume a simulating halt decider" because the proof shows,
>>> or at least claims to show, that a simulating halt decider can't exist.
>
> None of the proofs bother to specifically examine simulating halt
> deciders this is their big mistake. All of the proofs simply assume that
> the execution trace of the input to H(P,P) reaches the
> self-contradictory part. This is a provably false assumption.
>

Because a simulating halt decider can't do something that NO halt
decider can do.

Your "Simulating Halt Decider" only gives what you call a correct answer
because it isn't actually a Halt Decider, bcuase it isn't computing the
Mapping of the Halting Problem.

Your H isn't a Halt Decider, but a POOP decider.

BY DEFINITION, A Halt Decider Accepts representations for ALL
Machine/Input Combinations that Halt, and Rejects representations for
ALL Machine/Inputs Combinations that never halt.

Since H^ applied to H^ (ala P(P)) Halts when H is given there
representation and answers that its input represents a Non-Halting
Computation, H is just WRONG as a Halt Decider.

If you can't represent that input to H, then it still fails, as you need
to be able to represent ALL Machine/Input combinations.

This is DEFINITIONALLY true.

Note, the definition NEVER mentions an "Executiom Trace", that is only a
transform allowed when the definition of simulation matches that of a
UTM where the simulation DOES match the direct execution.

Since you claim this isn't true of your simulation, you can't use that
transform, and so you are shown to NOT be working on the Halting Problem.

On 6/2/2022 6:19 AM, Malcolm McLean wrote:
> On Wednesday, 1 June 2022 at 20:03:43 UTC+1, Ben wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>>> And actually, what you have done is construct a simulating attempted halt
>>> decider, which fails on H_Hat, for reasons unrelated to the invert
>>> loop.
>> What? H_Hat(H_Hat) halts because H(H_Hat, H_Hat) == 0 so, yes, no loop
>> is involved, but that's not interesting.
>>> So you have actually achieved something of interest, if you could only
>>> recognise that.
>> What do you think is new or interesting here? I can't see anything new
>> or interesting here at all.
>>
> The "simulating halt decider" will fail when fed H_Hat, not because of the invert
> step, but because it can't solve the simulation of H. That's inherent in the way
> it is set up - it can only terminate if it detects that the series of nested
> simulations is non-terminating, in which case it becomes terminating.
>

That is not the point. The simulated input to H(P,P) only halts if it
reaches its "ret" instruction otherwise it is non-halting.

P(P) does halt yet it is an entirely different sequence of x86
instructions than the correctly simulated input to H(P,P).

People here say that they really really don't believe this thus directly
disagree with the x86 language. This is a move that only one person here
is dumb enough to make, yet more than one person does.

> I don't think anyone has actually pointed that out before. It's not going to
> revolutionise computer science. But it is an interesting observation.

--
Copyright 2022 Pete Olcott

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

On 6/2/22 8:01 AM, olcott wrote:
> On 6/2/2022 6:19 AM, Malcolm McLean wrote:
>> On Wednesday, 1 June 2022 at 20:03:43 UTC+1, Ben wrote:
>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>
>>>> And actually, what you have done is construct a simulating attempted
>>>> halt
>>>> decider, which fails on H_Hat, for reasons unrelated to the invert
>>>> loop.
>>> What? H_Hat(H_Hat) halts because H(H_Hat, H_Hat) == 0 so, yes, no loop
>>> is involved, but that's not interesting.
>>>> So you have actually achieved something of interest, if you could only
>>>> recognise that.
>>> What do you think is new or interesting here? I can't see anything new
>>> or interesting here at all.
>>>
>> The "simulating halt decider" will fail when fed H_Hat, not because of
>> the invert
>> step, but because it can't solve the simulation of H. That's inherent
>> in the way
>> it is set up - it can only terminate if it detects that the series of
>> nested
>> simulations is non-terminating, in which case it becomes terminating.
>>
>
> That is not the point. The simulated input to H(P,P) only halts if it
> reaches its "ret" instruction otherwise it is non-halting.

No, the CORRECTLY simulated input will reach the "ret" instruction (if
H(P,P) returns 0)

All you have shown is that no H can be designed to reach the "ret"
instruction in its own simumatlion of the input, but that if it aborts
its simulation to avoid making the error of not answering, it make a
mistake because it doesn't have enough information to make a correct answer.
>
> P(P) does halt yet it is an entirely different sequence of x86
> instructions than the correctly simulated input to H(P,P).
>

No, it is EXACTLY the same sequence of x86 instuctons as the input to H.
If it isn't, then your input is incorrect. Your problem is that the
"sequence of x86 instructions" that represent the PROGRAM P, include all
the instructions of the subroutine H (and everything it calls). You H
acts as if those instructions were different then they actually are, so
doesn't create a CORRECT simulation of that input.

BAD LOGIC, BAD ANSWERS, DUMB logicitian.

> People here say that they really really don't believe this thus directly
> disagree with the x86 language. This is a move that only one person here
> is dumb enough to make, yet more than one person does.

So, what do YOU think the x86 processor manual says the "call"
instruction does?

>
>> I don't think anyone has actually pointed that out before. It's not
>> going to
>> revolutionise computer science. But it is an interesting observation.
>
>

Nope, you just prove how ignorant you are.

On 6/2/2022 11:21 AM, Ben wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On Wednesday, 1 June 2022 at 20:03:43 UTC+1, Ben wrote:
>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>
>>>> And actually, what you have done is construct a simulating attempted halt
>>>> decider, which fails on H_Hat, for reasons unrelated to the invert
>>>> loop.
>>> What? H_Hat(H_Hat) halts because H(H_Hat, H_Hat) == 0 so, yes, no loop
>>> is involved, but that's not interesting.
>>>> So you have actually achieved something of interest, if you could only
>>>> recognise that.
>>> What do you think is new or interesting here? I can't see anything new
>>> or interesting here at all.
>>>
>> The "simulating halt decider" will fail when fed H_Hat, not because of
>> the invert step, but because it can't solve the simulation of H.
>
> What's new or interesting about that? A simulating partial halt decider
> really only has only two ways to be wrong: fail to return a result or
> incorrectly decide some halting computations as non-halting (ignoring
> cases where it's designed to be deliberately wrong unnecessarily).
>
> And H_Hat never has anything to do with why a decider is wrong because
> we can show that any purported halt decider must get infinitely many
> instances wrong, so there will be an abundance of examples that have
> nothing to do with H_Hat.
>
> But none of this is what PO is claiming. He claims H is right to be
> wrong so you have your work cut out if you want to get him to accept
> that H really is wrong, even if you find the reason interesting.

NO I AM NOT SAYING THAT AT ALL PLEASE PAY MUCH CLOSER ATTENTION I HAVE
HAD TO REPEAT MYSELF HUNDREDS OF TIMES AND EVERYONE CONSISTENTLY IGNORES
MY CORRECTIONS TO THEIR FALSE ASSUMPTIONS AND MISCONCEPTIONS.

It is an easily verified fact that the correctly simulated input to
H(P,P) never reaches its "ret" instruction therefore even when the
simulation is aborted P did not halt and never would halt.

This conclusively proves that H(P,P)==0 to anyone that is merely
a fully competent software engineer having the required prerequisites
of C, x86, how C translates to x86, and what x86 emulation is.

LIARS AND IDIOTS DENY THE TRUTH OF THIS
It is completely obvious that when H(P,P) correctly emulates its input
that it must emulate the first seven instructions of P. Because the
seventh instruction repeats this process we can know with complete
certainty that the emulated P never reaches its find “ret” instruction,
thus never halts.

Because Ben very very persistently refused to confirm the truth of this
I mistook him for a liar. When he acknowledged that he saw no evidence
that it is not true I acknowledged that my attribution of liar was
incorrect.

>
>> That's inherent in the way
>> it is set up - it can only terminate if it detects that the series of nested
>> simulations is non-terminating, in which case it becomes terminating.
>
> No, it terminates because it /incorrectly/ concludes that the nested
> simulations are non-terminating. PO's silly argument is that this
> conclusion is not wrong because the nested simulations /would/ be
> non-terminating if they were not terminated. Go figure.
>
>> I don't think anyone has actually pointed that out before. It's not going to
>> revolutionise computer science. But it is an interesting observation.
>
> Why would anyone want to point this out? We know simulation can't be
> used to decide halting, and we know that there are only two ways a
> decider that tries to do so can be wrong. Both come up every time this
> is taught to a class of programmers. (I've never taught it to a class
> of mathematicians but I suspect the discussion would be very different.)
>

--
Copyright 2022 Pete Olcott

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

On 6/2/2022 11:32 AM, Mike Terry wrote:
> On 02/06/2022 12:19, Malcolm McLean wrote:
>> On Wednesday, 1 June 2022 at 20:03:43 UTC+1, Ben wrote:
>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>
>>>> And actually, what you have done is construct a simulating attempted
>>>> halt
>>>> decider, which fails on H_Hat, for reasons unrelated to the invert
>>>> loop.
>>> What? H_Hat(H_Hat) halts because H(H_Hat, H_Hat) == 0 so, yes, no loop
>>> is involved, but that's not interesting.
>>>> So you have actually achieved something of interest, if you could only
>>>> recognise that.
>>> What do you think is new or interesting here? I can't see anything new
>>> or interesting here at all.
>>>
>> The "simulating halt decider" will fail when fed H_Hat, not because of
>> the invert
>> step, but because it can't solve the simulation of H. That's inherent
>> in the way
>> it is set up - it can only terminate if it detects that the series of
>> nested
>> simulations is non-terminating, in which case it becomes terminating.
>
> ..in which case it becomes terminating BECAUSE OF THE INVERT STEP.
>

AS I HAVE PROVEN MANY HUNDREDS OF TIMES THE SIMULATED INPUT TO H(P,P)
NEVER REACHES THE INVERT STEP.

It is an easily verified fact that the correctly simulated input to
H(P,P) never reaches its "ret" instruction therefore even when the
simulation is aborted P did not halt and never would halt.

This conclusively proves that H(P,P)==0 to anyone that is merely
a fully competent software engineer having the required prerequisites
of C, x86, how C translates to x86, and what x86 emulation is.

LIARS AND IDIOTS DENY THE TRUTH OF THIS
It is completely obvious that when H(P,P) correctly emulates its input
that it must emulate the first seven instructions of P. Because the
seventh instruction repeats this process we can know with complete
certainty that the emulated P never reaches its find “ret” instruction,
thus never halts.

--
Copyright 2022 Pete Olcott

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

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

The HP where a decider decides what another decider will do with an
input (Like Sipser) is too convoluted. I only address what a halt
decider does with its input (Like Linz).

Any fully competent software engineer can easily verify that H(P,P)==0
is correct.

#include <stdint.h>
#define u32 uint32_t

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

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

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

It is completely obvious that when H(P,P) correctly emulates its input
that it must emulate the first seven instructions of P. Because the
seventh instruction repeats this process we can know with complete
certainty that the emulated P never reaches its final “ret” instruction,
thus never halts.

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

--
Copyright 2022 Pete Olcott

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

On 6/2/2022 2:00 PM, Ben wrote:
> Andy Walker <anw@cuboid.co.uk> writes:
>
>> On 02/06/2022 17:21, Ben wrote:
>>> [...] We know simulation can't be
>>> used to decide halting, and we know that there are only two ways a
>>> decider that tries to do so can be wrong. Both come up every time this
>>> is taught to a class of programmers. (I've never taught it to a class
>>> of mathematicians but I suspect the discussion would be very different.)
>>
>> My first thought was "no, it's the same", but on reflexion, and AFAIR,
>> our mathematicians simply accepted what I told them, which is essentially what
>> is at
>>
>> http://www.cuboid.me.uk/anw/G12FCO/lect17.html
>>
>> [second half, but see esp the last paragraph] and
>>
>> http://www.cuboid.me.uk/anw/G12FCO/lect18.html
>
> I see your notes are an explicit counterexample to PO's claims that
> emulation is never considered!
>

The emulation is simply describing a UTM not applying an adapted UTM to
the HP.

>> [both lectures from a module that I gave many moons ago]. We got pretty
>> bright students, among the top four or five cohorts in the UK at that time
>> [1990s] [but that was our high point, even beating Oxford one year], and of
>> course many of them went into IT as a career. They found NP-completeness
>> much harder than UTMs, HP and related stuff.
>
> We got pretty bright students too. Bright students ask good questions
> but eventually (rapidly even) settle the matter to their own
> satisfaction.
>
> And I agree that complexity is more... complex. The details become so
> very significant in complexity theory. One of the depressing things
> about these endless threads is that this is not a complex theorem.
>

--
Copyright 2022 Pete Olcott

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

On 6/2/2022 2:00 PM, Ben wrote:
> Andy Walker <anw@cuboid.co.uk> writes:
>
>> On 02/06/2022 17:21, Ben wrote:
>>> [...] We know simulation can't be
>>> used to decide halting, and we know that there are only two ways a
>>> decider that tries to do so can be wrong. Both come up every time this
>>> is taught to a class of programmers. (I've never taught it to a class
>>> of mathematicians but I suspect the discussion would be very different.)
>>
>> My first thought was "no, it's the same", but on reflexion, and AFAIR,
>> our mathematicians simply accepted what I told them, which is essentially what
>> is at
>>
>> http://www.cuboid.me.uk/anw/G12FCO/lect17.html
>>
>> [second half, but see esp the last paragraph] and
>>
>> http://www.cuboid.me.uk/anw/G12FCO/lect18.html
>
> I see your notes are an explicit counterexample to PO's claims that
> emulation is never considered!
>

For these cases, we can turn to our second weapon -- emulation. We want
to know whether a program halts, so we try it. If it halts, then we know
the answer. If it doesn't halt, then `it must be in a loop', so we
monitor its state and `detect the loop'. Sadly, although this is in one
sense correct, it is a false dichotomy. At any given moment as the
emulation proceeds, we are in one of not two but three states: the
program has halted, or it is looping, or it is still running and has not
yet entered a loop. It's the third case that kills us -- we just have to
keep going, and wait for one of the other two things to happen. The
trouble is that it may be that neither of them ever happens -- which is
why `it must be in a loop' was in quotes above.

It is not considered correctly.
(a) the program has halted
(b) the program is still running
(c) the program matched an infinite behavior pattern

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

H(P,P)==0 for the above behavior pattern. (The entire research scope)

>> [both lectures from a module that I gave many moons ago]. We got pretty
>> bright students, among the top four or five cohorts in the UK at that time
>> [1990s] [but that was our high point, even beating Oxford one year], and of
>> course many of them went into IT as a career. They found NP-completeness
>> much harder than UTMs, HP and related stuff.
>
> We got pretty bright students too. Bright students ask good questions
> but eventually (rapidly even) settle the matter to their own
> satisfaction.
>
> And I agree that complexity is more... complex. The details become so
> very significant in complexity theory. One of the depressing things
> about these endless threads is that this is not a complex theorem.
>

--
Copyright 2022 Pete Olcott

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

On 6/2/2022 1:12 PM, Andy Walker wrote:
> On 02/06/2022 17:21, Ben wrote:
>> [...]  We know simulation can't be
>> used to decide halting, and we know that there are only two ways a
>> decider that tries to do so can be wrong.  Both come up every time this
>> is taught to a class of programmers.  (I've never taught it to a class
>> of mathematicians but I suspect the discussion would be very different.)
>
>     My first thought was "no, it's the same", but on reflexion, and AFAIR,
> our mathematicians simply accepted what I told them, which is
> essentially what
> is at
>
>     http://www.cuboid.me.uk/anw/G12FCO/lect17.html
>
> [second half, but see esp the last paragraph] and
>
>     http://www.cuboid.me.uk/anw/G12FCO/lect18.html
>

For these cases, we can turn to our second weapon -- emulation. We want
to know whether a program halts, so we try it. If it halts, then we know
the answer. If it doesn't halt, then `it must be in a loop', so we
monitor its state and `detect the loop'. Sadly, although this is in one
sense correct, it is a false dichotomy. At any given moment as the
emulation proceeds, we are in one of not two but three states: the
program has halted, or it is looping, or it is still running and has not
yet entered a loop. It's the third case that kills us -- we just have to
keep going, and wait for one of the other two things to happen. The
trouble is that it may be that neither of them ever happens -- which is
why `it must be in a loop' was in quotes above.

It is not considered correctly.
(a) the program has halted
(b) the program is still running
(c) the program matched an infinite behavior pattern

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

Any competent software engineer can verify that H(P,P)==0
for the above behavior pattern. (The entire research scope)
As detailed in my paper:

Halting problem undecidability and infinitely nested simulation (V5)

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

> [both lectures from a module that I gave many moons ago].  We got pretty
> bright students, among the top four or five cohorts in the UK at that time
> [1990s] [but that was our high point, even beating Oxford one year], and of
> course many of them went into IT as a career.  They found NP-completeness
> much harder than UTMs, HP and related stuff.
>
>     [The code G12FCO means G1 -- maths, 2 -- second year, FCO -- Formal
> Computation.]
>

--
Copyright 2022 Pete Olcott

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

On Thu, 2 Jun 2022 15:47:22 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 6/2/2022 1:12 PM, Andy Walker wrote:
> > On 02/06/2022 17:21, Ben wrote:
> >> [...]  We know simulation can't be
> >> used to decide halting, and we know that there are only two ways a
> >> decider that tries to do so can be wrong.  Both come up every time
> >> this is taught to a class of programmers.  (I've never taught it
> >> to a class of mathematicians but I suspect the discussion would be
> >> very different.)
> >
> >     My first thought was "no, it's the same", but on reflexion,
> > and AFAIR, our mathematicians simply accepted what I told them,
> > which is essentially what
> > is at
> >
> >     http://www.cuboid.me.uk/anw/G12FCO/lect17.html
> >
> > [second half, but see esp the last paragraph] and
> >
> >     http://www.cuboid.me.uk/anw/G12FCO/lect18.html
> >
>
>
> For these cases, we can turn to our second weapon -- emulation. We
> want to know whether a program halts, so we try it. If it halts, then
> we know the answer. If it doesn't halt, then `it must be in a loop',
> so we monitor its state and `detect the loop'. Sadly, although this
> is in one sense correct, it is a false dichotomy. At any given moment
> as the emulation proceeds, we are in one of not two but three states:
> the program has halted, or it is looping, or it is still running and
> has not yet entered a loop. It's the third case that kills us -- we
> just have to keep going, and wait for one of the other two things to
> happen. The trouble is that it may be that neither of them ever
> happens -- which is why `it must be in a loop' was in quotes above.
>
> It is not considered correctly.
> (a) the program has halted
> (b) the program is still running
> (c) the program matched an infinite behavior pattern
>
> For any program H that might determine if programs halt, a
> "pathological"
> program P, called with some input, can pass its own source and
> its input to
> H and then specifically do the opposite of what H predicts P
> will do. No H
> can exist that handles this case.
> https://en.wikipedia.org/wiki/Halting_problem
>
> Any competent software engineer can verify that H(P,P)==0
> for the above behavior pattern. (The entire research scope)
> As detailed in my paper:
>
> Halting problem undecidability and infinitely nested simulation (V5)
>
> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>

The proofs you are attempting to refute do not contain the infinite
behaviour pattern you describe; you have been told this multiple times
now and keep ignoring it: is this because you have actually given up
trying to refute those proofs?

/Flibble

On 6/2/2022 6:38 PM, Mr Flibble wrote:
> On Thu, 2 Jun 2022 15:47:22 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 6/2/2022 1:12 PM, Andy Walker wrote:
>>> On 02/06/2022 17:21, Ben wrote:
>>>> [...]  We know simulation can't be
>>>> used to decide halting, and we know that there are only two ways a
>>>> decider that tries to do so can be wrong.  Both come up every time
>>>> this is taught to a class of programmers.  (I've never taught it
>>>> to a class of mathematicians but I suspect the discussion would be
>>>> very different.)
>>>
>>>     My first thought was "no, it's the same", but on reflexion,
>>> and AFAIR, our mathematicians simply accepted what I told them,
>>> which is essentially what
>>> is at
>>>
>>>     http://www.cuboid.me.uk/anw/G12FCO/lect17.html
>>>
>>> [second half, but see esp the last paragraph] and
>>>
>>>     http://www.cuboid.me.uk/anw/G12FCO/lect18.html
>>>
>>
>>
>> For these cases, we can turn to our second weapon -- emulation. We
>> want to know whether a program halts, so we try it. If it halts, then
>> we know the answer. If it doesn't halt, then `it must be in a loop',
>> so we monitor its state and `detect the loop'. Sadly, although this
>> is in one sense correct, it is a false dichotomy. At any given moment
>> as the emulation proceeds, we are in one of not two but three states:
>> the program has halted, or it is looping, or it is still running and
>> has not yet entered a loop. It's the third case that kills us -- we
>> just have to keep going, and wait for one of the other two things to
>> happen. The trouble is that it may be that neither of them ever
>> happens -- which is why `it must be in a loop' was in quotes above.
>>
>> It is not considered correctly.
>> (a) the program has halted
>> (b) the program is still running
>> (c) the program matched an infinite behavior pattern
>>
>> For any program H that might determine if programs halt, a
>> "pathological"
>> program P, called with some input, can pass its own source and
>> its input to
>> H and then specifically do the opposite of what H predicts P
>> will do. No H
>> can exist that handles this case.
>> https://en.wikipedia.org/wiki/Halting_problem
>>
>> Any competent software engineer can verify that H(P,P)==0
>> for the above behavior pattern. (The entire research scope)
>> As detailed in my paper:
>>
>> Halting problem undecidability and infinitely nested simulation (V5)
>>
>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>
>
> The proofs you are attempting to refute do not contain the infinite
> behaviour pattern you describe;

The correctly simulated input to a simulating halt decider never reaches
the final instruction of this simulated input thus is unequivocally
non-halting.

Halting does not mean stopped running, it means terminated normally.

Whether or not this simulated input specifies infinite behavior is a
matter of how one defines one's terms and makes no difference because
the behavior that it does exhibit is still correctly construed as
non-halting even after its simulation has been aborted.

>you have been told this multiple times
> now and keep ignoring it:

Every time that I correct my reviewers false assumptions and
misconceptions they always make sure to not read a single word of what I
have said.

It is always blah blah blah we know you must be wrong so there is no
sense in reading what your reply.

> is this because you have actually given up
> trying to refute those proofs?
>
> /Flibble
>

--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

On 6/2/22 7:45 PM, olcott wrote:
> On 6/2/2022 6:38 PM, Mr Flibble wrote:
>> On Thu, 2 Jun 2022 15:47:22 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 6/2/2022 1:12 PM, Andy Walker wrote:
>>>> On 02/06/2022 17:21, Ben wrote:
>>>>> [...]  We know simulation can't be
>>>>> used to decide halting, and we know that there are only two ways a
>>>>> decider that tries to do so can be wrong.  Both come up every time
>>>>> this is taught to a class of programmers.  (I've never taught it
>>>>> to a class of mathematicians but I suspect the discussion would be
>>>>> very different.)
>>>>
>>>>       My first thought was "no, it's the same", but on reflexion,
>>>> and AFAIR, our mathematicians simply accepted what I told them,
>>>> which is essentially what
>>>> is at
>>>>
>>>>       http://www.cuboid.me.uk/anw/G12FCO/lect17.html
>>>>
>>>> [second half, but see esp the last paragraph] and
>>>>
>>>>       http://www.cuboid.me.uk/anw/G12FCO/lect18.html
>>>
>>>
>>> For these cases, we can turn to our second weapon -- emulation. We
>>> want to know whether a program halts, so we try it. If it halts, then
>>> we know the answer. If it doesn't halt, then `it must be in a loop',
>>> so we monitor its state and `detect the loop'. Sadly, although this
>>> is in one sense correct, it is a false dichotomy. At any given moment
>>> as the emulation proceeds, we are in one of not two but three states:
>>> the program has halted, or it is looping, or it is still running and
>>> has not yet entered a loop. It's the third case that kills us -- we
>>> just have to keep going, and wait for one of the other two things to
>>> happen. The trouble is that it may be that neither of them ever
>>> happens -- which is why `it must be in a loop' was in quotes above.
>>>
>>> It is not considered correctly.
>>> (a) the program has halted
>>> (b) the program is still running
>>> (c) the program matched an infinite behavior pattern
>>>
>>>        For any program H that might determine if programs halt, a
>>> "pathological"
>>>        program P, called with some input, can pass its own source and
>>> its input to
>>>        H and then specifically do the opposite of what H predicts P
>>> will do. No H
>>>        can exist that handles this case.
>>> https://en.wikipedia.org/wiki/Halting_problem
>>>
>>> Any competent software engineer can verify that H(P,P)==0
>>> for the above behavior pattern. (The entire research scope)
>>> As detailed in my paper:
>>>
>>> Halting problem undecidability and infinitely nested simulation (V5)
>>>
>>> https://www.researchgate.net/publication/359984584_Halting_problem_undecidability_and_infinitely_nested_simulation_V5
>>>
>>>
>>
>> The proofs you are attempting to refute do not contain the infinite
>> behaviour pattern you describe;
>
> The correctly simulated input to a simulating halt decider never reaches
> the final instruction of this simulated input thus is unequivocally
> non-halting.

You keep on saying that, but it isn't actually true for the PROPER
definition of "correct simulation", that being, the simulation of the
input by a UTM equiavlent. (or an x86 processor for your x86 code).

What you want to call "correct simulation" is the partial simulation by
a particular H, but partial simulation are NEVER "correct" because they
are, by definitin=on, INCOMPLETE.

>
> Halting does not mean stopped running, it means terminated normally., so we can

Non-Halting also doesn't meen only partially run and it didn't reach
completion yet.

Note, the CORRECT simulation of the input to H will terminate normally,
It is only that H didn't complete its simulation.

Your arguement about "ANY H" is invalid, as H isn't just "ANY H" but is
a particualar H, and each of the possible H's your "ANY H" talks about
have DIFFERENT inputs so you can't use your "logic" to try to tight them
together.

That is a bit like saying the number N+5 is infinite for any finte
number N, since no matter what N you choose, N+5 is bigger than you
number, so that must mean that N+5 is bigger than all numbers, and thus
infinite.

Hopefully you can see the silliness of that claim, that is exact the
sort of claim you are making with your "any H" claim.

Given an H that aborts its simulation in "N" steps, we can show that
P(P) will halt is some number of steps that can be computed as f(N) > N,
but still finite. Your "ANY N" arguement to claim that P in non-halting
is saying that f(N) is infinite, when it is actually a finite number
just bigger then the N for that H.

>
> Whether or not this simulated input specifies infinite behavior is a
> matter of how one defines one's terms and makes no difference because
> the behavior that it does exhibit is still correctly construed as
> non-halting even after its simulation has been aborted.

Nope. Since there is ONE definition of Halting, and that is does the
ACTUAL MACHINE reach a final state in a finite number of steps, any
defintion that can't be proved to be EXACTLY EQUIVALENT is BY DEFINITION
incorrect.

With your definition of "Correctly Simulated' being based on the
simulation of the decider, that isn't true, so you can't use it as an
alternate definition of halting, so your definition is just INCORRECT.

>
>> you have been told this multiple times
>> now and keep ignoring it:
>
> Every time that I correct my reviewers false assumptions and
> misconceptions they always make sure to not read a single word of what I
> have said.

Nope, YOU don't read what people say and thus PROVE that you are just a
pathological liar or a totally incompetent and ignorate fool.

>
> It is always blah blah blah we know you must be wrong so there is no
> sense in reading what your reply.

So, what is actually wrong with what I said, or are YOU the one just
going blah, blah, blah?

(My guess is that is exactly what you will do, thus proving your status
as a fool)

>
>> is this because you have actually given up
>> trying to refute those proofs?
>>
>> /Flibble
>>
>
>

On 6/2/22 2:42 PM, olcott wrote:
> On 6/2/2022 11:21 AM, Ben wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>> On Wednesday, 1 June 2022 at 20:03:43 UTC+1, Ben wrote:
>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>
>>>>> And actually, what you have done is construct a simulating
>>>>> attempted halt
>>>>> decider, which fails on H_Hat, for reasons unrelated to the invert
>>>>> loop.
>>>> What? H_Hat(H_Hat) halts because H(H_Hat, H_Hat) == 0 so, yes, no loop
>>>> is involved, but that's not interesting.
>>>>> So you have actually achieved something of interest, if you could only
>>>>> recognise that.
>>>> What do you think is new or interesting here? I can't see anything new
>>>> or interesting here at all.
>>>>
>>> The "simulating halt decider" will fail when fed H_Hat, not because of
>>> the invert step, but because it can't solve the simulation of H.
>>
>> What's new or interesting about that?  A simulating partial halt decider
>> really only has only two ways to be wrong: fail to return a result or
>> incorrectly decide some halting computations as non-halting (ignoring
>> cases where it's designed to be deliberately wrong unnecessarily).
>>
>> And H_Hat never has anything to do with why a decider is wrong because
>> we can show that any purported halt decider must get infinitely many
>> instances wrong, so there will be an abundance of examples that have
>> nothing to do with H_Hat.
>>
>> But none of this is what PO is claiming.  He claims H is right to be
>> wrong so you have your work cut out if you want to get him to accept
>> that H really is wrong, even if you find the reason interesting.
>
> NO I AM NOT SAYING THAT AT ALL PLEASE PAY MUCH CLOSER ATTENTION I HAVE
> HAD TO REPEAT MYSELF HUNDREDS OF TIMES AND EVERYONE CONSISTENTLY IGNORES
> MY CORRECTIONS TO THEIR FALSE ASSUMPTIONS AND MISCONCEPTIONS.
>
> It is an easily verified fact that the correctly simulated input to
> H(P,P) never reaches its "ret" instruction therefore even when the
> simulation is aborted P did not halt and never would halt.

Really, then what have traces of this input being correctly simulated
been posted showing that it does reach the re tstatement.

Perhaps the problem is that you are using wrong definitions of what a
correct simulation is?

If you mean something besides the simulation that exactly duplicates the
behavor of the machine that the input rerpesents, you need to CLEARLY
state what you think the definition is and show why it is correct.

Note, just saying that you think it makes more sense isn't actually a
good reason.

>
> This conclusively proves that H(P,P)==0 to anyone that is merely
> a fully competent software engineer having the required prerequisites
> of C, x86, how C translates to x86, and what x86 emulation is.
>

No, it just shows that you don't know what the right definitions are.

> LIARS AND IDIOTS DENY THE TRUTH OF THIS
> It is completely obvious that when H(P,P) correctly emulates its input
> that it must emulate the first seven instructions of P. Because the
> seventh instruction repeats this process we can know with complete
> certainty that the emulated P never reaches its find “ret” instruction,
> thus never halts.

OK, so you show your ignorance as to what a correct emulation of
assembly code is.

The is ZERO grounds for the "break" in your simulation, thus it is
INCORRECT, and your instance that it is "correct" proves you to be a liar.

The ONLY correct simulation of the input needs to show the exectution of
the eighth instruction too, since that is what the code IS.

You failure to see that shows that you just don't understand how
computers works.

>
> Because Ben very very persistently refused to confirm the truth of this
> I mistook him for a liar. When he acknowledged that he saw no evidence
> that it is not true I acknowledged that my attribution of liar was
> incorrect.
>
>
>>
>>> That's inherent in the way
>>> it is set up - it can only terminate if it detects that the series of
>>> nested
>>> simulations is non-terminating, in which case it becomes terminating.
>>
>> No, it terminates because it /incorrectly/ concludes that the nested
>> simulations are non-terminating.  PO's silly argument is that this
>> conclusion is not wrong because the nested simulations /would/ be
>> non-terminating if they were not terminated.  Go figure.
>>
>>> I don't think anyone has actually pointed that out before. It's not
>>> going to
>>> revolutionise computer science. But it is an interesting observation.
>>
>> Why would anyone want to point this out?  We know simulation can't be
>> used to decide halting, and we know that there are only two ways a
>> decider that tries to do so can be wrong.  Both come up every time this
>> is taught to a class of programmers.  (I've never taught it to a class
>> of mathematicians but I suspect the discussion would be very different.)
>>
>
>

On 6/2/22 2:47 PM, olcott wrote:
> On 6/2/2022 11:32 AM, Mike Terry wrote:
>> On 02/06/2022 12:19, Malcolm McLean wrote:
>>> On Wednesday, 1 June 2022 at 20:03:43 UTC+1, Ben wrote:
>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>
>>>>> And actually, what you have done is construct a simulating
>>>>> attempted halt
>>>>> decider, which fails on H_Hat, for reasons unrelated to the invert
>>>>> loop.
>>>> What? H_Hat(H_Hat) halts because H(H_Hat, H_Hat) == 0 so, yes, no loop
>>>> is involved, but that's not interesting.
>>>>> So you have actually achieved something of interest, if you could only
>>>>> recognise that.
>>>> What do you think is new or interesting here? I can't see anything new
>>>> or interesting here at all.
>>>>
>>> The "simulating halt decider" will fail when fed H_Hat, not because
>>> of the invert
>>> step, but because it can't solve the simulation of H. That's inherent
>>> in the way
>>> it is set up - it can only terminate if it detects that the series of
>>> nested
>>> simulations is non-terminating, in which case it becomes terminating.
>>
>> ..in which case it becomes terminating BECAUSE OF THE INVERT STEP.
>>
>
> AS I HAVE PROVEN MANY HUNDREDS OF TIMES THE SIMULATED INPUT TO H(P,P)
> NEVER REACHES THE INVERT STEP.

You hav shown that the PARTIAL simulation by H never reaches that step.

You CLAIM this is a correct simulation,

>
> It is an easily verified fact that the correctly simulated input to
> H(P,P) never reaches its "ret" instruction therefore even when the
> simulation is aborted P did not halt and never would halt.

Nope, LIE. FAIL.

>
> This conclusively proves that H(P,P)==0 to anyone that is merely
> a fully competent software engineer having the required prerequisites
> of C, x86, how C translates to x86, and what x86 emulation is.

Nope, LIE, FAIL.

>
> LIARS AND IDIOTS DENY THE TRUTH OF THIS
> It is completely obvious that when H(P,P) correctly emulates its input
> that it must emulate the first seven instructions of P. Because the
> seventh instruction repeats this process we can know with complete
> certainty that the emulated P never reaches its find “ret” instruction,
> thus never halts.
>
>

YOU ARE THE LIAR because you use FALSE definitions.

It is actually completely true that a real correct simulation of the
input to HH(P,P) must match the behavior of P(P), and go through all the
instructions of the copy of H that P calls, and see that H abort its
simulation of ITS input, and returning its answer to the P that called
it, and that P reaching its "ret" instruction.

It is IMPOSSIBLE for H to do this, but that doesn't change the
definition of a CORRECT simulation.

The ONLY way that H can be a "Correct Simulator" is for it to NEVER
abort its simulation, and then if fails to answer. Yes, if THAT is your
H, then P(P) is non-halting, and H(P,P) returning zero WOULD have been a
right answer for the problem, but NOT correct behavior for the machine,
as we started with the premise that H didn't abort (or that it actual
was a correct simulator, which is the same thing).

You just show that you don't understand the meaning of the terms that
you use.

On 6/2/22 3:54 PM, olcott wrote:
> On 6/2/2022 2:00 PM, Ben wrote:
>> Andy Walker <anw@cuboid.co.uk> writes:
>>
>>> On 02/06/2022 17:21, Ben wrote:
>>>> [...]  We know simulation can't be
>>>> used to decide halting, and we know that there are only two ways a
>>>> decider that tries to do so can be wrong.  Both come up every time this
>>>> is taught to a class of programmers.  (I've never taught it to a class
>>>> of mathematicians but I suspect the discussion would be very
>>>> different.)
>>>
>>>     My first thought was "no, it's the same", but on reflexion, and
>>> AFAIR,
>>> our mathematicians simply accepted what I told them, which is
>>> essentially what
>>> is at
>>>
>>>     http://www.cuboid.me.uk/anw/G12FCO/lect17.html
>>>
>>> [second half, but see esp the last paragraph] and
>>>
>>>     http://www.cuboid.me.uk/anw/G12FCO/lect18.html
>>
>> I see your notes are an explicit counterexample to PO's claims that
>> emulation is never considered!
>>
>
> For these cases, we can turn to our second weapon -- emulation. We want
> to know whether a program halts, so we try it. If it halts, then we know
> the answer. If it doesn't halt, then `it must be in a loop', so we
> monitor its state and `detect the loop'. Sadly, although this is in one
> sense correct, it is a false dichotomy. At any given moment as the
> emulation proceeds, we are in one of not two but three states: the
> program has halted, or it is looping, or it is still running and has not
> yet entered a loop. It's the third case that kills us -- we just have to
> keep going, and wait for one of the other two things to happen. The
> trouble is that it may be that neither of them ever happens -- which is
> why `it must be in a loop' was in quotes above.
>
> It is not considered correctly.
> (a) the program has halted
> (b) the program is still running
> (c) the program matched an infinite behavior pattern
>
>      For any program H that might determine if programs halt, a
> "pathological"
>      program P, called with some input, can pass its own source and its
> input to
>      H and then specifically do the opposite of what H predicts P will
> do. No H
>      can exist that handles this case.
> https://en.wikipedia.org/wiki/Halting_problem
>
> H(P,P)==0 for the above behavior pattern. (The entire research scope)
>
>

And your problem is that while H is simulating its input H^, that H^ is
in the state (b) case, not state (c).

This is shown because if H THINKS that H^ has entered state (c), then
when we actually look that what H^ does, we see that after H has aborted
it, that an ACTUAL CORRECT simulation of this input that does continue
will see the H that this H^ is using also making that same (incorrect)
decision, aborting its simulation, and returning to H^ and then H^
entering state (a).

There is no ACTUAL finite pattern that H sees in its simulation of H^
applied to H^ that actually correctly matchs a correct "infinite behavor
pattern".

You just don't seem to be smart enough to understand this.

>>> [both lectures from a module that I gave many moons ago].  We got pretty
>>> bright students, among the top four or five cohorts in the UK at that
>>> time
>>> [1990s] [but that was our high point, even beating Oxford one year],
>>> and of
>>> course many of them went into IT as a career.  They found
>>> NP-completeness
>>> much harder than UTMs, HP and related stuff.
>>
>> We got pretty bright students too.  Bright students ask good questions
>> but eventually (rapidly even) settle the matter to their own
>> satisfaction.
>>
>> And I agree that complexity is more... complex.  The details become so
>> very significant in complexity theory.  One of the depressing things
>> about these endless threads is that this is not a complex theorem.
>>
>
>

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

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

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

In other words you keep saying the same cockamamy bullshit that it is
utterly impossible to correctly determine what a complete simulation
would be from a partial simulation.

This is the exactly same numbskull idea that it is utterly impossible to
determine that a loop is infinite until after waiting forever to see if
it stops running. *Why are you such a jackass?*

--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

On Fri, 3 Jun 2022 16:08:34 -0500
olcott <polcott2@gmail.com> wrote:

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

Your "infinite loop" only starts if an infinite recursion is detected
however the proofs you are attempting to refute contain no such
infinite recursion so your "infinite loop" is irrelevant.

/Flibble

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

That you can't comprehend that the full correct x86 emulation of the
input to H(P,P) by H would never stop running shows that your software
engineering skills are woefully insufficient to evalulate my work.

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

Like H0(Infinite_Loop) does not need to perform a complete x86 emulation
of its input to correctly determine the behavior of a complete emulation
H(P,P) correctly determines that its input would never halt.

--
Copyright 2022 Pete Olcott

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

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

That you can't comprehend that the full correct x86 emulation of the
input to H(P,P) by H would never stop running shows that your software
engineering skills are woefully insufficient to evaluate my work.

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

It is completely obvious that when H(P,P) correctly emulates its input
that it must emulate the first seven instructions of P. Because the
seventh instruction repeats this process we can know with complete
certainty that the emulated P never reaches its final “ret” instruction,
thus never halts.

Like H0(Infinite_Loop) does not need to perform a complete x86 emulation
of its input to correctly determine the behavior of a complete emulation
H(P,P) correctly determines that its input would never halt.

--
Copyright 2022 Pete Olcott

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