Re: Linz proof is essentially isomorphic

On 7/31/24 12:11 AM, olcott wrote:

On 7/30/2024 10:19 PM, Richard Damon wrote:

On 7/30/24 10:20 PM, olcott wrote:

On 7/30/2024 8:56 PM, Mike Terry wrote:

On 30/07/2024 08:19, joes wrote:

Am Mon, 29 Jul 2024 19:16:29 -0500 schrieb olcott:

On 7/29/2024 5:57 PM, Mike Terry wrote:

On 29/07/2024 20:36, Fred. Zwarts wrote:

Op 29.jul.2024 om 15:03 schreef olcott:

On 7/29/2024 2:29 AM, Fred. Zwarts wrote:

Op 28.jul.2024 om 22:10 schreef olcott:

On 7/28/2024 2:14 PM, Fred. Zwarts wrote:

Op 28.jul.2024 om 16:25 schreef olcott:

On 7/28/2024 2:59 AM, Fred. Zwarts wrote:

Op 28.jul.2024 om 05:15 schreef olcott:

On 7/27/2024 7:40 PM, Mike Terry wrote:

On 27/07/2024 19:14, Alan Mackenzie wrote:

olcott <polcott333@gmail.com> wrote:

>

You didn't even bother to look at how HHH examines the execution
trace of Infinite_Recursion() to determine that Infinite_Recursion()
specifies non-halting behavior.
Because of this you cannot see that the execution trace of DDD
correctly emulated by DDD is essentially this same trace and thus
also specifies non-halting behavior.

>
That is only because you are cheating, by hiding the conditional
branch instructions of HHH, which should follow the call instruction
into HHH.
HHH simulating itself is more like
void Finite_Recursion (int N) {
    if (N > 0) Finite_Recursion (N - 1);
}

>
Also there is the crucial difference that Infinite_Recursion() trace is
a trace for a single x86 processor.  The HHH/DDD trace is not a single
processor trace, as it contains entries for multiple virtual x86
processors, all merged into one.  There are all sorts of argument that
can be applied to the simple single x86 processor trace scenario, that
simply don't work when transferred to a multi-processor-simulation
merged trace.  PO doesn't understand these differences, and has said
there is NO difference!  He also deliberately tries to hide these
difference, by making his trace output resemble a single-processor
trace as far as he can:

non sequitur:

The simple fact that you continue to ignore is that DDD is correctly
emulated by DDD according to the semantics of the x86 instructions of
DDD and HHH that includes that DDD does call HHH(DDD) in recursive
emulation that will never stop running unless aborted.

Nobody is ignoring that.
The "unless" applies - every HHH in fact aborts simulating.
>

-  suppressing trace entries in H which would make it obvious that the
matching calls

I am not suppressing any freaking trace entries

You are completely suppressing the trace of the simulator HHH.
>

Two complete simulations show a pair of identical TMD's are simulating a
pair of identical inputs. We can see this thus proving recursive
simulation.

Except for the Root variable.
>

     to HHH are from completely separate logical x86 processors.  The
output as he presents it
     looks pretty much identical to the corresponding (but totally
different character) CALL
     scenario where HHH calls DDD rather than simulating it.

Right. I was confused by that for a while. A call could not be aborted.

>
Exactly.  To avoid infinite recursion:
-  Recursive /call/ pattern MUST break from innermost call at some point, which then percolates back throught the stack of calls until the outer call finally returns.

>
I have already shown that the Linz proof is essentially
isomorphic, thus making those points moot.
>
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(g) goto (d) with one more level of simulation
>
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(g) goto (d) with one more level of simulation
>
Two complete simulations show a pair of identical TMD's
are simulating a pair of identical inputs. We can see this
thus proving recursive simulation that cannot possibly
stop running unless aborted.
>
>

>

 embedded_H never stops running unless it aborts ⟨Ĥ⟩ ⟨Ĥ⟩

"unless" isn't app[licable, because embedded_H is a fixed defined program, as Yoda says, DO or DO NOT.
As any one instances, there is just one thing called "embedded_H" which must be identical to the one thing called "H"
If your ONE embedded_H aborts, so it answers, then the ONE H^ will halt.
If your ONE embeddED_H doesn't abort, it never answers.
You just don't understand the basic properties of programs.
Maybe your punsihment is Hell will be to use a computer that works the way you have tried to define how they work, where programs just spontaniously change what they do.,

 

But, since the simulations ard CONDITIONAL, since H / embedded_H by your logic WILL abort is simulation, and thus the embedded_H WILL abort its simulation too, it says that the embedd_H that started its simulation on the first occurance of (c) WILL abort its simulation after that one more level of simulation, and then return to H^.qn, where H^ (H^) will halt.
>
It is the bahavior of the machine H^ (H^) that H (H^) (H^) or equivalently that embedded_H (H^) (H^) needs to answer about, and since that halts, it needs to go to qy, but it won't.
>
You aren't allowed to imagine embedded_H being two different machines, either it DOES abort, and theu H^ (H^) will halt, or it doesn't, at which point H /embedded_H fails to be a decider.
>
Either way it fails to be a correct halt decider.
>
you can't use the behavior of one embedded_H to validiate the behaviofr of a different embedded_H.