Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Mikko <mikko.levanto@iki.fi>
Newsgroups: comp.theory
Subject: Re: DDD correctly emulated by HHH is Correctly rejected as non-halting V2
Date: Mon, 15 Jul 2024 11:15:08 +0300
Organization: -
Lines: 124
Message-ID: <v72lqc$k98l$1@dont-email.me>
References: <v6rg65$32o1o$3@dont-email.me> <97e0632d0d889d141bdc6005ce6e513c53867798@i2pn2.org> <v6sdlu$382g0$1@dont-email.me> <v6td3a$3ge79$1@dont-email.me> <v6tp1j$3imib$2@dont-email.me> <v6trdu$3irhh$1@dont-email.me> <v6tu01$3imib$11@dont-email.me> <v703vh$2sa4$1@dont-email.me> <v70ohq$61d8$9@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 15 Jul 2024 10:15:08 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="eb7bc3c094cc39ab136406329ffd9913";
	logging-data="664853"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+zxbj9nQ8dTcAcI8i273SX"
User-Agent: Unison/2.2
Cancel-Lock: sha1:kEbjGp8U7SKDWJWYwTgdHmNYz9E=
Bytes: 6767

On 2024-07-14 14:49:30 +0000, olcott said:

> On 7/14/2024 3:58 AM, Mikko wrote:
>> On 2024-07-13 13:04:01 +0000, olcott said:
>> 
>>> On 7/13/2024 7:20 AM, Fred. Zwarts wrote:
>>>> Op 13.jul.2024 om 13:39 schreef olcott:
>>>>> On 7/13/2024 3:15 AM, Fred. Zwarts wrote:
>>>>>> Op 13.jul.2024 om 01:19 schreef olcott:
>>>>>>> On 7/12/2024 5:56 PM, Richard Damon wrote:
>>>>>>>> On 7/12/24 10:56 AM, olcott wrote:
>>>>>>>>> We stipulate that the only measure of a correct emulation is the
>>>>>>>>> semantics of the x86 programming language.
>>>>>>>> 
>>>>>>>> Which means the only "correct emulation" that tells the behavior of the 
>>>>>>>> program at the input is a non-aborted one.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> _DDD()
>>>>>>>>> [00002163] 55         push ebp      ; housekeeping
>>>>>>>>> [00002164] 8bec       mov ebp,esp   ; housekeeping
>>>>>>>>> [00002166] 6863210000 push 00002163 ; push DDD
>>>>>>>>> [0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
>>>>>>>>> [00002170] 83c404     add esp,+04
>>>>>>>>> [00002173] 5d         pop ebp
>>>>>>>>> [00002174] c3         ret
>>>>>>>>> Size in bytes:(0018) [00002174]
>>>>>>>>> 
>>>>>>>>> When N steps of DDD are emulated by HHH according to the
>>>>>>>>> semantics of the x86 language then N steps are emulated correctly.
>>>>>>>> 
>>>>>>>> And thus HHH that do that know only the first N steps of the behavior 
>>>>>>>> of DDD, which continues per the definition of the x86 instruction set 
>>>>>>>> until the COMPLETE emulation (or direct execution) reaches a terminal 
>>>>>>>> instruction.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> When we examine the infinite set of every HHH/DDD pair such that:
>>>>>>>>> HHH₁ one step of DDD is correctly emulated by HHH.
>>>>>>>>> HHH₂ two steps of DDD are correctly emulated by HHH.
>>>>>>>>> HHH₃ three steps of DDD are correctly emulated by HHH.
>>>>>>>>> ...
>>>>>>>>> HHH∞ The emulation of DDD by HHH never stops running.
>>>>>>>> 
>>>>>>>> And thus, the subset that only did a finite number of steps and aborted 
>>>>>>>> its emulation on a non-terminal instrucition only have partial 
>>>>>>>> knowledge of the behavior of their DDD, and by returning to their 
>>>>>>>> caller, they establish that behavior for ALL copies of that HHH, even 
>>>>>>>> the one that DDD calls, which shows that DDD will be halting, even 
>>>>>>>> though HHH stopped its observation of the input before it gets to that 
>>>>>>>> point.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> The above specifies the infinite set of every HHH/DDD pair
>>>>>>>>> where 1 to infinity steps of DDD are correctly emulated by HHH.
>>>>>>>>> 
>>>>>>>>> No DDD instance of each HHH/DDD pair ever reaches past its
>>>>>>>>> own machine address of 0000216b and halts.
>>>>>>>> 
>>>>>>>> Wrong. EVERY DDD of an HHH that simulated its input for only a finite 
>>>>>>>> number of steps WILL halt becuase it will reach its final return.
>>>>>>>> 
>>>>>>>> The HHH that simulated it for only a finite number of steps, only 
>>>>>>>> learned that finite number of steps of the behaivor, and in EVERY case, 
>>>>>>>> when we look at the behavior past that point, which DOES occur per the 
>>>>>>>> definition of the x86 instruction set, as we have not reached a 
>>>>>>>> "termial" instruction that stops behavior, will see the HHH(DDD) that 
>>>>>>>> DDD called continuing to simulate its input to the point that this one 
>>>>>>>> was defined to stop, and then returns 0 to DDDD and then DDD returning 
>>>>>>>> and ending the behavior.
>>>>>>>> 
>>>>>>>> You continue to stupidly confuse the PARTIAL observation that HHH does 
>>>>>>>> of the behavior of DDD by its PARTIAL emulation with the ACTUAL FULL 
>>>>>>>> behavior of DDD as defined by the full definition of the x86 
>>>>>>>> insttuction set.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Thus each HHH element of the above infinite set of HHH/DDD
>>>>>>>>> pairs is necessarily correct to reject its DDD as non-halting.
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> Nope.
>>>>>>>> 
>>>>>>>> NONE Of them CORRECTLY rejected itS DDD as non-halting and you are 
>>>>>>>> shown to be ignorant of what you are talking about.
>>>>>>>> 
>>>>>>>> The HHH that did a partial emulation got the wrong answer, because 
>>>>>>>> THEIR DDD will halt. and the HHH that doen't abort never get around to 
>>>>>>>> rejecting its DDD as non-halting.
>>>>>>> 
>>>>>>> *Here is the gist of my proof it is irrefutable*
>>>>>>> When no DDD of every HHH/DDD that can possibly exist
>>>>>>> halts then each HHH that rejects its DDD as non-halting
>>>>>>> is necessarily correct.
>>>>>>> 
>>>>>>> *No double-talk and weasel words can overcome that*
>>>>>>> 
>>>>>> 
>>>>>> This is double talk, because no HHH can possibly exist that simulates 
>>>>>> itself correctly.
>>>>> 
>>>>> Your definition of correct contradicts the semantics of
>>>>> the x86 language making it wrong.
>>>>> 
>>>> 
>>>> You have a wrong understanding of the semantics of the x86 language. 
>>>> You think that the x86 language specifies that skipping instructions do 
>>>> not change the behaviour of a program.
>>> 
>>> You have the wrong understanding of a decider.
>> 
>> You seem to have a wrong understanding of a decider.
>> Calling a program a decider does not make it halt.
>> 
> 
> Calling a program a decider places a requirement
> on its behavior: that it must halt.

Placing a requirement that the program must halt does not make it halt.

-- 
Mikko