Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: dbush <dbush.mobile@gmail.com>
Newsgroups: comp.theory
Subject: Re: DDD specifies recursive emulation to HHH and halting to HHH1
Date: Sat, 29 Mar 2025 23:49:28 -0400
Organization: A noiseless patient Spider
Lines: 125
Message-ID: <vsaf07$2tqng$2@dont-email.me>
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 05:49:28 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0bf50eb60a3714748578f227116a9d7a";
	logging-data="3074800"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+yru3LkUa/D0PP0NrS4agj"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:1OyHOHGgveh1JYFk8Tfu1BdjNFA=
In-Reply-To: <vsaeba$34hfa$1@dont-email.me>
Content-Language: en-US
Bytes: 6869

On 3/29/2025 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.

FALSE!!!

The test program in this case is *also* part of the program under test, 
and therefore the fixed immutable code of HHH and everything it calls is 
part of the input and therefore is not allowed to be changed, 
hypothetically or otherwise.