Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: HHH maps its input to the behavior specified by it --- never
 reaches its halt state
Date: Thu, 8 Aug 2024 22:53:04 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <2273634377d1cb6884eca988541491e3f2e6d003@i2pn2.org>
References: <v8qqcb$put0$1@dont-email.me> <v8v5b2$2940d$1@dont-email.me>
 <v8vrhq$32fso$4@dont-email.me> <v91qdv$3q6cj$1@dont-email.me>
 <v933gn$5r7u$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 9 Aug 2024 02:53:04 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="1932052"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <v933gn$5r7u$2@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 5502
Lines: 95

On 8/8/24 2:41 PM, olcott wrote:
> On 8/8/2024 2:00 AM, Mikko wrote:
>> On 2024-08-07 13:07:06 +0000, olcott said:
>>
>>> On 8/7/2024 1:48 AM, Mikko wrote:
>>>> On 2024-08-05 15:16:27 +0000, olcott said:
>>>>
>>>>> I have been working in the x86 language back when my work
>>>>> computer at the US Army corps of engineers was an IBM PC
>>>>> with an 8088 processor, 512K of RAM and dual floppy drives.
>>>>>
>>>>> I was creating dBASE III systems on this computer. This was
>>>>> before the 8086 processor even existed thus the name x86
>>>>> language did not yet exist.
>>>>
>>>> Intel 8088 is a variant of 8086 for less expensive computers.
>>>> Intel 8086 already exsted when the first 8088 computers were
>>>> sold. Later Intel develped 80188, 80186, and other processors
>>>> that cold run programs that were written or compiled for 8086,
>>>> so someone coined the term x86 for the family.
>>>>
>>>
>>> Can you write programs in this language?
>>> I have written many interrupt intercept TSR
>>> programs in the 8088 versions of the language.
>>> I was doing my own time slicing back in 1987.
>>
>> I have done that tor 8088 and some other poocessors but not
>> recently so my skills may be rusty. Only rarely there is any
>> need for machine language programming.
>>
> 
> typedef void (*ptr)();
> int HHH(ptr P); // simulating termination analyzer
> 
> void DDD()
> {
>    HHH(DDD);
>    return;
> }
> 
> Each HHH of every HHH that can possibly exist definitely
> emulates zero to infinity instructions of DDD correctly.
> Every expert in the C language sees that this emulated DDD
> cannot possibly reaches its own "return" instruction halt state.
> 
> It seems that every rebuttal that anyone can possibly make is
> necessarily erroneous because the above paragraph is a tautology.
> 

Nope, it is a lie based on comfusing the behavior of DDD which is what 
"Halting" is.

Remember, the definition of "Halting" is THE PROGRAM reaching a final 
state. I will repeat that, it is THE PROGRAM reachibg a final state.

A Program, it the COMPLETE collection of ALL the instructions possible 
used in the execution of it, and thus, the PROGRAM DDD, includes the 
instructions of HHH as part of it, so when you pair different HHHs to 
the C function DDD, to get programs, each pairing is a DIFFERENT input.

Also, to be a valid input to decide on, it must contain all the 
information needed, and thus your version with just the bytes of the C 
function is NOT a valid input to decide on, and any claim based on that 
would just be a lie.

Now, when we look at your claimed about DDD correctly emulated for only 
a finite number of steps, and remembering that Halting is based on the 
behavior of the FULL program, the partial emulation does NOT define the 
behavior of that DDD. We CAN look at a Complete and Correct Emulation, 
which would be given the exact same input to the version of HHH that 
never aborts, and since the pairing of DDD to HHH creates a different 
DDD for each input, that means that we don't have this non-aborting HHH 
look at the DDD that calls the n\on-aborting HHH, but the DDD that calls 
the HHH that did abort after the finite number of steps. (And if you 
can't build that test, you are just proving your system is not Turing 
Complete, and thus not suitable for trying to use for the halting problem.

This emulation, will, BY DEFINITION, see exactly what the dirrect 
execution of DDD does (or even your non-aborting HHH doesn't correctly 
emulate its input), will see DDD call HHH, then, by your definition, 
that HHH doing some emulation, and then after that finite number of 
steps emulated, will abort its emulation and return to DDD and that DDD 
will reach its final state and be halting

THus, we have just proved that for every HHH that emulates from 0 to a 
arbitrary large finite number of steps of DDD correctly, and then return 
0, while its emulation doesn't reach the final return instruction, the 
COMPLETE CORRECT emulation of the same input does, as does the direct 
execution of the machine that the input represents.

Thus, your claimed "tautology" is a incorrect statement for all but one 
case, that of an HHH that emulates an INFINITE number of steps 
correctly, but that HHH can never answer about the behavior of its 
input, so is not a correct halt decider either.