Path: ...!news.snarked.org!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: Every sufficiently competent C programmer knows --- Semantic
 Property reiterated
Date: Fri, 14 Mar 2025 14:42:54 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <b89ae9be90cf40217e5bfde817b4b0e5689438d7@i2pn2.org>
References: <vqntaq$1jut5$1@dont-email.me> <vqp388$1tvqa$1@dont-email.me>
 <vqpdv9$202b2$2@dont-email.me> <vqperb$20c9k$2@dont-email.me>
 <E6mcnWv3nMa66036nZ2dnZfqnPWdnZ2d@brightview.co.uk>
 <vqpv2u$23vhr$1@dont-email.me>
 <Ny-dnRlMHcVpA036nZ2dnZfqnPqdnZ2d@brightview.co.uk>
 <878qp9gckd.fsf@bsb.me.uk> <vquvvs$3dmpj$2@dont-email.me>
 <e396868b6758cf3ab86721ef2714425be55485f4@i2pn2.org>
 <vr033r$ad6n$3@dont-email.me>
 <b93128c02559fa15fcb374b929ae5455cfb56e01@i2pn2.org>
 <vr08g1$ehgd$1@dont-email.me>
 <bca7ccc7cdf80b4ca23b0b7054bd8d9cefda8721@i2pn2.org>
 <vr1ltn$1ev1a$13@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 14 Mar 2025 18:42:55 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="187149"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <vr1ltn$1ev1a$13@dont-email.me>
Content-Language: en-US
Bytes: 9445
Lines: 200

On 3/14/25 12:36 PM, olcott wrote:
> On 3/14/2025 9:10 AM, Richard Damon wrote:
>> On 3/13/25 11:40 PM, olcott wrote:
>>> On 3/13/2025 10:03 PM, Richard Damon wrote:
>>>> On 3/13/25 10:08 PM, olcott wrote:
>>>>> On 3/13/2025 6:09 PM, Richard Damon wrote:
>>>>>> On 3/13/25 12:09 PM, olcott wrote:
>>>>>>> On 3/13/2025 10:44 AM, Ben Bacarisse wrote:
>>>>>>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>>>>>>>
>>>>>>>>> On 11/03/2025 18:23, Richard Heathfield wrote:
>>>>>>>>>> On 11/03/2025 17:42, Mike Terry wrote:
>>>>>>>>>>> Finally, if you really want to see the actual HHH code, its 
>>>>>>>>>>> in the
>>>>>>>>>>> halt7.c file (along with DDD) that PO provides links to from 
>>>>>>>>>>> time to
>>>>>>>>>>> time.  However it's not very illuminating due to bugs/design
>>>>>>>>>>> errors/misunderstandings which only serve to obfuscate PO's 
>>>>>>>>>>> errors in
>>>>>>>>>>> thinking.
>>>>>>>>>> [I've now seen the code. Oh deary deary me.]
>>>>>>>>>
>>>>>>>>> :)
>>>>>>>>>
>>>>>>>>>> Thank you for a spirited attempt to be cogent - or at least as 
>>>>>>>>>> cogent as
>>>>>>>>>> it is possible to be in the circumstances!
>>>>>>>>>> I think PO's first step must be to demonstrate that HHH() 
>>>>>>>>>> correctly
>>>>>>>>>> diagnoses some easy functions, such as these:
>>>>>>>>>
>>>>>>>>> Not really necessary - PO is not trying or claiming to have a 
>>>>>>>>> (full)
>>>>>>>>> halt decider.
>>>>>>>>>
>>>>>>>>> Originally his claim was that he had a program which worked for 
>>>>>>>>> the
>>>>>>>>> counter-example TM used in the common (e.g. Linz book) proof.
>>>>>>>>
>>>>>>>> That, of course, depends on the way the wind's blowing.  For 
>>>>>>>> example in
>>>>>>>> 2020:
>>>>>>>>
>>>>>>>>    "The non-halting decider that I defined accepts any and all
>>>>>>>>    non-halting inputs and rejects any and all halting inputs."
>>>>>>>>
>>>>>>>> But then he retreated to the "once case" argument again until:
>>>>>>>>
>>>>>>>> Me: "Recent posts have said that you really do claim to have a 
>>>>>>>> halting
>>>>>>>>      decider.  Have you extended your claim or was that a
>>>>>>>>      misunderstanding?"
>>>>>>>>
>>>>>>>> PO: "I really do have a halting decider."
>>>>>>>>
>>>>>>>>> ... Such a
>>>>>>>>> program is impossible, as Linz and others prove, so having a 
>>>>>>>>> program H and
>>>>>>>>> its corresponding "counter-example" D, such that H correctly 
>>>>>>>>> decides D,
>>>>>>>>> would certainly show that the Linz proof is wrong.  His claim 
>>>>>>>>> was always
>>>>>>>>> that he had "refuted the HP proof", or sometimes that he had 
>>>>>>>>> refuted the HP
>>>>>>>>> theorem itself although he's been told dozens of times that 
>>>>>>>>> there are many
>>>>>>>>> alternative proofs for the result.
>>>>>>>>
>>>>>>>> Way back in 2004 he was sure that:
>>>>>>>>
>>>>>>>>    "I have correctly refuted each and every mechanism by which the
>>>>>>>>    [halting theorem] has been proven to be true. I have not 
>>>>>>>> shown that
>>>>>>>>    solving the Halting Problem is possible, merely refuted every 
>>>>>>>> proof
>>>>>>>>    that it is impossible."
>>>>>>>>
>>>>>>>> I expect a publication anytime.  20 years is just about enough 
>>>>>>>> to get
>>>>>>>> all the details right.
>>>>>>>>
>>>>>>>>> [As it turned out, PO's D(D) halted when run under his x86utm 
>>>>>>>>> environment,
>>>>>>>>> while H(D,D) which is required to return the halting status of 
>>>>>>>>> computation
>>>>>>>>> D(D) returned 0 (=non-halting).  That is exactly what the Linz 
>>>>>>>>> proofs
>>>>>>>>> claim!]
>>>>>>>>
>>>>>>>> We must always remember that PO has re-defined what it means for 
>>>>>>>> the
>>>>>>>> answer to be correct:
>>>>>>>>
>>>>>>>> Me: "Here's the key question: do you still assert that H(P,P) == 
>>>>>>>> false
>>>>>>>>      is the "correct" answer even though P(P) halts?"
>>>>>>>>
>>>>>>>> PO: "Yes that is the correct answer even though P(P) halts."
>>>>>>>>
>>>>>>>> He's been quite clear about it:
>>>>>>>>
>>>>>>>>    "When we make the single change that I suggest the halting 
>>>>>>>> problem
>>>>>>>>    ceases to be impossible to solve because this revised 
>>>>>>>> question is not
>>>>>>>>    subject to pathological self-reference."
>>>>>>>>
>>>>>>>>    "This transforms an undecidable problem into a decidable 
>>>>>>>> problem."
>>>>>>>>
>>>>>>>> I hope you forgive me just chipping in with stuff you know 
>>>>>>>> perfectly
>>>>>>>> well, but I thought I'd just give some background as Richard is 
>>>>>>>> a new
>>>>>>>> participant and my comments fit better with your post than his.
>>>>>>>>
>>>>>>>
>>>>>>> typedef void (*ptr)();
>>>>>>> int HHH(ptr P);
>>>>>>>
>>>>>>> int DD()
>>>>>>> {
>>>>>>>    int Halt_Status = HHH(DD);
>>>>>>>    if (Halt_Status)
>>>>>>>      HERE: goto HERE;
>>>>>>>    return Halt_Status;
>>>>>>> }
>>>>>>>
>>>>>>> When N steps of DD are correctly emulated by
>>>>>>> any HHH then each DD cannot possibly reach
>>>>>>> its own final state and terminate normally.
>>>>>>
>>>>>> No, the PARTIAL EMULATION done by HHH can't reach that point, 
>>>>>
>>>>> But a complete emulation can?
>>>>>
>>>>
>>>> Yes, 
>>>
>>> Stupidly incorrect.
>>>
>>
>> Got proof of that? or it this just your use of more lies and falacies?
>>
> 
> void DDD()
> {
>    HHH(DDD);
>    return;
> }
> 
> The semantics of the finite string input DDD to HHH specifies
> that it will continue to call HHH(DDD) in recursive simulation.
> That the semantics of that tiny C function are over your head
> cannot be overcome.
> 

No, the finite string you provide proves that you are just a lying 
idiot, as since the code for HHH has not been included, DDD is not a 
program and thus it is a category error to ask about its behavior.

You are just showing that you just don't know what you are talking about.

When you include the actual definition of HHH, then we see that your HHH 
doesn't do a "correct simulation", just a partial simulation, but that 
the actual correct simulation of the input will see DDD call HHH(DDD) 
========== REMAINDER OF ARTICLE TRUNCATED ==========