Deutsch English Français Italiano |
<vvmk1p$35h7o$1@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: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Date: Sat, 10 May 2025 00:18:02 -0400 Organization: A noiseless patient Spider Lines: 135 Message-ID: <vvmk1p$35h7o$1@dont-email.me> References: <vv97ft$3fg66$1@dont-email.me> <vvil99$1ugd5$1@dont-email.me> <vvinvp$1vglb$1@dont-email.me> <vviv75$222r6$1@dont-email.me> <vvj1fp$22a62$1@dont-email.me> <vvj2j6$23gk7$1@dont-email.me> <as9TP.251456$lZjd.93653@fx05.ams4> <87msbmeo3b.fsf@nosuchdomain.example.com> <vvjc9b$27753$1@dont-email.me> <87ecwyekg2.fsf@nosuchdomain.example.com> <vvjg6a$28g5i$3@dont-email.me> <d577d485d0f5dfab26315f54f91eb84f25eecc40@i2pn2.org> <87bjs2cyj6.fsf@nosuchdomain.example.com> <vvkffn$2m36t$4@dont-email.me> <vvl84g$2rl0l$10@dont-email.me> <c0b0db5de5c7f7ccb24b06d44108deb41fbde8dc@i2pn2.org> <vvlm2k$30idv$1@dont-email.me> <vvlnad$2uvnf$5@dont-email.me> <vvlnpj$30vce$1@dont-email.me> <vvlsp5$31vqc$1@dont-email.me> <vvlv04$32kt3$1@dont-email.me> <87r00xchn5.fsf@nosuchdomain.example.com> <23a27379d226b7b3b9f8c303a492f66edc9019ff.camel@gmail.com> <vvmgtr$3a34p$7@dont-email.me> <5b613cbbf5464cced9768f517ff31c2b8bb34490@i2pn2.org> <vvmjoh$3atmt$2@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sat, 10 May 2025 06:18:02 +0200 (CEST) Injection-Info: dont-email.me; posting-host="bd74c3991261d909052bf71d3a970463"; logging-data="3327224"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18m1Uk0n3BdtG/qfv9a3ohF" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:5AntdS/0ddb9nro5UPZ+bHOCkY4= In-Reply-To: <vvmjoh$3atmt$2@dont-email.me> Content-Language: en-US Bytes: 7939 On 5/10/2025 12:13 AM, olcott wrote: > On 5/9/2025 10:53 PM, Richard Damon wrote: >> On 5/9/25 11:24 PM, olcott wrote: >>> On 5/9/2025 10:13 PM, wij wrote: >>>> On Fri, 2025-05-09 at 19:40 -0700, Keith Thompson wrote: >>>>> olcott <polcott333@gmail.com> writes: >>>>>> On 5/9/2025 4:40 PM, Richard Heathfield wrote: >>>>>>> On 09/05/2025 21:15, olcott wrote: >>>>>>>> On 5/9/2025 3:07 PM, Richard Heathfield wrote: >>>>>>>>> On 09/05/2025 20:46, olcott wrote: >>>>>>>>>> We have not begun to get into any of those points. >>>>>>>>>> We are only asking can DDD correctly simulated >>>>>>>>>> by any HHH that can exist ever reach its own >>>>>>>>>> "return" instruction. >>>>>>>>> >>>>>>>>> DDD can't be correctly simulated by itself (which is effectively >>>>>>>>> what you're trying to do when you fire up the simulation from >>>>>>>>> inside DDD). >>>>>>>> >>>>>>>> How the Hell did you twist my words to say that? >>>>>>> I haven't touched your words. What I have done is to observe that >>>>>>> DDD's /only/ action is to call a simulator. Since DDD isn't itself a >>>>>>> simulator, there is nothing to simulate except a call to a >>>>>>> simulator. >>>>>>> It's recursion without a base case - a rookie error. >>>>>>> HHH cannot successfully complete its task, because it never regains >>>>>>> control after the first recursion. To return, it must abort the >>>>>>> simulation, which means the simulation fails. >>>>>>> >>>>>>>> void DDD() >>>>>>>> { >>>>>>>> HHH(DDD); >>>>>>>> return; >>>>>>>> } >>>>>>>> >>>>>>>> When 1 or more statements of DDD are correctly >>>>>>>> simulated by HHH then this correctly simulated >>>>>>>> DDD cannot possibly reach its own “return statement”. >>>>>>> On what grounds can you persuade an extraordinarily sceptical >>>>>>> readership that HHH 'correctly simulated' DDD? >>>>>> >>>>>> Any competent C programmer can see that >>>>>> the call from DDD to HHH(DDD) (its own simulator) >>>>>> is equivalent to infinite recursion. >>>>>> >>>>>> On 5/8/2025 8:30 PM, Keith Thompson wrote: >>>>>>> Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it >>>>>>> does nothing else, your code would be equivalent to this: >>>>>>> >>>>>>> void DDD(void) { >>>>>>> DDD(); >>>>>>> return; >>>>>>> } >>>>>>> >>>>>>> Then the return statement (which is unnecessary anyway) will >>>>>>> never be >>>>>>> reached. In practice, the program will likely crash due to a stack >>>>>>> overflow, unless the compiler implements tail-call optimization, in >>>>>>> which case the program might just run forever -- which also means >>>>>>> the >>>>>>> unnecessary return statement will never be reached. >>>>> >>>>> I had not intended to post again, but I feel the need to make >>>>> a clarification. >>>>> >>>>> I acknowledged that the return statement would never be reached >>>>> *given the assumption* that HHH correctly simulates DDD. Given >>>>> that assumption, a call to DDD() should be equivalent to a call >>>>> to HHH(DDD). >>>>> >>>>> I did not address whether the assumption is valid. I merely >>>>> temporarily accepted it for the sake of discussion, just as I would >>>>> accept that if I were ten feet tall I would bump my head against >>>>> the ceiling in my house. >>>>> >>>>> The discussion I had with olcott did not reach the point of >>>>> discussing *how* HHH could correctly simulate DDD, or whether it >>>>> would even be logically possible for it to do so. I also did not >>>>> address any issues of partial simulation, where olcott claims that >>>>> HHH can "accurately simulate" only a few x86 instructions rather >>>>> than simulating its entire execution. I did not participate in >>>>> any discussion that would require knowledge of x86 machine or >>>>> assembly code. (I have no doubt that I could learn x86 machine >>>>> and assembly code reasonably well if motivated to do so, but I am >>>>> not so motivated.) >>>>> >>>>> What I acknowledged was barely more than "if HHH correctly simulates >>>>> DDD, then HHH correctly simulates DDD". (My understanding from >>>>> posts by others, whom I presume to be sufficiently knowledgeable, >>>>> is that HHH logically cannot accurately simulate DDD.) I would >>>>> prefer that olcott refrain from using my words to support any of >>>>> his arguments beyond the scope of what he and I directly discussed. >>>> >>>> Don't know why you people stick on the 'simulation' stuff so long. >>>> The HP simply asks for such an H (in function form. POOH does not >>>> resemble TM): >>>> H(D)=1 if D() halt. >>>> H(D)=0 if D() not halt. >>> >>> My invention of a simulating termination >>> analyzer shows exactly how to compute the >>> mapping that the input that HHH(DD) specifies >>> into a correct answer for the halting problem's >>> otherwise impossible input. >>> >>> All rebuttals are based on failing to compute >>> this mapping correctly. >>> >> >> The problem is you don't compute the correct mapping, as you LIE by >> changing the defined mapping with your strawman, >> >> Termination Analyzer, BY THEIR DEFINITION, determine if the program >> represented by their input will halt when run. PERIOD. >> > > When definitions contradict each other at > least one of them is wrong. > > HHH(DDD) computes the mapping from its input finite > string i.e. a description of the algorithm containing the fixed code of the function DD, the fixed code of the function HHH, and the fixed code of everything that HHH calls down to the OS level. > according to the rules of the x86 language Which is what happens when DD is actually run on an actual x86 processor, and that is halt. > thus obtains the actual behavior THAT THIS INPUT STRING SPECIFIES. i.e. halting.