Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: olcott Newsgroups: comp.theory Subject: Re: Simulation vs. Execution in the Halting Problem Date: Wed, 11 Jun 2025 19:52:03 -0500 Organization: A noiseless patient Spider Lines: 161 Message-ID: <102d8bk$29pam$1@dont-email.me> References: <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> <102d4fa$291mi$1@dont-email.me> <27181e2fc0e06453f53994e2a92e3a5c8808e581.camel@gmail.com> <102d6ge$29fp7$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 02:52:04 +0200 (CEST) Injection-Info: dont-email.me; posting-host="9f0ba097a1221e597ea76cc26b2e661a"; logging-data="2418006"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19brHXJlilUYalVR9a2i+ry" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:/6hkbJr6/sCQZZg/ul4WEhLKwWs= Content-Language: en-US X-Antivirus-Status: Clean In-Reply-To: X-Antivirus: Norton (VPS 250611-4, 6/11/2025), Outbound message On 6/11/2025 7:34 PM, wij wrote: > On Wed, 2025-06-11 at 19:20 -0500, olcott wrote: >> On 6/11/2025 7:03 PM, wij wrote: >>> On Wed, 2025-06-11 at 18:45 -0500, olcott wrote: >>>> On 6/11/2025 6:25 PM, wij wrote: >>>>> On Wed, 2025-06-11 at 17:33 -0500, 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? >>>>> >>>>> What is the same reason? What's the relationship of 1+1=2 relates to HP? >>>>> >>>>>> It is for this same reason that the function's caller >>>>>> cannot simultaneously be its input. >>>>> >>>>> D and H belong to the same set of TM equivalent stuff. >>>> >>>> Yes and we have the exact same issue with TM's it >>>> is merely more difficult to see. >>>> >>>> I am not going to get into that until after you totally >>>> understand this at the C level. I am unwilling to talk >>>> about this endlessly in circles. >>> >>> The problem is that you don't know TM and C as 1-year CS student does. >>> All the people here have problem to get the answer fits your level of understanding. >>> >>>>> D has to be able to perform exactly H's function (if D is a TM and if H exists). >>>>> Otherwise, that D is not the counter-example mentioned in the HP proof. >>>>> >>>> I have to covered too. Unless you understand that >>>> D cannot be both an input to H and its caller there >>>> is no sense going there. >>> >>> If it (D) cannot be both an input to H and its caller, that D is no resemble of >>> the counter-example mentioned in the HP proof. You made a crippled D. >>> >>> >> >> No D that anyone in the universe can define >> can simultaneously be the caller of a function >> and the input to the same function. > > Then, what does your example mean? > > void D() { > H(D); > } > > D cannot simultaneously be the caller of a function > and the input to the same function? > Are you refuting what you said? > If you don't understand the difference between object instances of OOP classes and the classes themselves then you might not understand. int main() { D(); // calls H(D) and the parameter to this H(D) } // is not the caller of this instance of H(D) ========== REMAINDER OF ARTICLE TRUNCATED ==========