Path: nntp.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory
Subject: Re: Title: A Structural Analysis of the Standard Halting Problem
 Proof
Date: Thu, 24 Jul 2025 09:32:45 -0500
Organization: A noiseless patient Spider
Lines: 118
Message-ID: <105tg6d$1fr8n$7@dont-email.me>
References: <105ht1n$36s20$1@dont-email.me>
 <eed26ffea811a639a76d0184321c57eafba746cd@i2pn2.org>
 <pI4fQ.147044$gKRf.71824@fx12.ams4> <105kvub$2q17h$1@dont-email.me>
 <105lg9k$3v8t8$6@dont-email.me> <105npl8$37i2t$1@dont-email.me>
 <105o4uu$g4mg$4@dont-email.me> <105q7nc$8slg$5@dont-email.me>
 <105qv4j$10rne$1@dont-email.me> <105t0cq$l7mf$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 24 Jul 2025 16:32:46 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="fd5759eac3b2dc0860524bda45510ca5";
	logging-data="1568023"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+sXoVhYuvT76ueBEfYHPCX"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:0viRP8nRubDJPwW6OEIO7t93bHE=
X-Antivirus-Status: Clean
Content-Language: en-US
In-Reply-To: <105t0cq$l7mf$2@dont-email.me>
X-Antivirus: Norton (VPS 250724-2, 7/24/2025), Outbound message

On 7/24/2025 5:03 AM, Fred. Zwarts wrote:
> Op 23.jul.2025 om 17:29 schreef olcott:
>> On 7/23/2025 3:49 AM, Fred. Zwarts wrote:
>>> Op 22.jul.2025 om 15:50 schreef olcott:
>>>> On 7/22/2025 5:37 AM, Mikko wrote:
>>>>> On 2025-07-21 13:45:24 +0000, olcott said:
>>>>>
>>>>>> 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.
>>>>>
>>>>> Where I live it is a crime to call anyone a liar or lacinkg sufficient
>>>>> technical compoetence unless a judge accepts your proof of your 
>>>>> claims.
>>>>>
>>>>
>>>> I have proven that my claims are self-evidently
>>>> true on the basis of the meaning of their words
>>>> and the meaning of the code samples that I have
>>>> provided.
>>>
>>> As usual incorrect claims without evidence.
>>>
>>>>
>>>> void DDD()
>>>> {
>>>>    HHH(DDD);
>>>>    return;
>>>> }
>>>>
>>>> When anyone says that DDD correctly simulated by
>>>> HHH reaches its own "return" statement final halt
>>>> state if we just wait long enough this is either
>>>> a lie or a lack of sufficient technical competence.
>>>
>>> Nobody said such a thing. Suggesting that somebody did, without any 
>>> evidence, may be considered as a lie.
>>> We all know that HHH fails to reach the final halt state,
>>
>> Counter-factual.
> 
> As usual claims without relevant evidence.
> 
>> The directly executed HHH does reach its final halt state.
>> DDD correctly simulated by HHH cannot possibly reach its
>> final halt state no matter what HHH does because it remains
>> stuck in recursive simulation.
> 
> Indeed, but irrelevant. The simulating HHH does not do a correct 
> simulation, it aborts prematurely. 
*Correctly emulated is defined as*
Emulated according to the rules of the x86 language.
This includes DDD emulated by HHH and HHH emulating
itself emulating DDD one or more times.

void DDD()
{
   HHH(DDD);
   return;
}

_DDD()
[00002192] 55             push ebp
[00002193] 8bec           mov ebp,esp
[00002195] 6892210000     push 00002192  // push DDD
[0000219a] e833f4ffff     call 000015d2  // call HHH
[0000219f] 83c404         add esp,+04
[000021a2] 5d             pop ebp
[000021a3] c3             ret
Size in bytes:(0018) [000021a3]

Aborting prematurely literally means that after
N instructions of DDD are correctly emulated by
HHH that this emulated DDD would reach its own
emulated "ret" instruction final halt state.

What value of N are you proposing?

-- 
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer