On 3/25/25 6:07 PM, olcott wrote:

On 3/25/2025 4:16 PM, joes wrote:

Am Tue, 25 Mar 2025 14:24:07 -0500 schrieb olcott:

Cannot possibly derive any outputs not computed from their inputs.

In particular, your HHH does not compute the behaviour of its input.

A Turing machine halt decider cannot possibly report on the behavior of
any directly executing process.
No Turing machine can every do this. This has always been beyond what
any Turing machine can ever do.
The best that any Turing machine halt decider can possibly do is
determine the behavior that an input finite string specifies.

Which iiis... surprise, whatever happens when you run it. You are
basically saying that simulators can make shit up.

When an input finite string specifies a pathological relationship with
its simulating halt decider the actual behavior that pathological
relationship derives must be reported because THAT IS THE BEHAVIOR THAT
IS SPECIFIED BY THIS INPUT FINITE STRING.

The relationship doesn't derive anything.
It is a tautology that a simulator reports what it reports. That doesn't
make that correct.

EEE emulates a finite number of steps EEE including
EEE emulating itself emulating III a finite number of times.

_III()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov  ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push III
[0000217a] e853f4ffff call 000015d2 ; call EEE(III)
[0000217f] 83c404     add  esp,+04
[00002182] 5d         pop  ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

III has different behavior when emulated by any EEE
than when it is emulated by any other emulator.

When III is emulated by EEE it never reaches its
final halt state.

When III is emulated by any other emulator it
ALWAYS reaches its final halt state.

ALWAYS is the opposite of NEVER.

So?

Since you defined that EEE wasn't a UTM, its result is allowed to be subjective.

The behavior of III is, and always is, the behavior of its direct
execution or the complete emulation of it by a REAL UTM, which for ALL
your EEEs that only emulate a finite number of steps and then return
will always be to HALT.

Note, none of those EEE ever showed the ACTUAL behavior of their input,
as that is BY DEFINITION, the behavior of that emulation by the UTM.

You are just proving your ignorance of what you are talking about, and
your stupidity to not see your ignorance.

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

Op 25.mrt.2025 om 23:07 schreef olcott:

On 3/25/2025 4:16 PM, joes wrote:

Am Tue, 25 Mar 2025 14:24:07 -0500 schrieb olcott:

Cannot possibly derive any outputs not computed from their inputs.

In particular, your HHH does not compute the behaviour of its input.

A Turing machine halt decider cannot possibly report on the behavior of
any directly executing process.
No Turing machine can every do this. This has always been beyond what
any Turing machine can ever do.
The best that any Turing machine halt decider can possibly do is
determine the behavior that an input finite string specifies.

Which iiis... surprise, whatever happens when you run it. You are
basically saying that simulators can make shit up.

When an input finite string specifies a pathological relationship with
its simulating halt decider the actual behavior that pathological
relationship derives must be reported because THAT IS THE BEHAVIOR THAT
IS SPECIFIED BY THIS INPUT FINITE STRING.

The relationship doesn't derive anything.
It is a tautology that a simulator reports what it reports. That doesn't
make that correct.

EEE emulates a finite number of steps EEE including
EEE emulating itself emulating III a finite number of times.

_III()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov  ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push III
[0000217a] e853f4ffff call 000015d2 ; call EEE(III)
[0000217f] 83c404     add  esp,+04
[00002182] 5d         pop  ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

III has different behavior when emulated by any EEE
than when it is emulated by any other emulator.

When III is emulated by EEE it never reaches its
final halt state.

It is not very interesting to know whether a simulator is able to report
that it did not reach the end of the simulation of a program that halts
in direct execution.
It is interesting to know:
'Is there an algorithm that can determine for all possible inputs
whether the input specifies a program that (according to the semantics
of the machine language) halts when directly executed?'
This question seems undecidable for Olcott.
Olcott will be remembered as the one who encountered new undecidable
questions for himself.

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

Am Tue, 25 Mar 2025 22:17:06 -0500 schrieb olcott:

On 3/25/2025 5:48 PM, Richard Damon wrote:

On 3/25/25 6:07 PM, olcott wrote:

On 3/25/2025 4:16 PM, joes wrote:

Am Tue, 25 Mar 2025 14:24:07 -0500 schrieb olcott:

When an input finite string specifies a pathological relationship
with its simulating halt decider the actual behavior that
pathological relationship derives must be reported because THAT IS
THE BEHAVIOR THAT IS SPECIFIED BY THIS INPUT FINITE STRING.

The relationship doesn't derive anything.
It is a tautology that a simulator reports what it reports. That
doesn't make that correct.

EEE emulates a finite number of steps EEE including EEE emulating
itself emulating III a finite number of times.

A partial simulation is not a complete simulation (non-halting
simulations are infinite).

III has different behavior when emulated by any EEE than when it is
emulated by any other emulator.
When III is emulated by EEE it never reaches its final halt state.
When III is emulated by any other emulator it ALWAYS reaches its final
halt state.
ALWAYS is the opposite of NEVER.

Sure looks like EEE is faulty here.

Since you defined that EEE wasn't a UTM, its result is allowed to be
subjective.

The same thing works for UTMs too yet they do not have such a concise
fully specified language where we can directly see every micro-step of
the algorithm.

The behavior of III is, and always is, the behavior of its direct
execution or the complete emulation of it by a REAL UTM, which for ALL

You have already said that there is no complete emulation.

Yes, that's the problem.

your EEEs that only emulate a finite number of steps and then return
will always be to HALT.

It is the III emulated by the EEEs that never halt.

Note, none of those EEE ever showed the ACTUAL behavior of their input,
as that is BY DEFINITION, the behavior of that emulation by the UTM.

The behavior of III is
[00002172] [00002173] [00002175] [0000217a]...

No, III has no loop. You are confusing different simulation levels.

--
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 3/25/25 11:17 PM, olcott wrote:

On 3/25/2025 5:48 PM, Richard Damon wrote:

On 3/25/25 6:07 PM, olcott wrote:

On 3/25/2025 4:16 PM, joes wrote:

Am Tue, 25 Mar 2025 14:24:07 -0500 schrieb olcott:

Cannot possibly derive any outputs not computed from their inputs.

In particular, your HHH does not compute the behaviour of its input.

A Turing machine halt decider cannot possibly report on the
behavior of
any directly executing process.
No Turing machine can every do this. This has always been beyond what >>>>> any Turing machine can ever do.
The best that any Turing machine halt decider can possibly do is
determine the behavior that an input finite string specifies.

Which iiis... surprise, whatever happens when you run it. You are
basically saying that simulators can make shit up.

When an input finite string specifies a pathological relationship with >>>>> its simulating halt decider the actual behavior that pathological
relationship derives must be reported because THAT IS THE BEHAVIOR
THAT
IS SPECIFIED BY THIS INPUT FINITE STRING.

The relationship doesn't derive anything.
It is a tautology that a simulator reports what it reports. That
doesn't
make that correct.

EEE emulates a finite number of steps EEE including
EEE emulating itself emulating III a finite number of times.

_III()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov  ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push III
[0000217a] e853f4ffff call 000015d2 ; call EEE(III)
[0000217f] 83c404     add  esp,+04
[00002182] 5d         pop  ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

III has different behavior when emulated by any EEE
than when it is emulated by any other emulator.

When III is emulated by EEE it never reaches its
final halt state.

When III is emulated by any other emulator it
ALWAYS reaches its final halt state.

ALWAYS is the opposite of NEVER.

So?

Since you defined that EEE wasn't a UTM, its result is allowed to be
subjective.

The same thing works for UTMs too yet they do not have
such a concise fully specified language where we can
directly see every micro-step of the algorithm.

Sure they do. You just need to look at the actual implementation of an
actual UTM.

The behavior of III is, and always is, the behavior of its direct
execution or the complete emulation of it by a REAL UTM, which for ALL

You have already said that there is no complete emulation.

Not by EEE, but by the UTM.

your EEEs that only emulate a finite number of steps and then return
will always be to HALT.

It is the III emulated by the EEEs that never halt.

No, it is the partial emulation of III by any EEE never reaches a final
state.

The fact that none of your EEE make a complete emulation means none of
them actually establish "Halting" for the III.

And the partial emulation does halt, when EEE aborts it.

Note, none of those EEE ever showed the ACTUAL behavior of their
input, as that is BY DEFINITION, the behavior of that emulation by the
UTM.

The behavior of III is
 [00002172]  [00002173]  [00002175]  [0000217a]...
This was always self-evident to anyone that knows the x86 language.

And what is after [0000217a], it SHOLD be [000015D2] but EEE don't know
what is there, or breaks the rules looking there.

All you are doing it proving that it isn't just ordinary stupidity, but deliberate FRAUD based on pathological stupidity that you speak out of.

It seems you have just enough knowledge of what you say to avoid making
your lies obvious enough to yourself that you might snap out of your brainwashing.

You are just proving your ignorance of what you are talking about, and
your stupidity to not see your ignorance.

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

On 3/26/25 12:47 PM, olcott wrote:

On 3/26/2025 6:17 AM, Richard Damon wrote:

On 3/25/25 11:17 PM, olcott wrote:

On 3/25/2025 5:48 PM, Richard Damon wrote:

On 3/25/25 6:07 PM, olcott wrote:

On 3/25/2025 4:16 PM, joes wrote:

Am Tue, 25 Mar 2025 14:24:07 -0500 schrieb olcott:

Cannot possibly derive any outputs not computed from their inputs. >>>>>> In particular, your HHH does not compute the behaviour of its input. >>>>>>
A Turing machine halt decider cannot possibly report on the
behavior of
any directly executing process.
No Turing machine can every do this. This has always been beyond >>>>>>> what
any Turing machine can ever do.
The best that any Turing machine halt decider can possibly do is >>>>>>> determine the behavior that an input finite string specifies.

Which iiis... surprise, whatever happens when you run it. You are
basically saying that simulators can make shit up.

When an input finite string specifies a pathological relationship >>>>>>> with
its simulating halt decider the actual behavior that pathological >>>>>>> relationship derives must be reported because THAT IS THE
BEHAVIOR THAT
IS SPECIFIED BY THIS INPUT FINITE STRING.

The relationship doesn't derive anything.
It is a tautology that a simulator reports what it reports. That
doesn't
make that correct.

EEE emulates a finite number of steps EEE including
EEE emulating itself emulating III a finite number of times.

_III()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov  ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push III
[0000217a] e853f4ffff call 000015d2 ; call EEE(III)
[0000217f] 83c404     add  esp,+04
[00002182] 5d         pop  ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

III has different behavior when emulated by any EEE
than when it is emulated by any other emulator.

When III is emulated by EEE it never reaches its
final halt state.

When III is emulated by any other emulator it
ALWAYS reaches its final halt state.

ALWAYS is the opposite of NEVER.

So?

Since you defined that EEE wasn't a UTM, its result is allowed to be
subjective.

The same thing works for UTMs too yet they do not have
such a concise fully specified language where we can
directly see every micro-step of the algorithm.

Sure they do. You just need to look at the actual implementation of an
actual UTM.

The behavior of III is, and always is, the behavior of its direct
execution or the complete emulation of it by a REAL UTM, which for ALL

You have already said that there is no complete emulation.

Not by EEE, but by the UTM.

your EEEs that only emulate a finite number of steps and then return
will always be to HALT.

It is the III emulated by the EEEs that never halt.

No, it is the partial emulation of III by any EEE never reaches a
final state.

The fact that none of your EEE make a complete emulation means none of
them actually establish "Halting" for the III.

And the partial emulation does halt, when EEE aborts it.

Stops running is not halting.

But programs don't just "stop running".

Reaches a final halt state is halting.
III emulated by EEE never reaches its final halt state
even after an infinite number of steps are emulated.

Because EEE is not a correct emulator, because it is a partial emulator,

Only COMPLETE emulation is correct for determining final behavior, and
thus your argument is just ADMITTING that you are just liar.

Note, none of those EEE ever showed the ACTUAL behavior of their
input, as that is BY DEFINITION, the behavior of that emulation by
the UTM.

The behavior of III is
  [00002172]  [00002173]  [00002175]  [0000217a]...
This was always self-evident to anyone that knows the x86 language.

And what is after [0000217a], it SHOLD be [000015D2] but EEE don't
know what is there, or breaks the rules looking there.

All you are doing it proving that it isn't just ordinary stupidity,
but deliberate FRAUD based on pathological stupidity that you speak
out of.

It seems you have just enough knowledge of what you say to avoid
making your lies obvious enough to yourself that you might snap out of
your brainwashing.

You are just proving your ignorance of what you are talking about,
and your stupidity to not see your ignorance.

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

On 3/26/25 12:18 PM, olcott wrote:

On 3/26/2025 4:46 AM, joes wrote:

Am Tue, 25 Mar 2025 22:17:06 -0500 schrieb olcott:

On 3/25/2025 5:48 PM, Richard Damon wrote:

On 3/25/25 6:07 PM, olcott wrote:

On 3/25/2025 4:16 PM, joes wrote:

Am Tue, 25 Mar 2025 14:24:07 -0500 schrieb olcott:

When an input finite string specifies a pathological relationship >>>>>>> with its simulating halt decider the actual behavior that
pathological relationship derives must be reported because THAT IS >>>>>>> THE BEHAVIOR THAT IS SPECIFIED BY THIS INPUT FINITE STRING.

The relationship doesn't derive anything.
It is a tautology that a simulator reports what it reports. That
doesn't make that correct.

EEE emulates a finite number of steps EEE including EEE emulating
itself emulating III a finite number of times.

A partial simulation is not a complete simulation (non-halting
simulations are infinite).

It is stupid to define a simulating termination that
cannot report non-terminating inputs. Simulating
termination analyzers recognize non-terminating
behavior patterns in a finite number of steps.

But that is the PROBLEM of trying to solve a problem by a method that
just doesn't work.

Yes, they can recognize SOME actual non-halting behaviors in finite time.

Your problem is you keep on trying to redefine the criteraa, and action
that is jst not allowed, and makes you into a liar. The criteria that
your decider must answer is if this exact same, and COMPLETE input (thus needing to contain ALL the code used in it) is given to a COMPLETE and
CORRECT simulator, would it stop.

Not if this "Program Template" (since templates are not programs) can be simulated by some decider that it is bound to can do it. That is just
your strawman lie.

III has different behavior when emulated by any EEE than when it is
emulated by any other emulator.
When III is emulated by EEE it never reaches its final halt state.
When III is emulated by any other emulator it ALWAYS reaches its final >>>>> halt state.
ALWAYS is the opposite of NEVER.

Sure looks like EEE is faulty here.

It might if you are totally clueless about the x86 language.

Really, and where in the Intel manual do you get that from?

Since you defined that EEE wasn't a UTM, its result is allowed to be
subjective.

The same thing works for UTMs too yet they do not have such a concise
fully specified language where we can directly see every micro-step of
the algorithm.

The behavior of III is, and always is, the behavior of its direct
execution or the complete emulation of it by a REAL UTM, which for ALL

You have already said that there is no complete emulation.

Of any non-terminating input.

But the COMPLETE input given to an actually correct emulator will halt,
so the input isn't "non-terminating".

You just don't understand what that means.

Yes, that's the problem.

your EEEs that only emulate a finite number of steps and then return
will always be to HALT.

It is the III emulated by the EEEs that never halt.

Note, none of those EEE ever showed the ACTUAL behavior of their input, >>>> as that is BY DEFINITION, the behavior of that emulation by the UTM.

The behavior of III is
   [00002172]  [00002173]  [00002175]  [0000217a]...

No, III has no loop. You are confusing different simulation levels.

I have used the term recursive emulation
hundreds of times, did you notice that I
ever said it at least once?

Right, but you MISUSE the term, as your usage requires that the emulator
be a COMPLETE emulator, but then you try to using it with a partial
emulator.

Sorry, all you have been doing is proving that you don't really
understand what you are talking about, but just lie about things.

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