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: Thu, 1 May 2025 20:41:21 -0400
Organization: A noiseless patient Spider
Lines: 96
Message-ID: <vv14bh$3ra6l$2@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>
 <vuv96l$27hsa$1@dont-email.me> <vv12qb$3pg7o$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 02 May 2025 02:41:21 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="bfb965ae000e29628a09f9a13a748901";
	logging-data="4040917"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/CDsaDnJgIO7X5O6KL8Ol7"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:15y6Gl7HBLR/OUzjb9B29qr7Yc4=
In-Reply-To: <vv12qb$3pg7o$2@dont-email.me>
Content-Language: en-US

On 5/1/2025 8:15 PM, olcott wrote:
> On 5/1/2025 2:51 AM, Richard Heathfield wrote:
>> On 30/04/2025 19:30, 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.
>>
>> Yes. That's what I call the Olcott Problem.
>>
>> De gustibus non est disputandum, but I venture to suggest that 
>> (correctly) overturning Turing's proof would be of cosmos-rocking 
>> interest to the world of computer science, compared to which pointing 
>> out a minor flaw in a minor[1] proof would, even if correct, have no 
>> more effect on our field than lobbing a pebble into the swash at high 
>> tide.
>>
> 
> int DD()
> {
>    int Halt_Status = HHH(DD);
>    if (Halt_Status)
>      HERE: goto HERE;
>    return Halt_Status;
> }
> 
> Replacing the code of HHH with an unconditional simulator and 
> subsequently running HHH(DD) according to the rules of
> the x86 language CANNOT POSSIBLY REACH ITS FINAL HALT
> STATE NO MATTER WHAT HHH DOES.
> 

Obviously, because you changed the input.

Changing the input is not allowed.

> 
> Unless we replace the code of HHH with an unconditional simulator and 
> subsequently run HHH(DD) we do
> not have the actual correct mapping of the actual
> input to the actual behavior of this actual input.
> 

Changing the input is not allowed.

> Unless we we replace the code of HHH with an unconditional simulator and 
> subsequently run HHH(DD) we do
> not have the actual correct mapping of the actual
> input to the actual behavior of this actual input.
> 

Changing the input is not allowed.

> Unless we we replace the code of HHH with an unconditional simulator and 
> subsequently run HHH(DD) we do
> not have the actual correct mapping of the actual
> input to the actual behavior of this actual input.
> 

Changing the input is not allowed.

> Unless we we replace the code of HHH with an unconditional simulator and 
> subsequently run HHH(DD) we do
> not have the actual correct mapping of the actual
> input to the actual behavior of this actual input.
> Changing the input is now allowed.

Changing the input is not allowed.