Deutsch   English   Français   Italiano  
<vv61pm$c2hj$1@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!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: Functions computed by Turing Machines MUST apply finite string
 transformations to inputs
Date: Sat, 3 May 2025 17:28:23 -0400
Organization: A noiseless patient Spider
Lines: 34
Message-ID: <vv61pm$c2hj$1@dont-email.me>
References: <TuuNP.2706011$nb1.2053729@fx01.ams4>
 <vugddv$b21g$2@dont-email.me> <vui4uf$20dpc$1@dont-email.me>
 <vuivtb$2lf64$3@dont-email.me> <vungtl$2v2kr$1@dont-email.me>
 <vuoaac$3jn5n$5@dont-email.me> <vuq81v$1hjka$1@dont-email.me>
 <vutefq$gmbi$3@dont-email.me>
 <991dde3a60e1485815b789520c7149e7842d18f2@i2pn2.org>
 <vuti3c$jq57$1@dont-email.me> <vutmr6$nvbg$2@dont-email.me>
 <vutv7r$v5pn$4@dont-email.me> <vuu73m$151a8$3@dont-email.me>
 <vuuej8$1cqp7$1@dont-email.me> <vuur2n$1qe3m$2@dont-email.me>
 <vv0352$2ur4q$1@dont-email.me> <vv0kpi$3djh5$1@dont-email.me>
 <vv13ro$3r3ei$1@dont-email.me> <vv160a$3smj7$1@dont-email.me>
 <vv18s7$3uer0$1@dont-email.me> <vv1b03$4a4k$2@dont-email.me>
 <vv1bav$3ra6l$7@dont-email.me> <vv1frt$97hp$1@dont-email.me>
 <vv1gfu$3ra6l$8@dont-email.me> <vv1js4$d4ik$1@dont-email.me>
 <-GOdnZvgEPn-84j1nZ2dnZfqn_SdnZ2d@brightview.co.uk>
 <vv4alu$2t388$1@dont-email.me>
 <K2ednc0OY5rg-Iv1nZ2dnZfqnPednZ2d@brightview.co.uk>
 <vv5rpm$8mnn$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 03 May 2025 23:28:23 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="612aa86f198076175a72741d4e91981c";
	logging-data="395827"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/G2F3YFO5YKK2mr7JgfAxY"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:ecL8XojfHPXRUugvsYg7aBtPhyk=
Content-Language: en-US
In-Reply-To: <vv5rpm$8mnn$1@dont-email.me>
Bytes: 3889

On 5/3/2025 3:45 PM, Richard Heathfield wrote:
> 
> I am conscious that you have already explained to me (twice!) that Mr 
> O's approach is aimed not at overturning the overarching indecidability 
> proof but a mere detail of Linz's proof. Unfortunately, your 
> explanations have not managed to establish a firm root in what passes 
> for my brain. This may be because I'm too dense to grok them, or 
> possibly it's because your explanations are TOAST (see above).
> 
> You have said, I think, that Olcott doesn't need a universal decider in 
> order to prove his point. But a less ambitious decider doesn't 
> contradict Linz's proof, surely? So once more for luck, what exactly 
> would PO be establishing with his non-universal and impatient simulator 
> if he could only get it to work?

The core issue is that PO, despise being nearly 70 and having worked as 
a programmer, fundamentally doesn't understand proof by contradiction.

He thinks that the H in the Linz proof *is* a halt decider, and 
therefore whatever result it comes up with *must* be correct.

He then concludes that whatever mapping that H is computing is the 
"correct" halting function and therefore the *actual* halting function 
is "wrong".  It is on this basis that he claims HHH(DD)==0 is correct, 
and therefore *any* halting problem proof is flawed.

His alternate halting criteria, in which he uses simulation, is that 
H(X,Y) determines what would happen if the code of H was replaced by a 
pure simulator and H(X,Y) is subsequently run to simulate X(Y).  In 
cases where X at some point calls H this results in an answer of 
non-halting but also changes the code being decided on.  This is 
obviously invalid, but PO then goes through a series of "justifications" 
(ex. H is the test code, not the code under test) based on the idea that 
H *must* be correct.