Re: How Partial Simulations correctly determine non-halting ---Mike Terry Error

Am Fri, 07 Jun 2024 09:59:14 -0500 schrieb olcott:

On 6/7/2024 9:55 AM, joes wrote:

Am Thu, 06 Jun 2024 21:53:13 -0500 schrieb olcott:

On 6/6/2024 4:55 PM, Mike Terry wrote:

On 05/06/2024 23:07, olcott wrote:

On 6/5/2024 3:28 PM, Mike Terry wrote:

On 05/06/2024 17:49, olcott wrote:

On 6/5/2024 10:55 AM, Mike Terry wrote:

On 05/06/2024 10:38, Ben Bacarisse wrote:

John Smith <news2@immibis.com> writes:

UTM's must share a portion of their tape with their simulated Turing
Machine description. They should also be able to read from this
portion tape of their own tape yet not write to this portion.

[Did you mean: UTMs must share a portion of their tape with the machine
they are simulating. These UTMs should also be able to read from this
portion of their own tape yet not write to it.]

Did you mean this?

No. The simulation can't know about its simulator. The simulator can do
whatever the fuck it wants, as long as the simulated state (incl. tape)
is right. The simulatee does whatever it does. Of course the simulator
must write to to its own tape, because it is the only machine running.

I repeat: your code is wrong.

When they maintain an incorrect notion what a correct simulation is
then they cannot possibly understand that ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated
by embedded_H is this exact same thing.

What is the incorrect notion?

What is an incorrect simulation?

If a UTM cannot pass a portion of its own tape to its simulated Turing
machine description (TMD) then UTMs cannot exist because this is the
ONLY way for the simulated TMD to get any tape space.
Certainly a UTM can read form its own tape. The objections that you
have seem to be based on false assumptions about HH.

No other machine suddenly starts running on the same tape. The
description is initially on the tape (and the input), and the simulator
maintains the simulated state in some other part of the tape, and looks
at the description to change the representation of the tape and state.
The simulatee does not have any tape space because it is only being
simulated.

The only legit way of doing this (without breaking
simulation-compatibility behaviour rules somewhere below from an
earlier post) is for each simulation to have its own trace table.

That is not the way that actual UTMs work.

There are no actual UTMs here.
If you share the trace table, you must prove it is not being read.

This never happens. The outer HH called from main() writes its trace
to execution_trace and never writes anything every again.
The last thing that it writes is the call to the next inner HH.

Surely it would write something when a called function returns?

I see Joes has summed it up succinctly:  The TM /uses/ its tape to
/implement/ the virtual machine where simulation is occuring.  That's
not a read/write backchannel between the simulator and simulated.

They are exactly the same except that the inner ones remain stuck in
recursive simulation until the outer one stops simulating its DD.

They are definitely not the same.

It is the exact same freaking machine code forcing it to be exactly
the same.

But do they also behave the same?

Apparently not.

so that as the code stands, the outer simulations in fact /won't/
write to the shared area (until the inner simulations terminate).

Not even then because the inner ones only terminate when the outer one
aborts its simulation of DD.

But the outer one continues running.

When HH simulates each instruction of the x86 machine code of DD
correctly and in the correct order THEN THIS CONCLUSIVELY PROVES THAT
THE SIMULATION IS CORRECT.

And continues to the last one, if any.

Yet they themselves cannot ever stop running unless and until the
outer HH stops simulating them. If every HH stops simulating after
three recursive simulations then the outer one sees this first.

If they halted, their simulation wouldn't need to be stopped.

They are not currently exactly the same, as explained above.  HH
simulated code paths are quite different to outer HH.

Not at all as a verified fact.

What does their tracew look like again?

So far EVERYONE has rejected the basic notion of a simulating halt
decider out-of-hand without sufficient review for three years.

One should think that three years constitute sufficient review.

Three years of people denying the verified facts?
 
Try to show how this DD correctly simulated by any HH ever stops running
without having its simulation aborted by HH.
_DD()
[00001e12] 55         push ebp [00001e13] 8bec       mov  ebp,esp
[00001e15] 51         push ecx [00001e16] 8b4508     mov  eax,[ebp+08]
[00001e19] 50         push eax      ; push DD [00001e1a] 8b4d08     mov
ecx,[ebp+08]
[00001e1d] 51         push ecx      ; push DD [00001e1e] e85ff5ffff call
00001382 ; call HH

How about you actually respond to my comments?

--
joes