Deutsch English Français Italiano |
<vvehho$etf4$2@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!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: Tue, 6 May 2025 22:46:16 -0400 Organization: A noiseless patient Spider Lines: 154 Message-ID: <vvehho$etf4$2@dont-email.me> References: <GE4SP.47558$VBab.42930@fx08.ams4> <vvamqc$o6v5$4@dont-email.me> <5b84f927f8052f5392b625cef9642140d439d1c7@i2pn2.org> <vvbs6b$1us1f$3@dont-email.me> <1a99b2ee77f8c0d1ff37e5febb47c5be17b2d4fb@i2pn2.org> <vvdidg$3cbpq$8@dont-email.me> <bf914e91ee1c9d27536cfebf811930e24014cdf3@i2pn2.org> <vveh6e$89u0$8@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 04:46:16 +0200 (CEST) Injection-Info: dont-email.me; posting-host="3013d96e0ac4b7dd359f7afe652f4ce0"; logging-data="488932"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18YZEf5UiFTDpEJPijzRT2V" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:bvzVk6g0ky9DN2GIK3keB1ZdARg= In-Reply-To: <vveh6e$89u0$8@dont-email.me> Content-Language: en-US Bytes: 7030 On 5/6/2025 10:40 PM, olcott wrote: > On 5/6/2025 6:00 PM, Richard Damon wrote: >> On 5/6/25 1:54 PM, olcott wrote: >>> On 5/6/2025 6:06 AM, Richard Damon wrote: >>>> On 5/5/25 10:29 PM, olcott wrote: >>>>> On 5/5/2025 8:06 PM, Richard Damon wrote: >>>>>> On 5/5/25 11:51 AM, olcott wrote: >>>>>>> On 5/5/2025 10:17 AM, Mr Flibble wrote: >>>>>>>> What constitutes halting problem pathological input: >>>>>>>> >>>>>>>> Input that would cause infinite recursion when using a decider >>>>>>>> of the >>>>>>>> simulating kind. >>>>>>>> >>>>>>>> Such input forms a category error which results in the halting >>>>>>>> problem >>>>>>>> being ill-formed as currently defined. >>>>>>>> >>>>>>>> /Flibble >>>>>>> >>>>>>> I prefer to look at it as a counter-example that refutes >>>>>>> all of the halting problem proofs. >>>>>>> >>>>>>> int DD() >>>>>>> { >>>>>>> int Halt_Status = HHH(DD); >>>>>>> if (Halt_Status) >>>>>>> HERE: goto HERE; >>>>>>> return Halt_Status; >>>>>>> } >>>>>> >>>>>> Which isn't a program until you include the SPECIFIC HHH that it >>>>>> refutes, and thus your talk about correctly emulated by HHH is >>>>>> just a lie. >>>>>> >>>>>>> >>>>>>> https://github.com/plolcott/x86utm >>>>>>> >>>>>>> The x86utm operating system includes fully >>>>>>> operational HHH and DD. >>>>>>> https://github.com/plolcott/x86utm/blob/master/Halt7.c >>>>>>> >>>>>>> When HHH computes the mapping from *its input* to >>>>>>> the behavior of DD emulated by HHH this includes >>>>>>> HHH emulating itself emulating DD. This matches >>>>>>> the infinite recursion behavior pattern. >>>>>>> >>>>>> >>>>>> And *ITS INPUT*, for the HHH that answers 0, is the representation >>>>>> of a program >>>>> >>>>> Not at all. This has always been stupidly wrong. >>>>> The input is actually a 100% perfectly precise >>>>> sequence of steps. With pathological self-reference >>>>> some of these steps are inside the termination analyzer. >>>>> >>>> >>>> Can't be, as the input needs to be about a program, which must, by >>>> the definition of a program, include all its algorithm. >>>> >>>> Yes, there are steps that also occur in the termination analyzer, >>>> but they have been effectively copied into the program the input >>>> describes. >>>> >>>> Note, nothing says that the representation of the program has to be >>>> an assembly level description of it. It has to be a complete >>>> description, that 100% defines the results the code will generate >>>> (and if it will generate) but it doesn't need to be the exact >>>> assembly code, >>>> >>>> YOU even understand that, as you present the code as "C" code, which >>>> isn't assembly. >>>> >>>> What you forget is that the input program INCLUDES as its definiton, >>>> all of the code it uses, and thus the call to the decider it is >>>> built on includes that code into the decider, and that is a FIXED >>>> and DETERMINDED version of the decider, the one that THIS version of >>>> the input is designed to make wrong. >>>> >>>> This doesn't change when you hypothosize a different decider looking >>>> at THIS input. >>>> >>> >>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>> If simulating halt decider H correctly simulates its >>> input D until H correctly determines that its simulated D >>> *would never stop running unless aborted* then >>> >>> *would never stop running unless aborted* >>> Refers to a hypothetical HHH/DD pair of the same HHH that >>> DD calls except that this hypothetical HHH never aborts. >>> >> >> Right, but a correct simulation of D does halt, > > How the Hell is breaking the rules specified > by the x86 language possibly correct? > > I could say that the sum of 5 + 7 is a dirty sock > according to the rules of random gibberish. > > When I go by the rules of arithmetic I am proved > wrong. > > DD <is> emulated by HHH according to the rules > of the x86 language False, as you yourself have admitted on the record: 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