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: Simulation vs. Execution in the Halting Problem Date: Wed, 11 Jun 2025 21:31:08 -0400 Organization: i2pn2 (i2pn.org) Message-ID: <86986f5b07dfc95decf50e25ba47921eb348496e@i2pn2.org> References: <102c5nb$21qj7$2@dont-email.me> <602d915e3a80042ddac7f05fb389837ce3cefc12.camel@gmail.com> <102c7dj$226jq$1@dont-email.me> <0373fc8c6462341f655385edf6d4a0664a35981d.camel@gmail.com> <102ca1c$22pmt$1@dont-email.me> <85f876c4db96fb776dabc80c4208feed6aabc76d.camel@gmail.com> <102cdon$23jal$1@dont-email.me> <2e40a87aeb9e28ce23b5ebf3fcbf23dad6728a9b.camel@gmail.com> <102cg6f$246h5$1@dont-email.me> <822e204898d419545ca400a9088970f0b6a5107f.camel@gmail.com> <102ckje$25dg0$2@dont-email.me> <102cm0u$25dg0$3@dont-email.me> <610e2a54b66e8576b80bda3a0fe188d025b9798e.camel@gmail.com> <102cp0e$26clp$1@dont-email.me> <102crbv$26rt0$1@dont-email.me> <102ctbg$26rt0$2@dont-email.me> <102d082$28067$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Thu, 12 Jun 2025 01:38:35 -0000 (UTC) Injection-Info: i2pn2.org; logging-data="129875"; mail-complaints-to="usenet@i2pn2.org"; posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg"; User-Agent: Mozilla Thunderbird In-Reply-To: <102d082$28067$1@dont-email.me> X-Spam-Checker-Version: SpamAssassin 4.0.0 Content-Language: en-US On 6/11/25 6:33 PM, olcott wrote: > On 6/11/2025 4:57 PM, wij wrote: >> On Wed, 2025-06-11 at 16:44 -0500, olcott wrote: >>> On 6/11/2025 4:23 PM, wij wrote: >>>> On Wed, 2025-06-11 at 16:10 -0500, olcott wrote: >>>>> On 6/11/2025 3:59 PM, wij wrote: >>>>>> On Wed, 2025-06-11 at 15:30 -0500, olcott wrote: >>>>>>> On 6/11/2025 2:45 PM, wij wrote: >>>>>>>> On Wed, 2025-06-11 at 14:39 -0500, olcott wrote: >>>>>>>>> On 6/11/2025 2:31 PM, wij wrote: >>>>>>>>>> On Wed, 2025-06-11 at 14:14 -0500, olcott wrote: >>>>>>>>>>> On 6/11/2025 1:25 PM, wij wrote: >>>>>>>>>>>> On Wed, 2025-06-11 at 12:59 -0500, olcott wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes all other people (especially Dennis Bush) are saying >>>>>>>>>>>>>>> that H(D) is required to report on the behavior of the >>>>>>>>>>>>>>> direct execution of D() never noticing that this stupidly >>>>>>>>>>>>>>> requires H(D) to report on the behavior of its caller. >>>>>>>>>>>>>> >>>>>>>>>>>>>> If the H above means the H that the HP refers to. The H is >>>>>>>>>>>>>> required to >>>>>>>>>>>>>> report its argument's behavior (ie. by H(D)). But NOT >>>>>>>>>>>>>> required by simulation. >>>>>>>>>>>>> >>>>>>>>>>>>> It turns out that no one ever noticed that simulating halt >>>>>>>>>>>>> deciders nullify the HP counter-example input in that this >>>>>>>>>>>>> input cannot possibly reach its contradictory part. >>>>>>>>>>>>> >>>>>>>>>>>>>> The HP does not care what D does (simply to say). >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Everyone says that H(D) must re[port on the behavior of >>>>>>>>>>>>> the direct execution of D(). >>>>>>>>>>>> >>>>>>>>>>>> That is what the HP asks. >>>>>>>>>>>> >>>>>>>>>>>>>> The HP only requires: H(D)==1 iff D() halts >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> int main() >>>>>>>>>>>>> { >>>>>>>>>>>>>          D(); // calls H(D) >>>>>>>>>>>>> } >>>>>>>>>>>>> >>>>>>>>>>>>> Which requires H(D) to report on the behavior of its >>>>>>>>>>>>> caller instead of reporting on the behavior that its >>>>>>>>>>>>> input actually specifies. >>>>>>>>>>>> >>>>>>>>>>>> That is no problem. H does not care what D does inside >>>>>>>>>>>> (simply to say). >>>>>>>>>>>> The HP simply asks for a H that "H(D)==1 iff D() halts". >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Which requires H to report on something that it cannot >>>>>>>>>>> possibly see. >>>>>>>>>> >>>>>>>>>> On the contrary, what the HP proves is very useful. >>>>>>>>>> >>>>>>>>> >>>>>>>>> I am not talking about the halting problem, I have always >>>>>>>>> been talking about the conventional halting problem proof. >>>>>>>>> THIS PROOF IS WRONG >>>>>>>> >>>>>>>> When talking about proof, we say it is valid or not. By doing >>>>>>>> so, we have >>>>>>>> to unambiguously pose the problem and the derivation to the >>>>>>>> conclusion. >>>>>>>> The HP proof just did that. >>>>>>>> >>>>>>> >>>>>>> It may seem that way if you pay less than 100% >>>>>>> complete attention. >>>>>>> >>>>>>> The HP proof depends on an *INPUT* that does >>>>>>> the opposite of whatever value that H returns >>>>>>> and no such *INPUT* can possibly exist. >>>>>> >>>>>> That is absolutely correct. No such *INPUT* (i.e. D) can possible >>>>>> exit is because >>>>>> the H inside D does not exist at all. >>>>>> So, if the H is assumed to exist, then D will exist to make H >>>>>> undecidable. >>>>>> >>>>> >>>>> There is no *input* to any termination analyzer >>>>> that can do the opposite of whatever value that >>>>> this termination analyzer returns >>>> >>>> Your reinterpretation of of HP case is wrong. >>>> Your D or H is not the case mention in the HP proof. >>>> >>> >>> There cannot possibly exist any D mine or >>> anyone else's that is encoded to do the opposite >>> of whatever value that H returns. >> >> Why not? D and H are supposed to be TM (or C function). >> If the D cannot do the opposite of whatever value that H returns, then >> that D is not powerful enough to be a TM, not an interesting case. >> > > Can you be your biological mother's biological father? > It is for this same reason that the function's caller > cannot simultaneously be its input. > Not a valid comparison. After all, programs REGULARLY include code from their "parent" programs. I guess you are just admitting that you don't understand the meaning of "all". Sorry, you are just proving you are just a pathological liar.