Deutsch   English   Français   Italiano  
<31884066c1cc49b47c3d4ea6009d04f2edca2795@i2pn2.org>

View for Bookmarking (what is this?)
Look up another Usenet article

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: Proof that DDD specifies non-halting behavior --- point by point
Date: Thu, 15 Aug 2024 21:57:42 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <31884066c1cc49b47c3d4ea6009d04f2edca2795@i2pn2.org>
References: <v9gv4k$4sc4$1@dont-email.me>
 <561f876601b0329c0260bac26f8b6dfb6e28647f@i2pn2.org>
 <v9h5af$9jn6$1@dont-email.me>
 <aa4bc24ac5642087e81796fffc31e5022bd8823e@i2pn2.org>
 <v9h9ec$a0id$1@dont-email.me>
 <190847da05ab48555c036a799e768f555461eb43@i2pn2.org>
 <v9kdmq$t1s7$1@dont-email.me> <v9l533$10ack$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 16 Aug 2024 01:57:42 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2724235"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <v9l533$10ack$1@dont-email.me>
Bytes: 5696
Lines: 117

On 8/15/24 10:58 AM, olcott wrote:
> On 8/15/2024 3:19 AM, Mikko wrote:
>> On 2024-08-14 04:04:23 +0000, Richard Damon said:
>>
>>> On 8/13/24 11:48 PM, olcott wrote:
>>>> On 8/13/2024 10:21 PM, Richard Damon wrote:
>>>>> On 8/13/24 10:38 PM, olcott wrote:
>>>>>> On 8/13/2024 9:29 PM, Richard Damon wrote:
>>>>>>> On 8/13/24 8:52 PM, olcott wrote:
>>>>>>>> void DDD()
>>>>>>>> {
>>>>>>>>    HHH(DDD);
>>>>>>>>    return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> _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]
>>>>>>>>
>>>>>>>> A simulation of N instructions of DDD by HHH according to
>>>>>>>> the semantics of the x86 language is necessarily correct.
>>>>>>>>
>>>>>>>
>>>>>>> Nope, it is just the correct PARTIAL emulation of the first N 
>>>>>>> instructions of DDD, and not of all of DDD,
>>>>>>
>>>>>> That is what I said dufuss.
>>>>>
>>>>> Nope. You didn't. I added clairifying words, pointing out why you 
>>>>> claim is incorrect.
>>>>>
>>>>> For an emulation to be "correct" it must be complete, as partial 
>>>>> emulations are only partially correct, so without the partial 
>>>>> modifier, they are not correct.
>>>>>
>>>>
>>>> A complete emulation of one instruction is
>>>> a complete emulation of one instruction
>>>
>>>
>>>
>>>>
>>>>>>
>>>>>>>
>>>>>>>> A correct simulation of N instructions of DDD by HHH is
>>>>>>>> sufficient to correctly predict the behavior of an unlimited
>>>>>>>> simulation.
>>>>>>>
>>>>>>> Nope, if a HHH returns to its caller,
>>>>>>
>>>>>> *Try to show exactly how DDD emulated by HHH returns to its caller*
>>>>>> (the first one doesn't even have a caller)
>>>>>> Use the above machine language instructions to show this.
>>>>>>
>>>>>
>>>>> Remember how English works:
>>>>>
>>>>> When you ask "How DDD emulated by HHH returns to its callers".
>>>>
>>>> Show the exact machine code trace of how DDD emulated
>>>> by HHH (according to the semantics of the x86 language)
>>>> reaches its own machine address 00002183
>>>
>>> No. The trace is to long, and since you HHH doesn't meet your 
>>> requirements (since it isn't a pure function) you can't give me a 
>>> compldte input to trace.
>>
>> The trace is regular enough that we could define a formal language for
>> the trace and construct an analyzer program to detect deviations from
>> x86 semnatics and hidden inputs.
>>
> 
> There are no deviations. The x86utm operating system is
> built from libx86emu that has had decades of development
> effort. HHH really does emulate itself emulating DDD.
> 

And then ignores that emulation, so it really didn't effectively emulate it.

> *This source-code proves it*
> https://github.com/plolcott/x86utm/blob/master/Halt7.c
> Mike seems to have the best understanding of that source-code.

Amd it proves that HHH is *NOT* a "pure function" and thus doesn't even 
qualify to be a "decider".

Sorry, but the simple inspection of the code proves that you have been 
lying about this the full time, and thus none of your proof that looks 
at that is valid.

> 
> He might not yet understand that HHH does emulate itself
> emulating DDD. He could find out how HHH does this.
> 
> HHH calls the x86utm operating system to create a new
> process context to emulate DDD. HHH emulates itself in
> the same process context. Its emulated self calls x86utm
> to create another process context to emulate its own
> DDD instance.
> 

And ignores the fact that the DDD that it is emulting (which includes 
the code of the HHH that it calls) only CONDITIONALLY emulates the next 
layer, and that it WILL abort its emulation (since it does the same as 
this HHH since it is the same code, or at least it would when you fix 
the impurity of the code) and thus HHH can not consider DDD to be 
non-halting.

Of course, the fact that as has been pointed out, your HHH that you have 
worked on for all these years STILL fails to meet the basic requirements 
of being a pure function and thus isn't eligable to be a Decider in the 
first place.