Re: Hypothetical possibilities -- I reread this again more carefully

On 7/21/24 12:15 AM, olcott wrote:

On 7/20/2024 10:51 PM, Richard Damon wrote:

On 7/20/24 11:14 PM, olcott wrote:

On 7/20/2024 8:46 PM, Richard Damon wrote:

On 7/20/24 9:23 PM, olcott wrote:

On 7/20/2024 8:01 PM, Richard Damon wrote:

On 7/20/24 8:21 PM, olcott wrote:

On 7/20/2024 7:05 PM, Richard Damon wrote:

On 7/20/24 7:06 PM, olcott wrote:

On 7/20/2024 6:00 PM, Richard Damon wrote:

On 7/20/24 6:47 PM, olcott wrote:

On 7/20/2024 5:11 PM, Richard Damon wrote:

On 7/20/24 5:21 PM, olcott wrote:

On 7/20/2024 4:06 PM, joes wrote:

Am Sat, 20 Jul 2024 15:05:53 -0500 schrieb olcott:

On 7/20/2024 2:50 PM, Richard Damon wrote:

On 7/20/24 3:09 PM, olcott wrote:

On 7/20/2024 2:00 PM, Fred. Zwarts wrote:

Op 20.jul.2024 om 17:28 schreef olcott:

>

(a) Termination Analyzers / Partial Halt Deciders must halt this is
a design requirement.
(b) Every simulating termination analyzer HHH either aborts the
simulation of its input or not.
(c) Within the hypothetical case where HHH does not abort the
simulation of its input {HHH, emulated DDD and executed DDD}
never stop running.
This violates the design requirement of (a) therefore HHH must abort
the simulation of its input.

You missed a couple details:
A terminating input shouldn't be aborted, or at least not classified
as not terminating. Terminating inputs needn't be aborted; they and the
simulator halt on their own.
>

And when it aborts, the simulation is incorrect. When HHH aborts and
halts, it is not needed to abort its simulation, because it will halt
of its own.

So you are trying to get away with saying that no HHH ever needs to
abort the simulation of its input and HHH will stop running?

Pretty much.

It is the fact that HHH DOES abort its simulation that makes it not
need to.

No stupid it is not a fact that every HHH that can possibly exist aborts
its simulation.

I thought they all halt after a finite number of steps?
>

>
void DDD()
{
    HHH(DDD);
    return;
}
>
DDD correctly simulated by pure function HHH cannot
possibly reach its own return instruction.
>

>
Wrong.
>

>
You know that you are lying about this as you admit below:

>
Nope, YOU just don't what the words mean, and reckless disregard the teaching you have been getting, which makes your errors not just honest mistakes but reckless pathological lies.
>

>

It may be that the simulation by HHH never reaches that point,

>

but if HHH aborts its simuliaton and returns (as required for it to be a decider) then the behavior of DDD

>
Simulated by HHH is to Die, stop running, no longer function.

>
Nope, HHH is NOT the "Machine" that determines what the code does, so can not "Kill" it.
>

>
So you are trying to get away with the lie
that an aborted simulation keeps on running.
>

>
No, but the BEHAVIOR of the program does, and that is what matters.

>
So you agree that DDD correctly simulated by any pure function
HHH cannot possibly reach its own return instruction?
>
>

>
No, I will let you claim (without proof, so we can argue tha later) that the simulation by HHH of DDD does not reach the return, but the behavior of the DDD simuliated by HHH continues,

>
We are talking about real hardware here not figments
of your imagination.
>

>
No, you are not. The "Hardware" would be the actual CPU chip which never stops the program when it is running. A Simulator is just a piece of software running on it, and what it does can't affect the behavior of the actual CPU running the program.
>
>

When an actual x86 emulator stops emulating its input
this emulated input immediately stops running.
>

>
Nope, that is you stupidity where you confuse the observation for the facts.
>
It has been told to you MANY times, but it seems that you just can not understand it.
>
The SIMULATION is an observation of the program, that if it stops doesn't affect the actual behavior of the program in question.
>

>
*If the simulator stops simulating then the simulated stops running*

>
No, the SIMULA*TION* stops running, the SIMULATED (which is the actual program) behaviof continues.
>

 Yes you are clueless.
 void DDD()
{
   HHH(DDD);
   return;
}
 When the simulation stops running the whole program
exits to the operating system.

Which just shows you don't understand the MEANING of the behavior of a program.
Behvior is the UNCHANING attribute of what the program does when it is run. As such, aborting a simulation of it doesn't stop behavior.
For example:
THe program:
int incr(int i) {
     i = i + 1;
     return i;
}
clearly has behavior of returning the value one bigger than its input (subject to numeric overflow).
Now, if I tell you that I have given the object code of this program to a simulator that stops if it sees an instruction that adds two numbers or increments a value, that doesn't change the behavior of the PROGRAM.
The SIMULATION of that program by THAT SIMULATOR may get aborted, but the behaivor of the program didn't change, because it CAN'T
Of course, that concept is probably beyond your ability to understand.
There is a difference between the PROGRAM, and an INSTANCE of the program being run, but my guess is you can only understand an instance, since that is fairly concrete, but not the concept of the program itself.
The exact same thing happens with DDD and HHH. The PROGRAM DDD will halt if the PROGRAM HHH aborts its simulation and returns, as will every instance of DDD that is allowed to go to completion (which is what the behavior refers to). The fact that the instances simulated by HHH are aborted doesn't mean that the behavior of the program DDD stopped there, because it CAN'T stop, except at a "final state".
Looking at your writtings, it is clear that you really don't understand abstract concepts, which makes it a shame that you decided that you goal was to do something in fields filled with abstractions that you just don't understand. But perhaps the issue was that because you couldn't understand them you fgured they must be wrong, and because it seems your Ego is unlimited, you figured (since you didn't really understand the depth of the nuances of the problems) that you could just redo the fields to something that made mre sense to your limited mind.
That doesn't work, and just makes it clear to the world how little you understand of what you are talking about.

 

Does you computer program stop at a point just because someone aborted a simulation at that poiint?
>