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

On 6/7/24 10:59 AM, olcott wrote:

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

long post.
Thanks Mike for the explanation.
>
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:

1) UTMs /aren't/ allowed to share a portion of their input tape with
what they're simulating.  (In the sense you mean.)

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.]
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.
>

2) At some point below I realised you were probably thinking that
because you suppress trace entries for everything but D/DD/.. code,
that means that inner simulations won't see trace entries from outer
simulations

Not at all. These traces are simply not displayed they still exist.
For three years no one has been able to correctly understand 1/2 of one
page of execution trace, thus mixing in 251 more pages CANNOT POSSIBLY
HELP.

The "problem" is not with the amount, but with the content.
>

[i.e. because they've been suppresed from the table].  That would be
correct but I didn't go back and re-edit earlier comments I'd made.
3) Your proposal will still be breaking basic simulation rules.

Based on your false assumption yes. It is a false assumption though.

4) I started to answer your question on how HH would do it properly,
but I would need more info on what exactly is needed.  So I'll wait for
your reply on that.

HH needs to see exactly what it does see the inner execution trace of DD
derived by one single recursive simulation. I just checked HH simply
recognizes this as an instance of infinite recursion. It has no idea
that DD is calling itself.

>

Most of all, I'd question whether it's worthwhile for you to expend
much of your remaining time on this issue.

It is my ONLY life's legacy and despite the fact that you very
persistently continue to simply ignore key details the notion of a
simulating halt decider IS VALID.

Sad to hear.
>

Disagreeing with the execution trace of this code is like disagreeing
with arithmetic. LIARS ARE EXPOSED.

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?
>

[but the problem is I don't believe you really understand what the
requirements of simulation are, because if you did you simply
wouldn't have written code like that in the first place...]

I was emulating a UTM passing a portion of its own tape down to its
simulated instances of itself. That aspect always seemed legit.

No it's not legit.

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.
>

There is no UTM tape in your x86utm and you've just picked on this
wording because in your mind it seems to validate something people
point out is wrong in your code.

The final result must be valid at the Turing Machine level so I create
the analog at the C level.

>

And calling it "a portion of what is essentially its own TM tape" is
just obfuscation to try to hide the obvious breaking of rules.

Not if the simulated instances never access the data from the
outer-simulations. I will encode this to make it impossible.

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.
It must work with actual UTMs.

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

I will encode u32 start_tape_address to the position in
execution_trace where the simulated HH begins so that it will not ever
look further back.
execution_trace is essentially a std::vector of Decoded_Line_Of_Code

That's exactly what I imagined.  But OUTER traces will write their
trace data into the vector BEYOND your start_tape_address.  In fact,
99% (or more) of entries beyond your start_tape_address will be for
outer simulation instructions.

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?
>

The key objection that you seemed to have is that it can't pass any
information to its simulated instance that they can use in their own
halt status decision.

Partly right but woefully incomplete.  If you added "...or to modify
its logical behaviour in any way" that would be a good summing up.

Either the simulated instances must some how know not to allocate
memory for what is essentially a portion of the master UTM tape that
is passed down to them, or the master UTM must some how find the UTM
tape of these simulated instances.

By now you must have realised the problem is the "master UTM tape",
which is not part of any computation model you're using.  Even TMs,
which do have a (personal) tape, cannot have a shared read/write
portion of tape that is global to all simulations.

The outer HH instance can see the inner simulations the inner
simulations do not need to see the outer ones. It is the outer
simulation that first sees its abort criteria. I can code this better.

>

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.

Thanks, I see you too.

No one here has had much of any actual clue besides you.

>

More specifically, the behaviour of a simulated HH must exactly[*]
match the behaviour of the outer (unsimulated) HH.
Behaviour means all of the following:
-  the instruction path of simulated HH exactly matches the
instruction path
     of the outer HH.  [Currently HH has different code paths for
simulated/
     outer execution!  It is not enough that you /believe/ this
     will not affect "the result".]

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?
>

Part of the issue here is that you routinely filter out all the logging
entries from H/HH, so perhaps it's not obvious to you that they are
different.  The "remain stuck" is OT.

HH never looks at any code the is part of the x86utm operating system.
HH cannot handle conditional branch instructions at all.

That seems to be incomplete to me.
>

The inner simulations examined a succession of trace entries written
by other simulation levels.

I don't think that they ever did this and they certainly do not need
to do this so I will encode HH so this is impossible.

I don't believe that can be legitimately achieved with your approach.

I think that I showed that it can with actual UTMs.

"Your approach" being a shared table.
>

Incidently I've just checked the HH source code, and nested HH's
actually SKIP all the inspection of trace tables! - it's skipped due to
the "Am I being simulated" logic, so the code path is completely
different to the outer HH.  (Perhaps because of this they don't see
outer trace data but that code is an even worse problem.)  Simulations
(must) have no way of detecting they're being simulated.

It might look like that. HH always ignores all of the x86utm operating
system code.

>

  That seems to be what you're
imagining.  But the outer simulations are still running!!!! They will
continue generating trace entries

Nope they completely finished before the inner one begins.
HH ignores all of the x86utm operating system code so when DD calls
another instance of HH(DD,DD) that is the last thing that the outer HH
ever writes to its execution_trace.

>

and writing to the table which will be picked up by the inner
simulations.
Hmmmmmmmmmmmm, I've just had a realisation - you're thinking that you
/suppress/ all those outer trace entries because you only capture
instructions from within D/DD.  So although you /are/ sharing one
memory area for output by all levels of simulation, you've arranged
your code

Yes just like a UTM shares a portion of its own tape.

>

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.
>

Nonetheless, simulators simply do not share such read/write
backchannels between simulator and simulated code.  Posters here can
and I'm sure WILL simply point out that "this is not a valid
simulation".

Posters here besides you seem to be happy with disagreeing with verified
facts. I thought that Ben was lying too, the real issue is that he was
hiding his ignorance of some of these technical details. He may have
memorized theory of computation material quite well. He may have been
mostly clueless about actual programming.

Your evil twin?
>

Another point -  The simple restrictions (like no mutable static data,
identical code paths, use of pointer values and so on) are actually
principles intended to /help/ you to justify the correctness of your
code.  As soon as you start deliberately breaking them but claiming it
doesn't matter, you're goint to have problems convincing people the
code logic does what you claim.  Don't think you can just tell people
"Anyone with enough skill can see that blah blah" and all will be ok -
you should realise through experience that doesn't turn out as you'd
hope.

They only need to look at things at a high level of abstraction to see
that I totally proved that DD is correctly simulated by HH with no need
to ever look at any of my code.

Then don't point at your code as "proof".
>

https://liarparadox.org/DD_correctly_simulated_by_HH_is_Proven.pdf 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.
>

As for (a):  What I think you're proposing is to still have the
global trace table, initialised by the outer HH, and still have
different code paths followed by inner and outer simulations.  That's
all No Good.

The outer UTM is allowed to pass a portion of its own tape to its
simulated instances. I may not have done this in the cleanest way, yet
*this <is> my architectural design intention*

UTMs just DO NOT DO THAT.  Where do you get the idea someone has
"allowed" them to do that?

(1) UTMs either share a portion of their own tape with their simulated
Turing machine Description or UTMs cannot exist.
(2) UTMs can read from their own tape.
(3) UTMs cannot write to the portion of this tape that their simulated
TMDs are using or the notion of computable function is trashed.

See above.
>

In effect you're still trying to keep the shared mutable static data
idea that breaks all 3 of the "proper simulation" requirements I laid
out above.

The outer UTM is allowed to pass a portion of its own tape to its
simulated instances. I may not have done this in the cleanest way, yet
*this <is> my architectural design intention*

UTMs just DO NOT DO THAT.

Before the notion of simulating halt decider that I invented they never
needed to do that.

They still don't.
>

I think you're confused by my comment somewhere else about the outer TM
using its own tape resources to /implement/ the virtual machine it
creates, like a TM that calculates Pi /uses/ its tape as a resource
during its calculation.  That doesn't count as "sharing a portion of
its tape with the calculation.

Obviously a simulator has access to the internal state (tape contents
etc.) of the simulated machine. No problem there.

Because that state doesn't exist outside of the simulator.
>

Anyway, the correct approach should obviously be for each simulation
to maintain its own trace table which is only written to and read by
itself.  [Obviously, outer simulations could work out where that
virtual table was implemented and /scrape/ data out of it if they
wanted to.

I knew that was one option yet could not figure out any way that HH
can reliably scrape the data from its inner simulated HH instances
without knowing that these inner HH instances are a copy of itself.

Not necessary.

If HH merely knows its own machine address then it can do this. If HH
knows its own machine address then there is no need for data scraping
it rejects the next simulation of itself before it begins. The newer H
already does that.

Rather than HH having to know its own machine address, it is more the
case that HH has to recognise when its simulated computation is itself
executing a DebugStep to simulating something.

DebugStep() is an x86utm operating system function. HH must ignore all
OS functions because they contain conditional branch instructions that
ruin its non-halting criteria.

Funny, that.
>

  Since in your x86utm
operations like DebugStep are primitive ops (provided atomically by
x86utm rather than the "user code" in H/HH/..) it is easy for HH to see
that it is simulating a nested DebugStep() operation.  Also it can see
what that nested DebugStep is debugstepping and so on.

It must ignore its own code or it fails.

>

But those outer simulations would have their own trace tables with
the data relevant for their processing.  What's more, the code paths
and behaviours of HH in each simulation level would be identical
which is a basic simulation requirement.

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.
>

The only issue left that seems to not matter is that each simulated
HH needs to see if it must initialize its own tape. Since this has
no effect on its halt status decision I don't think it makes any
difference.

That's wrong thinking.  Each simulation level must be exactly the
same as the outer one.  Not just in terms of "their halt status
decision" but in terms of code paths, data values accessed  [*
qualified as explained above due to data relocation issues in your
environment].

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 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 do their traces look like again?
>

I can do all of this when HH can know its own machine address. H(D,D)
is already implemented this way.
To follow your advice HH still needs to know its own machine address
so that its knows that the simulated copies of itself are copies of
itself. If it does not know this then is has no idea where to look
inside the simulated copies to find their execution traces.

You could simulate all programs with a trace in a fixed place.

It simply has to recognise that a recursive DebugStep is occuring and
scrape what it needs at that point.  Or perhaps it can just use what is
returned directly by the outer DebugStep.  It depends on exactly what
data HH needs in that situation, and what DebugStep returns.  [more
below...]

Can't possibly do this. This would take 20 more years and one million
dollars.
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.

And what does that matter.
All it proves is that your assertion of the subject is INCORRECT.
Because if we assume that no HH can correctly partially simulate its DD to a final state, then we can also show that for EVERY HH, that does abort its simulation and returns 0, that the ACTUAL BEHAVIOR of the machine described by the input is to halt, and thus your proposition is proven incorrect.
The fact that you continue to assert it just shows how utterly stupid and ignorant you are. That you just live in a reckless disregard for the truth and actual facts.
You are worse then the election deniers. At least there claims have a remote possibility of being true if there was a massive cover-up of facts. But you can't "cover-up" mathematical behavior, so you don't have that out.

 _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