Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!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:11:27 -0400
Organization: A noiseless patient Spider
Lines: 89
Message-ID: <vuu05e$v5pn$8@dont-email.me>
References: <vu6lnf$39fls$2@dont-email.me> <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>
 <vutu28$ts6e$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 30 Apr 2025 22:11:27 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="36c3ab966607e6b458aa2826fcd1def6";
	logging-data="1021751"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18j6KhRLUtYgNz47ooTCVKa"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:GKleEEs5i2v3VLLt9zn2tKmHFi0=
Content-Language: en-US
In-Reply-To: <vutu28$ts6e$1@dont-email.me>
Bytes: 5212

On 4/30/2025 3:35 PM, olcott wrote:
> On 4/30/2025 1: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.
>>
> 
> This is not an algorithm to calculate sum
> because it ignores its inputs thus does not transform them
> according to the transformation rules of arithmetic.
> int sum(int x, int y) { return 5; }

Obviously, it's an algorithm that computes the mapping of all pairs of 
numbers to 56.

> 
> A halt decider 

By its stipulated definition:


Given any algorithm (i.e. a fixed immutable sequence of instructions) X 
described as <X> with input Y:

A solution to the halting problem is an algorithm H that computes the 
following mapping:

(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly


> is not allowed to compute halting on
> the basis of direct execution. It is only allowed to
> transform inputs into outputs.

False.  It is *only* required to perform the above mapping.  How it does 
it is irrelevent.

> 
> There are ONLY finite string transformations according
> to the x86 language from the input to HHH(DD) to non
> halting behavior.

False, because when the input to HHH(DD), i.e. the code of the function 
DD, the function HHH, and everything that HHH calls down to the OS 
level, is actually run on an actual x86 processor it will halt.