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

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

On 6/18/2024 9:41 PM, Richard Damon wrote:

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

On 6/18/2024 9:16 PM, Richard Damon wrote:

On 6/18/24 1:25 PM, olcott wrote:

On 6/18/2024 12:06 PM, joes wrote:
>
void DDD()
{
   H0(DDD);
}
>
DDD correctly simulated by any H0 cannot possibly halt.
>

DDD halts iff H0 halts.

>
Halting is a technical term-of-the-art that corresponds
to terminates normally. Because Turing machines are
abstract mathematical objects there has been no notion
of abnormal termination for a Turing machine.

>
No "normally" as Turing Machine have no "abnormal terminatiom"
>
You just don't understand what they are.
>

>
We can derive a notion of abnormal termination for Turing
machines from the standard terms-of-the-art.

>
How?
>

>
Some TM's loop and thus never stop running, this is classical
non-halting behavior. UTM's simulate Turing machine descriptions.
This is the same thing as an interpreter interpreting the
source-code of a program.
>
A UTM can be adapted so that it only simulates a fixed number
of iterations of an input that loops. When this UTM stops
simulating this Turing machine description we cannot correctly
say that this looping input halted.
>

>
And then are no longer UTMs, and YES, if a machine based on such am modifed UTM (so it is no long a UTM) when the UTM stops simulating, we can not say the input halted, nor can we say it didn't halt.
>

>
When such a UTM has been adapted to only simulate
the first ten states of its input TMD, then every
simulated TMD with more than ten states did not
terminate normally.

>
Then it is no longer a UTM.
>
And its simulation say NOTHING about the machine not terminating, normally nor not.
>
Terminating is a property of the actual machine, and not a sumulation of it.
>

 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.

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.
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.
This means the "Correct Simulation" of a non-halting program will be non-halting itself.
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.

 

You just have lost track of the defintions of what is REALITY (the actual behavior of the machine) and what is just imagination.
>

Not I but you.

Who is it that thinks that a Halting Program can be correctly decided as Non-Halting?

 

>

The not-a-UTM just came to a no-answer state.
>

>
I have to go one-step-at-a-time with everyone or
they get overwhelmed and leap to the conclusion
that I am wrong.

>
Nope, you just forget about what is defined to be real.
>

>

The answer will be provided by useing an ACTUAL UTM that keeps on going, or the direct execution of the machine,
>
You are just stuck in your idea that Lies are sometimes ok.

>
You are stuck on the idea that repeating states cannot
be recognized in a finite number of steps.

>
No, ACTUAL REPEATING states can be recognised, but I guess you are too stupid to understand my description of it.
>

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

>
Which doesn't mean the program DDD needs to be abort to have it halt.
>

 The verified that that it does need to be aborted contradicts
your nonsense to the contrary.

Nope. That hasn't been verified, you have tricked yourself to look at the wrong input.
Remember, Program behavior deciders (like Halt Deciders) take in representations of full programs, not templates, so when H takes in the description of D, it must get ALL the code of D, including the H that it calls. Yours claims that isn't what the input is, so you are living in a world of wrong definitions,

 

That is just a figment of your imagination that doesn't understand the difference between truth and lies.
>

>
This was recently confirmed in the C group.
>

>
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.
Your problem is you are using poorly defined words to phrase your question to have it mean something that it doesn't actually mean.