Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!news.quux.org!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail From: Richard Damon Newsgroups: comp.theory Subject: Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD) Date: Fri, 9 May 2025 14:13:18 -0400 Organization: i2pn2 (i2pn.org) Message-ID: References: <87msbmeo3b.fsf@nosuchdomain.example.com> <875xiaejzg.fsf@nosuchdomain.example.com> <87jz6qczja.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Fri, 9 May 2025 18:34:35 -0000 (UTC) Injection-Info: i2pn2.org; logging-data="3837174"; mail-complaints-to="usenet@i2pn2.org"; posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg"; User-Agent: Mozilla Thunderbird Content-Language: en-US In-Reply-To: X-Spam-Checker-Version: SpamAssassin 4.0.0 On 5/9/25 10:45 AM, olcott wrote: > On 5/8/2025 9:02 PM, Keith Thompson wrote: >> olcott writes: >>> On 5/8/2025 6:54 PM, Keith Thompson wrote: >>>> olcott writes: >>>>> On 5/8/2025 6:30 PM, Richard Heathfield wrote: >>>>>> On 08/05/2025 23:50, olcott wrote: >>>> [...] >>>>>>> If you are a competent C programmer >>>>>> Keith Thompson is a highly-respected and very competent C >>>>>> programmer. >>>>> >>>>> *Then he is just who I need* >>>> No, what you need is someone who is an expert in mathematical logic >>>> (I am not) who can explain to you, in terms you can understand and >>>> accept, where you've gone wrong.  Some expertise in C could also >>>> be helpful. >>> >>> The key gap in my proof is that none of the comp.sci >>> people seems to have a slight clue about simple C >>> programming. >> >> You see, this is something you've gotten wrong, and you need somebody >> who can explain that to you in terms you can understand and accept. >> >>> void DDD() >>> { >>>    HHH(DDD); >>>    return; >>> } >>> >>> *THIS IS THE C PART THAT NO ONE HERE UNDERSTANDS* >>> DDD correctly simulated by HHH cannot possibly >>> reach its own "return" instruction. >> >> Is there any reason you couldn't have written that as follows? >> >> void DDD(void) >> { >>    HHH(DDD); >> } >> >> You could then talk about it not reaching its closing brace rather >> than not reaching its "return" instruction.  BTW, it's correctly >> called a "return statement" in C; dropping it would make it easier >> to avoid your incorrect use of terminology.  (Assembly or machine >> code has "instructions"; C has "statements" and "declarations".) >> > > I need the "return statement" to explicitly > mark the computer science: "final halt state". No you don't. Reaching the "end of the function" is a well defined term in the C standard. But, I guess looking at the actual Standards and the words they define is something foreign to youu. > >>> DDD correctly simulated by HHH is the same thing >>> as infinite recursion between HHH and DDD yet is >>> implemented as recursive simulation. >> >> Sure, infinite recursion is infinite, regardless of how it's >> implemented, assuming it's implemented correctly.  That's so trivally >> obvious that I simply don't believe that "the comp.sci" people are >> failing to understand it -- though I can believe that you believe it. >> > > Richard provided the same kind of fake "rebuttal" > that I always get. It isn't fake. If it was, you could show the error. > > void DDD() > { >   HHH(DDD); >   return; > } > > "..DDD correctly simulated by HHH cannot > possibly REACH its own "return statement". But HHH can not correct emulate that input. > > Everyone here has been denying that simple > statement for three years. They do this by > changing the subject away from the question > being asked to irrelevant details. Because it isn't true by your stipulation of what you mean. > > I am only referring to the above hypothetical > HHH/DDD pair of C functions. And DDD as a function isn't emulatable until you actually add the HHH it calls as the input. Then you final logic is broken. > > When 1 or more statements of DDD are correctly > simulated by HHH then the simulated DDD cannot > possibly reach its own "return statement" final > halt state. > Which must stop once DDD calls HHH, as HHH has not been given that code as its input, and thus it isn't ALLOWED to look there to access it. You have stipulated as much.