Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!i2pn.org!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 ---Ben's
 10/2022 analysis
Date: Fri, 7 Jun 2024 11:51:48 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v3vaak$39ri5$16@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> <v3p4ka$sk6h$1@dont-email.me>
 <v3pp7p$v133$8@dont-email.me> <v3s27e$1f9kd$1@dont-email.me>
 <v3sf1n$1gra7$11@dont-email.me> <v3sjo9$1ialb$1@dont-email.me>
 <v3skoo$1iedv$1@dont-email.me> <v3u9ej$1v7rn$1@dont-email.me>
 <v3v6i7$23l33$1@dont-email.me> <v3v70o$21qlc$3@dont-email.me>
 <v3v7j8$242e9$2@dont-email.me> <v3v7qh$21qlc$4@dont-email.me>
 <v3v8f9$242e9$3@dont-email.me> <v3v96e$39q1p$4@i2pn2.org>
 <v3v9ll$242e9$7@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 15:51:48 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="3468869"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <v3v9ll$242e9$7@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 5381
Lines: 85

On 6/7/24 11:40 AM, olcott wrote:
> On 6/7/2024 10:32 AM, joes wrote:
>> Am Fri, 07 Jun 2024 10:20:09 -0500 schrieb olcott:
>>> On 6/7/2024 10:09 AM, Python wrote:
>>>> Le 07/06/2024 à 17:05, olcott a écrit :
>>>>> On 6/7/2024 9:55 AM, Python wrote:
>>>>>> Le 07/06/2024 à 16:47, olcott a écrit :
>>>> Anyway, you're wrong : a Turing machine can take its own description as
>>>> part of its input, as it is finite.
>>> That is what I said. They cannot however take actual Turing machines as
>>> inputs it must always be a finite string machine description.
>> Of course. That is not a restriction.
>>
>>>>>>> The issue here is that I proved that DD correctly simulated by HH
>>>>>>> has different behavior than the directly executed DD(DD) and
>>>>>>> everyone's "rebuttal" to this proof is to simply ignore it.
>>>>> When you actually try to form a rebuttal of the above you will see
>>>>> that I am correct. So far everyone simply ignores the proof that I am
>>>>> correct as their only rebuttal.
>>> A {correct simulation} means that each instruction of the above x86
>>> machine language of DD is correctly simulated by HH and simulated in the
>>> correct order.
>> And to the end. Thus it can't behave differently than direct execution.
>>
> 
> void Infinite_Recursion(u32 N)
> {
>    Infinite_Recursion(N);
> }
> 
> You must not be very good at programming if you believe
> that Infinite_Recursion must be simulated "to the end"

And you must not be very good at all at programming (or logic) if you 
believe that shows anything about your case.

We can PROVE from a partial simulation of Infinite_Recursion that a 
complete simulation would never end. We can't do that for D.

> 
>>> Anyone claiming that HH should report on the behavior of the directly
>>> executed DD(DD) is requiring a violation of the above definition of
>>> correct simulation.
>> But those are the same. How does simulating something change it?
>>
> 
> It seems to boil down to you just don't know enough about
> programming otherwise it would occur to you that there
> cannot possibly exist any correct rebuttal to the following:
> 
> Try to show how this DD correctly simulated by any HH ever
> stops running without having its simulation aborted by HH.

Which is the wrong question, as has been pointed out to you for years.

But you have been caught in the briar patch by your own strawman, and 
thus fallen off the path you were tring to get to.

> 
> _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
> 
> A {correct simulation} means that each instruction of the
> above x86 machine language of DD is correctly simulated
> by HH and simulated in the correct order.
> 
> Anyone claiming that HH should report on the behavior
> of the directly executed DD(DD) is requiring a violation
> of the above definition of correct simulation.
> 
> 

And thus, you have proved that you are not talking about halting. as 
halting *IS* about the directly execute DD(DD), so if your definition of 
"correct simulation" can't map to it, it isn't applicable for the problem.

You are just admitting to trying to feed the world your POOP as a 
substitue for Halting, but the world doesn't what your POOP, it 
generally needs to know about actual Halting.