Re: Simulating termination analyzers by dummies --- What does halting mean?

On 6/19/2024 6:30 AM, Richard Damon wrote:

On 6/18/24 10:51 PM, olcott wrote:

>
Thus according to your faulty reasoning when the source-code
of a C program is simulated by interpreter this is mere nonsense
gibberish having nothing to do what the behavior that this
source-code specifies.
>

 Not at all, and just shows you don't understand the meaning of words, or how logic works.
 IF you can show that a given simulation will produce the exact same results as the direct execution of the program, then the simulation will show the actual behavior of the program.
 Now, if it doesn't. then it is gibberish.
 

No matter how much you try to simply ignore the verified fact that
the pathological relationship between an input and its termination analyzer changes the behavior of this emulated input relative to
the behavior of its direct execution
THIS VERIFIED FACT WILL NOT GO AWAY.

You could say the SIMULATION didn't terminate normally, but you can't say the machine didn't or even the Turing Machine Description, as you could give that exact same TMD to a real UTM and find out the actual behaviof or the input.
>

>
Sure you can otherwise interpreters of source-code would be
a bogus concept.

 Right, a CORRECT simulation is one that produces the same result as the original.
 

No. A correctly simulation is when each machine language instruction
of the input is correctly simulated and simulated in the correct order.
_DDD()
[000020a2] 55         push ebp      ; housekeeping
[000020a3] 8bec       mov ebp,esp   ; housekeeping
[000020a5] 68a2200000 push 000020a2 ; push DDD
[000020aa] e8f3f9ffff call 00001aa2 ; call H0
[000020af] 83c404     add esp,+04   ; housekeeping
[000020b2] 5d         pop ebp       ; housekeeping
[000020b3] c3         ret           ; never gets here
Size in bytes:(0018) [000020b3]
The call to the emulated H0 from DDD correctly emulated
by H0 CANNOT POSSIBLY RETURN.
The call to the directly executed H0 from the executed
DDD does return because
the directly executed D(D) is essentially the first call
in a recursive chain where the second call is always aborted.

When we are talking about halting, then it means that the simulator can't stop until it gets to the final state of the program it is simulating.
 

Why contradict the definition of a decider that must always halt?

This means the "Correct Simulation" of a non-halting program will be non-halting itself.
 

Why contradict the definition of a decider that must always halt?

This means that a program that is a correct simulator can't be a halt decider, as it could never answer non-halting, since it never finishes the simulation.
 It might be able to use a PARTIAL simulation, if it can show that if this exact input was given to a complete and correct simulator, it would not halt. This is NOT what you claim about your "Halt Deciders", which don't even take actual descriptions of programs.
 

void Infinite_Loop()
{
   HERE: goto HERE;
}
void Infinite_Recursion()
{
   Infinite_Recursion();
}
void DDD()
{
   H0(DDD);
}
Every C programmer that knows what an x86 emulator is knows
that when H0 emulates the machine language of Infinite_Loop,
Infinite_Recursion, and DDD that it must abort these emulations
so that itself can terminate normally.
If you don't know this then you simply lack the mandatory prerequisites.

Yes, by Bonita, whose confirmation is, if anything a mark against the statement.

>
Are you sure that you are not a liar?
I have had numerous experts in C confirm this.
Bonita confirmed this: "Everything correct"
>

 Yes.
 

Then you would not have lied about this:
Bonita confirmed this: "Everything correct"
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer