Deutsch   English   Français   Italiano  
<1026d8r$g0hl$3@dont-email.me>

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

Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: "Fred. Zwarts" <F.Zwarts@HetNet.nl>
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic
Subject: Re: DDD emulated by HHH diverges from DDD emulated by HHH1--- BEST
 ONE
Date: Mon, 9 Jun 2025 12:33:00 +0200
Organization: A noiseless patient Spider
Lines: 116
Message-ID: <1026d8r$g0hl$3@dont-email.me>
References: <101khcl$3bfvj$6@dont-email.me> <101qbtj$11qlg$1@dont-email.me>
 <101qc32$11sr2$3@dont-email.me> <101qhst$13bo7$1@dont-email.me>
 <101qicm$11sr2$4@dont-email.me> <101qjki$13i0e$1@dont-email.me>
 <101qn7s$14gq1$1@dont-email.me> <101qnp3$14gff$1@dont-email.me>
 <101qo1g$14gq1$2@dont-email.me> <101qoia$14gff$2@dont-email.me>
 <101qp3h$14gq1$3@dont-email.me> <101qqn5$14gff$4@dont-email.me>
 <101qrrc$14gq1$4@dont-email.me> <101qsfp$15bg8$1@dont-email.me>
 <101r4f3$1asab$1@dont-email.me> <101r6be$1adut$4@dont-email.me>
 <101v3lk$2c3ca$1@dont-email.me> <101v6df$2c1iv$4@dont-email.me>
 <b71e0886124c2f8ab25cf316517d32881cf353bc@i2pn2.org>
 <1020cg6$2ovvr$1@dont-email.me>
 <85bbc19fae66d1403bda5b9aff2778cd66d6f633@i2pn2.org>
 <1021hf0$3327l$5@dont-email.me>
 <8df4928973c30948ab744efcaaf4bf03223c4292@i2pn2.org>
 <1022jgj$3e610$1@dont-email.me>
 <92ed3ec7626ca56b37e6f4c58c894d393857a412@i2pn2.org>
 <1024egj$3uhti$1@dont-email.me> <1024gik$3v273$1@dont-email.me>
 <1024pbr$19lm$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 09 Jun 2025 12:32:59 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="2bf405748b57a10546635a47814e69b0";
	logging-data="524853"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/dCHoDxckZGUgXip07iXb9"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:lOqYg10lK4OHzeNTdcOyKoDq+ho=
Content-Language: nl, en-GB
In-Reply-To: <1024pbr$19lm$1@dont-email.me>

Op 08.jun.2025 om 21:47 schreef olcott:
> On 6/8/2025 12:17 PM, Fred. Zwarts wrote:
>> Op 08.jun.2025 om 18:41 schreef olcott:
>>> On 6/8/2025 6:11 AM, Richard Damon wrote:
>>>> On 6/7/25 7:54 PM, olcott wrote:
>>>>> On 6/7/2025 6:38 PM, Richard Damon wrote:
>>>>>> On 6/7/25 10:13 AM, olcott wrote:
>>>>>>> On 6/7/2025 6:18 AM, Richard Damon wrote:
>>>>>>>> On 6/6/25 11:43 PM, olcott wrote:
>>>>>>>>> On 6/6/2025 9:02 PM, Richard Damon wrote:
>>>>>>>>>> On 6/6/25 12:53 PM, olcott wrote:
>>>>>>>>>>> On 6/6/2025 11:06 AM, Mike Terry wrote:
>>>>>>>>>>>> On 05/06/2025 05:27, olcott wrote:
>>>>>>>>>>>>> On 6/4/2025 10:55 PM, Mike Terry wrote:
>>>>>>>>>>>>>> On 05/06/2025 02:39, olcott wrote:
>>>>>>>>>>>>>>> On 6/4/2025 8:28 PM, dbush wrote:
>>>>>>>>>>>>>>>> On 6/4/2025 9:08 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 6/4/2025 7:41 PM, dbush wrote:
>>>>>>>>>>>>>>>>>> On 6/4/2025 8:32 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Show me this side-by-side trace and I will point out 
>>>>>>>>>>>>>>>>>>> your mistake.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> See below, which shows that the simulations performed 
>>>>>>>>>>>>>>>>>> by HHH and HHH1 are identical up to the point that HHH 
>>>>>>>>>>>>>>>>>> aborts, as you have agreed on the record.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> False.  The correct trace is the one I posted, which 
>>>>>>>>>>>>>>>> shows all levels of emulation performed by HHH and HHH1. 
>>>>>>>>>>>>>>>> See the corrections I made to your comments
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is not supposed to do that.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Are you saying it's not supposed to include /nested/ 
>>>>>>>>>>>>>> emulations? It is perfectly sensible to include nested 
>>>>>>>>>>>>>> emulations.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> It can include nested simulations yet nested
>>>>>>>>>>>>> simulations are in a hierarchy thus not side-by-side.
>>>>>>>>>>>>> A side-by-side analysis must be side-by-side.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Hierarchies can be compared side-by-side.  In the case of 
>>>>>>>>>>>> these traces, the hierarchy can be "flattened" into one 
>>>>>>>>>>>> stream of nested simulations. You do this yourself every 
>>>>>>>>>>>> time you present one of your nested simulation traces.  Such 
>>>>>>>>>>>> a trace should include a simulation depth (or equivalent) 
>>>>>>>>>>>> for each entry.
>>>>>>>>>>>>
>>>>>>>>>>>> Two nested simulation traces can easily be presented side- 
>>>>>>>>>>>> by- side for comparisson.  You are just trying to divert 
>>>>>>>>>>>> attention from your own failings to properly understand the 
>>>>>>>>>>>> requirements.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> *From the execution trace of HHH1(DDD) shown below*
>>>>>>>>>>> DDD emulated by HHH1              DDD emulated by HHH
>>>>>>>>>>> [00002183] push ebp               [00002183] push ebp
>>>>>>>>>>> [00002184] mov ebp,esp            [00002184] mov ebp,esp
>>>>>>>>>>> [00002186] push 00002183 ; DDD    [00002186] push 00002183 ; DDD
>>>>>>>>>>> [0000218b] call 000015c3 ; HHH    [0000218b] call 000015c3 ; HHH
>>>>>>>>>>> *HHH1 emulates DDD once then HHH emulates DDD once, these match*
>>>>>>>>>>>
>>>>>>>>>>> *Then HHH emulates itself emulating DDD, HHH1 NEVER DOES THIS*
>>>>>>>>>>
>>>>>>>>>> Because the correct emulation of the input doesn't call for 
>>>>>>>>>> this to be done, and the identity of the emulator doesn't 
>>>>>>>>>> affect the defintion of a correct emulation.
>>>>>>>>>>
>>>>>>>>>> That fact that NONE of your traces actually show a correct 
>>>>>>>>>> emulation, 
>>>>>>>>>
>>>>>>>>> I have corrected you on this hundreds of times and
>>>>>>>>> you keep "forgetting" what I said.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> That you have an "excuse" doesn't change the fact that the 
>>>>>>>> traces shown are not correct.
>>>>>>>>
>>>>>>>
>>>>>>> *No actual error has ever been pointed out*
>>>>>>> One of the incoherent notions of error that you
>>>>>>> have proposed is that a non-terminating input
>>>>>>> was not simulated to completion.
>>>>>>
>>>>>> No, it just that you don't seem to understand the concept that a 
>>>>>> partial simulation not reaching a final state doesn't establish 
>>>>>> non- halting.
>>>>>>
>>>>>
>>>>> *CAN'T POSSIBLY REACH A FINAL STATE DOES ESTABLISH NOT HALTING*
>>>>>
>>>>
>>>> Right, but the subject of said proposition is the MACHINE, not a 
>>>> partial simulation of said machine.
>>>>
>>>> For simulations to be used to show non-halting, you must show that 
>>>> even after an unbounded number of steps simulated, it never reaches 
>>>> a final state.
>>>>
>>>
>>> We have been over this too many times, either you are
>>> a liar or you have severe brain damage. DDD simulated
>>> by HHH matches a non-halting behavior pattern after
>>> two complete simulations of its first four steps.
> 
>> No, it does not. It decides too early. It needs three cycles to see 
>> the halting behaviour.
> 
> All you have is a lack of sufficient technical competence.
> 
Ad hominem attack, proving that there are no counter argument.