Deutsch English Français Italiano |
<c7828c3213642ca2e314e9fb826c0ab9034184a6@i2pn2.org> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail From: Richard Damon <richard@damon-family.org> Newsgroups: comp.theory Subject: Re: DDD specifies recursive emulation to HHH and halting to HHH1 Date: Sat, 29 Mar 2025 16:38:45 -0400 Organization: i2pn2 (i2pn.org) Message-ID: <c7828c3213642ca2e314e9fb826c0ab9034184a6@i2pn2.org> References: <vrfuob$256og$1@dont-email.me> <vs1vuv$2ot1m$1@dont-email.me> <d2f86fad6c5823e3c098f30d331576c52263b398@i2pn2.org> <vs2fgn$354gv$5@dont-email.me> <vs2u3v$3mcjm$2@dont-email.me> <vs434l$mmcb$3@dont-email.me> <vs45a3$resr$1@dont-email.me> <vs4ne1$1c1ja$1@dont-email.me> <vs4ovc$1e09p$1@dont-email.me> <vs4pg8$1c1ja$6@dont-email.me> <vs4pi9$1e09p$2@dont-email.me> <vs4qpp$1c1ja$7@dont-email.me> <vs4r2u$1e09p$3@dont-email.me> <vs4snt$1c1ja$9@dont-email.me> <vs4srl$1e09p$4@dont-email.me> <vs4tj3$1c1ja$11@dont-email.me> <vs4tot$1e09p$5@dont-email.me> <vs50dt$1c1ja$13@dont-email.me> <vs51po$1e09p$6@dont-email.me> <vs6nv4$39556$1@dont-email.me> <vs6or0$2p360$1@dont-email.me> <vs6rnk$39556$7@dont-email.me> <vs6sjv$2p360$2@dont-email.me> <vs6t79$39556$13@dont-email.me> <45b3405a167984b8649777fdc0804b124b21e19b@i2pn2.org> <vs9dcd$1v2n9$1@dont-email.me> <vs9em1$20g2j$1@dont-email.me> <vs9ft6$1v2n9$4@dont-email.me> <vs9g1l$20g2j$2@dont-email.me> <vs9h4u$23cav$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Sat, 29 Mar 2025 20:46:06 -0000 (UTC) Injection-Info: i2pn2.org; logging-data="2303194"; mail-complaints-to="usenet@i2pn2.org"; posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg"; User-Agent: Mozilla Thunderbird X-Spam-Checker-Version: SpamAssassin 4.0.0 In-Reply-To: <vs9h4u$23cav$1@dont-email.me> Content-Language: en-US Bytes: 5511 Lines: 96 On 3/29/25 3:19 PM, olcott wrote: > On 3/29/2025 2:01 PM, dbush wrote: >> On 3/29/2025 2:58 PM, olcott wrote: >>> On 3/29/2025 1:37 PM, dbush wrote: >>>> On 3/29/2025 2:15 PM, olcott wrote: >>>>> On 3/29/2025 4:31 AM, joes wrote: >>>>>> Am Fri, 28 Mar 2025 14:27:36 -0500 schrieb olcott: >>>>>>> On 3/28/2025 2:17 PM, dbush wrote: >>>>>>>> On 3/28/2025 3:02 PM, olcott wrote: >>>>>>>>> On 3/28/2025 1:12 PM, dbush wrote: >>>>>>>>>> On 3/28/2025 1:57 PM, olcott wrote: >>>>>>>>>>> On 3/27/2025 9:33 PM, dbush wrote: >>>>>>>>>>>> On 3/27/2025 10:10 PM, olcott wrote: >>>>>>>>>>>>> On 3/27/2025 8:24 PM, dbush wrote: >>>>>>>>>>>>>> On 3/27/2025 9:21 PM, olcott wrote: >>>>>>>>>>>>>>> On 3/27/2025 8:09 PM, dbush wrote: >>>>>>>>>>>>>>>> On 3/27/2025 9:07 PM, olcott wrote: >>>>>>>>>>>>>>>>> On 3/27/2025 7:38 PM, dbush wrote: >>>>>> >>>>>>>>>>>>>> Good, because that's all that's required for a solution to >>>>>>>>>>>>>> the >>>>>>>>>>>>>> halting problem: >>>>>>>>>>>>>> >>>>>>>>>>>>> There are sometimes when the behavior of TM Description D >>>>>>>>>>>>> correctly simulated by UTM1 does not match the behavior >>>>>>>>>>>>> correctly >>>>>>>>>>>>> simulated by UTM2. >>>>>>>>>>>> >>>>>>>>>>>> Irrelevant, because to satisfy the requirements, the >>>>>>>>>>>> behavior of >>>>>>>>>>>> the described machine when executed directly must be reported. >>>>>>>>>>> >>>>>>>>>>> I HAVE PROVED THAT THE REQUIREMENT IS WRONG NITWIT. >>>>>> According to what? WE require it. YOU are answering a different >>>>>> question. >>>>>> >>>>>>>>>> Category error. >>>>>>>>>> I want to know if any arbitrary algorithm X with input Y will >>>>>>>>>> halt >>>>>>>>>> when executed directly. >>>>>>>>> >>>>>>>>> It is 100% impossible for any TM to take another executing TM >>>>>>>>> as its >>>>>>>>> input. >>>>>> Quit that. >>>>>> >>>>>>>> But it can take a complete description of a TM that >>>>>>> >>>>>>> Is not always a perfect proxy for the behavior of the direct >>>>>>> execution >>>>>>> of the underlying machine. >>>>> >>>>>> Uh yes it is. >>>>>> >>>>> >>>>> That my proof that I am correct >>>>> is over your head is less than >>>>> no rebuttal what-so-ever. >>>> >>>> The fact that such TM description can be given to a UTM which will >>>> exactly replicate the behavior of the described TM when executed >>>> directly proves otherwise is apparently over your head. >>>> >>> >>> One cannot correctly ignore the effect that a specified >>> pathological relationship has between its simulator >>> and its input on the behavior of this input. >>> >> >> All it means is that HHH does not correctly map DDD to 1 as per the >> requirements: >> > > int sum(int x, int y) { return x + y; } > In the same way that sum(2,3) cannot be mapped to 7. > > Computations apply a set of finite string transformation > rules to an input finite string to derive an output finite > string. Right, and HHH transform the finite string of the DDD + HHH input to non-halting, which thus makes DDD halting, so HHH was wrong. > > The semantic property that input DDD specifies to HHH > is non-halting. > No, the semantic propery that the input DDD specifies to ANYONE is Halting, as DDD will halt. PERIOD (since HHH has been defined to return non-halting) The semantics of an input to a halt decider is, and only is, the program the input describes, and whether it will halt when it is run. Sorry, you are just showing you are trying to us a strawman, since your brain is just full of straw.