Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!i2pn.org!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: Sun, 30 Mar 2025 07:20:05 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <aff792cf001a0a5b081ecb4ef872fddb60fe00b6@i2pn2.org>
References: <vrfuob$256og$1@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>
 <vsaeba$34hfa$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 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: <vsaeba$34hfa$1@dont-email.me>
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.