Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!news.quux.org!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: DDD specifies recursive emulation to HHH and halting to HHH1
Date: Mon, 31 Mar 2025 18:47:03 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <4dfe8b7810cf65376a740569f2d40fd1978476eb@i2pn2.org>
References: <vrfuob$256og$1@dont-email.me> <vs7kvf$3eal$2@dont-email.me>
 <aeb75b411e9f77c974585181c671a47d03b22078@i2pn2.org>
 <vs7qdm$8dae$2@dont-email.me> <vs7r9b$8ajp$1@dont-email.me>
 <vs92l3$1fccq$5@dont-email.me> <vs93ae$1k9u2$1@dont-email.me>
 <vs9g5p$1v2n9$5@dont-email.me> <vs9gcg$20g2j$3@dont-email.me>
 <vs9h9o$23cav$2@dont-email.me> <vs9hh3$20g2j$6@dont-email.me>
 <vs9jie$23cav$4@dont-email.me> <vs9kb1$26cg5$2@dont-email.me>
 <vs9pni$27rl4$9@dont-email.me>
 <3ade9e84224ba9b99c7363e0e9b69181804b7daa@i2pn2.org>
 <vsc2fd$1vihj$2@dont-email.me>
 <e1da7d564873d36f88e119fbbbdafd8c6b0f675e@i2pn2.org>
 <vsc9o7$2bk3d$2@dont-email.me>
 <e8a1a71c83ab391210359dec64ecf493433c813c@i2pn2.org>
 <vsceml$2fv3s$3@dont-email.me>
 <37611dde484778110d639014703daac38129f076@i2pn2.org>
 <vsctva$2ub5m$3@dont-email.me>
 <7ec2e83bc35a92bb7c5f7c9c7a9aa333da125931@i2pn2.org>
 <vsd1ec$379dn$2@dont-email.me>
 <821091edcf00ce1af435e2baf91b3ec94757aa1a@i2pn2.org>
 <vseon7$th5g$10@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 31 Mar 2025 22:52:32 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2597814"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <vseon7$th5g$10@dont-email.me>
Content-Language: en-US

On 3/31/25 2:59 PM, olcott wrote:
> On 3/31/2025 6:19 AM, Richard Damon wrote:
>> On 3/30/25 11:16 PM, olcott wrote:
>>> On 3/30/2025 9:40 PM, Richard Damon wrote:
>>>> On 3/30/25 10:17 PM, olcott wrote:
>>>>> On 3/30/2025 7:35 PM, Richard Damon wrote:
>>>>>> On 3/30/25 5:56 PM, olcott wrote:
>>>>>>> On 3/30/2025 4:05 PM, Richard Damon wrote:
>>>>>>>> On 3/30/25 4:32 PM, olcott wrote:
>>>>>>>>> On 3/30/2025 1:52 PM, Richard Damon wrote:
>>>>>>>>>> On 3/30/25 2:27 PM, olcott wrote:
>>>>>>>>>>> On 3/30/2025 3:12 AM, joes wrote:
>>>>>>>>>>>> Am Sat, 29 Mar 2025 16:46:26 -0500 schrieb olcott:
>>>>>>>>>>>>> On 3/29/2025 3:14 PM, dbush wrote:
>>>>>>>>>>>>>> On 3/29/2025 4:01 PM, olcott wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>>> We can know that when this adapted UTM simulates a finite 
>>>>>>>>>>>>>>> number of
>>>>>>>>>>>>>>> steps of its input that this finite number of steps were 
>>>>>>>>>>>>>>> simulated
>>>>>>>>>>>>>>> correctly.
>>>>>>>>>>>>>> And therefore does not do a correct UTM simulation that 
>>>>>>>>>>>>>> matches the
>>>>>>>>>>>>>> behavior of the direct execution as it is incomplete.
>>>>>>>>>>>>> It is dishonest to expect non-terminating inputs to complete.
>>>>>>>>>>>> A complete simulation of a nonterminating input doesn't halt.
>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2) changing the input is not allowed
>>>>>>>>>>>>>>> The input is unchanged. There never was any indication 
>>>>>>>>>>>>>>> that the input
>>>>>>>>>>>>>>> was in any way changed.
>>>>>>>>>>>>>> False, if the starting function calls UTM and UTM changes, 
>>>>>>>>>>>>>> you're
>>>>>>>>>>>>>> changing the input.
>>>>>>>>>>>>> When UTM1 is a UTM that has been adapted to only simulate a 
>>>>>>>>>>>>> finite
>>>>>>>>>>>>> number of steps
>>>>>>>>>>>> So not an UTM.
>>>>>>>>>>>>
>>>>>>>>>>>>> and input D calls UTM1 then the behavior of D simulated
>>>>>>>>>>>>> by UTM1 never reaches its final halt state.
>>>>>>>>>>>>> When D is simulated by ordinary UTM2 that D does not call 
>>>>>>>>>>>>> Then D reaches
>>>>>>>>>>>>> its final halt state.
>>>>>>>>>>>> Doesn't matter if it calls it, but if the UTM halts.
>>>>>>>>>>>>
>>>>>>>>>>>>>> Changing the input is not allowed.
>>>>>>>>>>>>> I never changed the input. D always calls UTM1.
>>>>>>>>>>>>> thus is the same input to UTM1 as it is to UTM2.
>>>>>>>>>>>> You changed UTM1, which is part of the input D.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> UTM1 simulates D that calls UTM1
>>>>>>>>>>> simulated D NEVER reaches final halt state
>>>>>>>>>>>
>>>>>>>>>>> UTM2 simulates D that calls UTM1
>>>>>>>>>>> simulated D ALWAYS reaches final halt state
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Only because UTM1 isn't actually a UTM, but a LIE since it 
>>>>>>>>>> only does a partial simulation, not a complete as REQURIED by 
>>>>>>>>>> the definition of a UTM.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _DDD()
>>>>>>>>> [00002172] 55         push ebp      ; housekeeping
>>>>>>>>> [00002173] 8bec       mov  ebp,esp  ; housekeeping
>>>>>>>>> [00002175] 6872210000 push 00002172 ; push DDD
>>>>>>>>> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
>>>>>>>>> [0000217f] 83c404     add  esp,+04
>>>>>>>>> [00002182] 5d         pop  ebp
>>>>>>>>> [00002183] c3         ret
>>>>>>>>> Size in bytes:(0018) [00002183]
>>>>>>>>>
>>>>>>>>> DDD EMULATED BY HHH DOES SPECIFY THAT IT
>>>>>>>>> CANNOT POSSIBLY REACH ITS OWN FINAL HALT STATE.
>>>>>>>>>
>>>>>>>>> THAT IS WHAT IT SAYS AND ANYONE THAT DISAGREES
>>>>>>>>> IS A DAMNED LIAR OR STUPID.
>>>>>>>>>
>>>>>>>>
>>>>>>>> How is that DDD correctly emulated beyond the call HHH 
>>>>>>>> instruction by a program that is a pure function, and thus only 
>>>>>>>> looks at its input?
>>>>>>>>
>>>>>>>
>>>>>>> *THE ENTIRE SCOPE IS*
>>>>>>> DDD EMULATED BY HHH DOES SPECIFY THAT IT
>>>>>>> CANNOT POSSIBLY REACH ITS OWN FINAL HALT STATE.
>>>>>>
>>>>>>  From where? Remember, the Halting problem is SPECIFICALLY 
>>>>>
>>>>> OFF F-CKING TOPIC. WE ABOUT ONE F-CKING STEP OF MY PROOF.
>>>>> WE HAVE BEEN TALKING ABOUT ONE F-CKING STEP OF MY PROOF
>>>>> FOR THREE F-CKING YEARS.
>>>>>
>>>>> DDD correctly emulated by HHH DOES NOT F-CKING HALT !!!
>>>>>
>>>>>
>>>>
>>>> Your proof is just off topic ranting.
>>>>
>>>> The problem is that DDD is NOT correctly emulated by HHH, 
>>>
>>> You are a damned liar when you try to get away
>>> with implying that HHH does not emulate itself
>>> emulating DDD in recursive emulation according
>>> to the semantics of the x86 language.
>>>
>>>
>>
>> Of course it doesn't CORRECTLY emulate itself emulating DDD (and 
>> omitting that CORRECTLY is a key point to your fraud), as it stops 
>> part way, and CORRECT emulation that determines behavior doesn't stop 
>> until the end is reached.
> 
> It is ALWAYS CORRECT for any simulating termination
> analyzer to stop simulating and reject any input
> that would otherwise prevent its own termination.
> 


And, as beem pointed out, but you are too stupid to understand, DDD 
doesn't prevent its own termination, as shown by the emulation of it by 
HHH1.

HHH just incorrectly aborts its emulation due to an error in its 
programming, since its input WILL halt, because HHH does that abort that 
it did so incorrectly,

Yes, a DIFFERENT input, the DDD based on the DIFFERENT HHH' that doesn't 
abort, will be non-halting, and that HHH' would have been correct to 
abort its emulation, but it unfortunately was programmed to not abort.

Sorry, you don't seem to understand that programs do not have "free 
will" but are constrained by their code, and they will do exactly what 
their code says to do, even if that leads them to the wrong answer.

There is no "Do the right thing" instruction, it is the problem for the 
programmer to make the code do the right thing, if that is possible.

This concept seems to just be beyond your understanding.