Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: dbush <dbush.mobile@gmail.com>
Newsgroups: comp.theory
Subject: Re: Turing Machine computable functions apply finite string
 transformations to inputs VERIFIED FACT
Date: Wed, 30 Apr 2025 16:06:12 -0400
Organization: A noiseless patient Spider
Lines: 107
Message-ID: <vutvri$v5pn$7@dont-email.me>
References: <vu6lnf$39fls$2@dont-email.me>
 <65dddfad4c862e6593392eaf27876759b1ed0e69@i2pn2.org>
 <vujlj0$3a526$1@dont-email.me> <vujln7$32om9$8@dont-email.me>
 <vujmmm$3a526$2@dont-email.me> <vujmrj$32om9$9@dont-email.me>
 <vujtcb$3gsgr$1@dont-email.me> <vuju44$3hnda$1@dont-email.me>
 <vuk47o$3qkbb$1@dont-email.me> <vuk6b6$3l184$1@dont-email.me>
 <vuls34$1bf1j$4@dont-email.me> <vun87k$2m24h$2@dont-email.me>
 <vunb06$2fjjl$5@dont-email.me> <vuo57j$3h5l9$2@dont-email.me>
 <vuoath$3ljma$1@dont-email.me> <vuohgi$3td7u$1@dont-email.me>
 <vuonh6$2g74$2@dont-email.me> <vupeor$qf60$1@dont-email.me>
 <vupu0r$18vrc$1@dont-email.me> <vuqj5u$1rljg$1@dont-email.me>
 <vuql8e$1svmd$1@dont-email.me> <vur7vd$2dvvs$1@dont-email.me>
 <vur9t9$2gjif$1@dont-email.me> <vurasr$2hkih$1@dont-email.me>
 <vurbgd$2gjif$2@dont-email.me> <vurgt8$2n355$1@dont-email.me>
 <vuric8$2gjif$3@dont-email.me> <vutepm$gmbi$4@dont-email.me>
 <vutgjt$hkal$3@dont-email.me>
 <djSdneHlvK3B8Y_1nZ2dnZfqnPqdnZ2d@brightview.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 30 Apr 2025 22:06:11 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="36c3ab966607e6b458aa2826fcd1def6";
	logging-data="1021751"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+gZFuEB8QOLnlMKbboKCRj"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:+db+V/cysVofYQHFh35Ccl5QU4c=
In-Reply-To: <djSdneHlvK3B8Y_1nZ2dnZfqnPqdnZ2d@brightview.co.uk>
Content-Language: en-US

On 4/30/2025 2:30 PM, Mike Terry wrote:
> On 30/04/2025 16:46, Richard Heathfield wrote:
>> On 30/04/2025 16:15, olcott wrote:
>>> On 4/29/2025 5:03 PM, Richard Heathfield wrote:
>>>> On 29/04/2025 22:38, olcott wrote:
>>>>
>>>> <snip>
>>>>
>>>>>
>>>>> int DD()
>>>>> {
>>>>>    int Halt_Status = HHH(DD);
>>>>>    if (Halt_Status)
>>>>>      HERE: goto HERE;
>>>>>    return Halt_Status;
>>>>> }
>>>>>
>>>>> HHH is correct DD as non-halting BECAUSE THAT IS
>>>>> WHAT THE INPUT TO HHH(DD) SPECIFIES.
>>>>
>>>> You're going round the same loop again.
>>>>
>>>> Either your HHH() is a universal termination analyser or it isn't. 
>>>
>>> The domain of HHH is DD.
>>
>> Then it is attacking not the Halting Problem but the Olcott Problem, 
>> which is of interest to nobody but you.
> 
> It would be (if correct) attacking the common proof for HP theorem as it 
> occurs for instance in the Linz book which PO links to from time to time.
> 
> The proof proceeds by assuming H is a halt decider.  Then it constructs 
> from H a new TM H^ by modify H in a prescribed manner.  The proof shows 
> that H fails to correctly decide input (<H^>,<H^>):  if H(<H^>,<H^>) = 
> halts, then H^(<H^>) never halts, while if H(<H^>,<H^>) = neverhalts 
> then H^(<H^>) halts.  So H is in fact NOT a halt decider.  
> (Alternatively the proof could be taken as proving that every halt 
> decider H decides at least one input [viz H^] incorrectly.
> 
> PO claimed to have constructed a TM H, and its corresponding TM H^, such 
> that H /correctly/ decides input (<H^>,<H^>).  Since the Linz (and 
> similar) proof shows H /incorrectly/ decides that input, there would 
> clearly be some problem with proof, assuming PO's claims to be correct.
> 
> So PO's H does not need to correctly decide every input - PO does not 
> claim to have a valid halt decider.  His claim is that the Linz and 
> similar proofs are invalid, so his H just has to decide that one input 
> (<H^>,<H^>) correctly.
> 
> Well by now you must be on the edge of your seat!  How did it all turn 
> out?  Did PO in fact have the TMs he claimed?  What actually happens 
> when you run those TMs???? !   (LOL)
> 
> You'll be highly disappointed (but not too surprised) to learn:
> 1)  PO didn't have any TMs, and didn't know what a TM was.
> 2)  PO was trying to make C program analogs of the TMs, but he didn't 
> have those either
>      (at the time he claimed to have them)
> 3)  Eventually PO did produce some code in the form of his H and H^, but 
> when you ran them:
>      -   H^(<H^>) halts
>      -   H(<H^>,<H^>) decided neverhalts
>      Exactly in line with the Linz proof.  (PO's names differ from what 
> I've used.)
> 
> All the current threads are variations of PO trying to claim that H is 
> "correct" in some wacky PO-sense, when it decides neverhalts for input 
> (<H^>,<H^>), despite the acknowledged fact that H^(<H^>) actually halts.
> 
> 
> Mike.
> 


What he's basically claiming is that the halting criteria *should* be 
that H(X,Y) computes what would happen if the code of H was replaced 
with an unconditional simulator and H(X,Y) is subsequently run.

In fact he's explicitly admitted this:

On 2/22/2025 1:02 PM, olcott wrote:
 > On 2/22/2025 11:10 AM, dbush wrote:
 >> On 2/22/2025 11:43 AM, olcott wrote:
 >>> The first point is DD correctly simulated by HHH cannot
 >>> possibly terminate normally by reaching its own "return"
 >>> instruction.
 >>
 >> In other words, if the code of HHH is replaced with an unconditional 
simulator then it can be shown that DD is non-halting and therefore 
HHH(DD)==0 is correct.
 >>
 >
 > Wow finally someone that totally gets it.


This is essentially the same as the halting criteria in cases where X 
does not call H at some point, but not in cases where it does.  He 
doesn't understand that he's changing the input in this case.

Lately we've been telling him that "direct execution" is what is decided 
on, as 1) it's the actual requirement, and 2) that it essentially 
enforces that the input can't be changed in a way that PO can understand.

A lot of this boils down to the fact that proof by contradiction is over 
his head, despite the fact that it's something high school students 
learn and understand.