Sujet : The error of the standard proof of the halting problem
De : polcott333 (at) *nospam* gmail.com (olcott)
Groupes : comp.theory sci.logic comp.ai.philosophyDate : 22. Jul 2025, 05:17:39
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <105n3d3$bgdn$1@dont-email.me>
References : 1 2 3 4 5 6
User-Agent : Mozilla Thunderbird
On 7/21/2025 9:20 PM, Richard Damon wrote:
On 7/21/25 9:45 AM, olcott wrote:
On 7/21/2025 4:06 AM, Mikko wrote:
On 2025-07-20 11:48:37 +0000, Mr Flibble said:
>
On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:
>
On 7/20/25 12:58 AM, olcott wrote:
Title: A Structural Analysis of the Standard Halting Problem Proof
>
Author: PL Olcott
>
Abstract:
This paper presents a formal critique of the standard proof of the
undecidability of the Halting Problem. While we do not dispute the
conclusion that the Halting Problem is undecidable, we argue that the
conventional proof fails to establish this conclusion due to a
fundamental misapplication of Turing machine semantics. Specifically,
we show that the contradiction used in the proof arises from conflating
the behavior of encoded simulations with direct execution, and from
making assumptions about a decider's domain that do not hold under a
rigorous model of computation.
>
Your problem is you don't understand the meaning of the words you are
using.
>
This is an ad hominem attack, not argumentation.
>
It is also honest and truthful, which is not as common as it should.
>
>
It is also honest and truthful that people
that deny verified facts are either liars
or lack sufficient technical competence.
>
Right, so YOU are the liar.
It is a verified fact that the PROGRAM DDD halts since your HHH(DDD) returns 0.
It is a self-evident truth that the halting problem proof
has always been incorrect when it requires a halt decider
to report on the behavior of the direct execution of any
Turing machine because no Turing machine decider can ever
take another directly executed Turing machine as its input.
The presumption that the behavior specified by the machine
description of a machine is always exactly the same as the
behavior of the directly executed machine has one exception.
When the input to the decider calls its own simulating halt
decider this causes recursive simulation. This changes the
behavior. The direct execution halts and the correctly simulated
machine cannot possibly halt.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
its simulated final halt state of ⟨Ĥ.qn⟩, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly
reach its simulated final halt state of ⟨Ĥ.qn⟩.
When Ĥ is applied to ⟨Ĥ⟩ and embedded_H is a simulating
partial halt decider
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ ...
Because ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H
would remain stuck in recursive simulation unless
embedded_H aborts this simulation embedded_H is
correct to transition to its own final state of Ĥ.qn.
-- Copyright 2025 Olcott "Talent hits a target no one else can hit; Geniushits a target no one else can see." Arthur Schopenhauer