Path: ...!weretis.net!feeder6.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory,sci.logic
Subject: Re: Refutation of the Peter Linz Halting Problem proof 2024-03-05
 --partial agreement--
Date: Thu, 7 Mar 2024 19:53:45 -0800
Organization: i2pn2 (i2pn.org)
Message-ID: <use249$15q44$6@i2pn2.org>
References: <us8shn$7g2d$1@dont-email.me> <us92f0$uvql$4@i2pn2.org>
 <us931e$8gmr$1@dont-email.me> <usa4rk$10ek4$3@i2pn2.org>
 <usa5to$gp0j$1@dont-email.me> <usa8lp$10ek5$5@i2pn2.org>
 <usa9o9$ho7b$1@dont-email.me> <usag21$118jg$1@i2pn2.org>
 <usanbu$klu7$1@dont-email.me> <usas0v$11q96$2@i2pn2.org>
 <usavq1$m7mn$1@dont-email.me> <usb01q$m897$1@dont-email.me>
 <usb0q0$m7mn$5@dont-email.me> <usb8d4$nksq$1@dont-email.me>
 <usb9e9$nkt8$4@dont-email.me> <usck1s$13k1e$2@dont-email.me>
 <uscs49$15f45$1@dont-email.me> <usdq1r$1be15$3@dont-email.me>
 <usdrjq$1bkg1$2@dont-email.me> <usdteu$15q44$1@i2pn2.org>
 <use0nb$1ga79$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 8 Mar 2024 03:53:46 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="1239172"; 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: <use0nb$1ga79$1@dont-email.me>
Bytes: 7871
Lines: 170

On 3/7/24 7:29 PM, olcott wrote:
> On 3/7/2024 8:34 PM, Richard Damon wrote:
>> On 3/7/24 6:02 PM, olcott wrote:
>>> On 3/7/2024 7:35 PM, immibis wrote:
>>>> On 7/03/24 18:05, olcott wrote:
>>>>> On 3/7/2024 8:47 AM, immibis wrote:
>>>>>> On 7/03/24 03:40, olcott wrote:
>>>>>>> On 3/6/2024 8:22 PM, immibis wrote:
>>>>>>>> On 7/03/24 01:12, olcott wrote:
>>>>>>>>> On 3/6/2024 5:59 PM, immibis wrote:
>>>>>>>>>> On 7/03/24 00:55, olcott wrote:
>>>>>>>>>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn
>>>>>>>>>>> Correctly reports that Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ must abort its simulation.
>>>>>>>>>>>
>>>>>>>>>>> H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>>>>> Correctly reports that H ⟨Ĥ⟩ ⟨Ĥ⟩ need not abort its simulation.
>>>>>>>>>>
>>>>>>>>>> What are the exact steps which the exact same program with the 
>>>>>>>>>> exact same input uses to get two different results?
>>>>>>>>>> I saw x86utm. In x86utm there is a mistake because Ĥ.H is not 
>>>>>>>>>> defined to do exactly the same steps as H, which means you 
>>>>>>>>>> failed to do the Linz procedure.
>>>>>>>>>
>>>>>>>>> Both H(D,D) and H1(D,D) answer the exact same question:
>>>>>>>>> Can I continue to simulate my input without ever aborting it?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Both H(D,D) and H1(D,D) are computer programs (or Turing 
>>>>>>>> machines). They execute instructions (or transitions) in 
>>>>>>>> sequence, determined by their programming and their input.
>>>>>>>
>>>>>>> Yet because they both know their own machine address
>>>>>>> they can both correctly determine whether or not they
>>>>>>> themselves are called in recursive simulation.
>>>>>>
>>>>>> They cannot do anything except for exactly what they are 
>>>>>> programmed to do.
>>>>>
>>>>> H1(D,D) and H(D,D) are programmed to do this.
>>>>> Because H1(D,D) simulates D(D) that calls H(D,D) that
>>>>> aborts its simulation of D(D). H1 can see that its
>>>>> own simulated D(D) returns from its call to H(D,D).
>>>>>
>>>>>>>
>>>>>>> An Olcott machine can perform an equivalent operation.
>>>>>>>
>>>>>>> Because Olcott machines are essentially nothing more than
>>>>>>> conventional UTM's combined with Conventional Turing machine
>>>>>>> descriptions their essence is already fully understood.
>>>>>>>
>>>>>>> The input to Olcott machines can simply be the conventional
>>>>>>> space delimited Turing Machine input followed by four spaces.
>>>>>>>
>>>>>>> This is followed by the machine description of the machine
>>>>>>> that the UTM is simulating followed by four more spaces.
>>>>>>
>>>>>> To make the Linz proof work properly with Olcott machines, Ĥ 
>>>>>> should search for 4 spaces, delete its own machine description, 
>>>>>> and then insert the description of the original H. Then the Linz 
>>>>>> proof works for Olcott machines.
>>>>>
>>>>> That someone can intentionally break an otherwise correct
>>>>> halt decider
>>>>
>>>> It always gives exactly the same answer as the working one, so how 
>>>> is it possibly broken?
>>>>
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does not halt
>>>
>>> When this is executed in an Olcott machine then
>>> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> is a different computation than H ⟨Ĥ⟩ ⟨Ĥ⟩ <H>
>>
>> WHY?
>>
>> The Master UTM will not change the usage at H^.H, because that is just 
>> an internal state of the Machine H^
>>
> 
> The ONLY thing that the master UTM does differently is append
> the TMD to the TMD's own tape.

Right, so it gives H and H^ that input.

H^ can erase that input and replace it.

> 
>> At that point we have the IDENTICAL set of transitions (with just an 
>> equivalence mapping of state numbers) as H will have, and the EXACT 
>> same input as H
> 
> it is stipulated by the definition of Olcott machines
> Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> // last element is <Ĥ> (not H)

Nope.

H^.H isn't a "Olcott Machine" it is a sub-machine of H^

Your Master UTM can't touch the tape here or it totally breaks the system.

It can only add the description at the beginning, as it doesn't know 
what state in that machine are "sub-machines" and what are just parts of 
the machine running.

You don't seem to understand much about Turing machines.

I seem to remember you bailed out after like the first part of the first 
lesson.

>    H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> // last element is <H> (not Ĥ)
> That the last element of the input to Ĥ.H and H <is> different.
> 

Until the code in H^ between q0 and H^.H changes it.

>>>
>>> No matter how Ĥ ⟨Ĥ⟩ screws itself up this can have no
>>> effect on H ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>
>>> The Olcott machine H ⟨Ĥ⟩ ⟨Ĥ⟩ <H> can see that it does not
>>> call itself in recursive simulation.
>>
>> As will the machine at H^.H, since the description it thinks it is 
>> doesn't match the machine that gets called.
> 
> A simply string comparison of the finite strings
> ⟨Ĥ⟩ and <Ĥ> proves that they are the same.
> 
>>>
>>> The Olcott machine Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ <Ĥ> can see that it calls
>>> itself in recursive simulation unless it discards this
>>> ability. In either case it cannot fool H, it either halts
>>> or fails to halt.
>>>
>>
>> But that isn't what H^.H gets called with.
> 
> Olcott machines always append the TMD to the end of the tape
> of this TMD.
So H^ STARTS with <H^> at the end. The Tape, BY DEFINITION, is writable.

That is sort of one problem with your x86UTM, its "tape" equivalent was 
Read Only since it was executable code space.

> 
> This means that they are an actual input to every TMD that
> does not ignore them.

Right, and H^ can change it.

> 
>>
>> The code between H^.q0 and H^.H removes the <H^> and replaces it with 
>> <H>, so the copy of H at H^.H can't tell the difference.
>>
> 
> Ĥ cannot possibly do this because it has no access to nor
> even knows the existence of any external ⟨H⟩.

Of course it know about the ONE H that it is on a mission to make wrong.

So that H, and only that H gets confonded.

You sure seem dumb about that.

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