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:52:53 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <d912d471444aeeb54f53f43c6aacac556614fb5a@i2pn2.org>
References: <v8jh7m$30k55$1@dont-email.me> <v8kou4$3b2ta$1@dont-email.me>
 <v8lcir$3f6vr$4@dont-email.me> <v8ldcs$3fcgg$2@dont-email.me>
 <v8lem0$3ftpo$2@dont-email.me>
 <735401a612caec3eedb531311fd1e09b3d94521d@i2pn2.org>
 <v8lkdb$3h16a$1@dont-email.me>
 <5ee8b34a57f12b0630509183ffbd7c07804634b3@i2pn2.org>
 <v8ll4v$3h8m2$1@dont-email.me>
 <cbde765b8f9e769930b6c8589556907a41d9c256@i2pn2.org>
 <v8lm80$3h8m2$3@dont-email.me> <v8n6mq$3tv07$3@dont-email.me>
 <v8o14v$30uf$1@dont-email.me>
 <950d4eed7965040e841a970d48d5b6f417ff43dc@i2pn2.org>
 <v8oj1n$6kik$3@dont-email.me> <v8pvke$ih0a$1@dont-email.me>
 <4-qdnbdw1JzlRS37nZ2dnZfqlJydnZ2d@giganews.com>
 <v8v7p3$29r2r$1@dont-email.me> <v8vub1$32fso$14@dont-email.me>
 <1e1fa9bc4bbc00aa65c1a7974bd1bda87687c92b@i2pn2.org>
 <v90di8$38oni$1@dont-email.me>
 <47a76378d634bf0db4017f879d0160793b57125e@i2pn2.org>
 <v9161o$3gaju$1@dont-email.me>
 <b84374e766c199e1ba38ef1dc3bc8f6ab2c39dfc@i2pn2.org>
 <v92g8f$p1$1@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:52:53 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="1932052"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US
In-Reply-To: <v92g8f$p1$1@dont-email.me>
Bytes: 7739
Lines: 132

On 8/8/24 9:12 AM, olcott wrote:
> On 8/7/2024 8:22 PM, Richard Damon wrote:
>> On 8/7/24 9:12 PM, olcott wrote:
>>> On 8/7/2024 8:03 PM, Richard Damon wrote:
>>>> On 8/7/24 2:14 PM, olcott wrote:
>>>>> On 8/7/2024 1:02 PM, joes wrote:
>>>>>> Am Wed, 07 Aug 2024 08:54:41 -0500 schrieb olcott:
>>>>>>> On 8/7/2024 2:29 AM, Mikko wrote:
>>>>>>>> On 2024-08-05 13:49:44 +0000, olcott said:
>>>>>>
>>>>>>>> I know what it means. But the inflected form "emulated" does not 
>>>>>>>> mean
>>>>>>>> what you apparently think it means. You seem to think that "DDD
>>>>>>>> emulated by HHH" means whatever HHH thinks DDD means but it does 
>>>>>>>> not.
>>>>>>>> DDD means what it means whether HHH emulates it or not.
>>>>>>>>
>>>>>>> In other words when DDD is defined to have a pathological 
>>>>>>> relationship
>>>>>>> to HHH we can just close our eyes and ignore it and pretend that it
>>>>>>> doesn't exist?
>>>>>> It doesn't change anything about DDD. HHH was supposed to decide 
>>>>>> anything
>>>>>> and can't fulfill that promise. That doesn't mean that DDD is somehow
>>>>>> faulty, it's just a counterexample.
>>>>>>
>>>>>
>>>>> void DDD()
>>>>> {
>>>>>    HHH(DDD);
>>>>>    return;
>>>>> }
>>>>>
>>>>> *HHH is required to report on the behavior of DDD*
>>>>> Anyone that does not understand that HHH meets this criteria
>>>>> has insufficient understanding.
>>>>
>>>> But it doesn't, as a correct simulation of a DDD that calls an HHH 
>>>> that returns will stop running, 
>>>
>>> I really think that you must be a liar here because
>>> you have known this for years:
>>>
>>> On 8/2/2024 11:32 PM, Jeff Barnett wrote:
>>>  > ...In some formulations, there are specific states
>>>  >    defined as "halting states" and the machine only
>>>  >    halts if either the start state is a halt state...
>>>
>>>  > ...these and many other definitions all have
>>>  >    equivalent computing prowess...
>>>
>>> Anyone that knows C knows that DDD correctly simulated
>>> by any HHH cannot possibly reach its "return" {halt state}.
>>>
>>
>> But the problem is that you HHH ODESN'T correctly emulate the DDD it 
>> is given, because it aborts its emulation.
>>
> 
> Each HHH of every HHH that can possibly exist definitely
> *emulates zero to infinity instructions correctly* In
> none of these cases does the emulated DDD ever reach
> its "return" instruction halt state.

Nope, proven wrong, see below.

> 
> *There are no double-talk weasel words around this*
> *There are no double-talk weasel words around this*
> *There are no double-talk weasel words around this*

Nope, your arguments are JUST double-talk weasel words.

> 
> There is no need to show any execution trace at the x86 level
> every expert in the C language sees that the emulated DDD
> cannot possibly reaches its "return" instruction halt state.

So, you are just admiting you can't show the correct simulation that you 
are doing. Since it is proven that the every DDD (except the one that 
calls a non-aborting HHH) will halt, it proves your claim just a lie.

> 
> Every rebuttal that anyone can possibly make is necessarily
> erroneous because the first 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.