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 Newsgroups: comp.theory Subject: Re: How the requirements that Professor Sipser agreed to are exactly met --- WDH Date: Wed, 14 May 2025 16:51:48 -0400 Organization: A noiseless patient Spider Lines: 148 Message-ID: <1002vp2$2mbr6$3@dont-email.me> References:

<1000dlc$21dtc$5@dont-email.me> <1000qdb$24gr3$4@dont-email.me> <1000rir$24jh0$3@dont-email.me> <1000rqc$24gr3$7@dont-email.me> <1000son$24sr2$3@dont-email.me> <7947826fb84c9c8db49c392b305d395c3669907f@i2pn2.org> <1002dre$2i4bk$14@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Wed, 14 May 2025 22:51:47 +0200 (CEST) Injection-Info: dont-email.me; posting-host="794812149fd3df87a1483ec84874242e"; logging-data="2830182"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/YtFsQ0b+lSsQ5o1RsADCO" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:j7Qzs8Hd+ILFXLYuwgU+QdFG5cQ= Content-Language: en-US In-Reply-To: <1002dre$2i4bk$14@dont-email.me> Bytes: 7316 On 5/14/2025 11:45 AM, olcott wrote: > On 5/14/2025 6:20 AM, Richard Damon wrote: >> On 5/13/25 9:48 PM, olcott wrote: >>> On 5/13/2025 8:31 PM, dbush wrote: >>>> On 5/13/2025 9:27 PM, olcott wrote: >>>>> On 5/13/2025 8:07 PM, dbush wrote: >>>>>> On 5/13/2025 5:30 PM, olcott wrote: >>>>>>> On 5/13/2025 6:43 AM, Richard Damon wrote: >>>>>>>> On 5/13/25 12:52 AM, olcott wrote: >>>>>>>>> On 5/12/2025 11:05 PM, Richard Damon wrote: >>>>>>>>>> On 5/12/25 10:53 PM, olcott wrote: >>>>>>>>>>> On 5/12/2025 8:27 PM, Richard Damon wrote: >>>>>>>>>>>> On 5/12/25 2:17 PM, olcott wrote: >>>>>>>>>>>>> Introduction to the Theory of Computation 3rd Edition >>>>>>>>>>>>> by Michael Sipser (Author) >>>>>>>>>>>>> 4.4 out of 5 stars 568 rating >>>>>>>>>>>>> >>>>>>>>>>>>> https://www.amazon.com/Introduction-Theory-Computation- >>>>>>>>>>>>> Michael- Sipser/ dp/113318779X >>>>>>>>>>>>> >>>>>>>>>>>>> int DD() >>>>>>>>>>>>> { >>>>>>>>>>>>> int Halt_Status = HHH(DD); >>>>>>>>>>>>> if (Halt_Status) >>>>>>>>>>>>> HERE: goto HERE; >>>>>>>>>>>>> return Halt_Status; >>>>>>>>>>>>> } >>>>>>>>>>>>> >>>>>>>>>>>>> DD correctly simulated by any pure simulator >>>>>>>>>>>>> named HHH cannot possibly terminate thus proving >>>>>>>>>>>>> that this criteria has been met: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> 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 >>>>>>>>>>>>> >>>>>>>>>>>>> H can abort its simulation of D and correctly report >>>>>>>>>>>>> that D >>>>>>>>>>>>> specifies a non-halting sequence of configurations. >>>>>>>>>>>>> >>>>>>>>>>>> words 10/13/2022> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Which your H doesn't do, as it can not correctly determine >>>>>>>>>>>> what doesn't happen. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Any C programmer can correctly tell what doesn't happen. >>>>>>>>>>> What doesn't happen is DD reaching its "return" statement >>>>>>>>>>> final halt state. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Sure they can, since that is the truth, as explained. >>>>>>>>>> >>>>>>>>>> Since your "logic" is based on lies and equivocation, >>>>>>>>> >>>>>>>>> If my logic was based on lies and equivocation >>>>>>>>> then you could provide actual reasoning that >>>>>>>>> corrects my errors. >>>>>>>> >>>>>>>> I hae. >>>>>>>> >>>>>>>>> >>>>>>>>> It is truism that simulating termination analyzers >>>>>>>>> must report on the behavior of their input as if >>>>>>>>> they themselves never aborted this simulation: >>>>>>>> >>>>>>>> Right, of the input actually given to them, which must include >>>>>>>> all their code, and that code is what is actually there, not >>>>>>>> created by this imaginary operation. >>>>>>>> >>>>>>> >>>>>>> In other words every single byte of HHH and DD are >>>>>>> 100% totally identical except the hypothetical HHH >>>>>>> has its abort code commented out. >>>>>> >>>>>> In other words you changed the input. >>>>>> >>>>>> Changing the input is not allowed. >>>>>> >>>>> >>>>> >>>>> >>>>>>> >>>>>>>> Thus, a HHH that aborts to return an answer, when looking at the >>>>>>>> DDD that calls it, must look at the unaborted emulation of THAT >>>>>>>> DDD, that calls the HHH that DOES abort and return an answer, as >>>>>>>> that is what the PROGRAM DDD is, If you can not create the HHH >>>>>>>> that does that without changing that input, that is a flaw in >>>>>>>> your system, not the problem. >>>>>>>> >>>>>>>>> >>>>>>>>> *simulated D would never stop running unless aborted* >>>>>>>>> or they themselves could become non-terminating. >>>>>>>> >>>>>>>> But you aren't simulating the same PROGRAM D that the original >>>>>>>> was given. >>>>>>>> >>>>>>> >>>>>>> It is not supposed to be the same program. >>>>>> >>>>>> So you *explicitly* admit to changing the input. >>>>>> >>>>> >>>>> The finite string of DD is specific sequence bytes. >>>> >>>> Which includes the specific sequence of bytes that is the finite >>>> string HHH >>>> >>> >>> No it does not. A function calls is not macro inclusion. >>> >>>>> The finite string of HHH is specific sequence bytes. >>>>> >>>>> The hypothetical HHH that does not abort its input >>>>> cannot have input that has changed because it never >>>>> comes into actual existence. >>>> >>>> But your HHH decides on that hypothetical non-input. >>>> >>> >>> The whole point here is not to critique the words >>> that professor Sipser agreed to. >>> >>> The whole point here is to determine whether or >>> not HHH meets this spec. It is a verified fact >>> that it does meet this spec. >> >> >> And since the DD that HHH is simulating WILL HALT when fully simulated >> (an action that HHH doesn't do) > > *NOT IN THE ACTUAL SPEC* > > 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 > That Sipser didn't agree what you think the above means: On Monday, March 6, 2023 at 2:41:27 PM UTC-5, Ben Bacarisse wrote: > I exchanged emails with him about this. He does not agree with anything > substantive that PO has written. I won't quote him, as I don't have > permission, but he was, let's say... forthright, in his reply to me.