Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory
Subject: Re: Incorrect requirements --- Computing the mapping from the input
 to HHH(DD)
Date: Sun, 11 May 2025 12:40:47 -0500
Organization: A noiseless patient Spider
Lines: 161
Message-ID: <vvqnev$i5d0$3@dont-email.me>
References: <vv97ft$3fg66$1@dont-email.me> <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>
 <b049926b61baa5d69d11655a8af06e537b7acd71.camel@gmail.com>
 <vvqga9$gldn$3@dont-email.me>
 <41e08841caf0d628beb5105bc78531a412eea440.camel@gmail.com>
 <vvql3p$gldn$15@dont-email.me>
 <cb999b6746607a1445c196e485a2c1124eaee8b5.camel@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 11 May 2025 19:40:48 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="ef7faca461217fa132b1f53eef89d0be";
	logging-data="595360"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+1UHDxF2Zrk5c5hhX5MbJ4"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:IYAfyXsz+P8qf8cyAp9o0zEVufQ=
In-Reply-To: <cb999b6746607a1445c196e485a2c1124eaee8b5.camel@gmail.com>
X-Antivirus-Status: Clean
Content-Language: en-US
X-Antivirus: Norton (VPS 250511-4, 5/11/2025), Outbound message

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
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add  esp,+04
[00002182] 5d         pop  ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

All anyone need do to show that I am wrong
is provide the steps where DDD emulated by
HHH according to the rules of the x86 language
reaches its own emulated "ret" instruction.

Because no one can actually correctly show any
mistake in the above they resort to rhetoric
because that have no actual reasoning.

========== REMAINDER OF ARTICLE TRUNCATED ==========