Path: ...!2.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott2@gmail.com>
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 11:14:06 -0600
Organization: A noiseless patient Spider
Lines: 76
Message-ID: <uscsku$15f5l$1@dont-email.me>
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>
 <uscl31$13k1e$3@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 17:14:06 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="991a76fa9aa76d17f8f6286f1a0a882d";
	logging-data="1227957"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/yB+ixjGvztdOCoB107Wol"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:jrnkCl9iO/934jQu4zZtxhWHvCI=
Content-Language: en-US
In-Reply-To: <uscl31$13k1e$3@dont-email.me>
Bytes: 4997

On 3/7/2024 9:05 AM, immibis wrote:
> On 7/03/24 06:23, Mike Terry wrote:
>> On 06/03/2024 23:59, immibis wrote:
>>> 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.
> 
> Last time I paid attention to what Olcott was saying about this 
> scenario, I think he said something like "the non-halting result 
> reported by H is correct, since D(D) never halts unless aborted." 

One of the leading experts on these things MIT professor Michael Sipser
agreed. Because this is unconventional I have adapted my view to be
more conventional.

H1(D,D) and H(D,D) both correctly report:
Can you continue to simulate your input without ever aborting it?

This results in H1(D,D) correctly reporting on the actual behavior
of the directly executed D(D) and H(D,D) incorrectly reporting on the
actual behavior of the directly executed D(D).

> and 
> then a lot of electrons were wasted trying to persuade Olcott that H was 
> supposed to return based on whether the "direct execution" of D(D) 
> "actually halts", not whether the "simulation" of D(D) "never halts 
> unless aborted."
> 
>> 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.  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.
> 
> Halting deciders are allowed to do anything they want with their input 
> programs, such as doing correct simulations, or incorrect simulators, or 
> counting the length to see if it's a prime number. However, Olcott's 
> argument was based on the premise that a correct simulation was 
> involved. This is invalid since the simulation is not actually correct, 
> and trying to hide the incorrectness - "cheating" - does not make it 
> actually a correct one.
> 

It is an easily fact that a correct and complete simulation of
the input to H(D,D) and the input to Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ cannot possibly halt.

> The mistake/cheating isn't that the simulation is incorrect (that's 
> allowed) - it's that the simulation is incorrect but the argument is 
> based on it being correct. That's why recently I got more careful by 
> saying "you failed to do the Linz procedure" instead of "you are cheating".

The lack of a complete understanding of what I am saying
never was any rebuttal what-so-ever.

-- 
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer