Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!news.quux.org!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: Incorrect requirements --- Computing the mapping from the input
 to HHH(DD)
Date: Sun, 11 May 2025 07:03:27 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <bd98b08c432b1bd38ae49288dffac3f66c55549a@i2pn2.org>
References: <vv97ft$3fg66$1@dont-email.me> <vvnsae$3in62$9@dont-email.me>
 <11cc09876004107c47467b9481f614f45f450f2c.camel@gmail.com>
 <vvnu9k$3k258$2@dont-email.me>
 <674a661e498281cca55b322cbd5905a1988a6171.camel@gmail.com>
 <vvnvut$3kher$3@dont-email.me>
 <088556c03067d8de7184bf88dd01cc6b8c99ba1b.camel@gmail.com>
 <vvo1ni$3l14p$1@dont-email.me>
 <c09f468e8485c22150cedb12a9010b401f292054.camel@gmail.com>
 <vvo58a$3lnkd$1@dont-email.me>
 <dc76ef3215a83481dfddc40c466bb9ebc0e77341.camel@gmail.com>
 <vvo709$3m1oc$1@dont-email.me>
 <b503e969e23dd1b2a6201ba78c82c9ff7906eaae.camel@gmail.com>
 <vvo9e8$3m1oc$3@dont-email.me>
 <b9cec56c1d257e09fdf8043f02f123a4243de6e1.camel@gmail.com>
 <vvoife$3ofmu$1@dont-email.me>
 <09cea75db07408dc9203aca3fb74408ad3a095b4.camel@gmail.com>
 <vvoubl$3qtsi$1@dont-email.me>
 <bc4fb153ff914177dba706ce6e0dfb467e2126eb.camel@gmail.com>
 <vvp04i$3r5li$3@dont-email.me>
 <853816e160c7b3fe75c71f0728e72989d9fb2e41.camel@gmail.com>
 <vvp1fm$3r5li$4@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 11 May 2025 11:04:07 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="4070293"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <vvp1fm$3r5li$4@dont-email.me>
Content-Language: en-US

On 5/10/25 10:19 PM, olcott wrote:
> On 5/10/2025 9:09 PM, wij wrote:
>> On Sat, 2025-05-10 at 20:56 -0500, olcott wrote:
>>> On 5/10/2025 8:44 PM, wij wrote:
>>>> On Sat, 2025-05-10 at 20:26 -0500, olcott wrote:
>>>>> On 5/10/2025 8:17 PM, wij wrote:
>>>>>> On Sat, 2025-05-10 at 17:03 -0500, olcott wrote:
>>>>>>> On 5/10/2025 4:44 PM, wij wrote:
>>>>>>>> On Sat, 2025-05-10 at 14:29 -0500, olcott wrote:
>>>>>>>>> On 5/10/2025 2:02 PM, wij wrote:
>>>>>
>>>>>>
>>>>>> You don't know the counter example in the HP proof, your D is not 
>>>>>> the case what HP says.
>>>>>>
>>>>>
>>>>> Sure I do this is it! (as correctly encoded in C)
>>>>>
>>>>> typedef void (*ptr)();
>>>>> int HHH(ptr P);
>>>>>
>>>>> int DD()
>>>>> {
>>>>>      int Halt_Status = HHH(DD);
>>>>>      if (Halt_Status)
>>>>>        HERE: goto HERE;
>>>>>      return Halt_Status;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>      HHH(DD);
>>>>> }
>>>>>
>>>>>
>>>>
>>>> Try to convert it to TM language to know you know nothing.
>>>>
>>>
>>> I spent 22 years on this. I started with the Linz text
>>>
>>> When Ĥ is applied to ⟨Ĥ⟩
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>     or
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>
>>> (a) Ĥ copies its input ⟨Ĥ⟩
>>> (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
>>> (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ ...
>>>
>>> Thus ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H
>>> cannot possibly reach its simulated final halt state
>>> ⟨Ĥ.qn⟩
>>>
>>>> To refute the HP, you need to understand what it exactly means in TM.
>>>
>>> I have known this for 22 years.
>>
>> A working TM. Build it explicitly from transition function, then explain
>> your derivation. You know nothing.
>>
> 
> That would be like examining how an operating system
> works entirely from its machine code.

And what is wrong with that?

Some parts need to be analyzed at that level.

> 
> We only have to actually know one detail:
> Every counter-example input encoded in any model
> of computation always specifies recursive simulation
> that never halts to its corresponding simulating
> termination analyzer.
> 

You are missing an important qualifier, it specifices FINITE recursive 
simulation as each level of the simulation limits how deep it will allow 
its self to go, or it just fails to meet its requirement to be a decider.

Your error is thinking that you can have as an input, claimed to be the 
same for every decider, that doesn't include the code it uses. WHen you 
include that needed code, they are no longer the "same input".

In simpler terms, your argument uses the equivalent of assume x = =, and 
then divides by x assuming that x is not equal to 0.

Sorry, your world is just based on you believing your own lies.