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: Re: Halting Problem Proof ERROR
Date: Fri, 18 Jul 2025 11:09:58 -0500
Organization: A noiseless patient Spider
Lines: 217
Message-ID: <105drkm$251hc$5@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>
 <105b287$1dh7g$1@dont-email.me> <105dafl$2asb4$6@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 18 Jul 2025 18:09:59 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="b5dfaa138f46cc0cd2e42fb576d98fb1";
	logging-data="2262572"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+07J7Cg9YSkiBfbVIY0H3J"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:Za/PdHLrhuHbRQj/VOJrpIUfiLc=
X-Antivirus-Status: Clean
In-Reply-To: <105dafl$2asb4$6@dont-email.me>
X-Antivirus: Norton (VPS 250718-2, 7/18/2025), Outbound message
Content-Language: en-US

On 7/18/2025 6:17 AM, Fred. Zwarts wrote:
> Op 17.jul.2025 om 16:44 schreef olcott:
>> 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*>
>>
========== REMAINDER OF ARTICLE TRUNCATED ==========