A simulating halt decider computes the mapping from its inputs to its
own final states on the basis of the behavior of its correctly simulated
input.

All of the conventional halting problem counter-example inputs are
simply rejected by a simulating halt decider as non-halting because they
fail to meet the Linz definition of halting:

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

USENET comp.theory: On 4/11/2022 3:19 PM, Malcolm McLean wrote:
> PO's idea is to have a simulator with an infinite cycle detector.
> You would achieve this by modifying a UTM, so describing it as
> a "modified UTM", or "acts like a UTM until it detects an infinite
> cycle", is reasonable. And such a machine is a fairly powerful
> halt decider. Even if the infinite cycle detector isn't very
> sophisticated, it will still catch a large subset of non-halting
> machines.

The following simplifies the syntax for the definition of the Linz
Turing machine Ĥ.

There is no need for the infinite loop after H.qy because it is never
reached.

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

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

When Ĥ is applied to ⟨Ĥ⟩
Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩

Then these steps would keep repeating: (unless their simulation is aborted)
Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then H2 simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩...

Since we can see that the simulated input: ⟨Ĥ0⟩ to H would never reach
its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ we know that it is non-halting.

Here is the same thing that has all of the missing Linz ⊢* wildcard
state transitions filled in by fully operational code. H uses an x86
emulator to simulate its input one x86 instruction at a time.

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

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

_P()
[000009d6](01) 55 push ebp
[000009d7](02) 8bec mov ebp,esp
[000009d9](03) 8b4508 mov eax,[ebp+08]
[000009dc](01) 50 push eax // push P
[000009dd](03) 8b4d08 mov ecx,[ebp+08]
[000009e0](01) 51 push ecx // push P
[000009e1](05) e840feffff call 00000826 // call H
[000009e6](03) 83c408 add esp,+08
[000009e9](02) 85c0 test eax,eax
[000009eb](02) 7402 jz 000009ef
[000009ed](02) ebfe jmp 000009ed
[000009ef](01) 5d pop ebp
[000009f0](01) c3 ret // Final state
Size in bytes:(0027) [000009f0]

Begin Local Halt Decider Simulation
....[000009d6][00211368][0021136c] 55 push ebp // enter P
....[000009d7][00211368][0021136c] 8bec mov ebp,esp
....[000009d9][00211368][0021136c] 8b4508 mov eax,[ebp+08]
....[000009dc][00211364][000009d6] 50 push eax // Push P
....[000009dd][00211364][000009d6] 8b4d08 mov ecx,[ebp+08]
....[000009e0][00211360][000009d6] 51 push ecx // Push P
....[000009e1][0021135c][000009e6] e840feffff call 00000826 // Call H
....[000009d6][0025bd90][0025bd94] 55 push ebp // enter P
....[000009d7][0025bd90][0025bd94] 8bec mov ebp,esp
....[000009d9][0025bd90][0025bd94] 8b4508 mov eax,[ebp+08]
....[000009dc][0025bd8c][000009d6] 50 push eax // Push P
....[000009dd][0025bd8c][000009d6] 8b4d08 mov ecx,[ebp+08]
....[000009e0][0025bd88][000009d6] 51 push ecx // Push P
....[000009e1][0025bd84][000009e6] e840feffff call 00000826 // Call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Because the correctly simulated input to H(P,P) cannot possibly reach
its own final state at [000009f0] it is necessarily correct for H to
reject this input as non-halting.

As long as the correctly simulated input to H(P,P) would never halt then
we know it is non-halting.

Anyone that disagrees with this is a liar by definition.
Anyone that disagrees with this is a liar by definition.
Anyone that disagrees with this is a liar by definition.

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 4/15/22 2:33 PM, olcott wrote:
> A simulating halt decider computes the mapping from its inputs to its
> own final states on the basis of the behavior of its correctly simulated
> input.
>
> All of the conventional halting problem counter-example inputs are
> simply rejected by a simulating halt decider as non-halting because they
> fail to meet the Linz definition of halting:
>
> computation that halts … the Turing machine will halt whenever it enters
> a final state. (Linz:1990:234)
>
> USENET comp.theory: On 4/11/2022 3:19 PM, Malcolm McLean wrote:
> > PO's idea is to have a simulator with an infinite cycle detector.
> > You would achieve this by modifying a UTM, so describing it as
> > a "modified UTM", or "acts like a UTM until it detects an infinite
> > cycle", is reasonable. And such a machine is a fairly powerful
> > halt decider. Even if the infinite cycle detector isn't very
> > sophisticated, it will still catch a large subset of non-halting
> > machines.
>
> The following simplifies the syntax for the definition of the Linz
> Turing machine Ĥ.
>
> There is no need for the infinite loop after H.qy because it is never
> reached.

Unless of course you try to say that since H^ applied to <H^> Halts, H
is correct in going to Qy.

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

Right, and 'correctly simulated' here means by a UTM, which means is
equivalent to the behavior of H^ applied to <H^>
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would never reach its own
> final state.

Right, see above.

>
> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ copies its input ⟨Ĥ0⟩ to ⟨Ĥ1⟩ then H simulates ⟨Ĥ0⟩ ⟨Ĥ1⟩
>
> Then these steps would keep repeating: (unless their simulation is aborted)
> Ĥ0 copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then H0 simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
> Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then H1 simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
> Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then H2 simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩...

If that is the ACTUAL trace of the machine (and ... means forever), you
have just established that your H will NEVER abort its simulation, and
thus H never answers and thus fails to meet the requirement.
>
> Since we can see that the simulated input: ⟨Ĥ0⟩ to H would never reach
> its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ we know that it is non-halting.
>

Yes, THAT H^ is non-halting, because it is based on an H that fails to
anwer.

>
> Here is the same thing that has all of the missing Linz ⊢* wildcard
> state transitions filled in by fully operational code. H uses an x86
> emulator to simulate its input one x86 instruction at a time.
>
> void P(u32 x)
> {
>   if (H(x, x)) //
>     HERE: goto HERE;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H((u32)P, (u32)P));
> }
>
> _P()
> [000009d6](01) 55 push ebp
> [000009d7](02) 8bec mov ebp,esp
> [000009d9](03) 8b4508 mov eax,[ebp+08]
> [000009dc](01) 50 push eax              // push P
> [000009dd](03) 8b4d08 mov ecx,[ebp+08]
> [000009e0](01) 51 push ecx              // push P
> [000009e1](05) e840feffff call 00000826 // call H
> [000009e6](03) 83c408 add esp,+08
> [000009e9](02) 85c0 test eax,eax
> [000009eb](02) 7402 jz 000009ef
> [000009ed](02) ebfe jmp 000009ed
> [000009ef](01) 5d pop ebp
> [000009f0](01) c3 ret                  // Final state
> Size in bytes:(0027) [000009f0]
>
> Begin Local Halt Decider Simulation
> ...[000009d6][00211368][0021136c] 55 push ebp              // enter P
> ...[000009d7][00211368][0021136c] 8bec mov ebp,esp
> ...[000009d9][00211368][0021136c] 8b4508 mov eax,[ebp+08]
> ...[000009dc][00211364][000009d6] 50 push eax              // Push P
> ...[000009dd][00211364][000009d6] 8b4d08 mov ecx,[ebp+08]
> ...[000009e0][00211360][000009d6] 51 push ecx              // Push P
> ...[000009e1][0021135c][000009e6] e840feffff call 00000826 // Call H
> ...[000009d6][0025bd90][0025bd94] 55 push ebp              // enter P
> ...[000009d7][0025bd90][0025bd94] 8bec mov ebp,esp
> ...[000009d9][0025bd90][0025bd94] 8b4508 mov eax,[ebp+08]
> ...[000009dc][0025bd8c][000009d6] 50 push eax              // Push P
> ...[000009dd][0025bd8c][000009d6] 8b4d08 mov ecx,[ebp+08]
> ...[000009e0][0025bd88][000009d6] 51 push ecx              // Push P
> ...[000009e1][0025bd84][000009e6] e840feffff call 00000826 // Call H
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>
> Because the correctly simulated input to H(P,P) cannot possibly reach
> its own final state at [000009f0] it is necessarily correct for H to
> reject this input as non-halting.

Nope, you have only prove that the input is non-halting when H fails tot
answer. Use an H that doesn't meet that specifiecaiton and your proof
doesn't hold.

>
> As long as the correctly simulated input to H(P,P) would never halt then
> we know it is non-halting.

Right, and that only happens when H fails to answer. If H answer false,
then when the input is correctly simulated it will halt.

>
> Anyone that disagrees with this is a liar by definition.
> Anyone that disagrees with this is a liar by definition.
> Anyone that disagrees with this is a liar by definition.
>

So? Since you haven't established your premise, you have't established
your conclusion.

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

Except that the CORRECTLY simulated input does halt, as you showed
below. The issue is you only proved the input is non-halting if the
decider fails to answer.

On 4/27/21 12:55 AM, olcott wrote:
Message-ID: <Teudndbu59GVBBr9nZ2dnUU7-V2dnZ2d@giganews.com>
> void H_Hat(u32 P)
> {
> u32 Input_Halts = Halts(P, P);
> if (Input_Halts)
> HERE: goto HERE;
> }
>
>
> int main()
> {
> H_Hat((u32)H_Hat);
> }
>
>
> _H_Hat()
> [00000b98](01) 55 push ebp
> [00000b99](02) 8bec mov ebp,esp
>
[00000b9b](01) 51 push ecx
> [00000b9c](03) 8b4508 mov eax,[ebp+08]
> [00000b9f](01) 50 push eax
> [00000ba0](03) 8b4d08 mov ecx,[ebp+08]
> [00000ba3](01) 51 push ecx
> [00000ba4](05) e88ffdffff call 00000938
> [00000ba9](03) 83c408 add esp,+08
> [00000bac](03) 8945fc mov [ebp-04],eax
> [00000baf](04) 837dfc00 cmp dword [ebp-04],+00
> [00000bb3](02) 7402 jz 00000bb7
> [00000bb5](02) ebfe jmp 00000bb5
> [00000bb7](02) 8be5 mov esp,ebp
> [00000bb9](01) 5d pop ebp
> [00000bba](01) c3 ret
> Size in bytes:(0035) [00000bba]
>
> _main()
> [00000bc8](01) 55 push ebp
> [00000bc9](02) 8bec mov ebp,esp
> [00000bcb](05) 68980b0000 push 00000b98
> [00000bd0](05) e8c3ffffff call 00000b98
> [00000bd5](03) 83c404 add esp,+04
> [00000bd8](02) 33c0 xor eax,eax
> [00000bda](01) 5d pop ebp
> [00000bdb](01) c3 ret
> Size in bytes:(0020) [00000bdb]
>
> ===============================
> ...[00000bc8][001015d4][00000000](01) 55 push ebp
> ...[00000bc9][001015d4][00000000](02) 8bec mov ebp,esp
> ...[00000bcb][001015d0][00000b98](05) 68980b0000 push 00000b98
> ...[00000bd0][001015cc][00000bd5](05) e8c3ffffff call 00000b98
> ...[00000b98][001015c8][001015d4](01) 55 push ebp
> ...[00000b99][001015c8][001015d4](02) 8bec mov ebp,esp
> ...[00000b9b][001015c4][00000000](01) 51 push ecx
> ...[00000b9c][001015c4][00000000](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][001015c0][00000b98](01) 50 push eax
> ...[00000ba0][001015c0][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][001015bc][00000b98](01) 51 push ecx
> ...[00000ba4][001015b8][00000ba9](05) e88ffdffff call 00000938
> Begin Local Halt Decider Simulation at Machine Address:b98
> ...[00000b98][00211674][00211678](01) 55 push ebp
> ...[00000b99][00211674][00211678](02) 8bec mov ebp,esp
> ...[00000b9b][00211670][00201644](01) 51 push ecx
> ...[00000b9c][00211670][00201644](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][0021166c][00000b98](01) 50 push eax
> ...[00000ba0][0021166c][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][00211668][00000b98](01) 51 push ecx
> ...[00000ba4][00211664][00000ba9](05) e88ffdffff call 00000938
> ...[00000b98][0025c09c][0025c0a0](01) 55 push ebp
> ...[00000b99][0025c09c][0025c0a0](02) 8bec mov ebp,esp
> ...[00000b9b][0025c098][0024c06c](01) 51 push ecx
> ...[00000b9c][0025c098][0024c06c](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][0025c094][00000b98](01) 50 push eax
> ...[00000ba0][0025c094][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][0025c090][00000b98](01) 51 push ecx
> ...[00000ba4][0025c08c][00000ba9](05) e88ffdffff call 00000938
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped

olcott <NoOne@NoWhere.com> writes:

> The following simplifies the syntax for the definition of the Linz
> Turing machine Ĥ.
>
> There is no need for the infinite loop after H.qy because it is never
> reached.

You: "No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you many
times"

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

The correct specification is

Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊢* oo if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn if Ĥ applied to ⟨Ĥ⟩ does not halt.

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

You've told us that H(P,P) is false even though P(P) halts. That's the
wrong result for a simple model of a C halt decider.

--
Ben.

On 4/15/2022 5:18 PM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> The following simplifies the syntax for the definition of the Linz
>> Turing machine Ĥ.
>>
>> There is no need for the infinite loop after H.qy because it is never
>> reached.
>
> You: "No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you many
> times"
>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would reach its own
>> final state.
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would never reach its
>> own final state.
>
> The correct specification is
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊢* oo if Ĥ applied to ⟨Ĥ⟩ halts, and
> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn if Ĥ applied to ⟨Ĥ⟩ does not halt.
>
>> void P(u32 x)
>> {
>> if (H(x, x)) //
>> HERE: goto HERE;
>> }
>
> You've told us that H(P,P) is false even though P(P) halts. That's the
> wrong result for a simple model of a C halt decider.
>

The fact that the input to H(P,P) is non-halting is complete proof that
H(P,P)===false is correct by logical necessity.

You reasoning goes like this
It is a fact that you have a dog in your living room, yet your neighbor
believes that the dog is a cat, so you conclude that you have a cat in
your living room and there is no dog.

--
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 4/15/22 6:27 PM, olcott wrote:
> On 4/15/2022 5:18 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> The following simplifies the syntax for the definition of the Linz
>>> Turing machine Ĥ.
>>>
>>> There is no need for the infinite loop after H.qy because it is never
>>> reached.
>>
>> You: "No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you many
>>       times"
>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would reach its own
>>> final state.
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would never reach its
>>> own final state.
>>
>> The correct specification is
>>
>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊢* oo  if Ĥ applied to ⟨Ĥ⟩ halts, and
>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn        if Ĥ applied to ⟨Ĥ⟩ does not
>> halt.
>>
>>> void P(u32 x)
>>> {
>>>    if (H(x, x)) //
>>>      HERE: goto HERE;
>>> }
>>
>> You've told us that H(P,P) is false even though P(P) halts.  That's the
>> wrong result for a simple model of a C halt decider.
>>
>
> The fact that the input to H(P,P) is non-halting is complete proof that
> H(P,P)===false is correct by logical necessity.

Except that the input to H(P,P) Halts if H(P,P) returns non-halting, rns
non-halting proves that you are lying.

You have only shown that the input to H(P,P) is non-halting when H(P,P)
doesn't answer. Since P has a copy of H, changing H means you have a
different P so that proof doesn't apply to the aborting H.

FAIL.

>
> You reasoning goes like this
> It is a fact that you have a dog in your living room, yet your neighbor
> believes that the dog is a cat, so you conclude that you have a cat in
> your living room and there is no dog.
>

Except YOU are the one that thinks the dog you have is a cat, or is it
that you think you have a dog when you actaully have a cat.

The fact that you can't actaully define anything you are doing makes it
hard to say where you error is, only that you are speaking in
inconsistent terems that prove you are in error.

FAIL.

On 4/15/2022 5:18 PM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> The following simplifies the syntax for the definition of the Linz
>> Turing machine Ĥ.
>>
>> There is no need for the infinite loop after H.qy because it is never
>> reached.
>
> You: "No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you many
> times"
>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would reach its own
>> final state.
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would never reach its
>> own final state.
>
> The correct specification is
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊢* oo if Ĥ applied to ⟨Ĥ⟩ halts, and
> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn if Ĥ applied to ⟨Ĥ⟩ does not halt.
>
>> void P(u32 x)
>> {
>> if (H(x, x)) //
>> HERE: goto HERE;
>> }
>
> You've told us that H(P,P) is false even though P(P) halts. That's the
> wrong result for a simple model of a C halt decider.
>

When H correctly determines that its input would never reach its own
final state that means this input is non-halting.

--
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 4/16/2022 12:24 AM, olcott wrote:
> On 4/15/2022 5:18 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> The following simplifies the syntax for the definition of the Linz
>>> Turing machine Ĥ.
>>>
>>> There is no need for the infinite loop after H.qy because it is never
>>> reached.
>>
>> You: "No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you many
>>       times"
>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would reach its own
>>> final state.
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would never reach its
>>> own final state.
>>
>> The correct specification is
>>
>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊢* oo  if Ĥ applied to ⟨Ĥ⟩ halts, and
>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn        if Ĥ applied to ⟨Ĥ⟩ does not
>> halt.
>>
>>> void P(u32 x)
>>> {
>>>    if (H(x, x)) //
>>>      HERE: goto HERE;
>>> }
>>
>> You've told us that H(P,P) is false even though P(P) halts.  That's the
>> wrong result for a simple model of a C halt decider.
>>
>
> When H correctly determines that its input would never reach its own
> final state that means this input is non-halting.
>

I think I am at the point where an honest review by a competent reviewer
would agree with me.

--
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 4/16/22 1:24 AM, olcott wrote:
> On 4/15/2022 5:18 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> The following simplifies the syntax for the definition of the Linz
>>> Turing machine Ĥ.
>>>
>>> There is no need for the infinite loop after H.qy because it is never
>>> reached.
>>
>> You: "No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you many
>>       times"
>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would reach its own
>>> final state.
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would never reach its
>>> own final state.
>>
>> The correct specification is
>>
>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊢* oo  if Ĥ applied to ⟨Ĥ⟩ halts, and
>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn        if Ĥ applied to ⟨Ĥ⟩ does not
>> halt.
>>
>>> void P(u32 x)
>>> {
>>>    if (H(x, x)) //
>>>      HERE: goto HERE;
>>> }
>>
>> You've told us that H(P,P) is false even though P(P) halts.  That's the
>> wrong result for a simple model of a C halt decider.
>>
>
> When H correctly determines that its input would never reach its own
> final state that means this input is non-halting.
>

Except that it doesn't do that, if H(P,P) returns false, then the input
to H(P,P), namely P(P), halts.

What your H does is not determine that its input, correctly simulated,
never halts, but that its own, potentially partial (and thus not
correct) simulation won't reach a final state.

This is a DIFFERENT condition, and thus not Halting.

FAIL.

On 4/16/22 1:31 AM, olcott wrote:
> On 4/16/2022 12:24 AM, olcott wrote:
>> On 4/15/2022 5:18 PM, Ben wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> The following simplifies the syntax for the definition of the Linz
>>>> Turing machine Ĥ.
>>>>
>>>> There is no need for the infinite loop after H.qy because it is never
>>>> reached.
>>>
>>> You: "No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you many
>>>       times"
>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would reach its own
>>>> final state.
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would never reach its
>>>> own final state.
>>>
>>> The correct specification is
>>>
>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊢* oo  if Ĥ applied to ⟨Ĥ⟩ halts, and
>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn        if Ĥ applied to ⟨Ĥ⟩ does not
>>> halt.
>>>
>>>> void P(u32 x)
>>>> {
>>>>    if (H(x, x)) //
>>>>      HERE: goto HERE;
>>>> }
>>>
>>> You've told us that H(P,P) is false even though P(P) halts.  That's the
>>> wrong result for a simple model of a C halt decider.
>>>
>>
>> When H correctly determines that its input would never reach its own
>> final state that means this input is non-halting.
>>
>
> I think I am at the point where an honest review by a competent reviewer
> would agree with me.
>

THen submit the paper and burn your bridges.

On Saturday, April 16, 2022 at 1:24:49 AM UTC-4, olcott wrote:
> On 4/15/2022 5:18 PM, Ben wrote:
> > olcott <No...@NoWhere.com> writes:
> >
> >> The following simplifies the syntax for the definition of the Linz
> >> Turing machine Ĥ.
> >>
> >> There is no need for the infinite loop after H.qy because it is never
> >> reached.
> >
> > You: "No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you many
> > times"
> >
> >> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
> >> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would reach its own
> >> final state.
> >>
> >> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
> >> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would never reach its
> >> own final state.
> >
> > The correct specification is
> >
> > Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊢* oo if Ĥ applied to ⟨Ĥ⟩ halts, and
> > Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn if Ĥ applied to ⟨Ĥ⟩ does not halt.
> >
> >> void P(u32 x)
> >> {
> >> if (H(x, x)) //
> >> HERE: goto HERE;
> >> }
> >
> > You've told us that H(P,P) is false even though P(P) halts. That's the
> > wrong result for a simple model of a C halt decider.
> >
> When H correctly determines that its input would never reach its own
> final state

Which is doesn't. Hb(P,P) simulates that same input to its own final state and returns true. And any simulating halt decider that simulates its input to its own final state is necessarily correct because it never leaves UTM mode.

That means the input to H(P,P) *does* reach a final state, even though H is unable to see that, and therefore H(P,P)==false is incorrect.

On 4/16/2022 7:27 AM, Dennis Bush wrote:
> On Saturday, April 16, 2022 at 1:24:49 AM UTC-4, olcott wrote:
>> On 4/15/2022 5:18 PM, Ben wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> The following simplifies the syntax for the definition of the Linz
>>>> Turing machine Ĥ.
>>>>
>>>> There is no need for the infinite loop after H.qy because it is never
>>>> reached.
>>>
>>> You: "No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you many
>>> times"
>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would reach its own
>>>> final state.
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would never reach its
>>>> own final state.
>>>
>>> The correct specification is
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊢* oo if Ĥ applied to ⟨Ĥ⟩ halts, and
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn if Ĥ applied to ⟨Ĥ⟩ does not halt.
>>>
>>>> void P(u32 x)
>>>> {
>>>> if (H(x, x)) //
>>>> HERE: goto HERE;
>>>> }
>>>
>>> You've told us that H(P,P) is false even though P(P) halts. That's the
>>> wrong result for a simple model of a C halt decider.
>>>
>> When H correctly determines that its input would never reach its own
>> final state
>
> Which is doesn't.

LIAR LIAR PANTS ON FIRE

The simulated input to H(P,P) cannot possibly reach its own final state
it keeps repeating [00000956] to [00000961] until aborted.

_P()
[00000956](01) 55 push ebp
[00000957](02) 8bec mov ebp,esp
[00000959](03) 8b4508 mov eax,[ebp+08]
[0000095c](01) 50 push eax // push P
[0000095d](03) 8b4d08 mov ecx,[ebp+08]
[00000960](01) 51 push ecx // push P
[00000961](05) e8c0feffff call 00000826 // call H(P,P)
The above keeps repeating until aborted

[00000966](03) 83c408 add esp,+08
[00000969](02) 85c0 test eax,eax
[0000096b](02) 7402 jz 0000096f
[0000096d](02) ebfe jmp 0000096d
[0000096f](01) 5d pop ebp
[00000970](01) c3 ret // final state.
Size in bytes:(0027) [00000970]

THIS IS THE KEY STUPID AND OR DISHONEST MISTAKE OF MY REVIEWERS
All of my reviewers take the position that the fact that the input to
H(P,P) is non-halting is not an entirely sufficient reason for H to
report that its input is non-halting.

> Hb(P,P) simulates that same input to its own final state and returns true. And any simulating halt decider that simulates its input to its own final state is necessarily correct because it never leaves UTM mode.
>
> That means the input to H(P,P) *does* reach a final state, even though H is unable to see that, and therefore H(P,P)==false is incorrect.

--
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 Saturday, April 16, 2022 at 10:44:29 AM UTC-4, olcott wrote:
> On 4/16/2022 7:27 AM, Dennis Bush wrote:
> > On Saturday, April 16, 2022 at 1:24:49 AM UTC-4, olcott wrote:
> >> On 4/15/2022 5:18 PM, Ben wrote:
> >>> olcott <No...@NoWhere.com> writes:
> >>>
> >>>> The following simplifies the syntax for the definition of the Linz
> >>>> Turing machine Ĥ.
> >>>>
> >>>> There is no need for the infinite loop after H.qy because it is never
> >>>> reached.
> >>>
> >>> You: "No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you many
> >>> times"
> >>>
> >>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
> >>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would reach its own
> >>>> final state.
> >>>>
> >>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
> >>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would never reach its
> >>>> own final state.
> >>>
> >>> The correct specification is
> >>>
> >>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊢* oo if Ĥ applied to ⟨Ĥ⟩ halts, and
> >>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn if Ĥ applied to ⟨Ĥ⟩ does not halt.
> >>>
> >>>> void P(u32 x)
> >>>> {
> >>>> if (H(x, x)) //
> >>>> HERE: goto HERE;
> >>>> }
> >>>
> >>> You've told us that H(P,P) is false even though P(P) halts. That's the
> >>> wrong result for a simple model of a C halt decider.
> >>>
> >> When H correctly determines that its input would never reach its own
> >> final state
> >
> > Which is doesn't.
> LIAR LIAR PANTS ON FIRE
>
> The simulated input to H(P,P) cannot possibly reach its own final state
> it keeps repeating [00000956] to [00000961] until aborted.
>
> _P()
> [00000956](01) 55 push ebp
> [00000957](02) 8bec mov ebp,esp
> [00000959](03) 8b4508 mov eax,[ebp+08]
> [0000095c](01) 50 push eax // push P
> [0000095d](03) 8b4d08 mov ecx,[ebp+08]
> [00000960](01) 51 push ecx // push P
> [00000961](05) e8c0feffff call 00000826 // call H(P,P)
> The above keeps repeating until aborted
>
>
> [00000966](03) 83c408 add esp,+08
> [00000969](02) 85c0 test eax,eax
> [0000096b](02) 7402 jz 0000096f
> [0000096d](02) ebfe jmp 0000096d
> [0000096f](01) 5d pop ebp
> [00000970](01) c3 ret // final state.
> Size in bytes:(0027) [00000970]
>
> THIS IS THE KEY STUPID AND OR DISHONEST MISTAKE OF MY REVIEWERS
> All of my reviewers take the position that the fact that the input to
> H(P,P) is non-halting is not an entirely sufficient reason for H to
> report that its input is non-halting.

FALSE. We reject the "fact" that the input to H(P,P) is non-halting. Read the whole message to understand why.

Also, since you claim that H aborts its simulation, we'll rename it to Ha to make that fact more explicit and likewise rename P to Pa.

Hb(Pa,Pa) simulates that same input to its own final state and returns true.. And any simulating halt decider that simulates its input to its own final state is necessarily correct because it never leaves UTM mode.

The trace of the input by Hb is as follows:

_Pa()
[00000956](01) 55 push ebp
[00000957](02) 8bec mov ebp,esp
[00000959](03) 8b4508 mov eax,[ebp+08]
[0000095c](01) 50 push eax // push Pa
[0000095d](03) 8b4d08 mov ecx,[ebp+08]
[00000960](01) 51 push ecx // push Pa
[00000961](05) e8c0feffff call 00000826 // call Ha(Pa,Pa)
The above keeps returns false as per the fixed algorithm of Ha

[00000966](03) 83c408 add esp,+08
[00000969](02) 85c0 test eax,eax
[0000096b](02) 7402 jz 0000096f
[0000096d](02) ebfe jmp 0000096d
[0000096f](01) 5d pop ebp
[00000970](01) c3 ret // final state.
Here the input reaches its final state

That means the input to Ha(Pa,Pa) *does* reach a final state, even though Ha is unable to see that, and therefore Ha(Pa,Pa)==false is incorrect.

On 4/16/2022 10:17 AM, Dennis Bush wrote:
> On Saturday, April 16, 2022 at 10:44:29 AM UTC-4, olcott wrote:
>> On 4/16/2022 7:27 AM, Dennis Bush wrote:
>>> On Saturday, April 16, 2022 at 1:24:49 AM UTC-4, olcott wrote:
>>>> On 4/15/2022 5:18 PM, Ben wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> The following simplifies the syntax for the definition of the Linz
>>>>>> Turing machine Ĥ.
>>>>>>
>>>>>> There is no need for the infinite loop after H.qy because it is never
>>>>>> reached.
>>>>>
>>>>> You: "No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you many
>>>>> times"
>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would reach its own
>>>>>> final state.
>>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would never reach its
>>>>>> own final state.
>>>>>
>>>>> The correct specification is
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊢* oo if Ĥ applied to ⟨Ĥ⟩ halts, and
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn if Ĥ applied to ⟨Ĥ⟩ does not halt.
>>>>>
>>>>>> void P(u32 x)
>>>>>> {
>>>>>> if (H(x, x)) //
>>>>>> HERE: goto HERE;
>>>>>> }
>>>>>
>>>>> You've told us that H(P,P) is false even though P(P) halts. That's the
>>>>> wrong result for a simple model of a C halt decider.
>>>>>
>>>> When H correctly determines that its input would never reach its own
>>>> final state
>>>
>>> Which is doesn't.
>> LIAR LIAR PANTS ON FIRE
>>
>> The simulated input to H(P,P) cannot possibly reach its own final state
>> it keeps repeating [00000956] to [00000961] until aborted.
>>
>> _P()
>> [00000956](01) 55 push ebp
>> [00000957](02) 8bec mov ebp,esp
>> [00000959](03) 8b4508 mov eax,[ebp+08]
>> [0000095c](01) 50 push eax // push P
>> [0000095d](03) 8b4d08 mov ecx,[ebp+08]
>> [00000960](01) 51 push ecx // push P
>> [00000961](05) e8c0feffff call 00000826 // call H(P,P)
>> The above keeps repeating until aborted
>>
>>
>> [00000966](03) 83c408 add esp,+08
>> [00000969](02) 85c0 test eax,eax
>> [0000096b](02) 7402 jz 0000096f
>> [0000096d](02) ebfe jmp 0000096d
>> [0000096f](01) 5d pop ebp
>> [00000970](01) c3 ret // final state.
>> Size in bytes:(0027) [00000970]
>>
>> THIS IS THE KEY STUPID AND OR DISHONEST MISTAKE OF MY REVIEWERS
>> All of my reviewers take the position that the fact that the input to
>> H(P,P) is non-halting is not an entirely sufficient reason for H to
>> report that its input is non-halting.
>
> FALSE. We reject the "fact" that the input to H(P,P) is non-halting.

If you disagree that France exists I do not need to read the whole
message to see that you are wrong.

Anyone that knows the x86 language can see that the simulated input to
H(P,P) never reaches its own final state.

--
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 4/16/22 10:44 AM, olcott wrote:
> On 4/16/2022 7:27 AM, Dennis Bush wrote:
>> On Saturday, April 16, 2022 at 1:24:49 AM UTC-4, olcott wrote:
>>> On 4/15/2022 5:18 PM, Ben wrote:
>>>> olcott <No...@NoWhere.com> writes:
>>>>
>>>>> The following simplifies the syntax for the definition of the Linz
>>>>> Turing machine Ĥ.
>>>>>
>>>>> There is no need for the infinite loop after H.qy because it is never
>>>>> reached.
>>>>
>>>> You: "No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you many
>>>> times"
>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would reach its own
>>>>> final state.
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would never reach its
>>>>> own final state.
>>>>
>>>> The correct specification is
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊢* oo if Ĥ applied to ⟨Ĥ⟩ halts, and
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn if Ĥ applied to ⟨Ĥ⟩ does not halt.
>>>>
>>>>> void P(u32 x)
>>>>> {
>>>>> if (H(x, x)) //
>>>>> HERE: goto HERE;
>>>>> }
>>>>
>>>> You've told us that H(P,P) is false even though P(P) halts. That's the
>>>> wrong result for a simple model of a C halt decider.
>>>>
>>> When H correctly determines that its input would never reach its own
>>> final state
>>
>> Which is doesn't.
>
> LIAR LIAR PANTS ON FIRE
>
> The simulated input to H(P,P) cannot possibly reach its own final state
> it keeps repeating [00000956] to [00000961] until aborted.

Then why did it when you showed it before?

Whose pants are on fire now?

>
> _P()
> [00000956](01)  55              push ebp
> [00000957](02)  8bec            mov ebp,esp
> [00000959](03)  8b4508          mov eax,[ebp+08]
> [0000095c](01)  50              push eax       // push P
> [0000095d](03)  8b4d08          mov ecx,[ebp+08]
> [00000960](01)  51              push ecx       // push P
> [00000961](05)  e8c0feffff      call 00000826  // call H(P,P)
> The above keeps repeating until aborted

WRONG, H incorrectly aborts the simulation because it incorrect
determines that the input will not halt.

>
>
> [00000966](03)  83c408          add esp,+08
> [00000969](02)  85c0            test eax,eax
> [0000096b](02)  7402            jz 0000096f
> [0000096d](02)  ebfe            jmp 0000096d
> [0000096f](01)  5d              pop ebp
> [00000970](01)  c3              ret            // final state.
> Size in bytes:(0027) [00000970]
>
> THIS IS THE KEY STUPID AND OR DISHONEST MISTAKE OF MY REVIEWERS
> All of my reviewers take the position that the fact that the input to
> H(P,P) is non-halting is not an entirely sufficient reason for H to
> report that its input is non-halting.

No we take the fact that the input to H(P,P) is actually Halting is
sufficient to say that the H(P,P) that incorrect aborts its simulaiton
is wrong.

Only the H(P,P) that never aborts its simulation would be correct to
return the non-halting answer, but unfortunately it can't do that as it
is stuck in an infinite loop.

FAIL

>
>> Hb(P,P) simulates that same input to its own final state and returns
>> true.  And any simulating halt decider that simulates its input to its
>> own final state is necessarily correct because it never leaves UTM mode.
>>
>> That means the input to H(P,P) *does* reach a final state, even though
>> H is unable to see that, and therefore H(P,P)==false is incorrect.
>
>

On 4/27/21 12:55 AM, olcott wrote:
Message-ID: <Teudndbu59GVBBr9nZ2dnUU7-V2dnZ2d@giganews.com>
> void H_Hat(u32 P)
> {
> u32 Input_Halts = Halts(P, P);
> if (Input_Halts)
> HERE: goto HERE;
> }
>
>
> int main()
> {
> H_Hat((u32)H_Hat);
> }
>
>
> _H_Hat()
> [00000b98](01) 55 push ebp
> [00000b99](02) 8bec mov ebp,esp
>
[00000b9b](01) 51 push ecx
> [00000b9c](03) 8b4508 mov eax,[ebp+08]
> [00000b9f](01) 50 push eax
> [00000ba0](03) 8b4d08 mov ecx,[ebp+08]
> [00000ba3](01) 51 push ecx
> [00000ba4](05) e88ffdffff call 00000938
> [00000ba9](03) 83c408 add esp,+08
> [00000bac](03) 8945fc mov [ebp-04],eax
> [00000baf](04) 837dfc00 cmp dword [ebp-04],+00
> [00000bb3](02) 7402 jz 00000bb7
> [00000bb5](02) ebfe jmp 00000bb5
> [00000bb7](02) 8be5 mov esp,ebp
> [00000bb9](01) 5d pop ebp
> [00000bba](01) c3 ret
> Size in bytes:(0035) [00000bba]
>
> _main()
> [00000bc8](01) 55 push ebp
> [00000bc9](02) 8bec mov ebp,esp
> [00000bcb](05) 68980b0000 push 00000b98
> [00000bd0](05) e8c3ffffff call 00000b98
> [00000bd5](03) 83c404 add esp,+04
> [00000bd8](02) 33c0 xor eax,eax
> [00000bda](01) 5d pop ebp
> [00000bdb](01) c3 ret
> Size in bytes:(0020) [00000bdb]
>
> ===============================
> ...[00000bc8][001015d4][00000000](01) 55 push ebp
> ...[00000bc9][001015d4][00000000](02) 8bec mov ebp,esp
> ...[00000bcb][001015d0][00000b98](05) 68980b0000 push 00000b98
> ...[00000bd0][001015cc][00000bd5](05) e8c3ffffff call 00000b98
> ...[00000b98][001015c8][001015d4](01) 55 push ebp
> ...[00000b99][001015c8][001015d4](02) 8bec mov ebp,esp
> ...[00000b9b][001015c4][00000000](01) 51 push ecx
> ...[00000b9c][001015c4][00000000](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][001015c0][00000b98](01) 50 push eax
> ...[00000ba0][001015c0][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][001015bc][00000b98](01) 51 push ecx
> ...[00000ba4][001015b8][00000ba9](05) e88ffdffff call 00000938
> Begin Local Halt Decider Simulation at Machine Address:b98
> ...[00000b98][00211674][00211678](01) 55 push ebp
> ...[00000b99][00211674][00211678](02) 8bec mov ebp,esp
> ...[00000b9b][00211670][00201644](01) 51 push ecx
> ...[00000b9c][00211670][00201644](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][0021166c][00000b98](01) 50 push eax
> ...[00000ba0][0021166c][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][00211668][00000b98](01) 51 push ecx
> ...[00000ba4][00211664][00000ba9](05) e88ffdffff call 00000938
> ...[00000b98][0025c09c][0025c0a0](01) 55 push ebp
> ...[00000b99][0025c09c][0025c0a0](02) 8bec mov ebp,esp
> ...[00000b9b][0025c098][0024c06c](01) 51 push ecx
> ...[00000b9c][0025c098][0024c06c](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][0025c094][00000b98](01) 50 push eax
> ...[00000ba0][0025c094][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][0025c090][00000b98](01) 51 push ecx
> ...[00000ba4][0025c08c][00000ba9](05) e88ffdffff call 00000938
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Above decision was from the call the Halts inside H_Hat, deciding that
H_Hat(H_Hat) seems to be non-halting, it then returns that answer and is
processed below:

> ...[00000ba9][001015c4][00000000](03) 83c408 add esp,+08
> ...[00000bac][001015c4][00000000](03) 8945fc mov [ebp-04],eax
> ...[00000baf][001015c4][00000000](04) 837dfc00 cmp dword [ebp-04],+00
> ...[00000bb3][001015c4][00000000](02) 7402 jz 00000bb7
> ...[00000bb7][001015c8][001015d4](02) 8be5 mov esp,ebp
> ...[00000bb9][001015cc][00000bd5](01) 5d pop ebp
> ...[00000bba][001015d0][00000b98](01) c3 ret
> ...[00000bd5][001015d4][00000000](03) 83c404 add esp,+04
> ...[00000bd8][001015d4][00000000](02) 33c0 xor eax,eax
> ...[00000bda][001015d8][00100000](01) 5d pop ebp
> ...[00000bdb][001015dc][00000098](01) c3 ret

SEE IT HALTED!

On 4/16/22 11:30 AM, olcott wrote:
> On 4/16/2022 10:17 AM, Dennis Bush wrote:
>> On Saturday, April 16, 2022 at 10:44:29 AM UTC-4, olcott wrote:
>>> On 4/16/2022 7:27 AM, Dennis Bush wrote:
>>>> On Saturday, April 16, 2022 at 1:24:49 AM UTC-4, olcott wrote:
>>>>> On 4/15/2022 5:18 PM, Ben wrote:
>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>
>>>>>>> The following simplifies the syntax for the definition of the Linz
>>>>>>> Turing machine Ĥ.
>>>>>>>
>>>>>>> There is no need for the infinite loop after H.qy because it is
>>>>>>> never
>>>>>>> reached.
>>>>>>
>>>>>> You: "No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you many
>>>>>> times"
>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would reach its own
>>>>>>> final state.
>>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would never reach its
>>>>>>> own final state.
>>>>>>
>>>>>> The correct specification is
>>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊢* oo if Ĥ applied to ⟨Ĥ⟩ halts, and
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn if Ĥ applied to ⟨Ĥ⟩ does not halt.
>>>>>>
>>>>>>> void P(u32 x)
>>>>>>> {
>>>>>>> if (H(x, x)) //
>>>>>>> HERE: goto HERE;
>>>>>>> }
>>>>>>
>>>>>> You've told us that H(P,P) is false even though P(P) halts. That's
>>>>>> the
>>>>>> wrong result for a simple model of a C halt decider.
>>>>>>
>>>>> When H correctly determines that its input would never reach its own
>>>>> final state
>>>>
>>>> Which is doesn't.
>>> LIAR LIAR PANTS ON FIRE
>>>
>>> The simulated input to H(P,P) cannot possibly reach its own final state
>>> it keeps repeating [00000956] to [00000961] until aborted.
>>>
>>> _P()
>>> [00000956](01) 55 push ebp
>>> [00000957](02) 8bec mov ebp,esp
>>> [00000959](03) 8b4508 mov eax,[ebp+08]
>>> [0000095c](01) 50 push eax // push P
>>> [0000095d](03) 8b4d08 mov ecx,[ebp+08]
>>> [00000960](01) 51 push ecx // push P
>>> [00000961](05) e8c0feffff call 00000826 // call H(P,P)
>>> The above keeps repeating until aborted
>>>
>>>
>>> [00000966](03) 83c408 add esp,+08
>>> [00000969](02) 85c0 test eax,eax
>>> [0000096b](02) 7402 jz 0000096f
>>> [0000096d](02) ebfe jmp 0000096d
>>> [0000096f](01) 5d pop ebp
>>> [00000970](01) c3 ret // final state.
>>> Size in bytes:(0027) [00000970]
>>>
>>> THIS IS THE KEY STUPID AND OR DISHONEST MISTAKE OF MY REVIEWERS
>>> All of my reviewers take the position that the fact that the input to
>>> H(P,P) is non-halting is not an entirely sufficient reason for H to
>>> report that its input is non-halting.
>>
>> FALSE.  We reject the "fact" that the input to H(P,P) is non-halting.
>
> If you disagree that France exists I do not need to read the whole
> message to see that you are wrong.
>
> Anyone that knows the x86 language can see that the simulated input to
> H(P,P) never reaches its own final state.
>

Nope, just shows that YOU don't understand the meaning of the words you
are saying.

THe x86 code is inconclusive, because it doesn't show ALL the code (the
code of H is part of the code being run, hiding it is just you way to lie).

What is true is that a correct simulation of a program doesn't abort it.

Since H(P,P) is claimed to return false, to 'correctly' answer that
question, the H(P,P) must also return that same answer when called by P.

You failure to show that here (even though you did show it in the trace
below) is proof that H's simulation is not correct or H fails to meets
its requirements.

FAIL

On 4/27/21 12:55 AM, olcott wrote:
Message-ID: <Teudndbu59GVBBr9nZ2dnUU7-V2dnZ2d@giganews.com>
> void H_Hat(u32 P)
> {
> u32 Input_Halts = Halts(P, P);
> if (Input_Halts)
> HERE: goto HERE;
> }
>
>
> int main()
> {
> H_Hat((u32)H_Hat);
> }
>
>
> _H_Hat()
> [00000b98](01) 55 push ebp
> [00000b99](02) 8bec mov ebp,esp
>
[00000b9b](01) 51 push ecx
> [00000b9c](03) 8b4508 mov eax,[ebp+08]
> [00000b9f](01) 50 push eax
> [00000ba0](03) 8b4d08 mov ecx,[ebp+08]
> [00000ba3](01) 51 push ecx
> [00000ba4](05) e88ffdffff call 00000938
> [00000ba9](03) 83c408 add esp,+08
> [00000bac](03) 8945fc mov [ebp-04],eax
> [00000baf](04) 837dfc00 cmp dword [ebp-04],+00
> [00000bb3](02) 7402 jz 00000bb7
> [00000bb5](02) ebfe jmp 00000bb5
> [00000bb7](02) 8be5 mov esp,ebp
> [00000bb9](01) 5d pop ebp
> [00000bba](01) c3 ret
> Size in bytes:(0035) [00000bba]
>
> _main()
> [00000bc8](01) 55 push ebp
> [00000bc9](02) 8bec mov ebp,esp
> [00000bcb](05) 68980b0000 push 00000b98
> [00000bd0](05) e8c3ffffff call 00000b98
> [00000bd5](03) 83c404 add esp,+04
> [00000bd8](02) 33c0 xor eax,eax
> [00000bda](01) 5d pop ebp
> [00000bdb](01) c3 ret
> Size in bytes:(0020) [00000bdb]
>
> ===============================
> ...[00000bc8][001015d4][00000000](01) 55 push ebp
> ...[00000bc9][001015d4][00000000](02) 8bec mov ebp,esp
> ...[00000bcb][001015d0][00000b98](05) 68980b0000 push 00000b98
> ...[00000bd0][001015cc][00000bd5](05) e8c3ffffff call 00000b98
> ...[00000b98][001015c8][001015d4](01) 55 push ebp
> ...[00000b99][001015c8][001015d4](02) 8bec mov ebp,esp
> ...[00000b9b][001015c4][00000000](01) 51 push ecx
> ...[00000b9c][001015c4][00000000](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][001015c0][00000b98](01) 50 push eax
> ...[00000ba0][001015c0][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][001015bc][00000b98](01) 51 push ecx
> ...[00000ba4][001015b8][00000ba9](05) e88ffdffff call 00000938
> Begin Local Halt Decider Simulation at Machine Address:b98
> ...[00000b98][00211674][00211678](01) 55 push ebp
> ...[00000b99][00211674][00211678](02) 8bec mov ebp,esp
> ...[00000b9b][00211670][00201644](01) 51 push ecx
> ...[00000b9c][00211670][00201644](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][0021166c][00000b98](01) 50 push eax
> ...[00000ba0][0021166c][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][00211668][00000b98](01) 51 push ecx
> ...[00000ba4][00211664][00000ba9](05) e88ffdffff call 00000938
> ...[00000b98][0025c09c][0025c0a0](01) 55 push ebp
> ...[00000b99][0025c09c][0025c0a0](02) 8bec mov ebp,esp
> ...[00000b9b][0025c098][0024c06c](01) 51 push ecx
> ...[00000b9c][0025c098][0024c06c](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][0025c094][00000b98](01) 50 push eax
> ...[00000ba0][0025c094][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][0025c090][00000b98](01) 51 push ecx
> ...[00000ba4][0025c08c][00000ba9](05) e88ffdffff call 00000938
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Above decision was from the call the Halts inside H_Hat, deciding that
H_Hat(H_Hat) seems to be non-halting, it then returns that answer and is
processed below:

> ...[00000ba9][001015c4][00000000](03) 83c408 add esp,+08
> ...[00000bac][001015c4][00000000](03) 8945fc mov [ebp-04],eax
> ...[00000baf][001015c4][00000000](04) 837dfc00 cmp dword [ebp-04],+00
> ...[00000bb3][001015c4][00000000](02) 7402 jz 00000bb7
> ...[00000bb7][001015c8][001015d4](02) 8be5 mov esp,ebp
> ...[00000bb9][001015cc][00000bd5](01) 5d pop ebp
> ...[00000bba][001015d0][00000b98](01) c3 ret
> ...[00000bd5][001015d4][00000000](03) 83c404 add esp,+04
> ...[00000bd8][001015d4][00000000](02) 33c0 xor eax,eax
> ...[00000bda][001015d8][00100000](01) 5d pop ebp
> ...[00000bdb][001015dc][00000098](01) c3 ret

On Saturday, April 16, 2022 at 11:30:11 AM UTC-4, olcott wrote:
> On 4/16/2022 10:17 AM, Dennis Bush wrote:
> > On Saturday, April 16, 2022 at 10:44:29 AM UTC-4, olcott wrote:
> >> On 4/16/2022 7:27 AM, Dennis Bush wrote:
> >>> On Saturday, April 16, 2022 at 1:24:49 AM UTC-4, olcott wrote:
> >>>> On 4/15/2022 5:18 PM, Ben wrote:
> >>>>> olcott <No...@NoWhere.com> writes:
> >>>>>
> >>>>>> The following simplifies the syntax for the definition of the Linz
> >>>>>> Turing machine Ĥ.
> >>>>>>
> >>>>>> There is no need for the infinite loop after H.qy because it is never
> >>>>>> reached.
> >>>>>
> >>>>> You: "No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you many
> >>>>> times"
> >>>>>
> >>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
> >>>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would reach its own
> >>>>>> final state.
> >>>>>>
> >>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
> >>>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would never reach its
> >>>>>> own final state.
> >>>>>
> >>>>> The correct specification is
> >>>>>
> >>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊢* oo if Ĥ applied to ⟨Ĥ⟩ halts, and
> >>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn if Ĥ applied to ⟨Ĥ⟩ does not halt.
> >>>>>
> >>>>>> void P(u32 x)
> >>>>>> {
> >>>>>> if (H(x, x)) //
> >>>>>> HERE: goto HERE;
> >>>>>> }
> >>>>>
> >>>>> You've told us that H(P,P) is false even though P(P) halts. That's the
> >>>>> wrong result for a simple model of a C halt decider.
> >>>>>
> >>>> When H correctly determines that its input would never reach its own
> >>>> final state
> >>>
> >>> Which is doesn't.
> >> LIAR LIAR PANTS ON FIRE
> >>
> >> The simulated input to H(P,P) cannot possibly reach its own final state
> >> it keeps repeating [00000956] to [00000961] until aborted.
> >>
> >> _P()
> >> [00000956](01) 55 push ebp
> >> [00000957](02) 8bec mov ebp,esp
> >> [00000959](03) 8b4508 mov eax,[ebp+08]
> >> [0000095c](01) 50 push eax // push P
> >> [0000095d](03) 8b4d08 mov ecx,[ebp+08]
> >> [00000960](01) 51 push ecx // push P
> >> [00000961](05) e8c0feffff call 00000826 // call H(P,P)
> >> The above keeps repeating until aborted
> >>
> >>
> >> [00000966](03) 83c408 add esp,+08
> >> [00000969](02) 85c0 test eax,eax
> >> [0000096b](02) 7402 jz 0000096f
> >> [0000096d](02) ebfe jmp 0000096d
> >> [0000096f](01) 5d pop ebp
> >> [00000970](01) c3 ret // final state.
> >> Size in bytes:(0027) [00000970]
> >>
> >> THIS IS THE KEY STUPID AND OR DISHONEST MISTAKE OF MY REVIEWERS
> >> All of my reviewers take the position that the fact that the input to
> >> H(P,P) is non-halting is not an entirely sufficient reason for H to
> >> report that its input is non-halting.
> >
> > FALSE. We reject the "fact" that the input to H(P,P) is non-halting.
> If you disagree that France exists I do not need to read the whole
> message to see that you are wrong.
>
> Anyone that knows the x86 language can see that the simulated input to
> H(P,P) never reaches its own final state.

Anyone that knows the x86 language can see that the simulated input to
Ha(Pa,Pa), when given as input to Hb, DOES reach its own final state.

Any simulating halt decider that simulates its input to its own final state is necessarily correct because the decider never leaves UTM mode.

_Pa()
[00000956](01) 55 push ebp
[00000957](02) 8bec mov ebp,esp
[00000959](03) 8b4508 mov eax,[ebp+08]
[0000095c](01) 50 push eax // push Pa
[0000095d](03) 8b4d08 mov ecx,[ebp+08]
[00000960](01) 51 push ecx // push Pa
[00000961](05) e8c0feffff call 00000826 // call Ha(Pa,Pa)
The above returns false as per the fixed algorithm of Ha

[00000966](03) 83c408 add esp,+08
[00000969](02) 85c0 test eax,eax
[0000096b](02) 7402 jz 0000096f
[0000096d](02) ebfe jmp 0000096d
[0000096f](01) 5d pop ebp
[00000970](01) c3 ret // final state.
Here the input reaches its final state and Hb returns true

On 4/16/2022 11:00 AM, Dennis Bush wrote:
> On Saturday, April 16, 2022 at 11:30:11 AM UTC-4, olcott wrote:
>> On 4/16/2022 10:17 AM, Dennis Bush wrote:
>>> On Saturday, April 16, 2022 at 10:44:29 AM UTC-4, olcott wrote:
>>>> On 4/16/2022 7:27 AM, Dennis Bush wrote:
>>>>> On Saturday, April 16, 2022 at 1:24:49 AM UTC-4, olcott wrote:
>>>>>> On 4/15/2022 5:18 PM, Ben wrote:
>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>
>>>>>>>> The following simplifies the syntax for the definition of the Linz
>>>>>>>> Turing machine Ĥ.
>>>>>>>>
>>>>>>>> There is no need for the infinite loop after H.qy because it is never
>>>>>>>> reached.
>>>>>>>
>>>>>>> You: "No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you many
>>>>>>> times"
>>>>>>>
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would reach its own
>>>>>>>> final state.
>>>>>>>>
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would never reach its
>>>>>>>> own final state.
>>>>>>>
>>>>>>> The correct specification is
>>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊢* oo if Ĥ applied to ⟨Ĥ⟩ halts, and
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn if Ĥ applied to ⟨Ĥ⟩ does not halt.
>>>>>>>
>>>>>>>> void P(u32 x)
>>>>>>>> {
>>>>>>>> if (H(x, x)) //
>>>>>>>> HERE: goto HERE;
>>>>>>>> }
>>>>>>>
>>>>>>> You've told us that H(P,P) is false even though P(P) halts. That's the
>>>>>>> wrong result for a simple model of a C halt decider.
>>>>>>>
>>>>>> When H correctly determines that its input would never reach its own
>>>>>> final state
>>>>>
>>>>> Which is doesn't.
>>>> LIAR LIAR PANTS ON FIRE
>>>>
>>>> The simulated input to H(P,P) cannot possibly reach its own final state
>>>> it keeps repeating [00000956] to [00000961] until aborted.
>>>>
>>>> _P()
>>>> [00000956](01) 55 push ebp
>>>> [00000957](02) 8bec mov ebp,esp
>>>> [00000959](03) 8b4508 mov eax,[ebp+08]
>>>> [0000095c](01) 50 push eax // push P
>>>> [0000095d](03) 8b4d08 mov ecx,[ebp+08]
>>>> [00000960](01) 51 push ecx // push P
>>>> [00000961](05) e8c0feffff call 00000826 // call H(P,P)
>>>> The above keeps repeating until aborted
>>>>
>>>>
>>>> [00000966](03) 83c408 add esp,+08
>>>> [00000969](02) 85c0 test eax,eax
>>>> [0000096b](02) 7402 jz 0000096f
>>>> [0000096d](02) ebfe jmp 0000096d
>>>> [0000096f](01) 5d pop ebp
>>>> [00000970](01) c3 ret // final state.
>>>> Size in bytes:(0027) [00000970]
>>>>
>>>> THIS IS THE KEY STUPID AND OR DISHONEST MISTAKE OF MY REVIEWERS
>>>> All of my reviewers take the position that the fact that the input to
>>>> H(P,P) is non-halting is not an entirely sufficient reason for H to
>>>> report that its input is non-halting.
>>>
>>> FALSE. We reject the "fact" that the input to H(P,P) is non-halting.
>> If you disagree that France exists I do not need to read the whole
>> message to see that you are wrong.
>>
>> Anyone that knows the x86 language can see that the simulated input to
>> H(P,P) never reaches its own final state.
>
> Anyone that knows the x86 language can see that the simulated input to
> Ha(Pa,Pa), when given as input to Hb, DOES reach its own final state.

I know that Bill Jones robbed the liquor store and no amount of evidence
that Bill Smith didn't do it exonerates Bill Jones, 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 4/16/22 12:03 PM, olcott wrote:
> On 4/16/2022 11:00 AM, Dennis Bush wrote:
>> On Saturday, April 16, 2022 at 11:30:11 AM UTC-4, olcott wrote:
>>> On 4/16/2022 10:17 AM, Dennis Bush wrote:
>>>> On Saturday, April 16, 2022 at 10:44:29 AM UTC-4, olcott wrote:
>>>>> On 4/16/2022 7:27 AM, Dennis Bush wrote:
>>>>>> On Saturday, April 16, 2022 at 1:24:49 AM UTC-4, olcott wrote:
>>>>>>> On 4/15/2022 5:18 PM, Ben wrote:
>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> The following simplifies the syntax for the definition of the Linz
>>>>>>>>> Turing machine Ĥ.
>>>>>>>>>
>>>>>>>>> There is no need for the infinite loop after H.qy because it is
>>>>>>>>> never
>>>>>>>>> reached.
>>>>>>>>
>>>>>>>> You: "No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you
>>>>>>>> many
>>>>>>>> times"
>>>>>>>>
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would reach its own
>>>>>>>>> final state.
>>>>>>>>>
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>>>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would never reach
>>>>>>>>> its
>>>>>>>>> own final state.
>>>>>>>>
>>>>>>>> The correct specification is
>>>>>>>>
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊢* oo if Ĥ applied to ⟨Ĥ⟩ halts, and
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn if Ĥ applied to ⟨Ĥ⟩ does not halt.
>>>>>>>>
>>>>>>>>> void P(u32 x)
>>>>>>>>> {
>>>>>>>>> if (H(x, x)) //
>>>>>>>>> HERE: goto HERE;
>>>>>>>>> }
>>>>>>>>
>>>>>>>> You've told us that H(P,P) is false even though P(P) halts.
>>>>>>>> That's the
>>>>>>>> wrong result for a simple model of a C halt decider.
>>>>>>>>
>>>>>>> When H correctly determines that its input would never reach its own
>>>>>>> final state
>>>>>>
>>>>>> Which is doesn't.
>>>>> LIAR LIAR PANTS ON FIRE
>>>>>
>>>>> The simulated input to H(P,P) cannot possibly reach its own final
>>>>> state
>>>>> it keeps repeating [00000956] to [00000961] until aborted.
>>>>>
>>>>> _P()
>>>>> [00000956](01) 55 push ebp
>>>>> [00000957](02) 8bec mov ebp,esp
>>>>> [00000959](03) 8b4508 mov eax,[ebp+08]
>>>>> [0000095c](01) 50 push eax // push P
>>>>> [0000095d](03) 8b4d08 mov ecx,[ebp+08]
>>>>> [00000960](01) 51 push ecx // push P
>>>>> [00000961](05) e8c0feffff call 00000826 // call H(P,P)
>>>>> The above keeps repeating until aborted
>>>>>
>>>>>
>>>>> [00000966](03) 83c408 add esp,+08
>>>>> [00000969](02) 85c0 test eax,eax
>>>>> [0000096b](02) 7402 jz 0000096f
>>>>> [0000096d](02) ebfe jmp 0000096d
>>>>> [0000096f](01) 5d pop ebp
>>>>> [00000970](01) c3 ret // final state.
>>>>> Size in bytes:(0027) [00000970]
>>>>>
>>>>> THIS IS THE KEY STUPID AND OR DISHONEST MISTAKE OF MY REVIEWERS
>>>>> All of my reviewers take the position that the fact that the input to
>>>>> H(P,P) is non-halting is not an entirely sufficient reason for H to
>>>>> report that its input is non-halting.
>>>>
>>>> FALSE. We reject the "fact" that the input to H(P,P) is non-halting.
>>> If you disagree that France exists I do not need to read the whole
>>> message to see that you are wrong.
>>>
>>> Anyone that knows the x86 language can see that the simulated input to
>>> H(P,P) never reaches its own final state.
>>
>> Anyone that knows the x86 language can see that the simulated input to
>> Ha(Pa,Pa), when given as input to Hb, DOES reach its own final state.
>
> I know that Bill Jones robbed the liquor store and no amount of evidence
> that Bill Smith didn't do it exonerates Bill Jones, Jackass.
>

So the fact that P(P) Halts, and thus the correct simulation of the
input to H(P,P) means you admit that H(P,P) is incorrect to say it is
non-halting?

You H is using exactly that sort of mis-identifcation to 'convict' P,P
of being non-halting. It is looking at the P built from the non-aborting
H instead of the one built on itself, the aborting H.

The problem with using multiple machines by the same name (And why that
is a rejectable error in a paper).

This is why people talk about your TWO halt deciders, Hn and Ha.

On Saturday, April 16, 2022 at 12:03:37 PM UTC-4, olcott wrote:
> On 4/16/2022 11:00 AM, Dennis Bush wrote:
> > On Saturday, April 16, 2022 at 11:30:11 AM UTC-4, olcott wrote:
> >> On 4/16/2022 10:17 AM, Dennis Bush wrote:
> >>> On Saturday, April 16, 2022 at 10:44:29 AM UTC-4, olcott wrote:
> >>>> On 4/16/2022 7:27 AM, Dennis Bush wrote:
> >>>>> On Saturday, April 16, 2022 at 1:24:49 AM UTC-4, olcott wrote:
> >>>>>> On 4/15/2022 5:18 PM, Ben wrote:
> >>>>>>> olcott <No...@NoWhere.com> writes:
> >>>>>>>
> >>>>>>>> The following simplifies the syntax for the definition of the Linz
> >>>>>>>> Turing machine Ĥ.
> >>>>>>>>
> >>>>>>>> There is no need for the infinite loop after H.qy because it is never
> >>>>>>>> reached.
> >>>>>>>
> >>>>>>> You: "No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you many
> >>>>>>> times"
> >>>>>>>
> >>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
> >>>>>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would reach its own
> >>>>>>>> final state.
> >>>>>>>>
> >>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
> >>>>>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would never reach its
> >>>>>>>> own final state.
> >>>>>>>
> >>>>>>> The correct specification is
> >>>>>>>
> >>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊢* oo if Ĥ applied to ⟨Ĥ⟩ halts, and
> >>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn if Ĥ applied to ⟨Ĥ⟩ does not halt.
> >>>>>>>
> >>>>>>>> void P(u32 x)
> >>>>>>>> {
> >>>>>>>> if (H(x, x)) //
> >>>>>>>> HERE: goto HERE;
> >>>>>>>> }
> >>>>>>>
> >>>>>>> You've told us that H(P,P) is false even though P(P) halts. That's the
> >>>>>>> wrong result for a simple model of a C halt decider.
> >>>>>>>
> >>>>>> When H correctly determines that its input would never reach its own
> >>>>>> final state
> >>>>>
> >>>>> Which is doesn't.
> >>>> LIAR LIAR PANTS ON FIRE
> >>>>
> >>>> The simulated input to H(P,P) cannot possibly reach its own final state
> >>>> it keeps repeating [00000956] to [00000961] until aborted.
> >>>>
> >>>> _P()
> >>>> [00000956](01) 55 push ebp
> >>>> [00000957](02) 8bec mov ebp,esp
> >>>> [00000959](03) 8b4508 mov eax,[ebp+08]
> >>>> [0000095c](01) 50 push eax // push P
> >>>> [0000095d](03) 8b4d08 mov ecx,[ebp+08]
> >>>> [00000960](01) 51 push ecx // push P
> >>>> [00000961](05) e8c0feffff call 00000826 // call H(P,P)
> >>>> The above keeps repeating until aborted
> >>>>
> >>>>
> >>>> [00000966](03) 83c408 add esp,+08
> >>>> [00000969](02) 85c0 test eax,eax
> >>>> [0000096b](02) 7402 jz 0000096f
> >>>> [0000096d](02) ebfe jmp 0000096d
> >>>> [0000096f](01) 5d pop ebp
> >>>> [00000970](01) c3 ret // final state.
> >>>> Size in bytes:(0027) [00000970]
> >>>>
> >>>> THIS IS THE KEY STUPID AND OR DISHONEST MISTAKE OF MY REVIEWERS
> >>>> All of my reviewers take the position that the fact that the input to
> >>>> H(P,P) is non-halting is not an entirely sufficient reason for H to
> >>>> report that its input is non-halting.
> >>>
> >>> FALSE. We reject the "fact" that the input to H(P,P) is non-halting.
> >> If you disagree that France exists I do not need to read the whole
> >> message to see that you are wrong.
> >>
> >> Anyone that knows the x86 language can see that the simulated input to
> >> H(P,P) never reaches its own final state.
> >
> > Anyone that knows the x86 language can see that the simulated input to
> > Ha(Pa,Pa), when given as input to Hb, DOES reach its own final state.
> I know that Bill Jones robbed the liquor store and no amount of evidence
> that Bill Smith didn't do it exonerates Bill Jones, Jackass.

Another bad analogy with no explanation. Again showing that you know that you're wrong and have no rebuttal.

On 4/16/2022 11:23 AM, Dennis Bush wrote:
> On Saturday, April 16, 2022 at 12:03:37 PM UTC-4, olcott wrote:
>> On 4/16/2022 11:00 AM, Dennis Bush wrote:
>>> On Saturday, April 16, 2022 at 11:30:11 AM UTC-4, olcott wrote:
>>>> On 4/16/2022 10:17 AM, Dennis Bush wrote:
>>>>> On Saturday, April 16, 2022 at 10:44:29 AM UTC-4, olcott wrote:
>>>>>> On 4/16/2022 7:27 AM, Dennis Bush wrote:
>>>>>>> On Saturday, April 16, 2022 at 1:24:49 AM UTC-4, olcott wrote:
>>>>>>>> On 4/15/2022 5:18 PM, Ben wrote:
>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> The following simplifies the syntax for the definition of the Linz
>>>>>>>>>> Turing machine Ĥ.
>>>>>>>>>>
>>>>>>>>>> There is no need for the infinite loop after H.qy because it is never
>>>>>>>>>> reached.
>>>>>>>>>
>>>>>>>>> You: "No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you many
>>>>>>>>> times"
>>>>>>>>>
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would reach its own
>>>>>>>>>> final state.
>>>>>>>>>>
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>>>>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would never reach its
>>>>>>>>>> own final state.
>>>>>>>>>
>>>>>>>>> The correct specification is
>>>>>>>>>
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊢* oo if Ĥ applied to ⟨Ĥ⟩ halts, and
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn if Ĥ applied to ⟨Ĥ⟩ does not halt.
>>>>>>>>>
>>>>>>>>>> void P(u32 x)
>>>>>>>>>> {
>>>>>>>>>> if (H(x, x)) //
>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> You've told us that H(P,P) is false even though P(P) halts. That's the
>>>>>>>>> wrong result for a simple model of a C halt decider.
>>>>>>>>>
>>>>>>>> When H correctly determines that its input would never reach its own
>>>>>>>> final state
>>>>>>>
>>>>>>> Which is doesn't.
>>>>>> LIAR LIAR PANTS ON FIRE
>>>>>>
>>>>>> The simulated input to H(P,P) cannot possibly reach its own final state
>>>>>> it keeps repeating [00000956] to [00000961] until aborted.
>>>>>>
>>>>>> _P()
>>>>>> [00000956](01) 55 push ebp
>>>>>> [00000957](02) 8bec mov ebp,esp
>>>>>> [00000959](03) 8b4508 mov eax,[ebp+08]
>>>>>> [0000095c](01) 50 push eax // push P
>>>>>> [0000095d](03) 8b4d08 mov ecx,[ebp+08]
>>>>>> [00000960](01) 51 push ecx // push P
>>>>>> [00000961](05) e8c0feffff call 00000826 // call H(P,P)
>>>>>> The above keeps repeating until aborted
>>>>>>
>>>>>>
>>>>>> [00000966](03) 83c408 add esp,+08
>>>>>> [00000969](02) 85c0 test eax,eax
>>>>>> [0000096b](02) 7402 jz 0000096f
>>>>>> [0000096d](02) ebfe jmp 0000096d
>>>>>> [0000096f](01) 5d pop ebp
>>>>>> [00000970](01) c3 ret // final state.
>>>>>> Size in bytes:(0027) [00000970]
>>>>>>
>>>>>> THIS IS THE KEY STUPID AND OR DISHONEST MISTAKE OF MY REVIEWERS
>>>>>> All of my reviewers take the position that the fact that the input to
>>>>>> H(P,P) is non-halting is not an entirely sufficient reason for H to
>>>>>> report that its input is non-halting.
>>>>>
>>>>> FALSE. We reject the "fact" that the input to H(P,P) is non-halting.
>>>> If you disagree that France exists I do not need to read the whole
>>>> message to see that you are wrong.
>>>>
>>>> Anyone that knows the x86 language can see that the simulated input to
>>>> H(P,P) never reaches its own final state.
>>>
>>> Anyone that knows the x86 language can see that the simulated input to
>>> Ha(Pa,Pa), when given as input to Hb, DOES reach its own final state.
>> I know that Bill Jones robbed the liquor store and no amount of evidence
>> that Bill Smith didn't do it exonerates Bill Jones, Jackass.
>
> Another bad analogy with no explanation. Again showing that you know that you're wrong and have no rebuttal.

If {an X is a Y} then anything that disagrees is incorrect.

If {an X is a Y} and Z says that {an X is a Y} then Z is necessarily
correct.

NOTHING IN THE UNIVERSE CAN POSSIBLY CORRECTLY CONTRADICT THIS:
The easily verified fact is that the input to H(P,P) is not halting thus
H(P,P)==false is necessarily correct.

--
Copyright 2022 Pete Olcott

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

On 4/16/22 12:27 PM, olcott wrote:
> On 4/16/2022 11:23 AM, Dennis Bush wrote:
>> On Saturday, April 16, 2022 at 12:03:37 PM UTC-4, olcott wrote:
>>> On 4/16/2022 11:00 AM, Dennis Bush wrote:
>>>> On Saturday, April 16, 2022 at 11:30:11 AM UTC-4, olcott wrote:
>>>>> On 4/16/2022 10:17 AM, Dennis Bush wrote:
>>>>>> On Saturday, April 16, 2022 at 10:44:29 AM UTC-4, olcott wrote:
>>>>>>> On 4/16/2022 7:27 AM, Dennis Bush wrote:
>>>>>>>> On Saturday, April 16, 2022 at 1:24:49 AM UTC-4, olcott wrote:
>>>>>>>>> On 4/15/2022 5:18 PM, Ben wrote:
>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> The following simplifies the syntax for the definition of the
>>>>>>>>>>> Linz
>>>>>>>>>>> Turing machine Ĥ.
>>>>>>>>>>>
>>>>>>>>>>> There is no need for the infinite loop after H.qy because it
>>>>>>>>>>> is never
>>>>>>>>>>> reached.
>>>>>>>>>>
>>>>>>>>>> You: "No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told
>>>>>>>>>> you many
>>>>>>>>>> times"
>>>>>>>>>>
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would reach its
>>>>>>>>>>> own
>>>>>>>>>>> final state.
>>>>>>>>>>>
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>>>>>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would never
>>>>>>>>>>> reach its
>>>>>>>>>>> own final state.
>>>>>>>>>>
>>>>>>>>>> The correct specification is
>>>>>>>>>>
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊢* oo if Ĥ applied to ⟨Ĥ⟩ halts,
>>>>>>>>>> and
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn if Ĥ applied to ⟨Ĥ⟩ does not halt.
>>>>>>>>>>
>>>>>>>>>>> void P(u32 x)
>>>>>>>>>>> {
>>>>>>>>>>> if (H(x, x)) //
>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> You've told us that H(P,P) is false even though P(P) halts.
>>>>>>>>>> That's the
>>>>>>>>>> wrong result for a simple model of a C halt decider.
>>>>>>>>>>
>>>>>>>>> When H correctly determines that its input would never reach
>>>>>>>>> its own
>>>>>>>>> final state
>>>>>>>>
>>>>>>>> Which is doesn't.
>>>>>>> LIAR LIAR PANTS ON FIRE
>>>>>>>
>>>>>>> The simulated input to H(P,P) cannot possibly reach its own final
>>>>>>> state
>>>>>>> it keeps repeating [00000956] to [00000961] until aborted.
>>>>>>>
>>>>>>> _P()
>>>>>>> [00000956](01) 55 push ebp
>>>>>>> [00000957](02) 8bec mov ebp,esp
>>>>>>> [00000959](03) 8b4508 mov eax,[ebp+08]
>>>>>>> [0000095c](01) 50 push eax // push P
>>>>>>> [0000095d](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>> [00000960](01) 51 push ecx // push P
>>>>>>> [00000961](05) e8c0feffff call 00000826 // call H(P,P)
>>>>>>> The above keeps repeating until aborted
>>>>>>>
>>>>>>>
>>>>>>> [00000966](03) 83c408 add esp,+08
>>>>>>> [00000969](02) 85c0 test eax,eax
>>>>>>> [0000096b](02) 7402 jz 0000096f
>>>>>>> [0000096d](02) ebfe jmp 0000096d
>>>>>>> [0000096f](01) 5d pop ebp
>>>>>>> [00000970](01) c3 ret // final state.
>>>>>>> Size in bytes:(0027) [00000970]
>>>>>>>
>>>>>>> THIS IS THE KEY STUPID AND OR DISHONEST MISTAKE OF MY REVIEWERS
>>>>>>> All of my reviewers take the position that the fact that the
>>>>>>> input to
>>>>>>> H(P,P) is non-halting is not an entirely sufficient reason for H to
>>>>>>> report that its input is non-halting.
>>>>>>
>>>>>> FALSE. We reject the "fact" that the input to H(P,P) is non-halting.
>>>>> If you disagree that France exists I do not need to read the whole
>>>>> message to see that you are wrong.
>>>>>
>>>>> Anyone that knows the x86 language can see that the simulated input to
>>>>> H(P,P) never reaches its own final state.
>>>>
>>>> Anyone that knows the x86 language can see that the simulated input to
>>>> Ha(Pa,Pa), when given as input to Hb, DOES reach its own final state.
>>> I know that Bill Jones robbed the liquor store and no amount of evidence
>>> that Bill Smith didn't do it exonerates Bill Jones, Jackass.
>>
>> Another bad analogy with no explanation.  Again showing that you know
>> that you're wrong and have no rebuttal.
>
>
> If {an X is a Y} then anything that disagrees is incorrect.
>
> If {an X is a Y} and Z says that {an X is a Y} then Z is necessarily
> correct.

Yes, and a Halting input is a Halting Input, and if H says otherwise it
is necessarily incorrect.

FAIL.

>
> NOTHING IN THE UNIVERSE CAN POSSIBLY CORRECTLY CONTRADICT THIS:
> The easily verified fact is that the input to H(P,P) is not halting thus
> H(P,P)==false is necessarily correct.
>

Not even YOUR OWN correct simulation of the inpt showing it halts?

On 4/27/21 12:55 AM, olcott wrote:
Message-ID: <Teudndbu59GVBBr9nZ2dnUU7-V2dnZ2d@giganews.com>
> void H_Hat(u32 P)
> {
> u32 Input_Halts = Halts(P, P);
> if (Input_Halts)
> HERE: goto HERE;
> }
>
>
> int main()
> {
> H_Hat((u32)H_Hat);
> }
>
>
> _H_Hat()
> [00000b98](01) 55 push ebp
> [00000b99](02) 8bec mov ebp,esp
>
[00000b9b](01) 51 push ecx
> [00000b9c](03) 8b4508 mov eax,[ebp+08]
> [00000b9f](01) 50 push eax
> [00000ba0](03) 8b4d08 mov ecx,[ebp+08]
> [00000ba3](01) 51 push ecx
> [00000ba4](05) e88ffdffff call 00000938
> [00000ba9](03) 83c408 add esp,+08
> [00000bac](03) 8945fc mov [ebp-04],eax
> [00000baf](04) 837dfc00 cmp dword [ebp-04],+00
> [00000bb3](02) 7402 jz 00000bb7
> [00000bb5](02) ebfe jmp 00000bb5
> [00000bb7](02) 8be5 mov esp,ebp
> [00000bb9](01) 5d pop ebp
> [00000bba](01) c3 ret
> Size in bytes:(0035) [00000bba]
>
> _main()
> [00000bc8](01) 55 push ebp
> [00000bc9](02) 8bec mov ebp,esp
> [00000bcb](05) 68980b0000 push 00000b98
> [00000bd0](05) e8c3ffffff call 00000b98
> [00000bd5](03) 83c404 add esp,+04
> [00000bd8](02) 33c0 xor eax,eax
> [00000bda](01) 5d pop ebp
> [00000bdb](01) c3 ret
> Size in bytes:(0020) [00000bdb]
>
> ===============================
> ...[00000bc8][001015d4][00000000](01) 55 push ebp
> ...[00000bc9][001015d4][00000000](02) 8bec mov ebp,esp
> ...[00000bcb][001015d0][00000b98](05) 68980b0000 push 00000b98
> ...[00000bd0][001015cc][00000bd5](05) e8c3ffffff call 00000b98
> ...[00000b98][001015c8][001015d4](01) 55 push ebp
> ...[00000b99][001015c8][001015d4](02) 8bec mov ebp,esp
> ...[00000b9b][001015c4][00000000](01) 51 push ecx
> ...[00000b9c][001015c4][00000000](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][001015c0][00000b98](01) 50 push eax
> ...[00000ba0][001015c0][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][001015bc][00000b98](01) 51 push ecx
> ...[00000ba4][001015b8][00000ba9](05) e88ffdffff call 00000938
> Begin Local Halt Decider Simulation at Machine Address:b98
> ...[00000b98][00211674][00211678](01) 55 push ebp
> ...[00000b99][00211674][00211678](02) 8bec mov ebp,esp
> ...[00000b9b][00211670][00201644](01) 51 push ecx
> ...[00000b9c][00211670][00201644](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][0021166c][00000b98](01) 50 push eax
> ...[00000ba0][0021166c][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][00211668][00000b98](01) 51 push ecx
> ...[00000ba4][00211664][00000ba9](05) e88ffdffff call 00000938
> ...[00000b98][0025c09c][0025c0a0](01) 55 push ebp
> ...[00000b99][0025c09c][0025c0a0](02) 8bec mov ebp,esp
> ...[00000b9b][0025c098][0024c06c](01) 51 push ecx
> ...[00000b9c][0025c098][0024c06c](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][0025c094][00000b98](01) 50 push eax
> ...[00000ba0][0025c094][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][0025c090][00000b98](01) 51 push ecx
> ...[00000ba4][0025c08c][00000ba9](05) e88ffdffff call 00000938
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped

On Saturday, April 16, 2022 at 12:27:25 PM UTC-4, olcott wrote:
> On 4/16/2022 11:23 AM, Dennis Bush wrote:
> > On Saturday, April 16, 2022 at 12:03:37 PM UTC-4, olcott wrote:
> >> On 4/16/2022 11:00 AM, Dennis Bush wrote:
> >>> On Saturday, April 16, 2022 at 11:30:11 AM UTC-4, olcott wrote:
> >>>> On 4/16/2022 10:17 AM, Dennis Bush wrote:
> >>>>> On Saturday, April 16, 2022 at 10:44:29 AM UTC-4, olcott wrote:
> >>>>>> On 4/16/2022 7:27 AM, Dennis Bush wrote:
> >>>>>>> On Saturday, April 16, 2022 at 1:24:49 AM UTC-4, olcott wrote:
> >>>>>>>> On 4/15/2022 5:18 PM, Ben wrote:
> >>>>>>>>> olcott <No...@NoWhere.com> writes:
> >>>>>>>>>
> >>>>>>>>>> The following simplifies the syntax for the definition of the Linz
> >>>>>>>>>> Turing machine Ĥ.
> >>>>>>>>>>
> >>>>>>>>>> There is no need for the infinite loop after H.qy because it is never
> >>>>>>>>>> reached.
> >>>>>>>>>
> >>>>>>>>> You: "No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you many
> >>>>>>>>> times"
> >>>>>>>>>
> >>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
> >>>>>>>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would reach its own
> >>>>>>>>>> final state.
> >>>>>>>>>>
> >>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
> >>>>>>>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would never reach its
> >>>>>>>>>> own final state.
> >>>>>>>>>
> >>>>>>>>> The correct specification is
> >>>>>>>>>
> >>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊢* oo if Ĥ applied to ⟨Ĥ⟩ halts, and
> >>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn if Ĥ applied to ⟨Ĥ⟩ does not halt.
> >>>>>>>>>
> >>>>>>>>>> void P(u32 x)
> >>>>>>>>>> {
> >>>>>>>>>> if (H(x, x)) //
> >>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>> }
> >>>>>>>>>
> >>>>>>>>> You've told us that H(P,P) is false even though P(P) halts. That's the
> >>>>>>>>> wrong result for a simple model of a C halt decider.
> >>>>>>>>>
> >>>>>>>> When H correctly determines that its input would never reach its own
> >>>>>>>> final state
> >>>>>>>
> >>>>>>> Which is doesn't.
> >>>>>> LIAR LIAR PANTS ON FIRE
> >>>>>>
> >>>>>> The simulated input to H(P,P) cannot possibly reach its own final state
> >>>>>> it keeps repeating [00000956] to [00000961] until aborted.
> >>>>>>
> >>>>>> _P()
> >>>>>> [00000956](01) 55 push ebp
> >>>>>> [00000957](02) 8bec mov ebp,esp
> >>>>>> [00000959](03) 8b4508 mov eax,[ebp+08]
> >>>>>> [0000095c](01) 50 push eax // push P
> >>>>>> [0000095d](03) 8b4d08 mov ecx,[ebp+08]
> >>>>>> [00000960](01) 51 push ecx // push P
> >>>>>> [00000961](05) e8c0feffff call 00000826 // call H(P,P)
> >>>>>> The above keeps repeating until aborted
> >>>>>>
> >>>>>>
> >>>>>> [00000966](03) 83c408 add esp,+08
> >>>>>> [00000969](02) 85c0 test eax,eax
> >>>>>> [0000096b](02) 7402 jz 0000096f
> >>>>>> [0000096d](02) ebfe jmp 0000096d
> >>>>>> [0000096f](01) 5d pop ebp
> >>>>>> [00000970](01) c3 ret // final state.
> >>>>>> Size in bytes:(0027) [00000970]
> >>>>>>
> >>>>>> THIS IS THE KEY STUPID AND OR DISHONEST MISTAKE OF MY REVIEWERS
> >>>>>> All of my reviewers take the position that the fact that the input to
> >>>>>> H(P,P) is non-halting is not an entirely sufficient reason for H to
> >>>>>> report that its input is non-halting.
> >>>>>
> >>>>> FALSE. We reject the "fact" that the input to H(P,P) is non-halting..
> >>>> If you disagree that France exists I do not need to read the whole
> >>>> message to see that you are wrong.
> >>>>
> >>>> Anyone that knows the x86 language can see that the simulated input to
> >>>> H(P,P) never reaches its own final state.
> >>>
> >>> Anyone that knows the x86 language can see that the simulated input to
> >>> Ha(Pa,Pa), when given as input to Hb, DOES reach its own final state.
> >> I know that Bill Jones robbed the liquor store and no amount of evidence
> >> that Bill Smith didn't do it exonerates Bill Jones, Jackass.
> >
> > Another bad analogy with no explanation. Again showing that you know that you're wrong and have no rebuttal.
> If {an X is a Y} then anything that disagrees is incorrect.
>
> If {an X is a Y} and Z says that {an X is a Y} then Z is necessarily
> correct.

The problem is that you don't have an X.

>
> NOTHING IN THE UNIVERSE CAN POSSIBLY CORRECTLY CONTRADICT THIS:
> The easily verified fact is that the input to H(P,P) is not halting

No it's not, as proved by Hb. So prove that Hb (Pa,Pa) == true is not correct or admit defeat.

> thus
> H(P,P)==false is necessarily correct.

If X then Y doesn't matter when X is false.

> --
> 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 4/16/2022 11:51 AM, Dennis Bush wrote:
> On Saturday, April 16, 2022 at 12:27:25 PM UTC-4, olcott wrote:
>> On 4/16/2022 11:23 AM, Dennis Bush wrote:
>>> On Saturday, April 16, 2022 at 12:03:37 PM UTC-4, olcott wrote:
>>>> On 4/16/2022 11:00 AM, Dennis Bush wrote:
>>>>> On Saturday, April 16, 2022 at 11:30:11 AM UTC-4, olcott wrote:
>>>>>> On 4/16/2022 10:17 AM, Dennis Bush wrote:
>>>>>>> On Saturday, April 16, 2022 at 10:44:29 AM UTC-4, olcott wrote:
>>>>>>>> On 4/16/2022 7:27 AM, Dennis Bush wrote:
>>>>>>>>> On Saturday, April 16, 2022 at 1:24:49 AM UTC-4, olcott wrote:
>>>>>>>>>> On 4/15/2022 5:18 PM, Ben wrote:
>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> The following simplifies the syntax for the definition of the Linz
>>>>>>>>>>>> Turing machine Ĥ.
>>>>>>>>>>>>
>>>>>>>>>>>> There is no need for the infinite loop after H.qy because it is never
>>>>>>>>>>>> reached.
>>>>>>>>>>>
>>>>>>>>>>> You: "No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you many
>>>>>>>>>>> times"
>>>>>>>>>>>
>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>>>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would reach its own
>>>>>>>>>>>> final state.
>>>>>>>>>>>>
>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>>>>>>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would never reach its
>>>>>>>>>>>> own final state.
>>>>>>>>>>>
>>>>>>>>>>> The correct specification is
>>>>>>>>>>>
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊢* oo if Ĥ applied to ⟨Ĥ⟩ halts, and
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn if Ĥ applied to ⟨Ĥ⟩ does not halt.
>>>>>>>>>>>
>>>>>>>>>>>> void P(u32 x)
>>>>>>>>>>>> {
>>>>>>>>>>>> if (H(x, x)) //
>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> You've told us that H(P,P) is false even though P(P) halts. That's the
>>>>>>>>>>> wrong result for a simple model of a C halt decider.
>>>>>>>>>>>
>>>>>>>>>> When H correctly determines that its input would never reach its own
>>>>>>>>>> final state
>>>>>>>>>
>>>>>>>>> Which is doesn't.
>>>>>>>> LIAR LIAR PANTS ON FIRE
>>>>>>>>
>>>>>>>> The simulated input to H(P,P) cannot possibly reach its own final state
>>>>>>>> it keeps repeating [00000956] to [00000961] until aborted.
>>>>>>>>
>>>>>>>> _P()
>>>>>>>> [00000956](01) 55 push ebp
>>>>>>>> [00000957](02) 8bec mov ebp,esp
>>>>>>>> [00000959](03) 8b4508 mov eax,[ebp+08]
>>>>>>>> [0000095c](01) 50 push eax // push P
>>>>>>>> [0000095d](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>> [00000960](01) 51 push ecx // push P
>>>>>>>> [00000961](05) e8c0feffff call 00000826 // call H(P,P)
>>>>>>>> The above keeps repeating until aborted
>>>>>>>>
>>>>>>>>
>>>>>>>> [00000966](03) 83c408 add esp,+08
>>>>>>>> [00000969](02) 85c0 test eax,eax
>>>>>>>> [0000096b](02) 7402 jz 0000096f
>>>>>>>> [0000096d](02) ebfe jmp 0000096d
>>>>>>>> [0000096f](01) 5d pop ebp
>>>>>>>> [00000970](01) c3 ret // final state.
>>>>>>>> Size in bytes:(0027) [00000970]
>>>>>>>>
>>>>>>>> THIS IS THE KEY STUPID AND OR DISHONEST MISTAKE OF MY REVIEWERS
>>>>>>>> All of my reviewers take the position that the fact that the input to
>>>>>>>> H(P,P) is non-halting is not an entirely sufficient reason for H to
>>>>>>>> report that its input is non-halting.
>>>>>>>
>>>>>>> FALSE. We reject the "fact" that the input to H(P,P) is non-halting.
>>>>>> If you disagree that France exists I do not need to read the whole
>>>>>> message to see that you are wrong.
>>>>>>
>>>>>> Anyone that knows the x86 language can see that the simulated input to
>>>>>> H(P,P) never reaches its own final state.
>>>>>
>>>>> Anyone that knows the x86 language can see that the simulated input to
>>>>> Ha(Pa,Pa), when given as input to Hb, DOES reach its own final state.
>>>> I know that Bill Jones robbed the liquor store and no amount of evidence
>>>> that Bill Smith didn't do it exonerates Bill Jones, Jackass.
>>>
>>> Another bad analogy with no explanation. Again showing that you know that you're wrong and have no rebuttal.
>> If {an X is a Y} then anything that disagrees is incorrect.
>>
>> If {an X is a Y} and Z says that {an X is a Y} then Z is necessarily
>> correct.
>
> The problem is that you don't have an X.
>
>>
>> NOTHING IN THE UNIVERSE CAN POSSIBLY CORRECTLY CONTRADICT THIS:
>> The easily verified fact is that the input to H(P,P) is not halting
>
> No it's not, as proved by Hb. So prove that Hb (Pa,Pa) == true is not correct or admit defeat.

It is a verified fact that the input to H(P,P) is non-halting.
That you rebut this conclusively proves that you are a liar.

--
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 Saturday, April 16, 2022 at 1:02:30 PM UTC-4, olcott wrote:
> On 4/16/2022 11:51 AM, Dennis Bush wrote:
> > On Saturday, April 16, 2022 at 12:27:25 PM UTC-4, olcott wrote:
> >> On 4/16/2022 11:23 AM, Dennis Bush wrote:
> >>> On Saturday, April 16, 2022 at 12:03:37 PM UTC-4, olcott wrote:
> >>>> On 4/16/2022 11:00 AM, Dennis Bush wrote:
> >>>>> On Saturday, April 16, 2022 at 11:30:11 AM UTC-4, olcott wrote:
> >>>>>> On 4/16/2022 10:17 AM, Dennis Bush wrote:
> >>>>>>> On Saturday, April 16, 2022 at 10:44:29 AM UTC-4, olcott wrote:
> >>>>>>>> On 4/16/2022 7:27 AM, Dennis Bush wrote:
> >>>>>>>>> On Saturday, April 16, 2022 at 1:24:49 AM UTC-4, olcott wrote:
> >>>>>>>>>> On 4/15/2022 5:18 PM, Ben wrote:
> >>>>>>>>>>> olcott <No...@NoWhere.com> writes:
> >>>>>>>>>>>
> >>>>>>>>>>>> The following simplifies the syntax for the definition of the Linz
> >>>>>>>>>>>> Turing machine Ĥ.
> >>>>>>>>>>>>
> >>>>>>>>>>>> There is no need for the infinite loop after H.qy because it is never
> >>>>>>>>>>>> reached.
> >>>>>>>>>>>
> >>>>>>>>>>> You: "No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you many
> >>>>>>>>>>> times"
> >>>>>>>>>>>
> >>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
> >>>>>>>>>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would reach its own
> >>>>>>>>>>>> final state.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
> >>>>>>>>>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would never reach its
> >>>>>>>>>>>> own final state.
> >>>>>>>>>>>
> >>>>>>>>>>> The correct specification is
> >>>>>>>>>>>
> >>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊢* oo if Ĥ applied to ⟨Ĥ⟩ halts, and
> >>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn if Ĥ applied to ⟨Ĥ⟩ does not halt.
> >>>>>>>>>>>
> >>>>>>>>>>>> void P(u32 x)
> >>>>>>>>>>>> {
> >>>>>>>>>>>> if (H(x, x)) //
> >>>>>>>>>>>> HERE: goto HERE;
> >>>>>>>>>>>> }
> >>>>>>>>>>>
> >>>>>>>>>>> You've told us that H(P,P) is false even though P(P) halts. That's the
> >>>>>>>>>>> wrong result for a simple model of a C halt decider.
> >>>>>>>>>>>
> >>>>>>>>>> When H correctly determines that its input would never reach its own
> >>>>>>>>>> final state
> >>>>>>>>>
> >>>>>>>>> Which is doesn't.
> >>>>>>>> LIAR LIAR PANTS ON FIRE
> >>>>>>>>
> >>>>>>>> The simulated input to H(P,P) cannot possibly reach its own final state
> >>>>>>>> it keeps repeating [00000956] to [00000961] until aborted.
> >>>>>>>>
> >>>>>>>> _P()
> >>>>>>>> [00000956](01) 55 push ebp
> >>>>>>>> [00000957](02) 8bec mov ebp,esp
> >>>>>>>> [00000959](03) 8b4508 mov eax,[ebp+08]
> >>>>>>>> [0000095c](01) 50 push eax // push P
> >>>>>>>> [0000095d](03) 8b4d08 mov ecx,[ebp+08]
> >>>>>>>> [00000960](01) 51 push ecx // push P
> >>>>>>>> [00000961](05) e8c0feffff call 00000826 // call H(P,P)
> >>>>>>>> The above keeps repeating until aborted
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> [00000966](03) 83c408 add esp,+08
> >>>>>>>> [00000969](02) 85c0 test eax,eax
> >>>>>>>> [0000096b](02) 7402 jz 0000096f
> >>>>>>>> [0000096d](02) ebfe jmp 0000096d
> >>>>>>>> [0000096f](01) 5d pop ebp
> >>>>>>>> [00000970](01) c3 ret // final state.
> >>>>>>>> Size in bytes:(0027) [00000970]
> >>>>>>>>
> >>>>>>>> THIS IS THE KEY STUPID AND OR DISHONEST MISTAKE OF MY REVIEWERS
> >>>>>>>> All of my reviewers take the position that the fact that the input to
> >>>>>>>> H(P,P) is non-halting is not an entirely sufficient reason for H to
> >>>>>>>> report that its input is non-halting.
> >>>>>>>
> >>>>>>> FALSE. We reject the "fact" that the input to H(P,P) is non-halting.
> >>>>>> If you disagree that France exists I do not need to read the whole
> >>>>>> message to see that you are wrong.
> >>>>>>
> >>>>>> Anyone that knows the x86 language can see that the simulated input to
> >>>>>> H(P,P) never reaches its own final state.
> >>>>>
> >>>>> Anyone that knows the x86 language can see that the simulated input to
> >>>>> Ha(Pa,Pa), when given as input to Hb, DOES reach its own final state.
> >>>> I know that Bill Jones robbed the liquor store and no amount of evidence
> >>>> that Bill Smith didn't do it exonerates Bill Jones, Jackass.
> >>>
> >>> Another bad analogy with no explanation. Again showing that you know that you're wrong and have no rebuttal.
> >> If {an X is a Y} then anything that disagrees is incorrect.
> >>
> >> If {an X is a Y} and Z says that {an X is a Y} then Z is necessarily
> >> correct.
> >
> > The problem is that you don't have an X.
> >
> >>
> >> NOTHING IN THE UNIVERSE CAN POSSIBLY CORRECTLY CONTRADICT THIS:
> >> The easily verified fact is that the input to H(P,P) is not halting
> >
> > No it's not, as proved by Hb. So prove that Hb (Pa,Pa) == true is not correct or admit defeat.
> It is a verified fact that the input to H(P,P) is non-halting.
> That you rebut this conclusively proves that you are a liar.

I proved that the input to Ha(Pa,Pa) does in fact halt when given to Hb.

Any simulating halt decider that simulates its input to its own final state is necessarily correct because the decider never leaves UTM mode. This means that Hb(Pa,Pa) == true is correct, therefore Ha(Pa,Pa) == false is wrong.

On 4/16/2022 12:24 PM, Dennis Bush wrote:
> On Saturday, April 16, 2022 at 1:02:30 PM UTC-4, olcott wrote:
>> On 4/16/2022 11:51 AM, Dennis Bush wrote:
>>> On Saturday, April 16, 2022 at 12:27:25 PM UTC-4, olcott wrote:
>>>> On 4/16/2022 11:23 AM, Dennis Bush wrote:
>>>>> On Saturday, April 16, 2022 at 12:03:37 PM UTC-4, olcott wrote:
>>>>>> On 4/16/2022 11:00 AM, Dennis Bush wrote:
>>>>>>> On Saturday, April 16, 2022 at 11:30:11 AM UTC-4, olcott wrote:
>>>>>>>> On 4/16/2022 10:17 AM, Dennis Bush wrote:
>>>>>>>>> On Saturday, April 16, 2022 at 10:44:29 AM UTC-4, olcott wrote:
>>>>>>>>>> On 4/16/2022 7:27 AM, Dennis Bush wrote:
>>>>>>>>>>> On Saturday, April 16, 2022 at 1:24:49 AM UTC-4, olcott wrote:
>>>>>>>>>>>> On 4/15/2022 5:18 PM, Ben wrote:
>>>>>>>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> The following simplifies the syntax for the definition of the Linz
>>>>>>>>>>>>>> Turing machine Ĥ.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> There is no need for the infinite loop after H.qy because it is never
>>>>>>>>>>>>>> reached.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You: "No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you many
>>>>>>>>>>>>> times"
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>>>>>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would reach its own
>>>>>>>>>>>>>> final state.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>>>>>>>>>>> If the correctly simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ to H would never reach its
>>>>>>>>>>>>>> own final state.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The correct specification is
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊢* oo if Ĥ applied to ⟨Ĥ⟩ halts, and
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn if Ĥ applied to ⟨Ĥ⟩ does not halt.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> void P(u32 x)
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> if (H(x, x)) //
>>>>>>>>>>>>>> HERE: goto HERE;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> You've told us that H(P,P) is false even though P(P) halts. That's the
>>>>>>>>>>>>> wrong result for a simple model of a C halt decider.
>>>>>>>>>>>>>
>>>>>>>>>>>> When H correctly determines that its input would never reach its own
>>>>>>>>>>>> final state
>>>>>>>>>>>
>>>>>>>>>>> Which is doesn't.
>>>>>>>>>> LIAR LIAR PANTS ON FIRE
>>>>>>>>>>
>>>>>>>>>> The simulated input to H(P,P) cannot possibly reach its own final state
>>>>>>>>>> it keeps repeating [00000956] to [00000961] until aborted.
>>>>>>>>>>
>>>>>>>>>> _P()
>>>>>>>>>> [00000956](01) 55 push ebp
>>>>>>>>>> [00000957](02) 8bec mov ebp,esp
>>>>>>>>>> [00000959](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>> [0000095c](01) 50 push eax // push P
>>>>>>>>>> [0000095d](03) 8b4d08 mov ecx,[ebp+08]
>>>>>>>>>> [00000960](01) 51 push ecx // push P
>>>>>>>>>> [00000961](05) e8c0feffff call 00000826 // call H(P,P)
>>>>>>>>>> The above keeps repeating until aborted
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> [00000966](03) 83c408 add esp,+08
>>>>>>>>>> [00000969](02) 85c0 test eax,eax
>>>>>>>>>> [0000096b](02) 7402 jz 0000096f
>>>>>>>>>> [0000096d](02) ebfe jmp 0000096d
>>>>>>>>>> [0000096f](01) 5d pop ebp
>>>>>>>>>> [00000970](01) c3 ret // final state.
>>>>>>>>>> Size in bytes:(0027) [00000970]
>>>>>>>>>>
>>>>>>>>>> THIS IS THE KEY STUPID AND OR DISHONEST MISTAKE OF MY REVIEWERS
>>>>>>>>>> All of my reviewers take the position that the fact that the input to
>>>>>>>>>> H(P,P) is non-halting is not an entirely sufficient reason for H to
>>>>>>>>>> report that its input is non-halting.
>>>>>>>>>
>>>>>>>>> FALSE. We reject the "fact" that the input to H(P,P) is non-halting.
>>>>>>>> If you disagree that France exists I do not need to read the whole
>>>>>>>> message to see that you are wrong.
>>>>>>>>
>>>>>>>> Anyone that knows the x86 language can see that the simulated input to
>>>>>>>> H(P,P) never reaches its own final state.
>>>>>>>
>>>>>>> Anyone that knows the x86 language can see that the simulated input to
>>>>>>> Ha(Pa,Pa), when given as input to Hb, DOES reach its own final state.
>>>>>> I know that Bill Jones robbed the liquor store and no amount of evidence
>>>>>> that Bill Smith didn't do it exonerates Bill Jones, Jackass.
>>>>>
>>>>> Another bad analogy with no explanation. Again showing that you know that you're wrong and have no rebuttal.
>>>> If {an X is a Y} then anything that disagrees is incorrect.
>>>>
>>>> If {an X is a Y} and Z says that {an X is a Y} then Z is necessarily
>>>> correct.
>>>
>>> The problem is that you don't have an X.
>>>
>>>>
>>>> NOTHING IN THE UNIVERSE CAN POSSIBLY CORRECTLY CONTRADICT THIS:
>>>> The easily verified fact is that the input to H(P,P) is not halting
>>>
>>> No it's not, as proved by Hb. So prove that Hb (Pa,Pa) == true is not correct or admit defeat.
>> It is a verified fact that the input to H(P,P) is non-halting.
>> That you rebut this conclusively proves that you are a liar.
>
> I proved that the input to Ha(Pa,Pa) does in fact halt when given to Hb.
>

God damn liars continue to pretend that verified facts can be correctly
contradicted. Maybe I should put you on Thunderbird filters delete posts
from "Dennis Bush".

> Any simulating halt decider that simulates its input to its own final state is necessarily correct because the decider never leaves UTM mode. This means that Hb(Pa,Pa) == true is correct, therefore Ha(Pa,Pa) == false is wrong.
>

--
Copyright 2022 Pete Olcott

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