Path: ...!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory,sci.logic
Subject: Re: How Partial Simulations correctly determine non-halting ---Mike
 Terry Error
Date: Thu, 6 Jun 2024 23:29:49 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v3turd$388ri$3@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; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 7 Jun 2024 03:29:49 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="3416946"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <v3tsmq$1td1o$1@dont-email.me>
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 37719
Lines: 841

On 6/6/24 10:53 PM, olcott wrote:
> 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:
>>
>> tldr;
>> 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 red from this portion
> tape of their own tape yet not write to this portion.

Nope, they create a "virtual" tape for the machine they are emulating 
(which gets encoded onto the tape, but in a way that the emulated 
machine can't tell the difference between the emulated tape and a real 
tape).

Remember, the description, as its is being emulated, needs to produce 
the IDENTICAL results to what it would have done if directly run, thus 
that description can't tell if its is being emulated or the machine 
described being directly run.

I know that seems complecated, but that is how it is defined to work.

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

But the traces you provide, are not a part of any properly produced 
tracing of the execution of the input, and HIDING the actual trace just 
indicates that you think there may be some evidence there you want to 
hide, if we can actually assume they exist at all.

After all, the code for you published H, SPECIFICALLY doesn't simulate 
the instructions of H, but just jump to the simulation of the machine 
being simulated, just like you publish, leading us to be able to suspect 
that that is what you are actually publishing.

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

Then you can prove it so.

Just publish some where that volumonous trace.

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

Except that it isn't infinite recursive simulation, as EVERY layer of 
that simulation, if fully simulated, would also abort the simulation it 
is doing and return to its called.

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

If so, you don't have a legacy, except of shame.

> 
> *This is my most concise proof of that*
> On 6/6/2024 1:35 PM, olcott wrote:
> Subject: [DD correctly simulated by HH ---
> never stops running without aborting its simulation]

Which is a meaningless statement if you goal is to say something about 
halting.

So, I guess your life was just meaningless.

> 
>> The whole x86utm thing does not really add to your argument, and 
>> certainly does not "prove" the things you think it proves.  That won't 
>> change if you spend your time fixing it. Instead you could just forget 
>> the traces etc. and argue your case in words.
>>
> 
> Once the x86utm version is correctly understood this forces people
> to understand that my notion of a correct simulation is correct or
> lie about it. Richard seem to prefer to lie about it. You refuse
> to look at my proof.

The problem is that you alternate definition of "correct simulation" 
just fails to provide the needed information to show non-halting behavior.

Correct partial simulation just isn't good enough, especially when you 
do it with just a single depth of simulation over an infinite number of 
diffferent machines.


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

But the execution trace doesn't actually prove anything, except that HH 
aborts its simulation, and returns to its caller, so since it is defined 
to be a pure function, we know that DD *MUST* in its actual execution 
get that same answer and thus shows that H was wrong.

By closing your eyes to the truth, you don't make it go away, just prove 
that you have a reckless disregard for the truth.

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

But it is YOU that has a incorrect notion, if the goal is to show that 
the machine being simulated is non-halting.

This is simply proven by the fact that the machine being simulated when 
run will halt, and that most simple definition of "correct" for a 
simulation is that it matches with the behavior it is trying to simulate.

> 
>>>>>>>
>>>>>>>> Then increase the stack space until it doesn't run out. Turing 
>>>>>>>> machines
>>>>>>>> can't run out of stack space unless you programmed them wrong.
>>>>>>>
>>>>>>> A Turing machine can't run out of stack space because there is no 
>>>>>>> stack.
>>>>>>> That's like saying a polynomial has limited precision if you 
>>>>>>> evaluate it
>>>>>>> badly.  It's the evaluation that's wrong, not the polynomial.  I 
========== REMAINDER OF ARTICLE TRUNCATED ==========