Deutsch English Français Italiano |
<vsaeba$34hfa$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: olcott <polcott333@gmail.com> Newsgroups: comp.theory Subject: Re: DDD specifies recursive emulation to HHH and halting to HHH1 Date: Sat, 29 Mar 2025 22:38:18 -0500 Organization: A noiseless patient Spider Lines: 132 Message-ID: <vsaeba$34hfa$1@dont-email.me> References: <vrfuob$256og$1@dont-email.me> <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> <9f2ff3ab9b99a7bb6dfa0885f9757f810ce52e66@i2pn2.org> <vsaam4$2sfhq$1@dont-email.me> <vsabfr$2tqng$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 05:38:19 +0200 (CEST) Injection-Info: dont-email.me; posting-host="77c560489286b435291d9494ad909b12"; logging-data="3294698"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/Mc0cWdrabhtJ161dqWZsn" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:jgpZh4VNHrKO1zS9iduX/Iu0iVI= X-Antivirus-Status: Clean X-Antivirus: Norton (VPS 250329-4, 3/29/2025), Outbound message In-Reply-To: <vsabfr$2tqng$1@dont-email.me> Content-Language: en-US Bytes: 7086 On 3/29/2025 9:49 PM, dbush wrote: > On 3/29/2025 10:35 PM, olcott wrote: >> On 3/29/2025 8:12 PM, Richard Damon wrote: >>> 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. >>> >> >> _DDD() >> [00002172] 55 push ebp ; housekeeping >> [00002173] 8bec mov ebp,esp ; housekeeping >> [00002175] 6872210000 push 00002172 ; push DDD >> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD) >> [0000217f] 83c404 add esp,+04 >> [00002182] 5d pop ebp >> [00002183] c3 ret >> Size in bytes:(0018) [00002183] >> >> The behavior that these machine code bytes specify: >> 558bec6872210000e853f4ffff83c4045dc3 > > As well as the machine code bytes of the function HHH and the machine > code bytes of everything that HHH calls down to the OS level, is that of > a program that halts when executed directly, which is the required > behavior to report on. > > The test program must ignore its own behavior when testing the program-under-test. The Peter Linz proof explicitly includes the halt decider embedded within it. The principle is the same. When Ĥ is applied to ⟨Ĥ⟩ it reaches Ĥ.qn Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn When embedded_H is applied to ⟨Ĥ⟩ ⟨Ĥ⟩ then ⟨Ĥ⟩ does not reach either ⟨Ĥ.qy⟩ or ⟨Ĥ.qn⟩ -- Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer