| Deutsch English Français Italiano |
|
<7806f6800c722a6f0d396e11bcc8d651ffcb3344@i2pn2.org> View for Bookmarking (what is this?) Look up another Usenet article |
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: Sat, 10 May 2025 22:12:38 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <7806f6800c722a6f0d396e11bcc8d651ffcb3344@i2pn2.org>
References: <vv97ft$3fg66$1@dont-email.me> <vvno4e$3in62$2@dont-email.me>
<5b14da4260c0b7e3235ce05f752c092fade4d70e.camel@gmail.com>
<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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 11 May 2025 02:12:47 -0000 (UTC)
Injection-Info: i2pn2.org;
logging-data="4019478"; mail-complaints-to="usenet@i2pn2.org";
posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <vvp04i$3r5li$3@dont-email.me>
On 5/10/25 9:56 PM, 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
You mean you have wasted 22 years on this.
>
> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Missing the qualification, if Ĥ ⟨Ĥ⟩ will halt
> or
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Missing the qualification, if Ĥ ⟨Ĥ⟩ will not halt
And those qualifications are based on H being correct.
>
> (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⟩
but step (c) will stop after some finite time when embedded_H does the
exact same process as H did when it reaches it conclusion (which it
follows exactly as it is exactly the same algorithm on the same data) at
which point it will stop and go to Qn and Ĥ ⟨Ĥ⟩ will halt, thus showing
that H returned the wrong answer for H ⟨Ĥ⟩ ⟨Ĥ⟩, as in this case, to be
correct H should have ended up in Qy instead of Qn.
>
>> To refute the HP, you need to understand what it exactly means in TM.
>
> I have known this for 22 years.
No, and you still don't as far as everything you have said.
You confuse where the requirements are, and even ignore and drop them
becuase of your ignorance.
You don't seem to understand that programs are deteministic entities
that will always do the same thing on the same input.
>
>> Assembly (or C) also work, but you need to understand more details and
>> be able to map every assembly instruction or C expressions to TM
>> language.
>> The form of the DD above (in some books maybe) is for layman to
>> understand,
>> which is not exactly the case that the HP provides. Don't be silly.
>>
>
>
>