Re: Simulation vs. Execution in the Halting Problem --- CHALLENGE

On 2025-06-18 15:10:42 +0000, olcott said:

On 6/18/2025 3:33 AM, Mikko wrote:

On 2025-06-17 14:15:33 +0000, olcott said:
 

On 6/17/2025 4:44 AM, Mikko wrote:

On 2025-06-16 18:36:47 +0000, olcott said:
 

On 6/16/2025 6:19 AM, Mikko wrote:

On 2025-06-15 20:02:28 +0000, olcott said:
 

On 6/15/2025 2:01 PM, Richard Damon wrote:

On 6/15/25 11:27 AM, olcott wrote:

On 6/15/2025 4:46 AM, Mikko wrote:

On 2025-06-14 13:44:30 +0000, olcott said:
 

On 6/14/2025 6:26 AM, Mikko wrote:

On 2025-06-13 17:59:23 +0000, André G. Isaak said:
 

On 2025-06-13 09:36, olcott wrote:

On 6/13/2025 6:53 AM, Mikko wrote:

 

Nothing is permanent. But you can (and to some extent do) maintan a web
page as long as you need it for usenet discussions.

 I want people to be able to validate my work 50 years after I am dead.
A web-page will not work for this.

 Usenet is dying. Do you seriously think it will be around in 50 years?

 Some of its contents might still be on some web page.

 Storing every text message ever written seems
to take < 1.0 TB.

 Doesn't matter. Unlikely that anyone would even notice that you wanted
a validation of something.
 

 Anyone with sufficient technical competence carefully
studying what I have said that is not so biased against
my position that they can actually pay complete attention
will understand that I am correct.

 Nope, only someone as mentally deranged as yourself would believe your lies.
 

 If this was not the case then there could be a correct
rebuttal to what I am saying now. Instead of any correct
rebuttal all that has been provided is persistently
false assumptions.

 There has been, but it has appearently been over you head.
 You have demonstarted this by making this claim many times, and the errors you have ignored pointed out.
 

 A termination analyzer / partial halt decider is
required to report on the behavior of the sequence
of state transitions that its input actually specifies.
It is not allowed to report on anything else.
 

 Right, and that sequence of states spedified by that input, is the sequence of states actually generated by that program when run,

 

int main()
{
   DDD(); // calls HHH(DDD) that is not allowed to report
}        // on the behavior of its caller.
 Richard pretends to not understand that a function
that calls another function is not itself the actual
input to the function that it calls.

 Richard does not pretend. You do but it does not work.
 In the followeing code fragment the identifier appears twice.
First it is defined. Later it is used to specify that the
argument to that function shall be a pointer to the function
where the call is. Using that pointer the called function
can access the calling function.

 main() is not part of the input to HHH(DDD) thus
HHH cannot possibly see its actual caller.

 The main quited above does not call HHH so its actual caller is
elsewhere and your "this" is wrong.

 In other words you don't know as much as any CS graduate
that knows that a function cannot examine its caller.

 Your "in other words" is an attempt of a straw man deception.
 

 int main()
{
   HHH(DDD);
   HERE: goto HERE;
}
 So then try to show how HHH(DDD) can report on the
behavior of its caller: main()

Your HHH implementation uses non-standard extensions to C. Your
C compiler provides those extensions to C and others that let
you read base pointer and then the return address of HHH. Then
you can simulate the remaining behaviour of the calling program
to determine whether it would halt.
I don't think doing it would be useful but at least it is possible.
--
Mikko