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

On 7/20/2024 10: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*

void DDD()
{
   HHH(DDD);
   return;
}

DDD *correctly simulated* by pure function HHH cannot
possibly reach its own return instruction.

Only DDD correctly emulated by HHH maps the finite string
of the x86 machine code of DDD to the behavior that it
actually specifies.

No, a correct emulation doesn't stop until it reaches a final state, and
an HHH that doesn't stop doesn't map the input to anything.

It is a FULLY CORRECT emulation of the input that shows that CORRECT
mapping that HHH was supposed to compute, but doesn't as you LIE about
it being correct.

First, the emulation needs ALL the code being emulated, which includes
the code of HHH, so by your definition, you can't do it so are a lair.

When we fix that by including that code, we find that if HHH(DDD) aborts
its PARTIAL simulation to return an answer (and it must or it isn't a
decider) then when we give that same input (which still calls that HHH
that aborted and returned) to a CORRECT emulator, and see what happens,
we see that DDD calls HHH(DDD) that emulates the string given to it for
awhile, and then it aborts its simulation and returns to DDD which returns,

So, all you have done is admitted that you are just a lying idiot that
doesn't know about what he is talking and haas wasted his life beliving
his own lies.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

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

void DDD()
{
  HHH(DDD);
  return;
}

DDD *correctly simulated* by pure function HHH cannot
possibly reach its own return instruction.

But HHH doesn't DO a "correct simulation" if it ever aborts and returns
the answer about not halting.

I guess you just don't know what "correct" means.

You are nothing but a pathetic ignorant pathological liar that has shows
that he has wasted his life by beliving his own lies.


The halting problem, BY ITS DEFINITION, as about a decider deciding from
an input representing the program to be decided on.

Since you claim the input doesn't represent a program, it can't be a
Halt Decider.

A program include all of the code that it uses.

Since you input doesn't include the code of the HHH that DDD calls, it
isn't a program, and the byte pattern can not be correctly emulated past
the first 4 instrucitons,

THis shows that you are nothing but a totally ignorant lying idiot.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Sat, 20 Jul 2024 22:31:04 -0500 schrieb olcott:

On 7/20/2024 10: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?

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.

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

The input doesn't even run. The simulator is the only thing in execution.

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*

The simulated program would still be non-halting.

DDD *correctly simulated* by pure function HHH cannot possibly reach
its own return instruction.

Only DDD correctly emulated by HHH maps the finite string of the x86
machine code of DDD to the behavior that it actually specifies.

Almost correct. Other simulators may map it too, to the behaviour
of the direct execution. HHH doesn't.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Sun, 21 Jul 2024 08:08:53 -0500 schrieb olcott:

On 7/21/2024 6:37 AM, Richard Damon wrote:

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:

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?

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.

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

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,

A simulated program doesn't actually run - it is only simulated.

The SIMULATION is an observation of the program, that if it stops
doesn't affect the actual behavior of the program in question.

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

When the simulation stops running the whole program exits to the
operating system.

Yes. That doesn't mean that DDD itself would terminate.

Because (a) We know that it is a logical impossibility for any decider
HHH to report on the halt status of any input that does the opposite of whatever it reports.
(b) We know that a decider is not allowed to report on the behavior computation that itself is contained within. Deciders only take finite
string inputs. They do not take executing processes as inputs. Thus HHH
is not allowed to report on the behavior of this int main() { DDD(); }.

That IS exactly the input.

Therefore we map the finite string input to HHH(DDD) to the behavior
that it species on the basis of DDD correctly emulated by any pure
function HHH that can possibly exist.

The basis is the direct behaviour.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Sun, 21 Jul 2024 09:19:43 -0500 schrieb olcott:

On 7/21/2024 4:05 AM, joes wrote:

Am Sat, 20 Jul 2024 22:31:04 -0500 schrieb olcott:

On 7/20/2024 10:14 PM, olcott wrote:

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

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

DDD *correctly simulated* by pure function HHH cannot possibly reach
its own return instruction.

Only DDD correctly emulated by HHH maps the finite string of the x86
machine code of DDD to the behavior that it actually specifies.

Almost correct. Other simulators may map it too, to the behaviour of
the direct execution. HHH doesn't.

No decider is ever allowed to report on the behavior of the actual computation that itself is contained within because all deciders only
take finite string inputs and thus never take a directly executing
process as an input.

Of course. A decider may, however, be given the description of its
enclosing program as input.

A Turing machine can report on the behavior that a finite string
specifies. It cannot report on the behavior of any executing Turing
machine including its own executing Turing machine.

See above.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Sun, 21 Jul 2024 09:34:57 -0500 schrieb olcott:

On 7/21/2024 9:24 AM, joes wrote:

Am Sun, 21 Jul 2024 08:08:53 -0500 schrieb olcott:

On 7/21/2024 6:37 AM, Richard Damon wrote:

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

(b) We know that a decider is not allowed to report on the behavior
computation that itself is contained within. Deciders only take finite
string inputs. They do not take executing processes as inputs. Thus
HHH is not allowed to report on the behavior of this int main() {
DDD(); }.

That IS exactly the input.

The behavior of emulated DDD after it has been aborted changes the
behavior of the directly existed DDD.

A deterministic program can't change. It was always going to be aborted.

When the second call of what would otherwise be infinite recursion is required to be aborted to prevent the infinite execution of the first
call this proves that HHH(DDD)==0 is correct even though the directly executed DDD() halts.

The second call stops simulating just like all others.

Therefore we map the finite string input to HHH(DDD) to the behavior
that it species on the basis of DDD correctly emulated by any pure
function HHH that can possibly exist.

The basis is the direct behaviour.

Unless you think the idea of UTMs is wrong-headed nonsense the behavior
of DDD correctly emulated by HHH determines the actual behavior
specified by the input to HHH(DDD).

HHH is not an UTM.

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Op 21.jul.2024 om 17:08 schreef olcott:

On 7/21/2024 9:54 AM, joes wrote:

Am Sun, 21 Jul 2024 09:34:57 -0500 schrieb olcott:

On 7/21/2024 9:24 AM, joes wrote:

Am Sun, 21 Jul 2024 08:08:53 -0500 schrieb olcott:

On 7/21/2024 6:37 AM, Richard Damon wrote:

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

(b) We know that a decider is not allowed to report on the behavior
computation that itself is contained within. Deciders only take finite >>>>> string inputs. They do not take executing processes as inputs. Thus
HHH is not allowed to report on the behavior of this int main() {
DDD(); }.

That IS exactly the input.

The behavior of emulated DDD after it has been aborted changes the
behavior of the directly existed DDD.

A deterministic program can't change. It was always going to be aborted.

None-the-less we can examine the exhaustively complete set
of every HHH/DDD pair that can possibly exist and find that
all of the HHH instances that never abort their simulation
of DDD never stop running.

And we find that all HHH that do abort, abort one cycle too soon, which
makes the simulation incomplete and, therefore, incorrect.
We find that the set of HHH that simulate correctly is empty.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/22/24 12:49 AM, olcott wrote:

On 7/21/2024 6:37 AM, Richard Damon wrote:

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

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

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.

*You are still totally clueless*

As soon as HHH(DDD) aborts its simulation HHH immediately
exits to the operating system.

No it return to its caller, or it isn't a decider.

You are just showing how clueless you are.

Turing Machines do not HAVE an "operating system" to return to.d

All you are doing is proving how totally ignorant you are of the field
you claim to be making groundbreaking discoveries in, which just show
you to be a pathological lying idiot with a reckless disregard for the
truth.

Face it, you are just showing how much you have wasted your life by
beleiving the lies you told yourself because you couldn't face the
actual Truth.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/22/24 8:47 AM, olcott wrote:

On 7/22/2024 6:27 AM, Richard Damon wrote:

On 7/22/24 12:49 AM, olcott wrote:

On 7/21/2024 6:37 AM, Richard Damon wrote:

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

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

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.

*You are still totally clueless*

As soon as HHH(DDD) aborts its simulation HHH immediately
exits to the operating system.

No it return to its caller, or it isn't a decider.

void DDD()
{
  HHH(DDD);
  return;
}

int main()
{
  HHH(DDD);
}

Unlike you I can admit my mistake.

As soon as HHH(DDD) aborts its simulation HHH immediately
returns to main() and
exits to the operating system.

Right, and thus the HHH that DDD calls will return to DDD and DDD will halt.

THAT is the definition of the behavior of DDD.

That HHH only sees part of it in its PARTIAL (and thus INCORRECT)
emulation just means it doesn't get the knowledge it needs of the right
answer.

You are just showing your ignorance of the words you use.

"Behavior" is an attribute of the program (with ITS input), and not some
other machines idea about it.

The partial emulation that HHH does is part of the behavior of HHH, and
reveals just PART of the behavior of the input DDD.

Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)