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.