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?

--
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/20/24 5: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?

No, he includes the non-decider version of HHH that never aborts, he
needs that so he can lie that the DDD that calls that HHH and thus never
halts and needs to be aborted is the same input as given to all the ones
that do aborts.

Of course, that only works if the input that describes DDD does't
include the code for HHH (or the input is diffferent) but then it fails
to actually be a description of the input PROGRAM, or the input just
isn't a program and he is just lying about what he is doing.

His logic is based on a lying shell game where everything has just
slightly fuzzy definitions so he can change things behind the scenes as
he makes his various claims.

Just like his "correct simulation" definition.

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

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.

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 is to call HHH(DDD), for that HHH to partially emulate DDD, and (after the point in that DDD that it
emulated) abort that emulation and return and thus DDD will return.

You are just proving you don't understand the difference between the Reality/Truth of the actual behavior of the PROGRAM DDD, and the partial knowledge gotten from the partial emulition by HHH of the DDD given.

THis just shows you are not qualified to talk about either the field of Computation, or Logic, as you have fundamental errors in your
understandings.

You also clearly don't understand what a program is, as you seem to
continue to claim that the "input" given to HHH(DDD) only includes the
code of the C function of DDD, and not the REQUIRED code of the rest of
the program, so you again lack the necessary understanding and knowledge
of what programs are, (or what it means/needs to correctly emulate one)
or that you are just nothing but a pathological lying idiot who just
doesn't care about what is actually true.

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

olcott <polcott333@gmail.com> wrote:

[ .... ]

May God have mercy on your soul (if you have a soul).

Oh, I have a soul, all right. I don't have a god, though. ;-)

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

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

On 7/20/2024 3:03 PM, Alan Mackenzie wrote:

[ Followup-To: set ]

In comp.theory Fred. Zwarts <F.Zwarts@hetnet.nl> wrote:

[ .... ]

Olcott could not point to an error, but prefers to ignore it. So, I will >>> repeat it, until either an error is found, or olcott admits that HHH
cannot possibly simulate itself correctly.

This has the disadvantage of making your posts boring to read.  All but
one poster on this newsgroup KNOW that Olcott is wrong, here.

Continually repeating your argument won't get him to admit he's wrong.
Richard has been trying that for much longer than you have, with the
same lack of success.  Olcott's lack of capacity for abstract reasoning,
combined with his ignorance, combined with his arrogance, prevent him
learning at all.

May I suggest that you reconsider your strategy of endless repetition?

Thanks!

So you are going to stupidly disagree with this?

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

It *is* a fact that no DDD correctly simulated by any
pure function HHH ever reaches its own return instruction.

Since it isn't a fact that the behavior of DDD will never reach that
point for ALL DDD, since it will for any DDD built on an HHH that
aborts its emulaiton and returns (as requiremd to be a decider).

So, you are just proved to be a LIAR.

Yes, the emulation by HHH doesn't get to that point, but that just shows
your ignorance about the difference between the actual program and its
PARTIAL emulation, which highlights your lack of understanding of the
differece between fact and knowledge, which shows that you are
unqualified to talk about logic, or program theory,

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

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.

The "Behavior" of the input is what happens when it is completely run or simulated, INCLUDED all of the code of HHH that it uses.

You are just showing your utter ignorant stupidity about what you are
talking about.

call HHH(DDD), for that HHH to

Why condemn yourself to Hell over this?

I'm not, but you might be.

Lying about the meaning of the terms is just lying. Even if you don't understand them, they have been explained to you enough that your
ignoring them make your statement a reckless disregard for the truth,
which is part of lying.

partially emulate DDD, and (after the point in that DDD that it
emulated) abort that emulation and return and thus DDD will return.

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

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.

You seem to be stuck in YOUR LIE, that the simulation determines what
the program does, not just observes it, because you don't understand the difference between the Truth itself and the ways to get Knowledge about it.

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

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, to the return if HHH aborts its simulation and returns, as the behavior of ALL copies of DDD do not
"stop" just because some simulator gave up looking at it.

I don't see how you get any agreement by me except by your totally misunderstanding English.

English lesson:

"DDD simulated by HHH" has as its subject, the PROGRAM DDD that we are specifing is the version of DDD that is being simulated by the HHH, but
being a PROGRAM, its behavior continues until it reaches the end. The simulation mentioned isn't a factor in that at all.

"The Simulation by HHH of DDD" has as its subject, the Simulation
itself, so the characteristics of that simulation are what is of
concern, and the "of DDD" and "by HHH" are refining which simulation we
are talking about.

The Halting Question is STRICTLY about the first case, the actual
behavior of DDD, which no HHH ever gets right by your description.

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

On 7/20/24 9:35 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, to the return if HHH
aborts its simulation and returns, as the behavior of ALL copies of
DDD do not "stop" just because some simulator gave up looking at it.

In other words you never understood that the input to an x86
emulator is a static finite string of bytes that does not do
anything at all on its own?

But it represents a program that does, and the question is about that
program.

It seems "representing" is a abstraction that is a bridge too far for
you mental ability, and that might be the same problem with "Truth",
since there is a abstract nature to what Truth is, as Truth can exist
without having anything to actually sense to make it occur.

That your mind can't handle abstractions would explain a lot of your
problems.

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

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.

After all, if you are running a copy of the program on your computer,
and someone on another computer is debugging a copy of that program in a simulator and aborts the simulation, does you copy of it stop running?

No, because the actual running copies are not affected by a copy being simulated.

This seems to go very deep into a fundamental misunderstanding you have
about what is truth that just makes it impossible for you to actually
reason about things correctly. It seems you just have a mental block on
this, perhaps due to your gaslighting yourself with your lies.

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

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

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

On 7/20/24 9:35 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, to the return if
HHH aborts its simulation and returns, as the behavior of ALL copies
of DDD do not "stop" just because some simulator gave up looking at it. >>>>

In other words you never understood that the input to an x86
emulator is a static finite string of bytes that does not do
anything at all on its own?

But it represents a program that does,

There is no representing to it.
It is static data within the x86 emulator process.

In other words, you have just been lying for years about doing the
Halting problem, whose input is the reperesentation of the program to be decided.

No program to be decided on, no program to be emulated.

It mean you are just admitting that all you are doing is talking about
your POOP.

Throw away to problems actual definition and all you work that you claim
to be ablut it become nothing but LIES.

You can't even connect that string of bytes to you description of it
being "DDD" without a concept of representation, as the bytes do not
have names on them.

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

On 7/20/24 10:25 PM, olcott wrote:

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

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

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

On 7/20/24 9:35 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,
to the return if HHH aborts its simulation and returns, as the
behavior of ALL copies of DDD do not "stop" just because some
simulator gave up looking at it.

In other words you never understood that the input to an x86
emulator is a static finite string of bytes that does not do
anything at all on its own?

But it represents a program that does,

There is no representing to it.
It is static data within the x86 emulator process.

In other words, you have just been lying for years about doing the
Halting problem, whose input is the reperesentation of the program to
be decided.

No program to be decided on, no program to be emulated.

There is never any representing involved when a simulator
correctly simulates a finite string.

Then you just don't understand the nature of the problem. But then, that
is an abstract concept which seems to be beyond your mental ability.

It has always been a mapping from the static finite string
to the behavior specified by this finite string.

That is what the decider does, but not what determines that correct answer.

HHH gives exactly the answer you programmed it to do, (as all programs
do), it just isn't the answer required by the problem.

But since you don't understand representation, and claim there isn't one involved, so the program can't actually be working on a problem that it
has been defined to not be able to do, even though you claim it to do so.

The PROBLEM sand ays the input needs to be a representation of the
program that you are asking about, but since you say that the input
doesn't actually represent a program, it can't be a Halt Decider.

But even if we look past that lie, and ask about the ACTUAL BEHAVIOR of
the program you are cliaiming it to be deciding, that would be the DDD()
that calls the HHH(DDD) that gave the answer, and that program clearly
halts, and thus an actual correct simulation of that program will halt,
even if HHH's partial simulaition can't get there.

So, you are just buring you work under your pile of POOP. If the byte
string is NOT supposed to be a representation of the program DDD(), then
HHH just can not be a Halt Decider.

It mean you are just admitting that all you are doing is talking about
your POOP.

Throw away to problems actual definition and all you work that you
claim to be ablut it become nothing but LIES.

You can't even connect that string of bytes to you description of it
being "DDD" without a concept of representation, as the bytes do not
have names on them.

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

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

On 7/20/2024 9:55 PM, Richard Damon wrote:

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

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

On 7/20/24 9:52 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,

Not at all. It is the same as a finite string of static data
interpreted by an interpreter. It is merely data within the
process of the x86 emulator. When the emulator stops emulating
it immediately stops.

In other words, you have just been lying for years about doing the
Halting problem, whose input is the reperesentation of the program
to be decided.

No program to be decided on, no program to be emulated.

I was shocked to find out that you really believed that a static
finite string could keep running after its x86 emulator stopped
emulating it.

I thought that you understood that when an interpreter stops
interpreting its input source-code the the interpreted program
would stop.

I guess I need to be shocked that you so poorly understand the problem

Trying to get away with changing the subject won't work.

Nope, not changing the subject but going back to your claims, which you
just admitted you have been lying about.

Your knowledge of software engineering is apparently
insufficient to understand very basic ideas that are
a mandatory prerequisite.

Nope, I know what you are talking about, but you just admitted to being
a liar and nothing you have done has any bearing on the halting problem.

If your input is NOT a representation of a program, and the criteria is
NOT if that program halts or not, then you are just lying about working
on the halting problem.

If the input you are giving doesn't contain the code for HHH, then you
are just lying that you can emulatioe the input past 4 instructions.

You are just admitting that all your work is just a LIE, and you are
nothing but an ignorant pathologcial liar.

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

Op 21.jul.2024 om 05:25 schreef olcott:

On 7/20/2024 3:03 PM, Alan Mackenzie wrote:

[ Followup-To: set ]

In comp.theory Fred. Zwarts <F.Zwarts@hetnet.nl> wrote:

[ .... ]

Olcott could not point to an error, but prefers to ignore it. So, I will >>> repeat it, until either an error is found, or olcott admits that HHH
cannot possibly simulate itself correctly.

This has the disadvantage of making your posts boring to read.  All but
one poster on this newsgroup KNOW that Olcott is wrong, here.

Continually repeating your argument won't get him to admit he's wrong.
Richard has been trying that for much longer than you have, with the
same lack of success.  Olcott's lack of capacity for abstract reasoning,
combined with his ignorance, combined with his arrogance, prevent him
learning at all.

May I suggest that you reconsider your strategy of endless repetition?

Thanks!

I have made slight changes to what I have been saying nearly every day.
This is my newest clearest way of saying it:

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

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

Which proves that the simulation is not correct.




DDD is a misleading and unneeded complication. It is easy to eliminate DDD:

int main() {
return HHH(main);
}

This has the same problem. This proves that the problem is not in DDD,
but in HHH, which halts when it aborts the simulation, but it decides
that the simulation of itself does not halt.
It shows that HHH cannot possibly simulate itself correctly.

HHH is simply unable to decide about finite recursions.

void Finite_Recursion (int N) {
if (N > 0) Finite_Recursion (N - 1);
}

It decides after N recursions that there is an infinite recursion, which
is incorrect.

Olcott's HHH is programmed to abort the simulation after N cycles of
recursive simulations. Therefore, it is incorrect to abort the
simulation of HHH when the simulated HHH has performed only N-1 cycles,
because that changes the behaviour of HHH.
Since the simulated HHH always runs one cycle behind the simulating HHH,
it is clear that HHH can never simulate enough cycles for a correct
simulation, as is required by the x86 language.
Therefore, the simulation is incorrect according to the criteria olcott stipulated.
The conclusion is simple:
HHH cannot possibly simulate itself correctly.

No matter how much olcott wants it to be correct, or how many times
olcott repeats that it is correct, it does not change the fact that such
a simulation is incorrect, because it is unable to reach the end.
Olcott's own claim that the simulated HHH does not reach its end
confirms it. The trace he has shown also proves that HHH cannot reach
the end of its own simulation. So, his own claims prove that it is true
that HHH cannot possibly simulate itself up to the end, which makes the simulation incorrect.

Sipser would agree that this incorrect simulation cannot be used to
detect a non-halting behaviour.

Olcott does not know how to point to an error in this explanation, but
prefers to ignore it. He even consistently removes it from the
citations. So, I will repeat it, until either an error is found, or
olcott admits that HHH cannot possibly simulate itself correctly.


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

Op 20.jul.2024 om 22:08 schreef olcott:

On 7/20/2024 3:03 PM, Alan Mackenzie wrote:

[ Followup-To: set ]

In comp.theory Fred. Zwarts <F.Zwarts@hetnet.nl> wrote:

[ .... ]

Olcott could not point to an error, but prefers to ignore it. So, I will >>> repeat it, until either an error is found, or olcott admits that HHH
cannot possibly simulate itself correctly.

This has the disadvantage of making your posts boring to read.  All but
one poster on this newsgroup KNOW that Olcott is wrong, here.

Continually repeating your argument won't get him to admit he's wrong.
Richard has been trying that for much longer than you have, with the
same lack of success.  Olcott's lack of capacity for abstract reasoning,
combined with his ignorance, combined with his arrogance, prevent him
learning at all.

May I suggest that you reconsider your strategy of endless repetition?

Thanks!

So you are going to stupidly disagree with this?

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

It *is* a fact that no DDD correctly simulated by any
pure function HHH ever reaches its own return instruction.

Which proves that these simulations are incorrect.


DDD is a misleading and unneeded complication. It is easy to eliminate DDD:

int main() {
return HHH(main);
}

This has the same problem. This proves that the problem is not in DDD,
but in HHH, which halts when it aborts the simulation, but it decides
that the simulation of itself does not halt.
It shows that HHH cannot possibly simulate itself correctly.

HHH is simply unable to decide about finite recursions.

void Finite_Recursion (int N) {
if (N > 0) Finite_Recursion (N - 1);
}

It decides after N recursions that there is an infinite recursion, which
is incorrect.

Olcott's HHH is programmed to abort the simulation after N cycles of
recursive simulations. Therefore, it is incorrect to abort the
simulation of HHH when the simulated HHH has performed only N-1 cycles,
because that changes the behaviour of HHH.
Since the simulated HHH always runs one cycle behind the simulating HHH,
it is clear that HHH can never simulate enough cycles for a correct
simulation, as is required by the x86 language.
Therefore, the simulation is incorrect according to the criteria olcott stipulated.
The conclusion is simple:
HHH cannot possibly simulate itself correctly.

No matter how much olcott wants it to be correct, or how many times
olcott repeats that it is correct, it does not change the fact that such
a simulation is incorrect, because it is unable to reach the end.
Olcott's own claim that the simulated HHH does not reach its end
confirms it. The trace he has shown also proves that HHH cannot reach
the end of its own simulation. So, his own claims prove that it is true
that HHH cannot possibly simulate itself up to the end, which makes the simulation incorrect.

Sipser would agree that this incorrect simulation cannot be used to
detect a non-halting behaviour.

Olcott does not know how to point to an error in this explanation, but
prefers to ignore it. He even consistently removes it from the
citations. So, I will repeat it, until either an error is found, or
olcott admits that HHH cannot possibly simulate itself correctly.

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

Op 21.jul.2024 om 16:27 schreef olcott:

On 7/21/2024 5:34 AM, Fred. Zwarts wrote:

Op 21.jul.2024 om 05:25 schreef olcott:

On 7/20/2024 3:03 PM, Alan Mackenzie wrote:

[ Followup-To: set ]

In comp.theory Fred. Zwarts <F.Zwarts@hetnet.nl> wrote:

[ .... ]

Olcott could not point to an error, but prefers to ignore it. So, I
will
repeat it, until either an error is found, or olcott admits that HHH >>>>> cannot possibly simulate itself correctly.

This has the disadvantage of making your posts boring to read.  All but >>>> one poster on this newsgroup KNOW that Olcott is wrong, here.

Continually repeating your argument won't get him to admit he's wrong. >>>> Richard has been trying that for much longer than you have, with the
same lack of success.  Olcott's lack of capacity for abstract
reasoning,
combined with his ignorance, combined with his arrogance, prevent him
learning at all.

May I suggest that you reconsider your strategy of endless repetition? >>>>
Thanks!

I have made slight changes to what I have been saying nearly every day.
This is my newest clearest way of saying it:

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

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

Which proves that the simulation is not correct.

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

When you disagree with the semantics of the meaning
of the x86 machine code instructions of DDD you are
taking a break from reality.

But since it is *you* who does not understand that skipping instructions
is against the semantics of the meaning of the x86 language, we know who
is far from reality.
Skipping the last cycle of the simulation of HHH, after which it would
halt, is against the semantics of the x86 language.



DDD is a misleading and unneeded complication. It is easy to eliminate DDD:

int main() {
return HHH(main);
}

This has the same problem. This proves that the problem is not in DDD,
but in HHH, which halts when it aborts the simulation, but it decides
that the simulation of itself does not halt.
It shows that HHH cannot possibly simulate itself correctly.

HHH is simply unable to decide about finite recursions.

void Finite_Recursion (int N) {
if (N > 0) Finite_Recursion (N - 1);
}

It decides after N recursions that there is an infinite recursion, which
is incorrect.

Olcott's HHH is programmed to abort the simulation after N cycles of
recursive simulations. Therefore, it is incorrect to abort the
simulation of HHH when the simulated HHH has performed only N-1 cycles,
because that changes the behaviour of HHH.
Since the simulated HHH always runs one cycle behind the simulating HHH,
it is clear that HHH can never simulate enough cycles for a correct
simulation, as is required by the x86 language.
Therefore, the simulation is incorrect according to the criteria olcott stipulated.
The conclusion is simple:
HHH cannot possibly simulate itself correctly.

No matter how much olcott wants it to be correct, or how many times
olcott repeats that it is correct, it does not change the fact that such
a simulation is incorrect, because it is unable to reach the end.
Olcott's own claim that the simulated HHH does not reach its end
confirms it. The trace he has shown also proves that HHH cannot reach
the end of its own simulation. So, his own claims prove that it is true
that HHH cannot possibly simulate itself up to the end, which makes the simulation incorrect.

Sipser would agree that this incorrect simulation cannot be used to
detect a non-halting behaviour.

Olcott does not know how to point to an error in this explanation, but
prefers to ignore it. He even consistently removes it from the
citations. So, I will repeat it, until either an error is found, or
olcott admits that HHH cannot possibly simulate itself correctly.

--
Paradoxes in the relation between Creator and creature. <http://www.wirholt.nl/English>.

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

Op 21.jul.2024 om 16:25 schreef olcott:

On 7/21/2024 5:25 AM, Fred. Zwarts wrote:

Op 20.jul.2024 om 22:08 schreef olcott:

On 7/20/2024 3:03 PM, Alan Mackenzie wrote:

[ Followup-To: set ]

In comp.theory Fred. Zwarts <F.Zwarts@hetnet.nl> wrote:

[ .... ]

Olcott could not point to an error, but prefers to ignore it. So, I
will
repeat it, until either an error is found, or olcott admits that HHH >>>>> cannot possibly simulate itself correctly.

This has the disadvantage of making your posts boring to read.  All but >>>> one poster on this newsgroup KNOW that Olcott is wrong, here.

Continually repeating your argument won't get him to admit he's wrong. >>>> Richard has been trying that for much longer than you have, with the
same lack of success.  Olcott's lack of capacity for abstract
reasoning,
combined with his ignorance, combined with his arrogance, prevent him
learning at all.

May I suggest that you reconsider your strategy of endless repetition? >>>>
Thanks!

So you are going to stupidly disagree with this?

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

It *is* a fact that no DDD correctly simulated by any
pure function HHH ever reaches its own return instruction.

Which proves that these simulations are incorrect.

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

*You don't get to be the judge of this*

Neither are *you*.

As long as the x86 machine language instructions of DDD
are emulated by HHH according to the semantic meaning
of these instructions then the emulation is correct and
anyone that disagrees is disagreeing with a tautology.

But if some x86 instructions are skipped, then it is dishonest to say
that it is a correct simulation. If the last cycle of HHH, after which
it would halt, is skipped by the simulation, then the simulation is
incorrect.
It is dishonest to deny that skipping instructions is correct according
to the semantics of the x86 language.

This correct emulation must take into account the fact
that DDD is calling its own emulator: HHH(DDD) in recursive
emulation.

And since HHH cannot possibly simulate itself correctly, the simulation
of DDD is incorrect.


DDD is a misleading and unneeded complication. It is easy to eliminate DDD:

int main() {
return HHH(main);
}

This has the same problem. This proves that the problem is not in DDD,
but in HHH, which halts when it aborts the simulation, but it decides
that the simulation of itself does not halt.
It shows that HHH cannot possibly simulate itself correctly.

HHH is simply unable to decide about finite recursions.

void Finite_Recursion (int N) {
if (N > 0) Finite_Recursion (N - 1);
}

It decides after N recursions that there is an infinite recursion, which
is incorrect.

Olcott's HHH is programmed to abort the simulation after N cycles of
recursive simulations. Therefore, it is incorrect to abort the
simulation of HHH when the simulated HHH has performed only N-1 cycles,
because that changes the behaviour of HHH.
Since the simulated HHH always runs one cycle behind the simulating HHH,
it is clear that HHH can never simulate enough cycles for a correct
simulation, as is required by the x86 language.
Therefore, the simulation is incorrect according to the criteria olcott stipulated.
The conclusion is simple:
HHH cannot possibly simulate itself correctly.

No matter how much olcott wants it to be correct, or how many times
olcott repeats that it is correct, it does not change the fact that such
a simulation is incorrect, because it is unable to reach the end.
Olcott's own claim that the simulated HHH does not reach its end
confirms it. The trace he has shown also proves that HHH cannot reach
the end of its own simulation. So, his own claims prove that it is true
that HHH cannot possibly simulate itself up to the end, which makes the simulation incorrect.

Sipser would agree that this incorrect simulation cannot be used to
detect a non-halting behaviour.

Olcott does not know how to point to an error in this explanation, but
prefers to ignore it. He even consistently removes it from the
citations. So, I will repeat it, until either an error is found, or
olcott admits that HHH cannot possibly simulate itself correctly.

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

Am Sun, 21 Jul 2024 18:42:26 +0200 schrieb Fred. Zwarts:

Op 21.jul.2024 om 16:25 schreef olcott:

On 7/21/2024 5:25 AM, Fred. Zwarts wrote:

Op 20.jul.2024 om 22:08 schreef olcott:

On 7/20/2024 3:03 PM, Alan Mackenzie wrote:

In comp.theory Fred. Zwarts <F.Zwarts@hetnet.nl> wrote:

Olcott could not point to an error, but prefers to ignore it. So, I >>>>>> will repeat it, until either an error is found, or olcott admits
that HHH cannot possibly simulate itself correctly.

This has the disadvantage of making your posts boring to read.  All >>>>> but one poster on this newsgroup KNOW that Olcott is wrong, here.
Continually repeating your argument won't get him to admit he's
wrong. Richard has been trying that for much longer than you have,
with the same lack of success.  Olcott's lack of capacity for
abstract reasoning,
combined with his ignorance, combined with his arrogance, prevent
him learning at all.
May I suggest that you reconsider your strategy of endless
repetition?

Yes. It is as spammy as olcott themselves, or Richard for that matter.

As long as the x86 machine language instructions of DDD are emulated by
HHH according to the semantic meaning of these instructions then the
emulation is correct and anyone that disagrees is disagreeing with a
tautology.

But if some x86 instructions are skipped, then it is dishonest to say
that it is a correct simulation. If the last cycle of HHH, after which
it would halt, is skipped by the simulation, then the simulation is incorrect.
It is dishonest to deny that skipping instructions is correct according
to the semantics of the x86 language.

Well put

This correct emulation must take into account the fact that DDD is
calling its own emulator: HHH(DDD) in recursive emulation.

And since HHH cannot possibly simulate itself correctly, the simulation
of DDD is incorrect.
DDD is a misleading and unneeded complication. It is easy to eliminate
DDD:
int main() {
return HHH(main);
}
This has the same problem. This proves that the problem is not in DDD,
but in HHH, which halts when it aborts the simulation, but it decides
that the simulation of itself does not halt.
It shows that HHH cannot possibly simulate itself correctly.

Yes. Why does HHH think it doesn't halt, when it makes damn sure to halt?

HHH is simply unable to decide about finite recursions.
void Finite_Recursion (int N) {
if (N > 0) Finite_Recursion (N - 1);
}
It decides after N recursions that there is an infinite recursion, which
is incorrect.

Do you agree with this analysis?

Olcott does not know how to point to an error in this explanation, but prefers to ignore it. He even consistently removes it from the
citations. So, I will repeat it, until either an error is found, or
olcott admits that HHH cannot possibly simulate itself correctly.

WONTFIX

--
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 2024-07-20 15:28:31 +0000, olcott said:

void DDD()
{
HHH(DDD);
}

int main()
{
DDD();
}

(a) Termination Analyzers / Partial Halt Deciders must halt
this is a design requirement.

For a partial analyzer or deciders this is not always required.

(b) Every simulating termination analyzer HHH either
aborts the simulation of its input or not.

This must be interpreted to mean that a simulating termination analyzer
may abort its simulation for some simulated abort and simulate others
to the termination.

(c) Within the hypothetical case where HHH does not abort
the simulation of its input {HHH, emulated DDD and executed DDD}
never stop running.

The case is not very hypothetical. Given the HHH you already have,
it is fairly easy to construct the "hypothetical" HHH and see what
it actually does.

This violates the design requirement of (a) therefore HHH must
abort the simulation of its input.

The violation simply means that the "hypothetical" HHH is not a
termination analyzer of partial halt decider in sense (a). What
it "must" be or do depends on the requirements.

--
Mikko

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

Op 22.jul.2024 om 17:10 schreef olcott:

On 7/21/2024 11:47 AM, Fred. Zwarts wrote:

Op 21.jul.2024 om 16:27 schreef olcott:

On 7/21/2024 5:34 AM, Fred. Zwarts wrote:

Op 21.jul.2024 om 05:25 schreef olcott:

On 7/20/2024 3:03 PM, Alan Mackenzie wrote:

[ Followup-To: set ]

In comp.theory Fred. Zwarts <F.Zwarts@hetnet.nl> wrote:

[ .... ]

Olcott could not point to an error, but prefers to ignore it. So, >>>>>>> I will
repeat it, until either an error is found, or olcott admits that HHH >>>>>>> cannot possibly simulate itself correctly.

This has the disadvantage of making your posts boring to read.
All but
one poster on this newsgroup KNOW that Olcott is wrong, here.

Continually repeating your argument won't get him to admit he's
wrong.
Richard has been trying that for much longer than you have, with the >>>>>> same lack of success.  Olcott's lack of capacity for abstract
reasoning,
combined with his ignorance, combined with his arrogance, prevent him >>>>>> learning at all.

May I suggest that you reconsider your strategy of endless
repetition?

Thanks!

I have made slight changes to what I have been saying nearly every
day.
This is my newest clearest way of saying it:

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

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

Which proves that the simulation is not correct.

_DDD()
[00002163] 55         push ebp      ; housekeeping
[00002164] 8bec       mov ebp,esp   ; housekeeping
[00002166] 6863210000 push 00002163 ; push DDD
[0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
[00002170] 83c404     add esp,+04
[00002173] 5d         pop ebp
[00002174] c3         ret
Size in bytes:(0018) [00002174]

When you disagree with the semantics of the meaning
of the x86 machine code instructions of DDD you are
taking a break from reality.

But since it is *you* who does not understand that skipping
instructions is against the semantics of the meaning of the x86
language, we know who is far from reality.
Skipping the last cycle of the simulation of HHH, after which it would
halt, is against the semantics of the x86 language.

It seems that your lack sufficient understanding of
ordinary programming.

Irrelevant nonsense ignored.

I am talking about hypothetical possible ways that HHH could be encoded.
(a) HHH(DDD) is encoded to abort its simulation.
(b) HHH(DDD) is encoded to never abort its simulation.

Therefore (a) is correct and (b) is incorrect according to the
design requirements for HHH that it must halt.

It is also a truism that any input that must be aborted
is a non-halting input.

It is a truism that HHH cannot possibly simulate itself correctly.
Both hypothetical ways to encode HHH result in an incorrect simulation.

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

On 2024-07-22 15:05:41 +0000, olcott said:

On 7/22/2024 6:05 AM, Mikko wrote:

On 2024-07-20 15:28:31 +0000, olcott said:

void DDD()
{
   HHH(DDD);
}

int main()
{
   DDD();
}

(a) Termination Analyzers / Partial Halt Deciders must halt
this is a design requirement.

For a partial analyzer or deciders this is not always required.

*You can't even get my words correctly*
A termination analyzer must report on the behavior of at least
one input for all of the inputs of this one input. This is
met when a termination analyzer analyzes an input having no inputs.

A partial halt decider must correctly determine the halt status
of at least one input and its specific input (if any).

HHH is both a partial halt decider and a termination analyzer
for DDD and a few other inputs having no input.

(b) Every simulating termination analyzer HHH either
aborts the simulation of its input or not.

This must be interpreted to mean that a simulating termination analyzer
may abort its simulation for some simulated abort and simulate others
to the termination.

I am talking about hypothetical possible ways that HHH could be encoded.
(a) HHH(DDD) is encoded to abort its simulation.
(b) HHH(DDD) is encoded to never abort its simulation.

(c) Within the hypothetical case where HHH does not abort
the simulation of its input {HHH, emulated DDD and executed DDD}
never stop running.

The case is not very hypothetical. Given the HHH you already have,
it is fairly easy to construct the "hypothetical" HHH and see what
it actually does.

(a) HHH(DDD) is encoded to abort its simulation.
(b) HHH(DDD) is encoded to never abort its simulation.

This violates the design requirement of (a) therefore HHH must
abort the simulation of its input.

The violation simply means that the "hypothetical" HHH is not a
termination analyzer of partial halt decider in sense (a). What
it "must" be or do depends on the requirements.

Therefore (a) is correct and (b) is incorrect according to the
design requirements for HHH that it must halt.

It is also a truism that any input that must be aborted
is a non-halting input.

No, it is not. The "must" and "non-halting" belong to different worlds.
The word "must" blongs to requirements. The word "non-halting" is a
feature of a program. They are unrelated, so one cannot be inferred
from the other.

--
Mikko

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

On 2024-07-23 14:41:11 +0000, olcott said:

On 7/23/2024 2:32 AM, Mikko wrote:

On 2024-07-22 15:05:41 +0000, olcott said:

On 7/22/2024 6:05 AM, Mikko wrote:

On 2024-07-20 15:28:31 +0000, olcott said:

void DDD()
{
   HHH(DDD);
}

int main()
{
   DDD();
}

(a) Termination Analyzers / Partial Halt Deciders must halt
this is a design requirement.

For a partial analyzer or deciders this is not always required.

*You can't even get my words correctly*
A termination analyzer must report on the behavior of at least
one input for all of the inputs of this one input. This is
met when a termination analyzer analyzes an input having no inputs.

A partial halt decider must correctly determine the halt status
of at least one input and its specific input (if any).

HHH is both a partial halt decider and a termination analyzer
for DDD and a few other inputs having no input.

(b) Every simulating termination analyzer HHH either
aborts the simulation of its input or not.

This must be interpreted to mean that a simulating termination analyzer >>>> may abort its simulation for some simulated abort and simulate others
to the termination.

I am talking about hypothetical possible ways that HHH could be encoded. >>> (a) HHH(DDD) is encoded to abort its simulation.
(b) HHH(DDD) is encoded to never abort its simulation.

(c) Within the hypothetical case where HHH does not abort
the simulation of its input {HHH, emulated DDD and executed DDD}
never stop running.

The case is not very hypothetical. Given the HHH you already have,
it is fairly easy to construct the "hypothetical" HHH and see what
it actually does.

(a) HHH(DDD) is encoded to abort its simulation.
(b) HHH(DDD) is encoded to never abort its simulation.

This violates the design requirement of (a) therefore HHH must
abort the simulation of its input.

The violation simply means that the "hypothetical" HHH is not a
termination analyzer of partial halt decider in sense (a). What
it "must" be or do depends on the requirements.

Therefore (a) is correct and (b) is incorrect according to the
design requirements for HHH that it must halt.

It is also a truism that any input that must be aborted
is a non-halting input.

No, it is not. The "must" and "non-halting" belong to different worlds.
The word "must" blongs to requirements. The word "non-halting" is a
feature of a program. They are unrelated, so one cannot be inferred
from the other.

When-so-ever there are two hypothetical possible way to encode
a simulating halt decider for a specific input
(a) one aborts its simulation of DDD
(b) never aborts its simulation of DDD

Does the simulator that simulates the beginning and end of the
simulated computation but skips a part in ghe middle belong to
class (a) or class (b)?

--
Mikko

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

On 2024-07-24 13:38:08 +0000, olcott said:

On 7/24/2024 4:01 AM, Mikko wrote:

On 2024-07-23 14:41:11 +0000, olcott said:

On 7/23/2024 2:32 AM, Mikko wrote:

On 2024-07-22 15:05:41 +0000, olcott said:

On 7/22/2024 6:05 AM, Mikko wrote:

On 2024-07-20 15:28:31 +0000, olcott said:

void DDD()
{
   HHH(DDD);
}

int main()
{
   DDD();
}

(a) Termination Analyzers / Partial Halt Deciders must halt
this is a design requirement.

For a partial analyzer or deciders this is not always required.

*You can't even get my words correctly*
A termination analyzer must report on the behavior of at least
one input for all of the inputs of this one input. This is
met when a termination analyzer analyzes an input having no inputs.

A partial halt decider must correctly determine the halt status
of at least one input and its specific input (if any).

HHH is both a partial halt decider and a termination analyzer
for DDD and a few other inputs having no input.

(b) Every simulating termination analyzer HHH either
aborts the simulation of its input or not.

This must be interpreted to mean that a simulating termination analyzer >>>>>> may abort its simulation for some simulated abort and simulate others >>>>>> to the termination.

I am talking about hypothetical possible ways that HHH could be encoded. >>>>> (a) HHH(DDD) is encoded to abort its simulation.
(b) HHH(DDD) is encoded to never abort its simulation.

(c) Within the hypothetical case where HHH does not abort
the simulation of its input {HHH, emulated DDD and executed DDD} >>>>>>> never stop running.

The case is not very hypothetical. Given the HHH you already have, >>>>>> it is fairly easy to construct the "hypothetical" HHH and see what >>>>>> it actually does.

(a) HHH(DDD) is encoded to abort its simulation.
(b) HHH(DDD) is encoded to never abort its simulation.

This violates the design requirement of (a) therefore HHH must
abort the simulation of its input.

The violation simply means that the "hypothetical" HHH is not a
termination analyzer of partial halt decider in sense (a). What
it "must" be or do depends on the requirements.

Therefore (a) is correct and (b) is incorrect according to the
design requirements for HHH that it must halt.

It is also a truism that any input that must be aborted
is a non-halting input.

No, it is not. The "must" and "non-halting" belong to different worlds. >>>> The word "must" blongs to requirements. The word "non-halting" is a
feature of a program. They are unrelated, so one cannot be inferred
from the other.

When-so-ever there are two hypothetical possible way to encode
a simulating halt decider for a specific input
(a) one aborts its simulation of DDD
(b) never aborts its simulation of DDD

Does the simulator that simulates the beginning and end of the
simulated computation but skips a part in ghe middle belong to
class (a) or class (b)?

That is off topic. I am only referring to a sequence of
1 to N x86 machine language instructions simulated according
to the x86 semantic meaning of these instructions.

No, it isn't. Abortion of simulation is a deviation form x86 macine
language semantics. What I ask about does not deviate more.

--
Mikko

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

On 2024-07-26 13:58:54 +0000, olcott said:

On 7/26/2024 3:05 AM, Mikko wrote:

On 2024-07-24 13:38:08 +0000, olcott said:

On 7/24/2024 4:01 AM, Mikko wrote:

On 2024-07-23 14:41:11 +0000, olcott said:

On 7/23/2024 2:32 AM, Mikko wrote:

On 2024-07-22 15:05:41 +0000, olcott said:

On 7/22/2024 6:05 AM, Mikko wrote:

On 2024-07-20 15:28:31 +0000, olcott said:

void DDD()
{
   HHH(DDD);
}

int main()
{
   DDD();
}

(a) Termination Analyzers / Partial Halt Deciders must halt
this is a design requirement.

For a partial analyzer or deciders this is not always required. >>>>>>>>

*You can't even get my words correctly*
A termination analyzer must report on the behavior of at least
one input for all of the inputs of this one input. This is
met when a termination analyzer analyzes an input having no inputs. >>>>>>>
A partial halt decider must correctly determine the halt status
of at least one input and its specific input (if any).

HHH is both a partial halt decider and a termination analyzer
for DDD and a few other inputs having no input.

(b) Every simulating termination analyzer HHH either
aborts the simulation of its input or not.

This must be interpreted to mean that a simulating termination analyzer
may abort its simulation for some simulated abort and simulate others >>>>>>>> to the termination.

I am talking about hypothetical possible ways that HHH could be encoded.
(a) HHH(DDD) is encoded to abort its simulation.
(b) HHH(DDD) is encoded to never abort its simulation.

(c) Within the hypothetical case where HHH does not abort
the simulation of its input {HHH, emulated DDD and executed DDD} >>>>>>>>> never stop running.

The case is not very hypothetical. Given the HHH you already have, >>>>>>>> it is fairly easy to construct the "hypothetical" HHH and see what >>>>>>>> it actually does.

(a) HHH(DDD) is encoded to abort its simulation.
(b) HHH(DDD) is encoded to never abort its simulation.

This violates the design requirement of (a) therefore HHH must >>>>>>>>> abort the simulation of its input.

The violation simply means that the "hypothetical" HHH is not a >>>>>>>> termination analyzer of partial halt decider in sense (a). What >>>>>>>> it "must" be or do depends on the requirements.

Therefore (a) is correct and (b) is incorrect according to the
design requirements for HHH that it must halt.

It is also a truism that any input that must be aborted
is a non-halting input.

No, it is not. The "must" and "non-halting" belong to different worlds. >>>>>> The word "must" blongs to requirements. The word "non-halting" is a >>>>>> feature of a program. They are unrelated, so one cannot be inferred >>>>>> from the other.

When-so-ever there are two hypothetical possible way to encode
a simulating halt decider for a specific input
(a) one aborts its simulation of DDD
(b) never aborts its simulation of DDD

Does the simulator that simulates the beginning and end of the
simulated computation but skips a part in ghe middle belong to
class (a) or class (b)?

That is off topic. I am only referring to  a sequence of
1 to N x86 machine language instructions simulated according
to the x86 semantic meaning of these instructions.

No, it isn't. Abortion of simulation is a deviation form x86 macine
language semantics. What I ask about does not deviate more.

In other words you are saying that it is absolutely impossible
to make an x86 program that is an x86 emulator that correctly
emulates a finite number of instructions of non-terminating
input x86 machine code.

You are lying again. That is not the same in other words, and I am
not saying what you falsely claim.

If a simulator correctly simulates a finite number of instructions
where x86 program specifies an execution of an infinite number of
instructions then the simulation deviates from x86 semantics at the
point where the simulation stops but the x86 semantics specify
countinuation.

That seems to be a pretty stupid thing to say when you know
that I have shown you an x86 program that does do those things.

That is indeed a stupid thig to say but you said it, I didn't.

--
Mikko

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