Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: joes <noreply@example.com>
Newsgroups: comp.theory
Subject: Re: How Partial Simulations correctly determine non-halting ---Mike
 Terry Error
Date: Fri, 7 Jun 2024 14:55:09 -0000 (UTC)
Organization: i2pn2 (i2pn.org)
Message-ID: <v3v70d$39q1p$1@i2pn2.org>
References: <v3j20v$3gm10$2@dont-email.me>
	<J_CdnTaA96jxpcD7nZ2dnZfqnPudnZ2d@brightview.co.uk>
	<87h6eamkgf.fsf@bsb.me.uk> <v3kcdj$3stk9$1@dont-email.me>
	<v3l7uo$13cp$8@dont-email.me> <v3lcat$228t$3@dont-email.me>
	<v3mq9j$chc3$1@dont-email.me> <v3mrli$chc4$1@dont-email.me>
	<_gWdnbwuZPJP2sL7nZ2dnZfqn_GdnZ2d@brightview.co.uk>
	<v3nkqr$h7f9$3@dont-email.me> <v3oeh5$jthg$2@dont-email.me>
	<v3of8e$lirl$1@dont-email.me> <v3ofld$jthh$1@dont-email.me>
	<v3oh8l$pi6u$3@dont-email.me> <v3ohkh$jthg$4@dont-email.me>
	<87frtr6867.fsf@bsb.me.uk>
	<p5ydnbxV2pHtF_37nZ2dnZfqn_WdnZ2d@brightview.co.uk>
	<v3q4ut$11tp3$1@dont-email.me>
	<sYqdnVoAec4XV_37nZ2dnZfqn_ednZ2d@brightview.co.uk>
	<v3qnip$152b5$1@dont-email.me>
	<wEKdnZMVNMfSrf_7nZ2dnZfqn_WdnZ2d@brightview.co.uk>
	<v3tsmq$1td1o$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 7 Jun 2024 14:55:09 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="3467321"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="nS1KMHaUuWOnF/ukOJzx6Ssd8y16q9UPs1GZ+I3D0CM";
User-Agent: Pan/0.145 (Duplicitous mercenary valetism; d7e168a
 git.gnome.org/pan2)
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 19753
Lines: 336

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.
========== REMAINDER OF ARTICLE TRUNCATED ==========