| Deutsch English Français Italiano |
|
<vvh73f$1bt2l$3@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 23:06:23 -0400 Organization: A noiseless patient Spider Lines: 162 Message-ID: <vvh73f$1bt2l$3@dont-email.me> References: <GE4SP.47558$VBab.42930@fx08.ams4> <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> <vvdmqe$3huo6$4@dont-email.me> <vvdneq$3k2gc$3@dont-email.me> <42d875b9727dae90799e064ac33b9e1be866f2b5@i2pn2.org> <vvegg3$89u0$7@dont-email.me> <2f87c70ff64c8b83fa2456545e3250930158a3b5@i2pn2.org> <vvfu5d$130t3$4@dont-email.me> <6528755608b2bbe4206f2b8e11c78417ba77dde5@i2pn2.org> <vvh6c5$1gq2p$2@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Thu, 08 May 2025 05:06:23 +0200 (CEST) Injection-Info: dont-email.me; posting-host="a565b5a0e22116f8f680253905402a9a"; logging-data="1438805"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+87cVg3qHu3QN1/YIv5uyF" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:tt5DZUzEJNbi++eghvF6YdUIdWk= Content-Language: en-US In-Reply-To: <vvh6c5$1gq2p$2@dont-email.me> Bytes: 7901 On 5/7/2025 10:53 PM, olcott wrote: > On 5/7/2025 9:28 PM, Richard Damon wrote: >> On 5/7/25 11:27 AM, olcott wrote: >>> On 5/7/2025 6:01 AM, Richard Damon wrote: >>>> On 5/6/25 10:28 PM, olcott wrote: >>>>> On 5/6/2025 5:59 PM, Richard Damon wrote: >>>>>> On 5/6/25 3:20 PM, olcott wrote: >>>>>>> On 5/6/2025 2:10 PM, Fred. Zwarts wrote: >>>>>>>> Op 06.mei.2025 om 20:47 schreef olcott: >>>>>>>>> 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. >>>>>>>>> >>>>>>>> >>>>>>>> That you do not understand it, does not mean that it has not >>>>>>>> been provided to you. It has, many times. If you do not know >>>>>>>> that you are wrong, you must be very stupid. >>>>>>> >>>>>>> Everything besides a machine address by machine >>>>>>> address of DD emulated by HHH (according to the >>>>>>> rules of the x86 language) where the emulated >>>>>>> DD reaches its own "ret" instruction >>>>>> >>>>>> In other words, if people don't agree with your fantasy that is >>>>>> just in error, then "they" must be wrong. >>>>>> >>>>>> No, it >>>>>> >>>>>>> >>>>>>> *IS A DISHONEST DODGE AWAY FROM THE ACTUAL QUESTION* >>>>>> >>>>>> No, YOU are a dishoneast dodge from the actual question >>>>>> >>>>>>> >>>>>>> Most of my reviewers switch to rhetoric when they >>>>>>> know that they are wrong and still want to disagree. >>>>>>> Disagreement (not truth) is their highest priority. >>>>>>> >>>>>> >>>>>> Nope, that is just you projecting again. >>>>> >>>>> You keep saying the DD emulated by HHH according >>>>> to the rules of the x86 language is wrong. >>>> >>>> Right, because it stops wnen it should not. >>>> >>>>> >>>>> You keep arguing that HHH is required to break these >>>>> rules to conform with the common misconception that HHH >>>>> is required to report on the direct execution of DD(). >>>> >>>> No, it needs to keep to them, which it doesn\'t. >>>> >>>> Where did I say it must break the rules? >>>> >>> >>> DD correctly simulated by HHH according to the rules >>> of the x86 language cannot possibly halt. >> >> Which is a non-sense statement, as HHH doesn't correctly simulate its >> input DD by those rules, as you have demonstarted, >> > > Liar > That would be you: On 5/5/2025 8:24 AM, dbush wrote: > On 5/4/2025 11:03 PM, dbush wrote: >> On 5/4/2025 10:05 PM, olcott wrote: >>> On 5/4/2025 7:23 PM, Richard Damon wrote: >>>> But HHH doesn't correct emulated DD by those rules, as those rules >>>> do not allow HHH to stop its emulation, >>> >>> Sure they do you freaking moron... >> >> Then show where in the Intel instruction manual that the execution of >> any instruction other than a HLT is allowed to stop instead of >> executing the next instruction. >> >> Failure to do so in your next reply, or within one hour of your next >> post on this newsgroup, will be taken as you official on-the-record >> admission that there is no such allowance and that HHH does NOT >> correctly simulate DD. > > Let the record show that Peter Olcott made the following post in this > newsgroup after the above message: > > On 5/4/2025 11:04 PM, olcott wrote: > > D *WOULD NEVER STOP RUNNING UNLESS* > > indicates that professor Sipser was agreeing > > to hypotheticals AS *NOT CHANGING THE INPUT* > > > > You are taking > > *WOULD NEVER STOP RUNNING UNLESS* > > to mean *NEVER STOPS RUNNING* that is incorrect. > > And has made no attempt after over 9 hours to show where in the Intel > instruction manual that execution is allowed to stop after any > instruction other than HLT. > > Therefore, as per the above criteria: > > LET THE RECORD SHOW > > That Peter Olcott > > Has *officially* admitted > > That DD is NOT correctly simulated by HHH