| Deutsch English Français Italiano |
|
<vvg80o$15i5e$7@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: dbush <dbush.mobile@gmail.com> Newsgroups: comp.theory Subject: Re: Halting Problem: What Constitutes Pathological Input Date: Wed, 7 May 2025 14:15:52 -0400 Organization: A noiseless patient Spider Lines: 139 Message-ID: <vvg80o$15i5e$7@dont-email.me> References: <GE4SP.47558$VBab.42930@fx08.ams4> <vvat0g$vtiu$1@dont-email.me> <vvatf3$o4v0$3@dont-email.me> <vvaut0$vtiu$4@dont-email.me> <vvav6o$o4v0$4@dont-email.me> <vvb329$15u5b$1@dont-email.me> <vvb37g$1451r$1@dont-email.me> <vvb43f$15u5b$4@dont-email.me> <vvb4ok$o4v0$9@dont-email.me> <vvb52g$15u5b$6@dont-email.me> <vvb5ca$o4v0$10@dont-email.me> <vvb5vp$15u5b$7@dont-email.me> <vvb675$o4v0$11@dont-email.me> <vvb9d7$1av94$3@dont-email.me> <vvbani$1b6l1$1@dont-email.me> <vvbb6s$1av94$4@dont-email.me> <vvbcb3$1b6l1$2@dont-email.me> <vvbe0j$1av94$8@dont-email.me> <vvbecc$1b6l1$6@dont-email.me> <vvbhk0$1ijna$1@dont-email.me> <vvc7t9$29pp8$1@dont-email.me> <vvc86c$2a4cs$1@dont-email.me> <vvcufi$2sk4a$3@dont-email.me> <vvdlff$3i09b$2@dont-email.me> <vvdo96$3lapa$1@dont-email.me> <vvdr87$3n3t4$1@dont-email.me> <vve3mf$3vva3$1@dont-email.me> <vve4ut$f5c$1@dont-email.me> <vvehuu$g8eg$1@dont-email.me> <vvej0u$g8jo$1@dont-email.me> <vvfv4c$13nqj$1@dont-email.me> <vvg1id$14bdu$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Wed, 07 May 2025 20:15:52 +0200 (CEST) Injection-Info: dont-email.me; posting-host="3013d96e0ac4b7dd359f7afe652f4ce0"; logging-data="1231022"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/J9rTZokw4TahB2LpI8LkB" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:db5rxTXWSXQuyQ7w59zT24bM8vU= Content-Language: en-US In-Reply-To: <vvg1id$14bdu$1@dont-email.me> Bytes: 7346 On 5/7/2025 12:25 PM, olcott wrote: > On 5/7/2025 10:44 AM, Mike Terry wrote: >> On 07/05/2025 04:11, olcott wrote: >>> On 5/6/2025 9:53 PM, Mike Terry wrote: >>>> On 07/05/2025 00:11, olcott wrote: >>>>> On 5/6/2025 5:49 PM, Mike Terry wrote: >>>>>> On 06/05/2025 21:25, olcott wrote: >>>>>>> On 5/6/2025 2:35 PM, dbush wrote: >>>>>>>> On 5/6/2025 2:47 PM, olcott wrote: >>>>>>>>> On 5/6/2025 7:14 AM, dbush wrote: >>>>>>>>>> On 5/6/2025 1:54 AM, olcott wrote: >>>>>>>>>>> On 5/6/2025 12:49 AM, Richard Heathfield wrote: >>>>>>>>>>>> On 06/05/2025 00:29, olcott wrote: >>>>>>>>>>>> >>>>>>>>>>>> <snip> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> It is the problem incorrect specification that creates >>>>>>>>>>>>> the contradiction. >>>>>>>>>>>> >>>>>>>>>>>> Not at all. The contradiction arises from the fact that it >>>>>>>>>>>> is not possible to construct a universal decider. >>>>>>>>>>>> >>>>>>>>>>>>> Everyone here insists that functions computed >>>>>>>>>>>>> by models of computation can ignore inputs and >>>>>>>>>>>>> base their output on something else. >>>>>>>>>>>> >>>>>>>>>>>> I don't think anyone's saying that. >>>>>>>>>>>> >>>>>>>>>>>> Maybe you don't read so well. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> What are the exact steps for DD to be emulated by HHH >>>>>>>>>>> according to the semantics of the x86 language? >>>>>>>>>>> *Only an execution trace will do* >>>>>>>>>> >>>>>>>>>> The exact same steps for DD to be emulated by UTM. >>>>>>>>>> >>>>>>>>> >>>>>>>>> _DD() >>>>>>>>> [00002133] 55 push ebp ; housekeeping >>>>>>>>> [00002134] 8bec mov ebp,esp ; housekeeping >>>>>>>>> [00002136] 51 push ecx ; make space for local >>>>>>>>> [00002137] 6833210000 push 00002133 ; push DD >>>>>>>>> [0000213c] e882f4ffff call 000015c3 ; call HHH(DD) >>>>>>>>> [00002141] 83c404 add esp,+04 >>>>>>>>> [00002144] 8945fc mov [ebp-04],eax >>>>>>>>> [00002147] 837dfc00 cmp dword [ebp-04],+00 >>>>>>>>> [0000214b] 7402 jz 0000214f >>>>>>>>> [0000214d] ebfe jmp 0000214d >>>>>>>>> [0000214f] 8b45fc mov eax,[ebp-04] >>>>>>>>> [00002152] 8be5 mov esp,ebp >>>>>>>>> [00002154] 5d pop ebp >>>>>>>>> [00002155] c3 ret >>>>>>>>> Size in bytes:(0035) [00002155] >>>>>>>>> >>>>>>>>> Machine address by machine address specifics >>>>>>>>> that you know that you cannot provide because >>>>>>>>> you know that you are wrong. >>>>>>>>> >>>>>>>> >>>>>>>> HHH and UTM emulate DD exactly the same up until the point that >>>>>>>> HHH aborts, >>>>>>> >>>>>>> When you trace through the actual steps you >>>>>>> will see that this is counter-factual. >>>>>> >>>>>> No, it is exactly right. Remember, I posted a comparison of the >>>>>> two traces side by side some time ago, and they were indeed >>>>>> IDENTICAL line for line up to the point where HHH decided to >>>>>> discontinue simulating. >>>>> >>>>> That is counter-factual. >>>> >>>> Dude! :/ I posted the comparison and the traces were the same up >>>> to the point where HHH discontinued the simulation. How can it be >>>> "counter-factual"? >>>> >>> >>> HHH1(DD) the call from DD to HHH(DD) returns. >>> HHH(DD) the call from DD to HHH(DD) cannot possibly return. >>> >>> A call that returns and a call that cannot possibly >>> return *are not exactly the same thing* >> >> You need to read what posters actually say. I said the traces were >> the same up to the point where HHH stops simulating. > > THAT IS COUNTER-FACTUAL. A lie, as you have admitted on the record that they are the same: On 5/6/2025 5:17 PM, dbush wrote: > On 5/6/2025 5:03 PM, olcott wrote: >> On 5/6/2025 3:51 PM, dbush wrote: >>> On 5/6/2025 4:46 PM, olcott wrote: >>>> On 5/6/2025 3:31 PM, dbush wrote: >>>>> Then what is the first instruction emulated by HHH that differs >>>>> from the emulation performed by UTM? >>>>> >>>> >>>> HHH1 is exactly the same as HHH except that DD >>>> does not call HHH1. This IS the UTM emulator. >>>> It does not abort. >>> >>> Last chance: >>> >>> What is the first instruction emulated by HHH that differs from the >>> emulation performed by HHH1? >> >> Go back and read the part you ignored moron. > > Let the record show that Peter Olcott has neglected to identify an > instruction that HHH emulates differently from HHH1. > >>> Failure to provide this in your next message or within one hour of >>> your next post in this newsgroup will be taken as your official on- >>> the-record admission that the emulations performed by HHH and HHH1 >>> are in fact exactly the same up until the point that HHH aborts, at >>> which point HHH did not correctly simulate the last instruction it >>> simulated as you are previously on record as admitting. > > Therefore, as per the above requirements: > > LET THE RECORD SHOW > > That Peter Olcott > > Has *officially* admitted > > That the emulations performed by HHH and HHH1 are in fact exactly the > same up until the point that HHH aborts, at which point HHH did not > correctly simulate the last instruction it simulated as he is previously > on record as admitting.