Path: nntp.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory,comp.ai.philosophy,sci.logic
Subject: Halting Problem Proof ERROR
Date: Thu, 17 Jul 2025 09:44:23 -0500
Organization: A noiseless patient Spider
Lines: 193
Message-ID: <105b287$1dh7g$1@dont-email.me>
References: <102sjg5$2k3e9$1@dont-email.me> <104041c$2nne5$1@dont-email.me>
 <1040hq4$2ql69$3@dont-email.me> <1042l0e$3cik5$1@dont-email.me>
 <1046v71$ctak$1@dont-email.me> <1047vld$n4s2$1@dont-email.me>
 <1048hp0$qd4f$2@dont-email.me>
 <66c00d5703907e846f537310dfb201485e1b7b2a@i2pn2.org>
 <10492eb$u8g5$1@dont-email.me> <104b5l9$fnl$1@news.muc.de>
 <104ben3$1hqln$1@dont-email.me> <104bt5h$1l1g$1@news.muc.de>
 <104bunk$1kcb5$1@dont-email.me> <104did7$hlh$1@news.muc.de>
 <104e164$2852a$1@dont-email.me> <104e6nd$12ua$1@news.muc.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 17 Jul 2025 16:44:24 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="757a756c4546e5542c44a33ac5ff5463";
	logging-data="1492208"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/xD3cLEspc9MryBu1hvtCW"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:6LCxH56nviiMMTu4n5oHjDwfbig=
In-Reply-To: <104e6nd$12ua$1@news.muc.de>
X-Antivirus-Status: Clean
Content-Language: en-US
X-Antivirus: Norton (VPS 250717-2, 7/17/2025), Outbound message

On 7/6/2025 11:02 AM, Alan Mackenzie wrote:
> [ Followup-To: set ]
> 
> In comp.theory olcott <polcott333@gmail.com> wrote:
>> On 7/6/2025 5:16 AM, Alan Mackenzie wrote:
>>> olcott <polcott333@gmail.com> wrote:
>>>> On 7/5/2025 2:07 PM, Alan Mackenzie wrote:
> 
>>>>> You lie.  You don't have a proof.  Many people in this group have pointed
>>>>> out lots of errors in various versions of your purported proof, which you
>>>>> just ignore.  The section in Professor Linz's book you used to be so fond
>>>>> of citing will contain plenty of details, if only you would take the
>>>>> trouble to understand it (assuming you're capable of such understanding).
> 
>>>> I have addressed ....
> 
>>> Meaningless pompous word.
> 
>>>> .... all of those details that you make sure to ignore so that you can
>>>> baselessly claim that I am wrong.
> 
>>> I vaguely remember rolling my eyes at your hopeless lack of
>>> understanding.  It was like watching a 7 year old trying to do calculus.
>>> The basic understanding was simply not there.  Years later, it's still
>>> not there.
> 
>>> And yes, you are wrong.  The proofs of the halting theorem which involve
>>> constructing programs which purported halting deciders cannot decide
>>> correctly are correct.
> 
>> Yet you cannot point to even one mistake because there are none.
> 
> That's what I'm saying.  Those proofs of the halting theorem are free
> from mistakes.
> 
> More to the point, it is YOU who cannot point to any mistakes in them.
> They are valid proofs.  Your work, if it contradicts those proofs (which
> isn't at all clear) can thus be dismissed without further consideration.
> 
>>>> There cannot possibly be *AN ACTUAL INPUT* that does the
>>>> opposite of whatever its decider decides. All of the examples
>>>> of this have never been *ACTUAL INPUTS*
> 
>>> That's so sloppily worded, it could mean almost anything.
> 
>> The standard halting problem proof cannot even be constructed.
> 
> It has been constructed, and is valid.  But one would normally talk about
> formulating a proof, rather than constructing one.
> 
> [ .... ]
> 
>>>> No Turing machine can possibly take another directly executing
>>>> Turing machine as in input, thus removing these from the
>>>> domain of every halt decider.
> 
>>> And that, too.
> 
>>>> *Thus the requirement that HHH report on the behavior*
>>>> *of the directly executed DD has always been bogus*
> 
>>> And that makes your hat trick.
> 
>>>> Turing machine partial halt deciders compute the mapping
>>>> from their actual inputs to the actual behavior that these
>>>> inputs specify.
> 
>>> And a fourth.  There's some semblance of truth in there, but it's very
>>> confused.
> 
> 
>> It is not at all confused. I know exactly what it means.
> 
> It's very confused to everybody but you, then.
> 
>>> Sloppy wording is your technique to get people to go down to your level
>>> of discussion.  That involves many posts trying just to tie you down to
>>> specific word meanings, and is very tiresome and unrewarding.  I decline
>>> to get involved any further.
> 
> 
>> *Yet as I claimed you found no actual mistake*
> 
> I've found plenty of actual mistakes.  I was a software developer by
> profession.
> 
>> Let me tell you the punchline so that you can
>> see why I said those things.
> 
> Despite what I said last post, I will actually go to the trouble of
> analysing your sloppy expression.
> 
>> Because directly executed Turing machines cannot
>> possibly be inputs to Turing machine deciders this
>> makes them outside of the domain of these deciders.
> 
> It's entirely unclear what a "directly executed Turing machine" is.  Most
> of the time turing machines are theoretical constructs used for proving
> theorems.  They can be executed, but rarely are.
> 
> It's unclear what you mean by a turing machine being an input to a turing
> machine.  Read up about universal turing machines to get a bit of
> background.
> 
>> When a partial halt decider is required to report
>> on the direct execution of a machine this requirement
>> is bogus.
> 
> See above.  That paragraph is meaningless.
> 
>> This means that the behavior of DD() is none of the damn
>> business of HHH, thus does not contradict HHH(DD)==0.
>> *If you disagree this only proves that you do not understand*
> 
> It's fully obscure what DD() and HHH mean, and thus impossible to
> affirm or contradict the meaningless "HHH(DD)==0".
> 
>> HHH(DD) does correctly detect that DD simulated by HHH
>> according to the semantics pf the C programming language
>> cannot possibly reach its own "return"statement final
>> halt state.
> 
> See above.  By the way, people concerned with computation theory use
> turing machines, which are well-defined, simple, and powerful.  They lack
> the complexity, ambiguity, and unsuitability for theoretical work of real
> world programming languages like C.
> 
>> *If you disagree this only proves that you do not understand*
> 
>> Any mindless idiot can disagree. Showing an error and proving
>> that it is an actual mistake requires much more than this.
> 
> Indeed.  All you have done is disagree with one of the proofs of the
> halting theorem.  You have yet to show an error in it.  That will be
> difficult, because there aren't any.
> 

q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ∞,
    if M applied to WM halts, and
q0 WM ⊢* Ĥq0 Wm WM ⊢* Ĥ y1 qn y2,
    if M applied to WM does not halt.

*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
   if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
   if Ĥ applied to ⟨Ĥ⟩ does not halt.

<*Halting Problem Proof ERROR*>

Requires Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ to report on the
direct execution of Ĥ applied to ⟨Ĥ⟩ and thus not
⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by Ĥ.embedded_H.

No Turing Machine decider can ever report on the
behavior of anything that is not an input encoded
as a finite string.

Ĥ is not a finite string input to Ĥ.embedded_H
⟨Ĥ⟩ ⟨Ĥ⟩ are finite string inputs to Ĥ.embedded_H

</*Halting Problem Proof ERROR*>

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
     ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
     its simulated final halt state of ⟨Ĥ.qn⟩, and

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
========== REMAINDER OF ARTICLE TRUNCATED ==========