Deutsch English Français Italiano |
<bc2bf85ea04563a24d60bd9e8767bab26fafb3d3@i2pn2.org> View for Bookmarking (what is this?) Look up another Usenet article |
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,comp.ai.philosophy,sci.logic Subject: Re: DDD emulated by HHH diverges from DDD emulated by HHH1--- BEST ONE Date: Sun, 8 Jun 2025 22:38:07 -0400 Organization: i2pn2 (i2pn.org) Message-ID: <bc2bf85ea04563a24d60bd9e8767bab26fafb3d3@i2pn2.org> 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, 9 Jun 2025 02:42:55 -0000 (UTC) Injection-Info: i2pn2.org; logging-data="3901545"; 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: <1024pbr$19lm$1@dont-email.me> Content-Language: en-US On 6/8/25 3:47 PM, olcott wrote: > 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. No, you do, as you have been undable to actually justify your disproven claims. Sorry, you are just proving how ignorant you are in the field, as you don't even understand the need to try to prove your lies. > >> It needs to simulate more that the first four steps. It also needs to >> count the conditional branch instructions in HHH. > >