Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: olcott Newsgroups: comp.theory Subject: Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Date: Fri, 9 May 2025 14:46:27 -0500 Organization: A noiseless patient Spider Lines: 76 Message-ID: References: <87msbmeo3b.fsf@nosuchdomain.example.com> <87ecwyekg2.fsf@nosuchdomain.example.com> <87bjs2cyj6.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Fri, 09 May 2025 21:46:35 +0200 (CEST) Injection-Info: dont-email.me; posting-host="b8226b0a928845ead4a9adb4b3b34c7d"; logging-data="3164607"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+0I2GbQnOxWsBVYcygWRXZ" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:L5EQC1M20jlSkEv/T4Qmy9zK6FU= X-Antivirus: Norton (VPS 250509-6, 5/9/2025), Outbound message In-Reply-To: Content-Language: en-US X-Antivirus-Status: Clean Bytes: 5011 On 5/9/2025 12:00 PM, Richard Damon wrote: > On 5/9/25 11:48 AM, olcott wrote: >> On 5/9/2025 3:47 AM, Fred. Zwarts wrote: >>> Op 09.mei.2025 om 04:23 schreef Keith Thompson: >>>> Richard Damon writes: >>>>> On 5/8/25 7:53 PM, olcott wrote: >>>> [...] >>>>>> void DDD() >>>>>> { >>>>>>     HHH(DDD); >>>>>>     return; >>>>>> } >>>>>> We don't need to look at any of my code for me >>>>>> to totally prove my point. For example when >>>>>> the above DDD is correctly simulated by HHH >>>>>> this simulated DDD cannot possibly reach its own >>>>>> "return" instruction. >>>>> >>>>> And thus not correctly simulatd. >>>>> >>>>> Sorry, there is no "OS Exemption" to correct simulaiton;. >>>> >>>> Perhaps I've missed something.  I don't see anything in the above that >>>> implies that HHH does not correctly simulate DDD.  Richard, you've read >>>> far more of olcott's posts than I have, so perhaps you can clarify. >>>> >>>> If we assume that HHH correctly simulates DDD, then the above code is >>>> equivalent to: >>>> >>>>      void DDD() >>>>      { >>>>        DDD(); >>>>        return; >>>>      } >>>> >>>> which is a trivial case of infinite recursion.  As far as I can tell, >>>> assuming that DDD() is actually called at some point, neither the >>>> outer execution of DDD nor the nested (simulated) execution of DDD >>>> can reach the return statement.  Infinite recursion might either >>>> cause a stack overflow and a probable program crash, or an unending >>>> loop if the compiler implements tail call optimization. >>>> >>>> I see no contradiction, just an uninteresting case of infinite >>>> recursion, something that's well understood by anyone with a >>>> reasonable level of programming experience.  (And it has nothing to >>>> do with the halting problem as far as I can tell, though of course >>>> olcott has discussed the halting problem elsewhere.) >>>> >>>> Richard, what am I missing? >>>> >>> >>> What you are missing is that the next step of olcott is to say that >>> when he uses the 'exact same HHH, with only some extra code to abort >>> the simulation', it is still an infinite recursion. He does not >>> understand that adding the abort code makes the behaviour >>> fundamentally different. >> >> When 1 or more statements of DDD are correctly simulated >> by HHH this correctly simulated DDD cannot possibly reach >> its own "return statement" final halt state. > > > But HHH can not correctly emulate this input (the code of just DDD) past > the call instruction and remain a pure function, as it hasn't been given > that code. > 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. -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer