Deutsch English Français Italiano |
<9f2ff3ab9b99a7bb6dfa0885f9757f810ce52e66@i2pn2.org> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!eternal-september.org!feeder3.eternal-september.org!news.quux.org!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 21:12:29 -0400 Organization: i2pn2 (i2pn.org) Message-ID: <9f2ff3ab9b99a7bb6dfa0885f9757f810ce52e66@i2pn2.org> References: <vrfuob$256og$1@dont-email.me> <vs4r2u$1e09p$3@dont-email.me> <vs4snt$1c1ja$9@dont-email.me> <e11c6f4f29bb0c77dbd10f8e20bca766712977d0@i2pn2.org> <vs50kt$1c1ja$15@dont-email.me> <vs5r0j$2f37e$1@dont-email.me> <vs6srk$39556$12@dont-email.me> <vs6t10$2p360$6@dont-email.me> <vs70tc$39556$21@dont-email.me> <vs71bq$2p360$10@dont-email.me> <vs76m9$3m3q0$1@dont-email.me> <vs77th$2p360$11@dont-email.me> <vs78cu$3ms9k$1@dont-email.me> <c2b91231b9052e07b6705250938fb9095e711327@i2pn2.org> <vs7kvf$3eal$2@dont-email.me> <aeb75b411e9f77c974585181c671a47d03b22078@i2pn2.org> <vs7qdm$8dae$2@dont-email.me> <vs7r9b$8ajp$1@dont-email.me> <vs92l3$1fccq$5@dont-email.me> <vs93ae$1k9u2$1@dont-email.me> <vs9g5p$1v2n9$5@dont-email.me> <vs9gcg$20g2j$3@dont-email.me> <vs9h9o$23cav$2@dont-email.me> <vs9hh3$20g2j$6@dont-email.me> <vs9jie$23cav$4@dont-email.me> <vs9kb1$26cg5$2@dont-email.me> <vs9pni$27rl4$9@dont-email.me> <vs9r1b$28tqg$2@dont-email.me> <vs9t45$2f6n5$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sun, 30 Mar 2025 01:12:55 -0000 (UTC) Injection-Info: i2pn2.org; logging-data="2329472"; mail-complaints-to="usenet@i2pn2.org"; posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg"; User-Agent: Mozilla Thunderbird Content-Language: en-US In-Reply-To: <vs9t45$2f6n5$1@dont-email.me> X-Spam-Checker-Version: SpamAssassin 4.0.0 Bytes: 5574 Lines: 99 On 3/29/25 6:44 PM, olcott wrote: > On 3/29/2025 5:08 PM, dbush wrote: >> On 3/29/2025 5:46 PM, olcott wrote: >>> On 3/29/2025 3:14 PM, dbush wrote: >>>> On 3/29/2025 4:01 PM, olcott wrote: >>>>> On 3/29/2025 2:26 PM, dbush wrote: >>>>>> On 3/29/2025 3:22 PM, olcott wrote: >>>>>>> On 3/29/2025 2:06 PM, dbush wrote: >>>>>>>> On 3/29/2025 3:03 PM, olcott wrote: >>>>>>>>> On 3/29/2025 10:23 AM, dbush wrote: >>>>>>>>>> On 3/29/2025 11:12 AM, olcott wrote: >>>>>>>>>>> On 3/28/2025 11:00 PM, dbush wrote: >>>>>>>>>>>> On 3/28/2025 11:45 PM, olcott wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> It defines that it must compute the mapping from >>>>>>>>>>>>> the direct execution of a Turing Machine >>>>>>>>>>>> >>>>>>>>>>>> Which does not require tracing an actual running TM, only >>>>>>>>>>>> mapping properties of the TM described. >>>>>>>>>>> >>>>>>>>>>> The key fact that you continue to dishonestly ignore >>>>>>>>>>> is the concrete counter-example that I provided that >>>>>>>>>>> conclusively proves that the finite string of machine >>>>>>>>>>> code input is not always a valid proxy for the behavior >>>>>>>>>>> of the underlying virtual machine. >>>>>>>>>> >>>>>>>>>> In other words, you deny the concept of a UTM, which can take >>>>>>>>>> a description of any Turing machine and exactly reproduce the >>>>>>>>>> behavior of the direct execution. >>>>>>>>> >>>>>>>>> I deny that a pathological relationship between a UTM and >>>>>>>>> its input can be correctly ignored. >>>>>>>>> >>>>>>>> >>>>>>>> In such a case, the UTM will not halt, and neither will the >>>>>>>> input when executed directly. >>>>>>> >>>>>>> It is not impossible to adapt a UTM such that it >>>>>>> correctly simulates a finite number of steps of an >>>>>>> input. >>>>>>> >>>>>> >>>>>> 1) then you no longer have a UTM, so statements about a UTM don't >>>>>> apply >>>>> >>>>> We can know that when this adapted UTM simulates a >>>>> finite number of steps of its input that this finite >>>>> number of steps were simulated correctly. >>>> >>>> And therefore does not do a correct UTM simulation that matches the >>>> behavior of the direct execution as it is incomplete. >>>> >>> >>> It is dishonest to expect non-terminating inputs to complete. >> >> An input that halts when executed directly is not non-terminating >> >>> >>>>> >>>>>> 2) changing the input is not allowed >>>>> >>>>> The input is unchanged. There never was any >>>>> indication that the input was in any way changed. >>>>> >>>> >>>> False, if the starting function calls UTM and UTM changes, you're >>>> changing the input. >>>> >>> >>> When UTM1 is a UTM that has been adapted to only simulate >>> a finite number of steps >> >> And is therefore no longer a UTM that does a correct and complete >> simulation >> >>> and input D calls UTM1 then the >>> behavior of D simulated by UTM1 >> >> >> Is not what I asked about. I asked about the behavior of D when >> executed directly. >> > > Off topic for this thread. > UTM1 D DOES NOT HALT > UTM2 D HALTS > D is the same finite string in both cases. > No it isn't, not if it is the definition of a PROGRAM. Or, are you admitting you don't understand the meaning of a program? If D doesn't include the machine it calls, then NOTHING can emulate it past the call instruction without violating the definition of a computation/pure program, which you have admitted is a core requirement of your decider (which it turns out it never met). Sorry, you are just proving that you don't understand what you are talking about.