Re: Simulation vs. Execution in the Halting Problem

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.