Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Mike Terry <news.dead.person.stones@darjeeling.plus.com>
Newsgroups: comp.theory
Subject: Re: What. A. Slog.
Date: Wed, 14 May 2025 20:06:08 +0100
Organization: A noiseless patient Spider
Lines: 47
Message-ID: <1002pj0$2ldvf$1@dont-email.me>
References: <1001fms$29d3f$1@dont-email.me> <1002l5k$2ke1m$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 14 May 2025 21:06:09 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="4e231014b4bda2c2ebd2afa0b5bf7250";
	logging-data="2799599"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19sejzT3y037ilnuyxZ2UYFCWSNRgCSmGA="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 SeaMonkey/2.53.18.2
Cancel-Lock: sha1:EFSGQeRpIyJqq7OdAGZZZea2ZSQ=
In-Reply-To: <1002l5k$2ke1m$1@dont-email.me>

On 14/05/2025 18:50, Mike Terry wrote:
> On 14/05/2025 08:11, vallor wrote:
>> Spent a couple of hours reading back the last few days of posts.  Huboy,
>> what a train wreck.  (But like a train wreck, it's hard to look
>> away, which might explain how this has been going on for 20(?) years.)
>>
>> I want to thank both Richard's, wij, dbush, Mike, Keith, Fred,
>> Mikko, and anybody else I've forgotten for trying to explain to
>> Mr. Olcott and Mr. Flibble how you all see their claims.  I wanted to
>> point out three things:
>>
>> a) Mr. Olcott claims his HHH simulator detects an non-terminating
>> input and halts.  But others (I forget who) report that -- due
>> to a bug -- D would actually terminate on its own.  His HHH
>> simulator therefore gives the wrong answer.
> 
> Not really due to a bug.  D actually /does/ terminate on its own, and that's a consequence of PO's 
> intended design.  (Yes, there are bugs, but D's coding is what PO intended.)
> 
Hmm, I thought some more about this.  What's considered a bug (rather than e.g. a design error) is 
entirely dependent on the program's specification.  It seems perfectly reasonable to say the spec. 
for HHH is to decide whether the computation represented by its input halts.  That's the HP 
specification, and PO is discussing halt deciders (or perhaps a "partial halt decider" but the spec 
covering input DD will be the same).

Accepting that specification, PO's HHH deviates from spec. when given input DD, so that can be filed 
under "bug".  The source of the misbehaviour is not the simulation code, but rather one of the 
specific tests HHH applies for non-halting, viz PO's "infinite recursive emulation" test.  That test 
is unsound, so we've found the bug!  The problem is there's no alternative test it can be changed to 
in order to fix the bug.  And it is the test which PO thought up many years ago, and probably sent 
him down the whole HP proof refutation path...

If this test were simply deleted from HHH to give a new HHH2, then HHH2 processing HHH2's 
corresponding new DD2 would never return, but that is also a violation of the HP spec, so there must 
still be some bug in the new HHH2, right?  PO might reason that to fix the "non-halting" bug he HAS 
TO introduce his unsound non-halting test (or similar), AND SO THE NON-HALTING TEST IS CORRECT. 
That's nonsense of course and PO has been told.

We might say "HHH2 never halts, due to a bug", and that seems technically correct as above, but then 
like the original HHH "bug" there's still no conceivable fix for it.

In the end, the HP spec cannot logically be satisfied (as shown by Linz proof), so /any/ claim to 
meet that spec is sure to "contain a bug".  I'm not sure whether that's a good use for the term "bug"...


Mike.