Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory,sci.logic
Subject: Re: How Partial Simulations correctly determine non-halting ---Mike
 Terry Error
Date: Fri, 7 Jun 2024 09:59:14 -0500
Organization: A noiseless patient Spider
Lines: 359
Message-ID: <v3v783$242e9$1@dont-email.me>
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> <v3v70d$39q1p$1@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 07 Jun 2024 16:59:16 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="ad5aa88e540ea762834522b410d9de6a";
	logging-data="2230729"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19JnAi0D6uVIsaKvqo/zAY2"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:bSoYFOo3DvDHJ5Zh4FvyZr+D9+Y=
In-Reply-To: <v3v70d$39q1p$1@i2pn2.org>
Content-Language: en-US
Bytes: 21002

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