Path: 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 Subject: Re: DDD specifies recursive emulation to HHH and halting to HHH1 Date: Sun, 30 Mar 2025 07:20:05 -0400 Organization: i2pn2 (i2pn.org) Message-ID: References: <9f2ff3ab9b99a7bb6dfa0885f9757f810ce52e66@i2pn2.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sun, 30 Mar 2025 11:21:23 -0000 (UTC) Injection-Info: i2pn2.org; logging-data="2386220"; mail-complaints-to="usenet@i2pn2.org"; posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg"; User-Agent: Mozilla Thunderbird In-Reply-To: X-Spam-Checker-Version: SpamAssassin 4.0.0 Content-Language: en-US On 3/29/25 11:38 PM, olcott wrote: > 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. Where do you get this from? Why does it apply to the behavior of a copy of it in 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⟩ > > Sure it does, since H (Ĥ) (Ĥ) does, and it is an exact copy of that, so it behaves just like it. You are just proving you are just an ignorant liar.