Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!news.quux.org!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: Turing Machine computable functions apply finite string
 transformations to inputs VERIFIED FACT
Date: Thu, 1 May 2025 21:56:45 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <b59b9d67844067b7c4b476cd2af0276dc00b182e@i2pn2.org>
References: <vu6lnf$39fls$2@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> <87o6wcgxdn.fsf@bsb.me.uk>
 <vv12bu$3pg7o$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 2 May 2025 02:08:36 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2752403"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <vv12bu$3pg7o$1@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US

On 5/1/25 8:07 PM, olcott wrote:
> On 5/1/2025 10:32 AM, Ben Bacarisse wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>
>>> 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.
>>>
>>> I suspect that the only reason we bother to argue with Mr Olcott so 
>>> much is
>>> because (even if he does so unwittingly) he manages to convey the
>>> appearance of attacking the Halting Problem, and arguing about the 
>>> Halting
>>> Problem is a lot more fun than arguing about the Olcott Problem.
>>>
>>> To be of any interest, solving the Olcott Problem would have to have
>>> important consequences. But does it? Let's see.
>>>
>>> Dr Linz Theorem 12.1 (Halting Problem is Undecidable): There does not 
>>> exist
>>> any Turing machine H that behaves as required by Linz Definition 
>>> 12.1. Thus
>>> the halting problem is undecidable.
>>>
>>> Dr Linz has a proof for this claim, which can be found here:
>>> <https://john.cs.olemiss.edu/~hcc/csci311/notes/chap12/ch12.pdf>
>>>
>>> If the proof is flawless, the conclusion stands and Mr Olcott is simply
>>> wrong.
>>
>> There is peculiar irony here.  The proof is /not/ flawless.  It has, in
>> fact, a flaw that PO pointed out (although in passing).  PO does not
>> care about the flaw because it is easily fixed, but it's there none the
>> less[1].
>>
>> Anyway, Linz only gives this argument because it is of historical
>> interest.  His "real" proof immediately follows this argument (in the
>> book) and is a trivial corollary of the fact, proved in chapter 11, that
>> not all recursively enumerable languages are recursive.  But no crank
>> ever addresses that proof.  I wonder why...
>>
> 
> You wasted fifteen years of my life by your change-the-subject
> form of rebuttal so I no longer tolerate that from an anyone.

No, you wasted those yours on your own by not knowing what you were 
talking about.

> 
> The flaw in all of the conventional proofs is that the
> mapping they they DO specify IS NOT the direct execution
> of their input.

Why not? That *IS* the definition of the mapping of the Halting 
Function, which is the mapping the Halt Decider needs to try to compute.

> 
> Everyone moronically ignores how the pathological relationship
> between the INPUT and its TERMINATION ANALYZER CHANGES the
> behavior OF THE INPUT.

No, but that doesn't change anything, since that doesn't actually affect 
the behavior of the machine described by the input, as that is fixed by 
the definition of the decider it is built to contradict.

> 
> *When HHH emulates DD correctly the emulated DD cannot possibly halt*
> THIS IS THE BEHAVIOR OF THE FREAKING INPUT.

The Hypothetical HHH, when looking at the Hypothetical DD built on it, 
never answer, so isn't a correct decider.

THe actual HHH, that does abort, when given the DD that was built on it, 
jkust aborts its emulation too soon. The actual correct emulation of the 
input, which those HHH don't do, reachs the final state.

You are just proving you are just a pathological liar by calling HHH as 
a correct emulator, when it doesn't finish the job, and thus violating 
the rules of the x86 language.

SOmething you have implicitly admitted by failing to quote ANY reference 
for your insaine definiton of the x86 language that just allows the 
processor to stop whenever it feels like.

Good thing that isn't how real processors work, which *IS* the 
definition of the x86 language. Thus proving you really don't understand 
how words get their defintions.

> 
> That you saw Bill's identical twin brother rob a liquor
> store DOES NOT PROVE THAT BILL IS GUILTY.

Which is why you can't look at the DD built on HHH's near twin (the one 
that doesn't abort).

> 
> If anyone would pay any freaking attention THEY WOULD
> ALL KNOW THAT I HAVE BEEN CORRECT ABOUT THIS FOR SEVERAL YEARS.

No, if you had stopped to look at the errors being pointed out, you 
would have seen YOUR error all those years ago.

> 
>>> If the proof is flawed through some error of reasoning, *either* it 
>>> merely
>>> fails to correctly support its conclusion *or* a duly corrected proof
>>> /overturns/ the conclusion.
>>
>> ... or a duly corrected proof /supports/ the conclusion.  Maybe you
>> intended this possibility to be include in your first "merely fails to
>> support" alternative.
>>
>>> The latter would be /extremely/ interesting, but it would also mean 
>>> that we
>>> have two proofs proving opposite things, and so it would effectively 
>>> be a
>>> cataclysmic sideways attack on Turing's reasoning.
>>
>> It would be a cataclysmic attack on all of conventional mathematics and
>> logic as two proofs, one of T and another of ~T, makes the system of
>> proof oneself inconsistent (and everything becomes a theorem).
>>
>> [1] It centres on the naming of states in H and the derived machines H'
>> and H^.  Details available if you really care.
>>
> 
>