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: HHH(DD) --- COMPUTE ACTUAL MAPPING FROM INPUT TO OUTPUT ---
 Ignoramus !!!
Date: Sun, 4 May 2025 20:28:08 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <f2d90d4fadac1c5db862568ee016dd520dd0c884@i2pn2.org>
References: <vsnchj$23nrb$2@dont-email.me> <vth52t$3in23$9@dont-email.me>
 <vth557$3a127$7@dont-email.me> <vth8lr$3n2du$2@dont-email.me>
 <a8ab995b650b894cbfb635478f7406c4eee4d187@i2pn2.org>
 <vthqtc$5g2e$2@dont-email.me>
 <63af93cb608258cc3e12b9bab3a2efa0b7ee7eee@i2pn2.org>
 <vtit6a$15e5s$3@dont-email.me> <vtivmo$19aqd$1@dont-email.me>
 <vtkc4l$2h48g$3@dont-email.me> <vtkdnm$2iqu5$1@dont-email.me>
 <vtkkge$2si58$2@dont-email.me> <vtl56j$3aajg$1@dont-email.me>
 <vtlu0a$3vgp0$1@dont-email.me> <vtm04f$2a90$1@dont-email.me>
 <vtm9q8$aut7$1@dont-email.me> <vtmah8$2a90$2@dont-email.me>
 <vtmgen$gs48$1@dont-email.me> <vtmh1n$2a90$3@dont-email.me>
 <vto4vh$23i07$1@dont-email.me> <vto7qu$267in$1@dont-email.me>
 <vtopqv$2meit$1@dont-email.me> <vung5v$2uf19$1@dont-email.me>
 <vuo87d$3jn5n$3@dont-email.me> <vuq7bm$1gtva$1@dont-email.me>
 <vutfj1$gmbi$5@dont-email.me> <vv21pc$p89b$1@dont-email.me>
 <vv4575$2oad7$1@dont-email.me> <vv4i60$33el4$1@dont-email.me>
 <vv8b7s$2erlq$6@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 5 May 2025 00:28:32 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="3165240"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <vv8b7s$2erlq$6@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0

On 5/4/25 2:21 PM, olcott wrote:
> On 5/3/2025 2:55 AM, Mikko wrote:
>> On 2025-05-03 04:14:27 +0000, olcott said:
>>
>>> On 5/2/2025 4:03 AM, Mikko wrote:
>>>> On 2025-04-30 15:28:33 +0000, olcott said:
>>>>
>>>>> On 4/29/2025 4:49 AM, Mikko wrote:
>>>>>> On 2025-04-28 15:52:13 +0000, olcott said:
>>>>>>
>>>>>>> On 4/28/2025 4:01 AM, Mikko wrote:
>>>>>>>> On 2025-04-16 17:36:31 +0000, olcott said:
>>>>>>>>
>>>>>>>>> On 4/16/2025 7:29 AM, Richard Heathfield wrote:
>>>>>>>>>> On 16/04/2025 12:40, olcott wrote:
>>>>>>>>>>> sum(3,2) IS NOT THE SAME AS sum(5,2).
>>>>>>>>>>> IT IS EITHER STUPID OR DISHONEST FOR YOU TO TRY TO
>>>>>>>>>>> GET AWAY FOR CLAIMING THIS USING THE STRAW DECEPTION
>>>>>>>>>>> INTENTIONALLY INCORRECT PARAPHRASE OF MY WORDS.
>>>>>>>>>>
>>>>>>>>>> Whether sum(3,2) is or is not the same as sum(5,2) is not the 
>>>>>>>>>> question. The question is whether a universal termination 
>>>>>>>>>> analyser can be constructed, and the answer is that it can't.
>>>>>>>>>>
>>>>>>>>>> This has been rigorously proved. If you want to overturn the 
>>>>>>>>>> proof you've got your work cut out to persuade anyone to 
>>>>>>>>>> listen, not least because anyone who tries to enter into a 
>>>>>>>>>> dialogue with you is met with contempt and scorn.
>>>>>>>>>>
>>>>>>>>>> The proof stands.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *corresponding output to the input*
>>>>>>>>> *corresponding output to the input*
>>>>>>>>> *corresponding output to the input*
>>>>>>>>> *corresponding output to the input*
>>>>>>>>> *corresponding output to the input*
>>>>>>>>>
>>>>>>>>> Not freaking allowed to look at any damn thing
>>>>>>>>> else besides the freaking input. Must compute whatever
>>>>>>>>> mapping ACTUALLY EXISTS FROM THIS INPUT.
>>>>>>>>
>>>>>>>> A halt decider is is not allowed to compute "whatever" mapping. 
>>>>>>>> It is
>>>>>>>> required to compute one specific mapping: to "no" if the 
>>>>>>>> computation
>>>>>>>> described by the input can be continesd forever without halting, to
>>>>>>>> "no" otherwise.
>>>>>>>
>>>>>>> It must do this by applying the finite string transformation
>>>>>>> rules specified by the x86 language to the input to HHH(DD).
>>>>>>
>>>>>> No, it needn't. A halt decider cannot do other than certain finite 
>>>>>> string
>>>>>> operations. No relation to x86 language is required.
>>>>>>
>>>>>>> This DOES NOT DERIVE THE BEHAVIOR OF THE DIRECTLY EXECUTED DD.
>>>>>>
>>>>>> Whether the execution is "direct" or otherwise is irrelevant. A 
>>>>>> computation
>>>>>> either halts or not. A halt decider must just tell whether the 
>>>>>> somputation
>>>>>> halts. It is true that no Turing machine can determine this about 
>>>>>> every
>>>>>> computation, i.e., no Turing machine is a halt decider.
>>>>>>
>>>>>>> It DOES DERIVE DD EMULATED BY HHH AND ALSO DERIVES THE RECURSIVE
>>>>>>> EMULATION OF HHH EMULATING ITSELF EMULATING DD.
>>>>>>
>>>>>> Which are not mentioned in the halting problem.
>>>>>
>>>>> When understand rather than simply ignore the HHH/DD
>>>>> example it can be seen that every conventional halting
>>>>> problem proof suffers the same fate.
>>>>
>>>> That you (or some other people) don't understand the proof is not 
>>>> fatal.
>>>>
>>>>> The contradictory part of the "impossible" input IS NEVER REACHABLE.
>>>>>
>>>>> int DD()
>>>>> {
>>>>>    int Halt_Status = HHH(DD);
>>>>>    if (Halt_Status)
>>>>>      HERE: goto HERE;
>>>>>    return Halt_Status;
>>>>> }
>>>>
>>>> It is unless HHH never returns.
>>>
>>> HHH cannot possibly return to any DD correctly
>>> emulated by HHH.
>>
>> In that case what I said is true. Another way to say the same is that
>> if you can determine that the above DD does not execute the "if" line
>> you can infer that HHH(DD) does not return and therefore HHH is not a
>> halt decider (nor any other decder).
>>
> 
> That would be true IFF (if and only if) the directly
> executed HHH did not see that DD has caused its emulated
> self to get stuck in recursive emulation.

No, it can't see that, as that isn't what happens, as HHH is, and can 
onoy be, the one and only HHH that is defined in Halt7.c, which you have 
stipulated as part of the problem.


> 
> HHH(DD) does see this and rejects its input on that basis.
> 

And is wrong, as that isn't the HHH that DD calls, that HHH deosn't get 
stuck but always aborts and returns.

This means your HHH(DD) is just like your sum(2,3) thinking it was given 
5 and 7 and returning 12. Those weren't the inputs. The input DD calls 
an HHH that WILL abort and return 0, so HHH is just incorrect to not 
consider that.

The fact that you made the logical error when you designed HHH, just 
makes HHH incorect, and you are bad programmer that doesn't understand 
logic.