Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: DDD INcorrectly emulated by HHH is INcorrectly rejected as
 non-halting V2
Date: Tue, 16 Jul 2024 21:10:19 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <1f67aceb599ae163623b1cd39dfd84fde69f0a95@i2pn2.org>
References: <v6rg65$32o1o$3@dont-email.me> <v7085g$3j1h$1@dont-email.me>
 <v70ok7$61d8$10@dont-email.me> <v72lvl$k9t3$1@dont-email.me>
 <v73926$mjis$17@dont-email.me> <v75950$166e9$1@dont-email.me>
 <v76dgv$1cf96$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 17 Jul 2024 01:10:19 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="3536827"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US
In-Reply-To: <v76dgv$1cf96$2@dont-email.me>
Bytes: 5158
Lines: 107

On 7/16/24 2:18 PM, olcott wrote:
> On 7/16/2024 2:57 AM, Mikko wrote:
>> On 2024-07-15 13:43:34 +0000, olcott said:
>>
>>> On 7/15/2024 3:17 AM, Mikko wrote:
>>>> On 2024-07-14 14:50:47 +0000, olcott said:
>>>>
>>>>> On 7/14/2024 5:09 AM, Mikko wrote:
>>>>>> On 2024-07-12 14:56:05 +0000, olcott said:
>>>>>>
>>>>>>> We stipulate that the only measure of a correct emulation is the
>>>>>>> semantics of the x86 programming language.
>>>>>>>
>>>>>>> _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.
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> The above specifies the infinite set of every HHH/DDD pair
>>>>>>> where 1 to infinity steps of DDD are correctly emulated by HHH.
>>>>>>
>>>>>> You should use the indices here, too, e.g., "where 1 to infinity 
>>>>>> steps of
>>>>>> DDD₁ are correctly emulated by HHH₃" or whatever you mean.
>>>>>>
>>>>>
>>>>> DDD is the exact same fixed constant finite string that
>>>>> always calls HHH at the same fixed constant machine
>>>>> address.
>>>>
>>>> If the function called by DDD is not part of the input then the 
>>>> input does
>>>> not specify a behaviour and the question whether DDD halts is 
>>>> ill-posed.
>>>>
>>>
>>> We don't care about whether HHH halts. We know that
>>> HHH halts or fails to meet its design spec.
>>>
>>> We are only seeing if DDD correctly emulated by HHH
>>> can can possibly reach its own final state.
>>
>> HHH does not see even that. It only sees whther that it does not emulate
>> DDD to its final state. 
> 
> No. HHH is not judging whether or not itself is a correct
> emulator. The semantics of the x86 instructions that emulates
> prove that its emulation is correct.

No they don't as HHH seemse to think that a call to HHH causes the x86 
processor to create a new processor context and then jump to DDD instead 
of going into HHH.

> 
> Only because DDD calls HHH(DDD) in recursive emulation it is
> impossible for DDD correctly emulated by HHH to reach past
> its own machine address of 0000216b.

But it is onlh FINITE recursive emulation since HHH DOES abort its 
emulaiton and return.

That makes the emulation by HHH not reach the point, but the actual DDD 
does.

> 
>> But we can see more, in particuar that DDD() halts
>> if HHH(DDD) does.
>>
> 
> In the exact same way that we can see that we are no longer
> hungry after we have eaten. It is still a fact that HHH(DDD)
> was required to abort its emulation in the exact same way
> that it was required for us to eat to no longer be hungry.

Just a Red Herring. Program attributes that deciders look at are not 
time varying, like your "hunger" attribute.

> 
>> Anyway, if the function DDD calls is not a part of the input then the
>> question whether DDD halts is not well-posed and can only be ansered
>> with a conditional.
>>
> 
> We are analyzing whether or not DDD halts.
> We are NOT analyzing whether or not HHH halts.
> 

But DDD Halts IF and ONLY IF HHH halts, so they ARE effectively the same 
question.

If by the definition HHH is using, HHH does not halt, then HHH can't 
call itself a decider.