Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: immibis <news@immibis.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 16:05:05 +0100
Organization: A noiseless patient Spider
Lines: 50
Message-ID: <uscl31$13k1e$3@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 7 Mar 2024 15:05:05 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="721206688087f3d939b9cd1e9d62ce12";
	logging-data="1167406"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+VH3IVkCIrMfqbbRpR+fpO"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:9dtFVUq+Hse3rJlXviHuKLtySOs=
In-Reply-To: <c-GcnbJk3KPt0nT4nZ2dnZfqn_GdnZ2d@brightview.co.uk>
Content-Language: en-US
Bytes: 3982

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

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