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

Am Wed, 19 Jun 2024 09:23:04 -0500 schrieb olcott:

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.

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.

That's just wrong. A program/machine has a fixed behaviour.

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
behavior of 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.

And completely.

The call to the emulated H0 from DDD correctly emulated by H0 CANNOT
POSSIBLY RETURN.

As a decider, H0 MUST 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?

The requirements of being a simulator AND a decider contradict each other.
That means that such a program cannot exist.

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?

A nonterminating program doesn't suddenly become one that does.

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.

This is the core issue.

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.

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.

Nobody is disputing that part. It's not a simulation, though.

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

--
joes