Path: nntp.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: "Fred. Zwarts" <F.Zwarts@HetNet.nl>
Newsgroups: comp.theory,sci.logic,comp.ai.philosophy
Subject: Re: Title: A Structural Analysis of the Standard Halting Problem
 Proof
Date: Tue, 22 Jul 2025 10:55:12 +0200
Organization: A noiseless patient Spider
Lines: 92
Message-ID: <105njlh$36e8e$3@dont-email.me>
References: <105ht1n$36s20$1@dont-email.me>
 <eed26ffea811a639a76d0184321c57eafba746cd@i2pn2.org>
 <pI4fQ.147044$gKRf.71824@fx12.ams4> <105ipi1$67q$1@news.muc.de>
 <105j2ej$3dqi8$1@dont-email.me> <105l068$2q2ce$1@dont-email.me>
 <105lgvh$3v8t8$7@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 22 Jul 2025 08:55:13 +0000 (UTC)
Injection-Info: dont-email.me; posting-host="93c4df84a66726d55c0578f53e43d7fe";
	logging-data="3356942"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/Lb9m4HKZugHuWt8WVwpjL"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:l6tSjTlxzUzx7BTFcwKQdhJX1Q0=
In-Reply-To: <105lgvh$3v8t8$7@dont-email.me>
Content-Language: nl, en-GB

Op 21.jul.2025 om 15:57 schreef olcott:
> On 7/21/2025 4:10 AM, Mikko wrote:
>> On 2025-07-20 15:36:51 +0000, olcott said:
>>
>>> On 7/20/2025 8:05 AM, Alan Mackenzie wrote:
>>>> [ Followup-To: set ]
>>>>
>>>> In comp.theory Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:
>>>>> 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.
>>>>
>>>> Maybe it was you wanting to create that impression by dishonestly
>>>> snipping the substance of Richard's post, where he illustrated some of
>>>> the words whose meaning PO fails to understand.
>>>
>>> It never has been that I do not understand
>>> the definitions of words it is that I have
>>> proven that some of these definitions are incorrect.
>>
>> That you think a definition is incorrect does not change the defined
>> meaning. If you don't accept the definition the best you can do is
>> that you don't use the term.
>>
> 
> That I prove that a definition is derived from provably
> false assumptions proves that this definition is incorrect.

As usual incorrect claims without evidence. Nobody ever saw the proof.>
> No one here is capable of paying enough attention to my
> proof that the halting problem definition is incorrect
> because my proof requires two steps and no one here can
> even pay attention to one step.

Even the first step has many errors. But you close your eyes and pretend 
that nobody showed these errors to you.

> 
> *This right here is a type mismatch error*
> The simplest step is that no Turing machine decider
> ever takes another directly executing Turing machine
> as its input yet the halting problem requires a halt
> decider to report on the behavior of the directly
> executed machine.

Nobody require the decider to report on the direct execution of another 
machine. But if the input specifies a halting program, but HHH is unable 
to report that, HHH just fails.

> 
> This would not be an issue if the correct simulation
> of a Turing machine description always had the exact
> same behavior as the directly executed machine.

It has, because that is the definition of behaviour. The semantics of 
the x86 language does not allow multiple interpretations for the 
behaviour. The same holds for other machine languages.

> 
> Everyone here sees that the behavior is not the same
> and rules that the simulation is wrong because it
> differs from the behavior of the direct execution.
> *That is an incorrect measure of correct simulation*
> 

We only see that HHH fails to do a correct simulation up to the end, 
because of a premature abort. We see bugs in HHH, where it concludes 
from a finite recursion that there is a non-halting behaviour.