Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: "Fred. Zwarts" <F.Zwarts@HetNet.nl>
Newsgroups: comp.theory
Subject: Re: Simulation vs. Execution in the Halting Problem
Date: Sat, 14 Jun 2025 11:49:08 +0200
Organization: A noiseless patient Spider
Lines: 132
Message-ID: <102jgil$3l67$2@dont-email.me>
References: <yU0_P.1529838$4AM6.776697@fx17.ams4>
 <822e204898d419545ca400a9088970f0b6a5107f.camel@gmail.com>
 <102ckje$25dg0$2@dont-email.me>
 <c5adb4ff9ac0a31da990ff83ab1ef7f242a2f7a7.camel@gmail.com>
 <102cm0u$25dg0$3@dont-email.me>
 <610e2a54b66e8576b80bda3a0fe188d025b9798e.camel@gmail.com>
 <102cp0e$26clp$1@dont-email.me>
 <d4b02c8deb6dd72c7bf143b07c2752d93b825b1d.camel@gmail.com>
 <102crbv$26rt0$1@dont-email.me>
 <ade2f19a880169bbaf09794b496e585b7eb8b677.camel@gmail.com>
 <102ctbg$26rt0$2@dont-email.me>
 <f09964feafdca25ea8efbe546868084bcd9df3a0.camel@gmail.com>
 <102d082$28067$1@dont-email.me>
 <a480d0b388903cc2c039fb39792007fc8c88841f.camel@gmail.com>
 <102d4fa$291mi$1@dont-email.me>
 <27181e2fc0e06453f53994e2a92e3a5c8808e581.camel@gmail.com>
 <102d6ge$29fp7$1@dont-email.me>
 <ce43ca906ca40618fefd39f3fe2388b099bff58b.camel@gmail.com>
 <102d8bk$29pam$1@dont-email.me> <102e74m$2jopg$1@dont-email.me>
 <102et14$2ohps$8@dont-email.me> <102gpvq$3bhe0$1@dont-email.me>
 <102hcb7$3fnmh$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 14 Jun 2025 11:49:09 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="e6a1a9d2c4ec8df2ebbe13317fee6ee4";
	logging-data="120007"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19pnFpxqlKJHHhPwPrQfN0x"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:Lg9bayfddvtSp4db+2HZ5AFB6O4=
Content-Language: nl, en-GB
In-Reply-To: <102hcb7$3fnmh$1@dont-email.me>

Op 13.jun.2025 om 16:24 schreef olcott:
> On 6/13/2025 4:11 AM, Fred. Zwarts wrote:
>> Op 12.jun.2025 om 17:51 schreef olcott:
>>> On 6/12/2025 4:37 AM, Fred. Zwarts wrote:
>>>> Op 12.jun.2025 om 02:52 schreef olcott:
>>>>>
>>>>> If you don't understand the difference between object
>>>>> instances of OOP classes and the classes themselves
>>>>> then you might not understand.
>>>>>
>>>>> int main()
>>>>> {
>>>>>    D(); // calls H(D) and the parameter to this H(D)
>>>>> }      // is not the caller of this instance of H(D)
>>>>>
>>>> The analyser should not decide about an instance, but about what is 
>>>> specified by the code. 
>>> void DDD()
>>> {
>>>    HHH(DDD);
>>>    return;
>>> }
>>>
>>> The input to HHH(DDD) specifies a sequence of configurations
>>> that cannot possibly reach their own "return" statement
>>> final halt state.
>>
>> The input is a pointer to code that includes the code to abort and halt.
> 
> I m not going to correct you on this again.

You can't, because every competent programmer knows that it is correct.

> I will simply stop looking at anything that you say.
> 
>> That HHH is not able to reach that part of the code is a failure of 
>> HHH, not a property of the program specified in the input.
> 
> counter-factual and over-your-head.
> It is a verified fact that unless the outermost HHH(DDD)
> aborts its simulation of DDD then this simulated DDD, the
> directly executed DDD() and the directly executed HHH()
> would never stop running.

Which exactly proves my point, because HHH does abort, not only the 
simulating HHH, but also the simulated HHH is programmed to abort. So, 
it would stop running.
You cannot deny that verified fact that the code for the simulated HHH 
includes the code to abort and halt, because it is a verified fact. 
Everybody can verify it by looking at the code in Halt7.c.

> 
> That you don't have enough technical skill to verify
> this fact should cause you to have the position that
> you don't know if this fact is verified. That you
> take the position that I am wrong knowing that you
> don't understand these things seems dishonest.

Not understanding what simulation means is not stupid, but the 
resistance against learning is.
Not learning from your errors, but repeating claims that have been 
proven to contain errors shows a mental incapability to learn, which 
some people call 'stupid'.

> 
>> That HHH cannot reach it, does not change the specified code.
> 
> Within a correct execution trace unreachable code is
> the same as non-existent code. That you don't know that
> is merely a lack of sufficient technical competence on
> your part.

In a simulator that simulates only one instruction after which aborts, 
all other instructions are unreachable.
If you think that this makes the code non-existent, shows again your 
lack of understanding of a correct simulation. It is only showing a 
failure to do a correct simulation.

> 
>> The program aborts as world-class simulators en direct execution of 
>> exactly the same input prove.
>>
> 
> int main()
> {
>    DDD(); // calls HHH(DDD) with a different instance of DDD
> }
> 
>>>
>>> That you are insufficiently competent to see this is proven
>>> by the fact that you have no rebuttal anchored in correct
>>> reasoning.
>>>
>>
>> Ad hominem attacks only prove your lack of counter-arguments.
> You say that I am wrong and cannot provide all of the details
> showing exactly how and why I am wrong does not count as a
> rebuttal. It only counts as incorrect intuition.
> 
> You prove your ignorance by the lack of details that
> you provide in your purely dogmatic assertions that I
> am wrong.
> 
> void DDD()
> {
>    HHH(DDD);
>    return;
> }
> 
> The input to HHH(DDD) specifies non-halting behavior
> in that DDD correctly simulated by HHH cannot possibly
> reach its own "return" statement final halt state.

No, the input DDD is a pointer to a function (as a competent C 
programmer should know). This function has addresses to other functions, 
which includes the code to abort and halt.
That is what the input specifies.
But HHH does not see the full specification, because the programmer 
coded a premature abort after a finite recursion, forgetting to count 
the conditional branch instruction during the simulation of itself.
That HHH is made blind for the full specification does not change the 
specification.

> 
> Only a correct simulation of the input to HHH(DDD) by
> HHH derives the actual behavior specified by this input.
> 

And the actual behaviour specified is a program with finite recursion 
that halts.
Dreaming of an infinite recursion does not change the code that should 
be simulated.