Path: ...!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: Sat, 29 Mar 2025 16:45:37 -0400 Organization: i2pn2 (i2pn.org) Message-ID: <1ca5bd660c893e4c9b41fc4c68f6242d87dc7282@i2pn2.org> References: 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:08 -0000 (UTC) Injection-Info: i2pn2.org; logging-data="2303194"; mail-complaints-to="usenet@i2pn2.org"; posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg"; User-Agent: Mozilla Thunderbird In-Reply-To: Content-Language: en-US X-Spam-Checker-Version: SpamAssassin 4.0.0 Bytes: 4304 Lines: 61 On 3/29/25 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. Right, but not the whole program, so we don't know if it will halt or not. It doesn't show "non-halting", as that requires showing that it will NEVER halt, all it shows is that it didn't halt yet, so the halting property of this input is still unknow to the decider. > >> 2) changing the input is not allowed > > The input is unchanged. There never was any > indication that the input was in any way changed. > Since the input, to be a program, include the code of all the functions it calls, it has changed if you change between HHHs and/or a UTM. Sorry, you are just proving you are intentionally lying about what you are doing.