Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: dbush <dbush.mobile@gmail.com>
Newsgroups: comp.theory
Subject: Re: Incorrect requirements --- Computing the mapping from the input
 to HHH(DD)
Date: Sun, 11 May 2025 16:21:13 -0400
Organization: A noiseless patient Spider
Lines: 234
Message-ID: <vvr0ro$k1ua$1@dont-email.me>
References: <vv97ft$3fg66$1@dont-email.me> <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>
 <b049926b61baa5d69d11655a8af06e537b7acd71.camel@gmail.com>
 <vvqga9$gldn$3@dont-email.me>
 <41e08841caf0d628beb5105bc78531a412eea440.camel@gmail.com>
 <vvql3p$gldn$15@dont-email.me>
 <cb999b6746607a1445c196e485a2c1124eaee8b5.camel@gmail.com>
 <vvqnev$i5d0$3@dont-email.me>
 <07c4f2302645a7e58957b5e5bffed80397a6ddae.camel@gmail.com>
 <vvr0ot$k9nu$1@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 22:21:13 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="aad4969e8ca95f1c06ff9de97da90e9e";
	logging-data="657354"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18r+5Lt9QGELCxx0TQX3CNR"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:favgX35pfUjjcFbiwNr0nYLXlTM=
Content-Language: en-US
In-Reply-To: <vvr0ot$k9nu$1@dont-email.me>
Bytes: 10999

On 5/11/2025 4:19 PM, olcott wrote:
> On 5/11/2025 1:38 PM, wij wrote:
>> On Sun, 2025-05-11 at 12:40 -0500, olcott wrote:
>>> On 5/11/2025 12:21 PM, wij wrote:
>>>> On Sun, 2025-05-11 at 12:00 -0500, olcott wrote:
>>>>> On 5/11/2025 11:28 AM, wij wrote:
>>>>>> On Sun, 2025-05-11 at 10:38 -0500, olcott wrote:
>>>>>>> On 5/11/2025 9:34 AM, wij wrote:
>>>>>>>> On Sat, 2025-05-10 at 21:19 -0500, 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.
>>>>>>>>
>>>>>>>> You are refuting a CS foundamental theorem (i.e. HP) officially.
>>>>>>>> So, yes, and actually MORE need to be done (beyond your 
>>>>>>>> imagination).
>>>>>>>>
>>>>>>>> Knowing a car or smart phone,... is far different from making one.
>>>>>>>> Knowing E=mc^2 is far from knowing relativity, making A-bomb 
>>>>>>>> (actually, making
>>>>>>>> A-bomb don't need to know E=mc^2, people are often fooled by 
>>>>>>>> popular saying)
>>>>>>>> Every chapter of Linz's book, C text textbook has exercises, you 
>>>>>>>> need to those
>>>>>>>> exercises AT LEAST to comment CS (and computation theory is more 
>>>>>>>> advanced topic
>>>>>>>> than TM). Saying so is because we know you can't do the exercise 
>>>>>>>> and boast lots
>>>>>>>> about TM stuff (and pretty much anything else from just reading 
>>>>>>>> words), even
>>>>>>>> about theorem.
>>>>>>>>
>>>>>>>
>>>>>>> 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 ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>
>>>>>>> All that I need to know is that I proved that
>>>>>>> embedded_H correctly recognizes the repeating
>>>>>>> pattern where its correctly simulated ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>> cannot possibly reach its own simulated final
>>>>>>> halt state of ⟨Ĥ.qn⟩
>>>>>>>
>>>>>>> https://www.liarparadox.org/Linz_Proof.pdf
>>>>>>>
>>>>>>>>> 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.
>>>>>>>>
>>>>>>>> More example here that you don't understand nearly all CS terms.
>>>>>>>>
>>>>>>>
>>>>>>> Mere empty rhetoric entirely bereft of any supporting
>>>>>>> reasoning. The x86 language is comparable to a RASP
>>>>>>> machine that is equivalent to a Turing machine.
>>>>>>
>>>>>> Question:
>>>>>> 1. Do you understand that you can't do the exercises in Linz's book?
>>>>>
>>>>> Everything is 100% irrelevant besides the fact that
>>>>> I have shown that ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by
>>>>> embedded_H cannot possibly reach its own simulated
>>>>> final halt state ⟨Ĥ.qn⟩. Thus when embedded_H reports
>>>>> on the behavior that its input specifies it can
>>>>> correctly transition to Ĥ.qn.
>>>>>
>>>>>> 2. Do you understand your ability of C/assembly/TM is less than 1 
>>>>>> year CS level?
>>>>>>
>>>>>
>>>>> I construe C as high level assembly language thus
>>>>> disregard any inessentials. No change since K & R
>>>>> is of any use to me. I write C++ the same way. I
>>>>> use it as C with classes. I also use std::vector a lot.
>>>>
>>>> Q3. If people know the capability of the author of POOH is less than 
>>>> 1 year CS
>>>>       level. How persuasive and reliable of POOH do you think it 
>>>> would be?
>>>>
>>>> Q4: Why no one can reproduce the result of POOH for these 22? years?
>>>>
>>>>
>>>
>>> _DDD()
>>> [00002172] 55         push ebp      ; housekeeping
>>> [00002173] 8bec       mov  ebp,esp  ; housekeeping
========== REMAINDER OF ARTICLE TRUNCATED ==========