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: Mon, 31 Mar 2025 18:54:49 -0400
Organization: A noiseless patient Spider
Lines: 123
Message-ID: <vsf6fp$1adee$2@dont-email.me>
References: <vrfuob$256og$1@dont-email.me> <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> <vsbi7e$1hblk$1@dont-email.me>
 <vsc6qi$27lbo$2@dont-email.me>
 <8a3e7e93e6cad20b29d23405a0e6dbd497a492ac@i2pn2.org>
 <vscegq$2fv3s$2@dont-email.me>
 <26f33bb039fda7d28ae164cfc4d0f582d4698f31@i2pn2.org>
 <vsclsb$2n4jc$1@dont-email.me>
 <36a4c76730b23cf78ddde73c723116b5380973a1@i2pn2.org>
 <vsctnm$2ub5m$2@dont-email.me>
 <72d003704b5bacf77110750e8c973d62869ad204@i2pn2.org>
 <vsf402$1crun$4@dont-email.me> <vsf49v$1adee$1@dont-email.me>
 <vsf520$1crun$5@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 01 Apr 2025 00:54:49 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="43a1f663b1fe04e5f0ee05272f138407";
	logging-data="1390030"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19G/DbKcd7HO3mx8yggB37B"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:0GBXuVioMYpZi1JZlHG4uQDF4Ho=
Content-Language: en-US
In-Reply-To: <vsf520$1crun$5@dont-email.me>
Bytes: 7346

On 3/31/2025 6:30 PM, olcott wrote:
> On 3/31/2025 5:17 PM, dbush wrote:
>> On 3/31/2025 6:12 PM, olcott wrote:
>>> On 3/31/2025 3:44 PM, joes wrote:
>>>> Am Sun, 30 Mar 2025 21:13:09 -0500 schrieb olcott:
>>>>> On 3/30/2025 7:32 PM, Richard Damon wrote:
>>>>>> On 3/30/25 7:59 PM, olcott wrote:
>>>>>>> On 3/30/2025 5:50 PM, Richard Damon wrote:
>>>>>>>> On 3/30/25 5:53 PM, olcott wrote:
>>>>>>>>> On 3/30/2025 4:01 PM, Richard Damon wrote:
>>>>>>>>>> On 3/30/25 3:42 PM, olcott wrote:
>>>>>>>>>>> On 3/30/2025 8:50 AM, Fred. Zwarts wrote:
>>>>>>>>>>>> Op 30.mrt.2025 om 04:35 schreef olcott:
>>>>>>>>>>>>> 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:
>>>>
>>>>>>>>>>>>>>>> An input that halts when executed directly is not non-
>>>>>>>>>>>>>>>> terminating
>>>>
>>>>>>>>>>>>>>>>> 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.
>>>> Yes, HHH is off the topic of deciding halting.
>>>>
>>>>>>>>>>>>>>> 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.
>>>>
>>>>>>>>>>>>> The behavior that these machine code bytes specify:
>>>>>>>>>>>>> 558bec6872210000e853f4ffff83c4045dc3 as an input to HHH is
>>>>>>>>>>>>> different than these same bytes as input to HHH1 as a verified
>>>>>>>>>>>>> fact.
>>>> What does "specify to" mean? Which behaviour is correct?
>>>>
>>>>>>>>> DDD EMULATED BY HHH DOES SPECIFY THAT IT CANNOT POSSIBLY REACH ITS
>>>>>>>>> OWN FINAL HALT STATE.
>>>>>>>> How does HHH emulate the call to HHH instruction
>>>>>>> The semantics of the x86 language.
>>>>>> Right, which were defined by INTEL, and requires the data emulated to
>>>>>> be part of the input.
>>>>> It is part of the input in the sense that HHH must emulate itself
>>>>> emulating DDD. HHH it the test program thus not the program-under- 
>>>>> test.
>>>> It is part of the program under test, being called by it. That's what
>>>> you call a pathological relationship.
>>>>
>>>>> HHH is not asking does itself halt?
>>>> Yes it is saying "I can't simulate this".
>>>>
>>>>> It was encoded to always halt for
>>>>> such inputs. HHH is asking does this input specify that it reaches its
>>>>> own final halt state?
>>>> Which it does (except when simulated by HHH).
>>>>
>>>>>> Is it guessing based on your limited input that doesn't contain the
>>>>>> code at 000015d2, or
>>>>>> Is it admitting to not being a pure function, by looking outsde the
>>>>>> input to the function (since you say that above is the full 
>>>>>> input), or
>>>>>> Are you admitting all of Halt7.c/obj as part of the input, and 
>>>>>> thus you
>>>>>> hae a FIXED definition of HHH, which thus NEVER does a complete
>>>>>> emulation, and thus you can't say that the call to HHH is a complete
>>>>>> emulation.
>>>>>>
>>>>>>> How we we determine that DDD emulated by HHH cannot possibly 
>>>>>>> reach its
>>>>>>> final halt state?
>>>>>>> Two recursive emulations provide correct inductive proof.
>>>>>> Nope, because if you admit to the first two lies, your HHH never 
>>>>>> was a
>>>>>> valid decider,
>>>
>>> It is ALWAYS CORRECT for any simulating termination
>>> analyzer to stop simulating and reject any input
>>> that would otherwise prevent its own termination.
>>>
>>>
>>
>> Except when doing so changes the input, as is the case with HHH and DDD.
>>
>> Changing the input is not allowed.
> 
> I have already addressed your misconception that the input is changed.
> 

No, it is YOUR misconception.  The algorithm DDD consists of the 
function DDD, the function HHH, and everything that HHH calls down to 
the OS level.

And the halting problem is about algorithms, not C functions:


Given any algorithm (i.e. a fixed immutable sequence of instructions) X 
described as <X> with input Y:

A solution to the halting problem is an algorithm H that computes the 
following mapping:

(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly