Path: ...!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: Anyone with sufficient knowledge of C knows that DD specifies
 non-terminating behavior to HHH
Date: Sat, 8 Feb 2025 17:29:02 -0500
Organization: i2pn2 (i2pn.org)
Message-ID: <47f02a4b9e61fe386c169419609533b2f8091b86@i2pn2.org>
References: <vo6420$3mpmf$1@dont-email.me> <vo79lj$8vq$1@dont-email.me>
 <vo7qj9$36ra$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 8 Feb 2025 22:29:02 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="3334156"; 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: <vo7qj9$36ra$1@dont-email.me>
Content-Language: en-US
Bytes: 3873
Lines: 80

On 2/8/25 9:43 AM, olcott wrote:
> On 2/8/2025 3:54 AM, Fred. Zwarts wrote:
>> Op 08.feb.2025 om 00:13 schreef olcott:
>>> Experts in the C programming language will know that DD
>>> correctly simulated by HHH cannot possibly reach its own
>>> "if" statement.
>>
>> Yes, it demonstrates the incapability of HHH to correctly determine 
>> the halting behaviour of DD
>>
>>>
>>> The finite string DD specifies non-terminating recursive
>>> simulation to simulating termination analyzer HHH. This
>>> makes HHH necessarily correct to reject its input as
>>> non-halting.
>>
>> The finite string defines one behaviour. This finite string, when 
>> given to an X86 processor shows halting behaviour. This finite 
>> string,when given to a world class simulator, shows halting behaviour. 
>> Only HHH fails to see this proven halting behaviour. So it proves the 
>> failure of HHH.
>> HHH aborts the simulation on unsound grounds one cycle before the 
>> simulation would terminate normally.
>>
>>>
>>> typedef void (*ptr)();
>>> int HHH(ptr P);
>>>
>>> int DD()
>>> {
>>>    int Halt_Status = HHH(DD);
>>>    if (Halt_Status)
>>>      HERE: goto HERE;
>>>    return Halt_Status;
>>> }
>>>
>>> int main()
>>> {
>>>    HHH(DD);
>>> }
>>>
>>> https://www.researchgate.net/ 
>>> publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
>>>
>>> https://github.com/plolcott/x86utm/blob/master/Halt7.c
>>> has fully operational HHH and DD
>>>
>>> The halting problem has always been a mathematical mapping
>>> from finite strings to behaviors. 
>>
>> Yes. And the behaviour of this finite string has been proven to show 
>> halting behaviour. Only Olcott's HHH fails to see it.
>> His misunderstanding is that he thinks that the behaviour defined by 
>> the finite string depends on the simulator.
> 
> When DD calls HHH(DD) in recursive simulation it is a
> verified fact that DD cannot possibly halt.

Of course it can, since you claim that HHH(DD) is correct to return 0, 
then it must do so, as you can't be a correct decider and not do what is 
claimed to be correct, and that means that DD calls HHH(DD) which WILL 
return to DD.

The fact that HHH can't correctly simulate to that point is irrelevent, 
as "Halting" is defined by the behavior of the actual machine, and not 
some incorrect simulators simulation.

And any simulation that stops before reaching a final state is incorrect 
for the purposes of detemining halting.

Sorry, you just don't know what your words mean.

> 
>> He fail to see that a finite string defines a behaviour independent of 
>> the thing that runs or simulates it. It seems that he is incapable to 
>> learn that a failure of a simulator does not define a behaviour.
>>
>>
> 
>