Path: nntp.eternal-september.org!news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!i2pn.org!i2pn2.org!.POSTED!not-for-mail From: Richard Damon Newsgroups: comp.theory,sci.logic Subject: Re: My reviewers think that halt deciders must report on the behavior of their caller Date: Wed, 16 Jul 2025 22:15:52 -0400 Organization: i2pn2 (i2pn.org) Message-ID: <35adb477993842e03ae02a0ac99d471d6043b1f5@i2pn2.org> References: <101nq32$99vd$1@dont-email.me> <1ca786773f9ff02718c66e082bbc4182b36732ab@i2pn2.org> <104fduv$2n8gq$2@dont-email.me> <4cb5d16be8d1e6549823f35081050e7dad462da2@i2pn2.org> <104gi8j$2uc68$2@dont-email.me> <152859a4a4ef31aa45580e873eb6970c34b97ef9@i2pn2.org> <104hmb5$35gkb$1@dont-email.me> <104i15g$36mma$2@dont-email.me> <104jcqn$3jrpl$10@dont-email.me> <104lb03$13ioh$2@dont-email.me> <104lp8o$7l4q$7@dont-email.me> <104o662$18h8g$1@dont-email.me> <104oj2v$t0u4$7@dont-email.me> <104qjcg$1c0m7$1@dont-email.me> <104ruag$1ml84$3@dont-email.me> <104t5nk$1frch$2@dont-email.me> <104tuh6$264oq$9@dont-email.me> <104vij5$1jfin$2@dont-email.me> <1050juk$2qkok$6@dont-email.me> <1052i2m$1pbs1$1@dont-email.me> <10530ga$3dptv$4@dont-email.me> <10559er$1tk4j$3@dont-email.me> <1055hn6$2t13$1@dont-email.me> <1057mgt$21svn$3@dont-email.me> <1058gq9$q07u$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Thu, 17 Jul 2025 02:16:34 -0000 (UTC) Injection-Info: i2pn2.org; logging-data="959202"; mail-complaints-to="usenet@i2pn2.org"; posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg"; User-Agent: Mozilla Thunderbird In-Reply-To: <1058gq9$q07u$1@dont-email.me> X-Spam-Checker-Version: SpamAssassin 4.0.0 Content-Language: en-US On 7/16/25 11:34 AM, olcott wrote: > On 7/16/2025 3:05 AM, Fred. Zwarts wrote: >> Op 15.jul.2025 om 14:31 schreef olcott: >>> On 7/15/2025 5:10 AM, Fred. Zwarts wrote: >>>> Op 14.jul.2025 om 15:25 schreef olcott: >>>>> On 7/14/2025 4:19 AM, Fred. Zwarts wrote: >>>>>> Op 13.jul.2025 om 17:38 schreef olcott: >>>>>>> On 7/13/2025 1:09 AM, Fred. Zwarts wrote: >>>>>>>> Op 12.jul.2025 om 17:21 schreef olcott: >>>>>>>>> On 7/12/2025 3:17 AM, Fred. Zwarts wrote: >>>>>>>>>> Op 11.jul.2025 om 23:05 schreef olcott: >>>>>>>>>>> On 7/11/2025 3:52 AM, Fred. Zwarts wrote: >>>>>>>>>>>> Op 10.jul.2025 om 16:35 schreef olcott: >>>>>>>>>>>>> On 7/10/2025 5:54 AM, Fred. Zwarts wrote: >>>>>>>>>>>>>> Op 09.jul.2025 om 15:02 schreef olcott:> >>>>>>>>>>>>>>> All Turing machine deciders only compute the mapping >>>>>>>>>>>>>>> from their actual inputs. This entails that they never >>>>>>>>>>>>>>> compute any mapping from non-inputs. >>>>>>>>>>>>>> >>>>>>>>>>>>>> At least one thing you understand. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> *From the bottom of page 319 has been adapted to this* >>>>>>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf >>>>>>>>>>>>> >>>>>>>>>>>>> *The Linz proof does not understand this* >>>>>>>>>>>>> >>>>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩ >>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞ >>>>>>>>>>>>>    *if Ĥ applied to ⟨Ĥ⟩ halts, and* >>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>    *if Ĥ applied to ⟨Ĥ⟩ does not halt* >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The evidence is that the input includes the code to >>>>>>>>>>>>>>>> abort and halt, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> abort and stop running >>>>>>>>>>>>>>> *IS NOT THE SAME THING AS* >>>>>>>>>>>>>>> abort and halt >>>>>>>>>>>>>> >>>>>>>>>>>>>> Another claim without evidence. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> *It is common knowledge in the theory of computation* >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Another claim without evidence. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *Your lack of knowledge of computer science is not a rebuttal* >>>>>>>>>>> >>>>>>>>>>> Look at the definition of a Turing Machine (e.g., the one >>>>>>>>>>> here). The machine has states. Each state can be final or >>>>>>>>>>> non- final. If the machine's state is non-final, in the next >>>>>>>>>>> step the machine "does" something, namely, it can write >>>>>>>>>>> something on the tape, move its head, and/or change its state >>>>>>>>>>> to a different state. This is how the machine makes a progress. >>>>>>>>>> >>>>>>>>>> So, aborting the simulation when the machine has not yet >>>>>>>>>> reached its final state, is a violation of the Turing Machine. >>>>>>>>>> >>>>>>>>> >>>>>>>>> void DDD() >>>>>>>>> { >>>>>>>>>    HHH(DDD); >>>>>>>>>    return; >>>>>>>>> } >>>>>>>>> >>>>>>>>> So you don't understand that DDD simulated by >>>>>>>>> pure simulator HHH keeps repeating its first >>>>>>>>> line forever? >>>>>>>> >>>>>>>> Irrelevant, because that is not what HHH does. >>>>>>> >>>>>>> void DDD() >>>>>>> { >>>>>>>    HHH(DDD); >>>>>>>    return; >>>>>>> } >>>>>>> >>>>>>> I stipulated this HHH a pure simulator temporarily >>>>>>> overriding and superseding everything else that I ever >>>>>>> said about HHH. >>>>>> >>>>>> You can stipulate that, but is irrelevant for the HHH you >>>>>> published in Halt7.c. *That* HHH is not a pure simulator. The fact >>>>>> that a pure simulator fails is no proof for the correctness of the >>>>>> non- pure simulator. >>>>>> Dreaming of other simulators with other behaviour does not change >>>>>> the factual behaviour of the HHH we are discussing. >>>>>> >>>>> >>>>> void RRR() >>>>> { >>>>>    SSS(RRR); >>>>>    return; >>>>> } >>>>> >>>>> When RRR is simulated by pure simulator SSS >>>>> RRR simulated by SSS never reaches its own >>>>> "return" statement. >>>> >>>> You have been corrected on this many times, but you seem unable to >>>> understand it. >>>> We are discussing a non-pure simulator, so the behaviour of a pure >>>> simulator is irrelevant. >>>> >>>>> >>>>> When we adapt SSS so that it only simulates >>>>> N instructions of RRR then no RRR ever reaches >>>>> its own "return" statement. >>> >>>> Now there is a final halt state, but SSS is unable to reach it. This >>>> illustrates that simulation is not the right tool for this input to >>>> analyse the behaviour, because it cannot see the full specification. >>>> Other tools are needed, but each tool will fail for some inputs. >>> >>> _DDD() >>> [00002192] 55             push ebp >>> [00002193] 8bec           mov ebp,esp >>> [00002195] 6892210000     push 00002192  // push DDD >>> [0000219a] e833f4ffff     call 000015d2  // call HHH >>> [0000219f] 83c404         add esp,+04 >>> [000021a2] 5d             pop ebp >>> [000021a3] c3             ret >>> Size in bytes:(0018) [000021a3] >>> >>> So when the actual behavior of the actual x86 code >>> disagrees with you you disagree with the x86 language. >>> >> >> And since it does not disagree with me, > Show how DDD emulated by HHH > (according to the semantics of the x86 language) > reaches its "ret" instruction final halt state. > > Don't fucking change the subject to something else. > That isn't our problem. YHOUR problem is YOU need to prove that it DOES a correct simulation, even though the code for HHH isn't in the input. The definition of non-halting references the behavior of the DIRECT EXECUTION of the PROGRAM that the input represents. Since you input doesn't include HHH, it isn't a program, and thus doesn't have a halting property, and you arguement blows up in a category error.