Deutsch   English   Français   Italiano  
<vvsa1a$104j2$1@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!news.misty.com!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: Mikko <mikko.levanto@iki.fi>
Newsgroups: comp.theory
Subject: Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD)
Date: Mon, 12 May 2025 11:03:54 +0300
Organization: -
Lines: 129
Message-ID: <vvsa1a$104j2$1@dont-email.me>
References: <vv97ft$3fg66$1@dont-email.me> <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> <b049926b61baa5d69d11655a8af06e537b7acd71.camel@gmail.com> <vvqga9$gldn$3@dont-email.me> <41e08841caf0d628beb5105bc78531a412eea440.camel@gmail.com> <vvql3p$gldn$15@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 12 May 2025 10:03:55 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d66022cf12555db523e1c5ad57a06eab";
	logging-data="1053282"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/V4qDUvaeP8JgA4Publl0T"
User-Agent: Unison/2.2
Cancel-Lock: sha1:QFdbWFf/x5w79U8CthtxYIMycu0=
Bytes: 6712

On 2025-05-11 17:00:41 +0000, olcott said:

> 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⟩.

Which is irrelevant as from that you can't infer whether the input
specifies a halting computation.

-- 
Mikko