Path: ...!3.us.feeder.erje.net!feeder.erje.net!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 10:10:24 -0800
Organization: i2pn2 (i2pn.org)
Message-ID: <uscvug$14o2s$7@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>
 <c-GcnbJk3KPt0nT4nZ2dnZfqn_GdnZ2d@brightview.co.uk>
 <87cys6i7da.fsf@bsb.me.uk> <uscnu1$14gm6$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 7 Mar 2024 18:10:25 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="1204316"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US
In-Reply-To: <uscnu1$14gm6$1@dont-email.me>
Bytes: 6892
Lines: 132

On 3/7/24 7:53 AM, olcott wrote:
> On 3/7/2024 5:55 AM, Ben Bacarisse wrote:
>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>
>>> On 06/03/2024 23:59, 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.
>>>
>>> Not sure if we're discussing a general H here, or PO's H/Ĥ under his
>>> x86utm.  (Ĥ is called D under x86utm.)
>>>
>>> Under x86utm, Ĥ.H is implemented as a call to H from D, whilst H in
>>> implemented as a call to H from main.  So we would expect stack 
>>> addresses
>>> to differ, but for that not to affect the computation.
>>>
>>> In both cases, H:
>>> -  simulates D(D) computation
>>> -  spots PO's unsound "infinite recursion" pattern
>>> -  announces it has encountered infinite recursion
>>> -  returns 0  [non-halting]
>>>
>>> So Ĥ.H does exactly the same steps as H, and reports the same result, as
>>> required for Linz proof. And just as Linz proof proves, the result 
>>> reported
>>> by H is incorrect, since D(D) halts.  I have compared the instructions
>>> executed by both H/Ĥ and THEY ARE EXACTLY THE SAME.  (In the region 
>>> of 1000
>>> or so machine instructions, including the handful of simulated
>>> instructions.  Obviously stack addresses differ.  If required I could 
>>> post
>>> the output log but its quite long.]
>>>
>>> So... in this case the exact same program is given the exact same 
>>> input and
>>> gets the exact same result as Linz logic requires, and the outcome is
>>> exactly what Linz says.  There is really no mystery here that needs
>>> explaining by faulty coding/cheating with simulations on PO's part.
>>
>> Yes, this was the crystal clear case that led PO to answer:
>>
>> | do you still assert that H(P,P) == false is the "correct" answer even
>> | though P(P) halts?
>>
>> PO: Yes that is the correct answer even though P(P) halts.
>>
>> I think your analysis of the traces was a key part of getting that clear
>> statement from him.
>>
> 
> H(D,D) could never provide a return value consistent with the direct
> execution of D(D) because it must abort its simulation or it cannot
> report at all. From the POV of H(D,D) D(D) does not halt.

There is no "POV" of H that says does not halt. All H sees is that it 
didn't halt yet, and I see I am walking into a possible trap.

> 
>  From the POV of external observers D(D) does halt. H1(D,D)
> is one such external observer.
> 
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does not halt
> 
> Since no Turing machine can actually call another the results
> that we get from the Linz proof are more applicable.

So, you are now agreeing with Linz?

> 
>>> The HH/DD case is different, as that coding is completely broken by 
>>> misuse
>>> of global variables to divert the course of the code under the 
>>> simulator.
> 
> Olcott Machines are totally derived From Turing Machines
> thus all of their aspects have been fully understood.
> 
> An Olcott machine is merely an ordinary UTM paired
> with an arbitrary Turing Machine Description (TMD).
> 
> This UTM always appends the TMD to the end of the
> TMD's own tape. The TMD is free to access its TMD
> or ignore it.
> 
> This provides each TMD with the functional equivalent
> of knowing their own machine address.

Except for all the problems presented that you are just ignoring, 
showing you are just totally ignorant of the field you are talking about.

> 
>>> But since EVEN WHEN THINGS WORK EXACTLY AS PO WANTS his results are in
>>> AGREEMENT with Linz, it seems to me that arguing that his problem is
>>> relating to cheating with the simulation is kind of missing the 
>>> point.  Um,
>>> not to say there's much point arguing with PO even if making perfectly
>>> "on-point" arguments!  It all makes no difference to PO... :)
>>
>> The irony here is that if one cheats it's possible to have H(D,D) (in
>> main, say) return 1 and yet have D(D) halt.  This can be done with D
>> constructed as usual.  It's only H that needs the cheat.  So to his
>> credit, he is not cheating, just totally at sea.
>>
> 
> When you understand the details you will understand
> that I am correct.
> 

No, we see that you are just an ignorant talking head babbling 
incoherently about things that they don't understand.

The fact that you can't see this just show how good you were at 
gas-lighting yourself into beleiving your lies so you have no interest 
in learning the truth.

This shows that all of you work just needs to be ignored, as it is just 
infiltrated with your lies.

This becomes very obvious when you keep on describing results and then 
say, it must be possible to create a machine to do this, without even 
questioning if it is possible.