From Newsgroup: sci.logic

On 8/4/25 9:42 AM, olcott wrote:

On 8/4/2025 7:47 AM, Fred. Zwarts wrote:

Op 02.aug.2025 om 16:16 schreef olcott:

On 8/2/2025 4:18 AM, Fred. Zwarts wrote:

Op 01.aug.2025 om 16:46 schreef olcott:

On 8/1/2025 1:53 AM, joes wrote:

Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott:

On 7/31/2025 7:07 PM, Richard Damon wrote:

On 7/31/25 11:50 AM, olcott wrote:

On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
-a-a> It is a lack of technical ability on your part which is >>>>>>>>> unable to
-a-a> judge whether such a correct simulation is possible. >>>>>>>>> Everybody
-a-a> else sees that it is not, so further questions about it are >>>>>>>>> -a-a> non-sensical.
HHH emulates DDD in a separate process context. When this DDD >>>>>>>>> calls
HHH(DDD) the original HHH emulates this HHH in the DDD process >>>>>>>>> context.

And that separate proccess, if left unaborted, would halt. But HHH >>>>>>>> gives up and aborts it, so the process is Halting, not non-halting. >>>>>

And HHH cannot simulate itself to its undeniable halting state.

This emulated HHH creates yet another process context to
emulate its
own DDD. When this DDD calls yet another HHH(DDD) this provides >>>>>>>>> enough
execution trace that the repeating pattern can be seen.

But the pattern isn't non-halting by the fact that DDD is shown >>>>>>>> to be
halting.

*No not at all. Not in the least little bit* Recursive simulation is >>>>>>> only a little more difficult than self recursion.

DDD halts if it weren't aborted.

(1) That is counter-factual. Neither HHH() nor DDD() nor DDD
simulated by HHH ever stops running unless HHH(DDD) aborts
its input.

It is irrelevant what a hypothetical non-input would do. HHH aborts,
so DDD and HHH, both the directly executing and the simulated
versions halt.

DDD correctly simulated by HHH cannot possibly reach
its own simulated "return" instruction final halt state
in 1 to infinity steps of correct simulation. When the
simulation is aborted the entire process is killed so
there is no stack unwinding.

(2) I have never been taking about DDD() the behavior of a non-input. >>>>> Turing machines are only accountable for the behavior that their
inputs specify, they are never accountable for any non-inputs.

And this input specifies a program with code to abort, so it
specifies a halting program. When HHH does not see that, it fails.

I discovered a case where the correct simulation
and the direct execution have different halting
behaviors.

No, you dreamed, but could not prove it. Only by twisting the meaning
of the words, you could make yourself believing it.

(3) When I make a claim about DDD simulated by HHH and this is
changed to the behavior of the directly executed DDD this is
a dishonest tactic known as the strawman error.

When the input specifies a halting behaviour, it is an error to
close your eyes and pretend that it does not exist.

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

Executed HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
Then HHH kills the whole simulation process and returns 0

Counterfactual. HHH abors after a few cycles, when only one more
cycle is needed to complete the simulation, as proven by simulators
that do not abort the exact same input.

The above HHH aborts after ten recursive simulations
because people here did not understand that there were
any recursive simulation when I only show one or two.

That does not make any difference. We also see that you are cheating,
by not only changing the simulator, but also the simulated input.
World class simulators show that the original input, when correctly
simulated, reaches its final halt state after tree recursion.
The HHH that simulates 10 recursions would also reach the final halt
state for this same input.
But, because your are cheating, you changed the input, which now needs
eleven recursion to halt.
We see in this way, the, no matter how many recursions you simulate,
this method is unable to reach the final halt state that is specified
in the input when we construct a new DDD with this new HHH.

When N instructions of DDD are correctly emulated by every HHH
that can
possibly exist (technically this is an infinite set of HHH/DDD
pairs)
no emulated DDD can possibly halt and every directly executed DDD() >>>>>>> halts.

See, and I thought DDD was a concrete program filled in with HHH,
which aborts after two levels of simulation, not something that
calls "HHH" symbolically, producing many different programs.

I had to turn it into an infinite set of HHH/DDD
pairs so that it could be more easily understood
that DDD simulated by HHH cannot possibly halt.

When HHH detects the above non-halting behavior
pattern it kills the whole simulation process so
there is no stack unwinding.

There is no non-halting behaviour pattern, only a finite number more
than N instructions are needed to reach the final input *for this
input*.

counter-factual

_DDD()
[00002192] 55-a-a-a-a-a-a-a-a push ebp
[00002193] 8bec-a-a-a-a-a-a mov ebp,esp
[00002195] 6892210000 push 00002192-a // push DDD
[0000219a] e833f4ffff call 000015d2-a // call HHH
[0000219f] 83c404-a-a-a-a add esp,+04
[000021a2] 5d-a-a-a-a-a-a-a-a pop ebp
[000021a3] c3-a-a-a-a-a-a-a-a ret
Size in bytes:(0018) [000021a3]

WE have told you many times that it is incorrect to suggest that these
18 bytes describe the whole input for the simulator.
All functions called by DDD, directly or indirectly, also belong to
the input under test.

Every 5 instructions of DDD that are correctly emulated
end up in HHH at line one. One more instruction of
DDD emulates line two, one more emulates line three,
one more ends up at line four, one more ends up back
at line one.

Incorrect, the call ends up inside HHH. When you would correctly
follow the code of HHH in your simulator, keeping track of the
internal state of HHH and its conditional branch instruction, you
would see that after a few cycles, HHH is specified to abort and
return to DDD at line 5.
Then lines 6 and 7 would be simulated and the final halt state is
reached.
But HHH fails to do this correct simulation, because it prematurely
aborts before it can see that.
Then HHH uses your attitude: close its eyes and pretend that what is
not seen does not exist.

Proving that for all N the program specifies a halting behaviour,
but we can construct *another* input for which HHH fails again.
But you cheat by changing the input, which then needs more steps.

I do not cheat. I define the infinite set of HHH/DDD pairs
where HHH emulates N instructions of DDD and N is one element
of the natural numbers.

Each pair has a different input for the simulator. Each simulator
fails for the input constructed with its own version. But many of them
prove that the input constructed with other HHH versions, which have
less steps before the premature abort, have a final halt state that
can be reached.

Because HHH correctly predicts that DDD emulated by
HHH cannot possibly reach its own final state each HHH that
aborts after N instructions have been emulated is correct
to reject its input as non halting.

But it can't do that, as that HHH doesn't correct emulate this DDD.

All you are doing is proving you are just basing your logic on lying.

Either DDD includes the code of the specific HHH that it is built on so
they are all different, or no HHH can correctly simulate the input as it doesn't include the needed information to be simulated.

Looking at things not part of the input isn't allowed.

This shows that the infinite set is irrelevant.
One example if already enough to prove the failure of this method.
So, don't change the subject and lets stay at the HHH that aborts
after two cycles, which need a simulator that simulates at least three
cycles.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

On 8/4/2025 8:25 PM, Richard Damon wrote:

On 8/4/25 9:42 AM, olcott wrote:

On 8/4/2025 7:47 AM, Fred. Zwarts wrote:

Op 02.aug.2025 om 16:16 schreef olcott:

On 8/2/2025 4:18 AM, Fred. Zwarts wrote:

Op 01.aug.2025 om 16:46 schreef olcott:

On 8/1/2025 1:53 AM, joes wrote:

Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott:

On 7/31/2025 7:07 PM, Richard Damon wrote:

On 7/31/25 11:50 AM, olcott wrote:

On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
-a-a> It is a lack of technical ability on your part which is >>>>>>>>>> unable to
-a-a> judge whether such a correct simulation is possible. >>>>>>>>>> Everybody
-a-a> else sees that it is not, so further questions about it are >>>>>>>>>> -a-a> non-sensical.
HHH emulates DDD in a separate process context. When this DDD >>>>>>>>>> calls
HHH(DDD) the original HHH emulates this HHH in the DDD process >>>>>>>>>> context.

And that separate proccess, if left unaborted, would halt. But HHH >>>>>>>>> gives up and aborts it, so the process is Halting, not non- >>>>>>>>> halting.

And HHH cannot simulate itself to its undeniable halting state.

This emulated HHH creates yet another process context to
emulate its
own DDD. When this DDD calls yet another HHH(DDD) this
provides enough
execution trace that the repeating pattern can be seen.

But the pattern isn't non-halting by the fact that DDD is shown >>>>>>>>> to be
halting.

*No not at all. Not in the least little bit* Recursive
simulation is
only a little more difficult than self recursion.

DDD halts if it weren't aborted.

(1) That is counter-factual. Neither HHH() nor DDD() nor DDD
simulated by HHH ever stops running unless HHH(DDD) aborts
its input.

It is irrelevant what a hypothetical non-input would do. HHH
aborts, so DDD and HHH, both the directly executing and the
simulated versions halt.

DDD correctly simulated by HHH cannot possibly reach
its own simulated "return" instruction final halt state
in 1 to infinity steps of correct simulation. When the
simulation is aborted the entire process is killed so
there is no stack unwinding.

(2) I have never been taking about DDD() the behavior of a non-input. >>>>>> Turing machines are only accountable for the behavior that their
inputs specify, they are never accountable for any non-inputs.

And this input specifies a program with code to abort, so it
specifies a halting program. When HHH does not see that, it fails.

I discovered a case where the correct simulation
and the direct execution have different halting
behaviors.

No, you dreamed, but could not prove it. Only by twisting the meaning
of the words, you could make yourself believing it.

(3) When I make a claim about DDD simulated by HHH and this is
changed to the behavior of the directly executed DDD this is
a dishonest tactic known as the strawman error.

When the input specifies a halting behaviour, it is an error to
close your eyes and pretend that it does not exist.

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

Executed HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
Then HHH kills the whole simulation process and returns 0

Counterfactual. HHH abors after a few cycles, when only one more
cycle is needed to complete the simulation, as proven by simulators >>>>> that do not abort the exact same input.

The above HHH aborts after ten recursive simulations
because people here did not understand that there were
any recursive simulation when I only show one or two.

That does not make any difference. We also see that you are cheating,
by not only changing the simulator, but also the simulated input.
World class simulators show that the original input, when correctly
simulated, reaches its final halt state after tree recursion.
The HHH that simulates 10 recursions would also reach the final halt
state for this same input.
But, because your are cheating, you changed the input, which now
needs eleven recursion to halt.
We see in this way, the, no matter how many recursions you simulate,
this method is unable to reach the final halt state that is specified
in the input when we construct a new DDD with this new HHH.

When N instructions of DDD are correctly emulated by every HHH >>>>>>>> that can
possibly exist (technically this is an infinite set of HHH/DDD >>>>>>>> pairs)
no emulated DDD can possibly halt and every directly executed DDD() >>>>>>>> halts.

See, and I thought DDD was a concrete program filled in with HHH, >>>>>>> which aborts after two levels of simulation, not something that
calls "HHH" symbolically, producing many different programs.

I had to turn it into an infinite set of HHH/DDD
pairs so that it could be more easily understood
that DDD simulated by HHH cannot possibly halt.

When HHH detects the above non-halting behavior
pattern it kills the whole simulation process so
there is no stack unwinding.

There is no non-halting behaviour pattern, only a finite number
more than N instructions are needed to reach the final input *for
this input*.

counter-factual

_DDD()
[00002192] 55-a-a-a-a-a-a-a-a push ebp
[00002193] 8bec-a-a-a-a-a-a mov ebp,esp
[00002195] 6892210000 push 00002192-a // push DDD
[0000219a] e833f4ffff call 000015d2-a // call HHH
[0000219f] 83c404-a-a-a-a add esp,+04
[000021a2] 5d-a-a-a-a-a-a-a-a pop ebp
[000021a3] c3-a-a-a-a-a-a-a-a ret
Size in bytes:(0018) [000021a3]

WE have told you many times that it is incorrect to suggest that
these 18 bytes describe the whole input for the simulator.
All functions called by DDD, directly or indirectly, also belong to
the input under test.

Every 5 instructions of DDD that are correctly emulated
end up in HHH at line one. One more instruction of
DDD emulates line two, one more emulates line three,
one more ends up at line four, one more ends up back
at line one.

Incorrect, the call ends up inside HHH. When you would correctly
follow the code of HHH in your simulator, keeping track of the
internal state of HHH and its conditional branch instruction, you
would see that after a few cycles, HHH is specified to abort and
return to DDD at line 5.
Then lines 6 and 7 would be simulated and the final halt state is
reached.
But HHH fails to do this correct simulation, because it prematurely
aborts before it can see that.
Then HHH uses your attitude: close its eyes and pretend that what is
not seen does not exist.

Proving that for all N the program specifies a halting behaviour,
but we can construct *another* input for which HHH fails again.
But you cheat by changing the input, which then needs more steps.

I do not cheat. I define the infinite set of HHH/DDD pairs
where HHH emulates N instructions of DDD and N is one element
of the natural numbers.

Each pair has a different input for the simulator. Each simulator
fails for the input constructed with its own version. But many of
them prove that the input constructed with other HHH versions, which
have less steps before the premature abort, have a final halt state
that can be reached.

Because HHH correctly predicts that DDD emulated by
HHH cannot possibly reach its own final state each HHH that
aborts after N instructions have been emulated is correct
to reject its input as non halting.

But it can't do that, as that HHH doesn't correct emulate this DDD.

HHH correctly emulates DDD until this emulated DDD
proves that it cannot possibly reach its own emulated
final halt state.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

On 8/4/25 9:31 PM, olcott wrote:

On 8/4/2025 8:25 PM, Richard Damon wrote:

On 8/4/25 9:42 AM, olcott wrote:

On 8/4/2025 7:47 AM, Fred. Zwarts wrote:

Op 02.aug.2025 om 16:16 schreef olcott:

On 8/2/2025 4:18 AM, Fred. Zwarts wrote:

Op 01.aug.2025 om 16:46 schreef olcott:

On 8/1/2025 1:53 AM, joes wrote:

Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott:

On 7/31/2025 7:07 PM, Richard Damon wrote:

On 7/31/25 11:50 AM, olcott wrote:

On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
-a-a> It is a lack of technical ability on your part which is >>>>>>>>>>> unable to
-a-a> judge whether such a correct simulation is possible. >>>>>>>>>>> Everybody
-a-a> else sees that it is not, so further questions about it are >>>>>>>>>>> -a-a> non-sensical.
HHH emulates DDD in a separate process context. When this DDD >>>>>>>>>>> calls
HHH(DDD) the original HHH emulates this HHH in the DDD process >>>>>>>>>>> context.

And that separate proccess, if left unaborted, would halt. But >>>>>>>>>> HHH
gives up and aborts it, so the process is Halting, not non- >>>>>>>>>> halting.

And HHH cannot simulate itself to its undeniable halting state. >>>>>>>>

This emulated HHH creates yet another process context to >>>>>>>>>>> emulate its
own DDD. When this DDD calls yet another HHH(DDD) this
provides enough
execution trace that the repeating pattern can be seen.

But the pattern isn't non-halting by the fact that DDD is >>>>>>>>>> shown to be
halting.

*No not at all. Not in the least little bit* Recursive
simulation is
only a little more difficult than self recursion.

DDD halts if it weren't aborted.

(1) That is counter-factual. Neither HHH() nor DDD() nor DDD
simulated by HHH ever stops running unless HHH(DDD) aborts
its input.

It is irrelevant what a hypothetical non-input would do. HHH
aborts, so DDD and HHH, both the directly executing and the
simulated versions halt.

DDD correctly simulated by HHH cannot possibly reach
its own simulated "return" instruction final halt state
in 1 to infinity steps of correct simulation. When the
simulation is aborted the entire process is killed so
there is no stack unwinding.

(2) I have never been taking about DDD() the behavior of a non- >>>>>>> input.
Turing machines are only accountable for the behavior that their >>>>>>> inputs specify, they are never accountable for any non-inputs.

And this input specifies a program with code to abort, so it
specifies a halting program. When HHH does not see that, it fails. >>>>>>

I discovered a case where the correct simulation
and the direct execution have different halting
behaviors.

No, you dreamed, but could not prove it. Only by twisting the
meaning of the words, you could make yourself believing it.

(3) When I make a claim about DDD simulated by HHH and this is
changed to the behavior of the directly executed DDD this is
a dishonest tactic known as the strawman error.

When the input specifies a halting behaviour, it is an error to
close your eyes and pretend that it does not exist.

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

Executed HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
Then HHH kills the whole simulation process and returns 0

Counterfactual. HHH abors after a few cycles, when only one more
cycle is needed to complete the simulation, as proven by
simulators that do not abort the exact same input.

The above HHH aborts after ten recursive simulations
because people here did not understand that there were
any recursive simulation when I only show one or two.

That does not make any difference. We also see that you are
cheating, by not only changing the simulator, but also the simulated
input. World class simulators show that the original input, when
correctly simulated, reaches its final halt state after tree recursion. >>>> The HHH that simulates 10 recursions would also reach the final halt
state for this same input.
But, because your are cheating, you changed the input, which now
needs eleven recursion to halt.
We see in this way, the, no matter how many recursions you simulate,
this method is unable to reach the final halt state that is
specified in the input when we construct a new DDD with this new HHH.

When N instructions of DDD are correctly emulated by every HHH >>>>>>>>> that can
possibly exist (technically this is an infinite set of HHH/DDD >>>>>>>>> pairs)
no emulated DDD can possibly halt and every directly executed >>>>>>>>> DDD()
halts.

See, and I thought DDD was a concrete program filled in with HHH, >>>>>>>> which aborts after two levels of simulation, not something that >>>>>>>> calls "HHH" symbolically, producing many different programs.

I had to turn it into an infinite set of HHH/DDD
pairs so that it could be more easily understood
that DDD simulated by HHH cannot possibly halt.

When HHH detects the above non-halting behavior
pattern it kills the whole simulation process so
there is no stack unwinding.

There is no non-halting behaviour pattern, only a finite number
more than N instructions are needed to reach the final input *for >>>>>> this input*.

counter-factual

_DDD()
[00002192] 55-a-a-a-a-a-a-a-a push ebp
[00002193] 8bec-a-a-a-a-a-a mov ebp,esp
[00002195] 6892210000 push 00002192-a // push DDD
[0000219a] e833f4ffff call 000015d2-a // call HHH
[0000219f] 83c404-a-a-a-a add esp,+04
[000021a2] 5d-a-a-a-a-a-a-a-a pop ebp
[000021a3] c3-a-a-a-a-a-a-a-a ret
Size in bytes:(0018) [000021a3]

WE have told you many times that it is incorrect to suggest that
these 18 bytes describe the whole input for the simulator.
All functions called by DDD, directly or indirectly, also belong to
the input under test.

Every 5 instructions of DDD that are correctly emulated
end up in HHH at line one. One more instruction of
DDD emulates line two, one more emulates line three,
one more ends up at line four, one more ends up back
at line one.

Incorrect, the call ends up inside HHH. When you would correctly
follow the code of HHH in your simulator, keeping track of the
internal state of HHH and its conditional branch instruction, you
would see that after a few cycles, HHH is specified to abort and
return to DDD at line 5.
Then lines 6 and 7 would be simulated and the final halt state is
reached.
But HHH fails to do this correct simulation, because it prematurely
aborts before it can see that.
Then HHH uses your attitude: close its eyes and pretend that what is
not seen does not exist.

Proving that for all N the program specifies a halting behaviour, >>>>>> but we can construct *another* input for which HHH fails again.
But you cheat by changing the input, which then needs more steps.

I do not cheat. I define the infinite set of HHH/DDD pairs
where HHH emulates N instructions of DDD and N is one element
of the natural numbers.

Each pair has a different input for the simulator. Each simulator
fails for the input constructed with its own version. But many of
them prove that the input constructed with other HHH versions, which
have less steps before the premature abort, have a final halt state
that can be reached.

Because HHH correctly predicts that DDD emulated by
HHH cannot possibly reach its own final state each HHH that
aborts after N instructions have been emulated is correct
to reject its input as non halting.

But it can't do that, as that HHH doesn't correct emulate this DDD.

HHH correctly emulates DDD until this emulated DDD
proves that it cannot possibly reach its own emulated
final halt state.

And Correctly until ... isn't correct.

Just like living until you die isn't living forever.

Of course, your statement also shows that you don't understand what
programs are, as of course if HHH is programmed to abort, it can't
possible simulate long enough to reach its own emulated final halt
state, as it must do what it is programmed to do.

So, by your logic, EVERY emulator can "correctly" determine that it
won't reach the final state (assuming it hasn't already) if it is
programmed to abort at that point.

You don't seem to understand the fully defined and deterministic nature
of a program, because you never learned how they work.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

On 8/4/2025 8:41 PM, Richard Damon wrote:

On 8/4/25 9:31 PM, olcott wrote:

On 8/4/2025 8:25 PM, Richard Damon wrote:

On 8/4/25 9:42 AM, olcott wrote:

On 8/4/2025 7:47 AM, Fred. Zwarts wrote:

Op 02.aug.2025 om 16:16 schreef olcott:

On 8/2/2025 4:18 AM, Fred. Zwarts wrote:

Op 01.aug.2025 om 16:46 schreef olcott:

On 8/1/2025 1:53 AM, joes wrote:

Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott:

On 7/31/2025 7:07 PM, Richard Damon wrote:

On 7/31/25 11:50 AM, olcott wrote:

On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
-a-a> It is a lack of technical ability on your part which is >>>>>>>>>>>> unable to
-a-a> judge whether such a correct simulation is possible. >>>>>>>>>>>> Everybody
-a-a> else sees that it is not, so further questions about it are >>>>>>>>>>>> -a-a> non-sensical.
HHH emulates DDD in a separate process context. When this >>>>>>>>>>>> DDD calls
HHH(DDD) the original HHH emulates this HHH in the DDD process >>>>>>>>>>>> context.

And that separate proccess, if left unaborted, would halt. >>>>>>>>>>> But HHH
gives up and aborts it, so the process is Halting, not non- >>>>>>>>>>> halting.

And HHH cannot simulate itself to its undeniable halting state. >>>>>>>>>

This emulated HHH creates yet another process context to >>>>>>>>>>>> emulate its
own DDD. When this DDD calls yet another HHH(DDD) this >>>>>>>>>>>> provides enough
execution trace that the repeating pattern can be seen. >>>>>>>>>>> But the pattern isn't non-halting by the fact that DDD is >>>>>>>>>>> shown to be

halting.

*No not at all. Not in the least little bit* Recursive
simulation is
only a little more difficult than self recursion.

DDD halts if it weren't aborted.

(1) That is counter-factual. Neither HHH() nor DDD() nor DDD
simulated by HHH ever stops running unless HHH(DDD) aborts
its input.

It is irrelevant what a hypothetical non-input would do. HHH
aborts, so DDD and HHH, both the directly executing and the
simulated versions halt.

DDD correctly simulated by HHH cannot possibly reach
its own simulated "return" instruction final halt state
in 1 to infinity steps of correct simulation. When the
simulation is aborted the entire process is killed so
there is no stack unwinding.

(2) I have never been taking about DDD() the behavior of a non- >>>>>>>> input.
Turing machines are only accountable for the behavior that their >>>>>>>> inputs specify, they are never accountable for any non-inputs.

And this input specifies a program with code to abort, so it
specifies a halting program. When HHH does not see that, it fails. >>>>>>>

I discovered a case where the correct simulation
and the direct execution have different halting
behaviors.

No, you dreamed, but could not prove it. Only by twisting the
meaning of the words, you could make yourself believing it.

(3) When I make a claim about DDD simulated by HHH and this is >>>>>>>> changed to the behavior of the directly executed DDD this is
a dishonest tactic known as the strawman error.

When the input specifies a halting behaviour, it is an error to >>>>>>> close your eyes and pretend that it does not exist.

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

Executed HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
Then HHH kills the whole simulation process and returns 0

Counterfactual. HHH abors after a few cycles, when only one more >>>>>>> cycle is needed to complete the simulation, as proven by
simulators that do not abort the exact same input.

The above HHH aborts after ten recursive simulations
because people here did not understand that there were
any recursive simulation when I only show one or two.

That does not make any difference. We also see that you are
cheating, by not only changing the simulator, but also the
simulated input. World class simulators show that the original
input, when correctly simulated, reaches its final halt state after >>>>> tree recursion.
The HHH that simulates 10 recursions would also reach the final
halt state for this same input.
But, because your are cheating, you changed the input, which now
needs eleven recursion to halt.
We see in this way, the, no matter how many recursions you
simulate, this method is unable to reach the final halt state that
is specified in the input when we construct a new DDD with this new >>>>> HHH.

When N instructions of DDD are correctly emulated by every HHH >>>>>>>>>> that can
possibly exist (technically this is an infinite set of HHH/DDD >>>>>>>>>> pairs)
no emulated DDD can possibly halt and every directly executed >>>>>>>>>> DDD()
halts.

See, and I thought DDD was a concrete program filled in with HHH, >>>>>>>>> which aborts after two levels of simulation, not something that >>>>>>>>> calls "HHH" symbolically, producing many different programs. >>>>>>>>>

I had to turn it into an infinite set of HHH/DDD
pairs so that it could be more easily understood
that DDD simulated by HHH cannot possibly halt.

When HHH detects the above non-halting behavior
pattern it kills the whole simulation process so
there is no stack unwinding.

There is no non-halting behaviour pattern, only a finite number >>>>>>> more than N instructions are needed to reach the final input *for >>>>>>> this input*.

counter-factual

_DDD()
[00002192] 55-a-a-a-a-a-a-a-a push ebp
[00002193] 8bec-a-a-a-a-a-a mov ebp,esp
[00002195] 6892210000 push 00002192-a // push DDD
[0000219a] e833f4ffff call 000015d2-a // call HHH
[0000219f] 83c404-a-a-a-a add esp,+04
[000021a2] 5d-a-a-a-a-a-a-a-a pop ebp
[000021a3] c3-a-a-a-a-a-a-a-a ret
Size in bytes:(0018) [000021a3]

WE have told you many times that it is incorrect to suggest that
these 18 bytes describe the whole input for the simulator.
All functions called by DDD, directly or indirectly, also belong to >>>>> the input under test.

Every 5 instructions of DDD that are correctly emulated
end up in HHH at line one. One more instruction of
DDD emulates line two, one more emulates line three,
one more ends up at line four, one more ends up back
at line one.

Incorrect, the call ends up inside HHH. When you would correctly
follow the code of HHH in your simulator, keeping track of the
internal state of HHH and its conditional branch instruction, you
would see that after a few cycles, HHH is specified to abort and
return to DDD at line 5.
Then lines 6 and 7 would be simulated and the final halt state is
reached.
But HHH fails to do this correct simulation, because it prematurely >>>>> aborts before it can see that.
Then HHH uses your attitude: close its eyes and pretend that what
is not seen does not exist.

Proving that for all N the program specifies a halting behaviour, >>>>>>> but we can construct *another* input for which HHH fails again.
But you cheat by changing the input, which then needs more steps. >>>>>>

I do not cheat. I define the infinite set of HHH/DDD pairs
where HHH emulates N instructions of DDD and N is one element
of the natural numbers.

Each pair has a different input for the simulator. Each simulator
fails for the input constructed with its own version. But many of
them prove that the input constructed with other HHH versions,
which have less steps before the premature abort, have a final halt >>>>> state that can be reached.

Because HHH correctly predicts that DDD emulated by
HHH cannot possibly reach its own final state each HHH that
aborts after N instructions have been emulated is correct
to reject its input as non halting.

But it can't do that, as that HHH doesn't correct emulate this DDD.

HHH correctly emulates DDD until this emulated DDD
proves that it cannot possibly reach its own emulated
final halt state.

And Correctly until ... isn't correct.

In other words when HHH correctly emulates N instructions
of DDD you are claiming that HHH did not correctly emulate
N instructions of DDD and likewise 1 does not equal itself.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

On 8/4/25 9:45 PM, olcott wrote:

On 8/4/2025 8:41 PM, Richard Damon wrote:

On 8/4/25 9:31 PM, olcott wrote:

On 8/4/2025 8:25 PM, Richard Damon wrote:

On 8/4/25 9:42 AM, olcott wrote:

On 8/4/2025 7:47 AM, Fred. Zwarts wrote:

Op 02.aug.2025 om 16:16 schreef olcott:

On 8/2/2025 4:18 AM, Fred. Zwarts wrote:

Op 01.aug.2025 om 16:46 schreef olcott:

On 8/1/2025 1:53 AM, joes wrote:

Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott:

On 7/31/2025 7:07 PM, Richard Damon wrote:

On 7/31/25 11:50 AM, olcott wrote:

On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
-a-a> It is a lack of technical ability on your part which is >>>>>>>>>>>>> unable to
-a-a> judge whether such a correct simulation is possible. >>>>>>>>>>>>> Everybody
-a-a> else sees that it is not, so further questions about it >>>>>>>>>>>>> are
-a-a> non-sensical.
HHH emulates DDD in a separate process context. When this >>>>>>>>>>>>> DDD calls
HHH(DDD) the original HHH emulates this HHH in the DDD process >>>>>>>>>>>>> context.

And that separate proccess, if left unaborted, would halt. >>>>>>>>>>>> But HHH
gives up and aborts it, so the process is Halting, not non- >>>>>>>>>>>> halting.

And HHH cannot simulate itself to its undeniable halting state. >>>>>>>>>>

This emulated HHH creates yet another process context to >>>>>>>>>>>>> emulate its
own DDD. When this DDD calls yet another HHH(DDD) this >>>>>>>>>>>>> provides enough
execution trace that the repeating pattern can be seen. >>>>>>>>>>>> But the pattern isn't non-halting by the fact that DDD is >>>>>>>>>>>> shown to be

halting.

*No not at all. Not in the least little bit* Recursive
simulation is
only a little more difficult than self recursion.

DDD halts if it weren't aborted.

(1) That is counter-factual. Neither HHH() nor DDD() nor DDD >>>>>>>>> simulated by HHH ever stops running unless HHH(DDD) aborts
its input.

It is irrelevant what a hypothetical non-input would do. HHH
aborts, so DDD and HHH, both the directly executing and the
simulated versions halt.

DDD correctly simulated by HHH cannot possibly reach
its own simulated "return" instruction final halt state
in 1 to infinity steps of correct simulation. When the
simulation is aborted the entire process is killed so
there is no stack unwinding.

(2) I have never been taking about DDD() the behavior of a non- >>>>>>>>> input.
Turing machines are only accountable for the behavior that their >>>>>>>>> inputs specify, they are never accountable for any non-inputs. >>>>>>>>

And this input specifies a program with code to abort, so it
specifies a halting program. When HHH does not see that, it fails. >>>>>>>>

I discovered a case where the correct simulation
and the direct execution have different halting
behaviors.

No, you dreamed, but could not prove it. Only by twisting the
meaning of the words, you could make yourself believing it.

(3) When I make a claim about DDD simulated by HHH and this is >>>>>>>>> changed to the behavior of the directly executed DDD this is >>>>>>>>> a dishonest tactic known as the strawman error.

When the input specifies a halting behaviour, it is an error to >>>>>>>> close your eyes and pretend that it does not exist.

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

Executed HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
Then HHH kills the whole simulation process and returns 0

Counterfactual. HHH abors after a few cycles, when only one more >>>>>>>> cycle is needed to complete the simulation, as proven by
simulators that do not abort the exact same input.

The above HHH aborts after ten recursive simulations
because people here did not understand that there were
any recursive simulation when I only show one or two.

That does not make any difference. We also see that you are
cheating, by not only changing the simulator, but also the
simulated input. World class simulators show that the original
input, when correctly simulated, reaches its final halt state
after tree recursion.
The HHH that simulates 10 recursions would also reach the final
halt state for this same input.
But, because your are cheating, you changed the input, which now
needs eleven recursion to halt.
We see in this way, the, no matter how many recursions you
simulate, this method is unable to reach the final halt state that >>>>>> is specified in the input when we construct a new DDD with this
new HHH.

When N instructions of DDD are correctly emulated by every >>>>>>>>>>> HHH that can
possibly exist (technically this is an infinite set of HHH/ >>>>>>>>>>> DDD pairs)
no emulated DDD can possibly halt and every directly executed >>>>>>>>>>> DDD()
halts.

See, and I thought DDD was a concrete program filled in with HHH, >>>>>>>>>> which aborts after two levels of simulation, not something that >>>>>>>>>> calls "HHH" symbolically, producing many different programs. >>>>>>>>>>

I had to turn it into an infinite set of HHH/DDD
pairs so that it could be more easily understood
that DDD simulated by HHH cannot possibly halt.

When HHH detects the above non-halting behavior
pattern it kills the whole simulation process so
there is no stack unwinding.

There is no non-halting behaviour pattern, only a finite number >>>>>>>> more than N instructions are needed to reach the final input
*for this input*.

counter-factual

_DDD()
[00002192] 55-a-a-a-a-a-a-a-a push ebp
[00002193] 8bec-a-a-a-a-a-a mov ebp,esp
[00002195] 6892210000 push 00002192-a // push DDD
[0000219a] e833f4ffff call 000015d2-a // call HHH
[0000219f] 83c404-a-a-a-a add esp,+04
[000021a2] 5d-a-a-a-a-a-a-a-a pop ebp
[000021a3] c3-a-a-a-a-a-a-a-a ret
Size in bytes:(0018) [000021a3]

WE have told you many times that it is incorrect to suggest that
these 18 bytes describe the whole input for the simulator.
All functions called by DDD, directly or indirectly, also belong
to the input under test.

Every 5 instructions of DDD that are correctly emulated
end up in HHH at line one. One more instruction of
DDD emulates line two, one more emulates line three,
one more ends up at line four, one more ends up back
at line one.

Incorrect, the call ends up inside HHH. When you would correctly
follow the code of HHH in your simulator, keeping track of the
internal state of HHH and its conditional branch instruction, you >>>>>> would see that after a few cycles, HHH is specified to abort and
return to DDD at line 5.
Then lines 6 and 7 would be simulated and the final halt state is >>>>>> reached.
But HHH fails to do this correct simulation, because it
prematurely aborts before it can see that.
Then HHH uses your attitude: close its eyes and pretend that what >>>>>> is not seen does not exist.

Proving that for all N the program specifies a halting
behaviour, but we can construct *another* input for which HHH >>>>>>>> fails again.
But you cheat by changing the input, which then needs more steps. >>>>>>>

I do not cheat. I define the infinite set of HHH/DDD pairs
where HHH emulates N instructions of DDD and N is one element
of the natural numbers.

Each pair has a different input for the simulator. Each simulator >>>>>> fails for the input constructed with its own version. But many of >>>>>> them prove that the input constructed with other HHH versions,
which have less steps before the premature abort, have a final
halt state that can be reached.

Because HHH correctly predicts that DDD emulated by
HHH cannot possibly reach its own final state each HHH that
aborts after N instructions have been emulated is correct
to reject its input as non halting.

But it can't do that, as that HHH doesn't correct emulate this DDD.

HHH correctly emulates DDD until this emulated DDD
proves that it cannot possibly reach its own emulated
final halt state.

And Correctly until ... isn't correct.

In other words when HHH correctly emulates N instructions
of DDD you are claiming that HHH did not correctly emulate
N instructions of DDD and likewise 1 does not equal itself.

No, and you are just lying by changing my words.

I said that H didn't CORRCTLY EMULATE H, which means to have finished
the job.

Doing N steps, of a job that takes N+50 steps is not correct.

Or, do you think you completed your IQ test correctly when you answered
the first question (write you name) and then stopped working on the test?

Or is doing the test correcctly FINISHING it with all the answers correct.

All you are doing is demonstrating how you like to lie about things.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

On 8/4/2025 8:58 PM, Richard Damon wrote:

On 8/4/25 9:45 PM, olcott wrote:

On 8/4/2025 8:41 PM, Richard Damon wrote:

On 8/4/25 9:31 PM, olcott wrote:

On 8/4/2025 8:25 PM, Richard Damon wrote:

On 8/4/25 9:42 AM, olcott wrote:

On 8/4/2025 7:47 AM, Fred. Zwarts wrote:

Op 02.aug.2025 om 16:16 schreef olcott:

On 8/2/2025 4:18 AM, Fred. Zwarts wrote:

Op 01.aug.2025 om 16:46 schreef olcott:

On 8/1/2025 1:53 AM, joes wrote:

Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott:

On 7/31/2025 7:07 PM, Richard Damon wrote:

On 7/31/25 11:50 AM, olcott wrote:

On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
-a-a> It is a lack of technical ability on your part which >>>>>>>>>>>>>> is unable to
-a-a> judge whether such a correct simulation is possible. >>>>>>>>>>>>>> Everybody
-a-a> else sees that it is not, so further questions about >>>>>>>>>>>>>> it are
-a-a> non-sensical.
HHH emulates DDD in a separate process context. When this >>>>>>>>>>>>>> DDD calls
HHH(DDD) the original HHH emulates this HHH in the DDD >>>>>>>>>>>>>> process
context.

And that separate proccess, if left unaborted, would halt. >>>>>>>>>>>>> But HHH
gives up and aborts it, so the process is Halting, not non- >>>>>>>>>>>>> halting.

And HHH cannot simulate itself to its undeniable halting state. >>>>>>>>>>>

This emulated HHH creates yet another process context to >>>>>>>>>>>>>> emulate its
own DDD. When this DDD calls yet another HHH(DDD) this >>>>>>>>>>>>>> provides enough
execution trace that the repeating pattern can be seen. >>>>>>>>>>>>> But the pattern isn't non-halting by the fact that DDD is >>>>>>>>>>>>> shown to be

halting.

*No not at all. Not in the least little bit* Recursive >>>>>>>>>>>> simulation is
only a little more difficult than self recursion.

DDD halts if it weren't aborted.

(1) That is counter-factual. Neither HHH() nor DDD() nor DDD >>>>>>>>>> simulated by HHH ever stops running unless HHH(DDD) aborts >>>>>>>>>> its input.

It is irrelevant what a hypothetical non-input would do. HHH >>>>>>>>> aborts, so DDD and HHH, both the directly executing and the >>>>>>>>> simulated versions halt.

DDD correctly simulated by HHH cannot possibly reach
its own simulated "return" instruction final halt state
in 1 to infinity steps of correct simulation. When the
simulation is aborted the entire process is killed so
there is no stack unwinding.

(2) I have never been taking about DDD() the behavior of a >>>>>>>>>> non- input.
Turing machines are only accountable for the behavior that their >>>>>>>>>> inputs specify, they are never accountable for any non-inputs. >>>>>>>>>

And this input specifies a program with code to abort, so it >>>>>>>>> specifies a halting program. When HHH does not see that, it fails. >>>>>>>>>

I discovered a case where the correct simulation
and the direct execution have different halting
behaviors.

No, you dreamed, but could not prove it. Only by twisting the
meaning of the words, you could make yourself believing it.

(3) When I make a claim about DDD simulated by HHH and this is >>>>>>>>>> changed to the behavior of the directly executed DDD this is >>>>>>>>>> a dishonest tactic known as the strawman error.

When the input specifies a halting behaviour, it is an error to >>>>>>>>> close your eyes and pretend that it does not exist.

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

Executed HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
Then HHH kills the whole simulation process and returns 0

Counterfactual. HHH abors after a few cycles, when only one >>>>>>>>> more cycle is needed to complete the simulation, as proven by >>>>>>>>> simulators that do not abort the exact same input.

The above HHH aborts after ten recursive simulations
because people here did not understand that there were
any recursive simulation when I only show one or two.

That does not make any difference. We also see that you are
cheating, by not only changing the simulator, but also the
simulated input. World class simulators show that the original
input, when correctly simulated, reaches its final halt state
after tree recursion.
The HHH that simulates 10 recursions would also reach the final >>>>>>> halt state for this same input.
But, because your are cheating, you changed the input, which now >>>>>>> needs eleven recursion to halt.
We see in this way, the, no matter how many recursions you
simulate, this method is unable to reach the final halt state
that is specified in the input when we construct a new DDD with >>>>>>> this new HHH.

When N instructions of DDD are correctly emulated by every >>>>>>>>>>>> HHH that can
possibly exist (technically this is an infinite set of HHH/ >>>>>>>>>>>> DDD pairs)
no emulated DDD can possibly halt and every directly
executed DDD()
halts.

See, and I thought DDD was a concrete program filled in with >>>>>>>>>>> HHH,
which aborts after two levels of simulation, not something that >>>>>>>>>>> calls "HHH" symbolically, producing many different programs. >>>>>>>>>>>

I had to turn it into an infinite set of HHH/DDD
pairs so that it could be more easily understood
that DDD simulated by HHH cannot possibly halt.

When HHH detects the above non-halting behavior
pattern it kills the whole simulation process so
there is no stack unwinding.

There is no non-halting behaviour pattern, only a finite number >>>>>>>>> more than N instructions are needed to reach the final input >>>>>>>>> *for this input*.

counter-factual

_DDD()
[00002192] 55-a-a-a-a-a-a-a-a push ebp
[00002193] 8bec-a-a-a-a-a-a mov ebp,esp
[00002195] 6892210000 push 00002192-a // push DDD
[0000219a] e833f4ffff call 000015d2-a // call HHH
[0000219f] 83c404-a-a-a-a add esp,+04
[000021a2] 5d-a-a-a-a-a-a-a-a pop ebp
[000021a3] c3-a-a-a-a-a-a-a-a ret
Size in bytes:(0018) [000021a3]

WE have told you many times that it is incorrect to suggest that >>>>>>> these 18 bytes describe the whole input for the simulator.
All functions called by DDD, directly or indirectly, also belong >>>>>>> to the input under test.

Every 5 instructions of DDD that are correctly emulated
end up in HHH at line one. One more instruction of
DDD emulates line two, one more emulates line three,
one more ends up at line four, one more ends up back
at line one.

Incorrect, the call ends up inside HHH. When you would correctly >>>>>>> follow the code of HHH in your simulator, keeping track of the
internal state of HHH and its conditional branch instruction, you >>>>>>> would see that after a few cycles, HHH is specified to abort and >>>>>>> return to DDD at line 5.
Then lines 6 and 7 would be simulated and the final halt state is >>>>>>> reached.
But HHH fails to do this correct simulation, because it
prematurely aborts before it can see that.
Then HHH uses your attitude: close its eyes and pretend that what >>>>>>> is not seen does not exist.

Proving that for all N the program specifies a halting
behaviour, but we can construct *another* input for which HHH >>>>>>>>> fails again.
But you cheat by changing the input, which then needs more steps. >>>>>>>>

I do not cheat. I define the infinite set of HHH/DDD pairs
where HHH emulates N instructions of DDD and N is one element
of the natural numbers.

Each pair has a different input for the simulator. Each simulator >>>>>>> fails for the input constructed with its own version. But many of >>>>>>> them prove that the input constructed with other HHH versions,
which have less steps before the premature abort, have a final
halt state that can be reached.

Because HHH correctly predicts that DDD emulated by
HHH cannot possibly reach its own final state each HHH that
aborts after N instructions have been emulated is correct
to reject its input as non halting.

But it can't do that, as that HHH doesn't correct emulate this DDD.

HHH correctly emulates DDD until this emulated DDD
proves that it cannot possibly reach its own emulated
final halt state.

And Correctly until ... isn't correct.

In other words when HHH correctly emulates N instructions
of DDD you are claiming that HHH did not correctly emulate
N instructions of DDD and likewise 1 does not equal itself.

No, and you are just lying by changing my words.

I am paraphrasing so that we can get a mutual understanding.

I said that H didn't CORRCTLY EMULATE H, which means to have finished
the job.

When HHH correctly emulates N instructions of DDD
then HHH has correctly finished its job of correctly
emulating N instructions of DDD.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

Op 04.aug.2025 om 15:42 schreef olcott:

On 8/4/2025 7:47 AM, Fred. Zwarts wrote:

Op 02.aug.2025 om 16:16 schreef olcott:

On 8/2/2025 4:18 AM, Fred. Zwarts wrote:

Op 01.aug.2025 om 16:46 schreef olcott:

On 8/1/2025 1:53 AM, joes wrote:

Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott:

On 7/31/2025 7:07 PM, Richard Damon wrote:

On 7/31/25 11:50 AM, olcott wrote:

On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
-a-a> It is a lack of technical ability on your part which is >>>>>>>>> unable to
-a-a> judge whether such a correct simulation is possible. >>>>>>>>> Everybody
-a-a> else sees that it is not, so further questions about it are >>>>>>>>> -a-a> non-sensical.
HHH emulates DDD in a separate process context. When this DDD >>>>>>>>> calls
HHH(DDD) the original HHH emulates this HHH in the DDD process >>>>>>>>> context.

And that separate proccess, if left unaborted, would halt. But HHH >>>>>>>> gives up and aborts it, so the process is Halting, not non-halting. >>>>>

And HHH cannot simulate itself to its undeniable halting state.

This emulated HHH creates yet another process context to
emulate its
own DDD. When this DDD calls yet another HHH(DDD) this provides >>>>>>>>> enough
execution trace that the repeating pattern can be seen.

But the pattern isn't non-halting by the fact that DDD is shown >>>>>>>> to be
halting.

*No not at all. Not in the least little bit* Recursive simulation is >>>>>>> only a little more difficult than self recursion.

DDD halts if it weren't aborted.

(1) That is counter-factual. Neither HHH() nor DDD() nor DDD
simulated by HHH ever stops running unless HHH(DDD) aborts
its input.

It is irrelevant what a hypothetical non-input would do. HHH aborts,
so DDD and HHH, both the directly executing and the simulated
versions halt.

DDD correctly simulated by HHH cannot possibly reach
its own simulated "return" instruction final halt state
in 1 to infinity steps of correct simulation. When the
simulation is aborted the entire process is killed so
there is no stack unwinding.

(2) I have never been taking about DDD() the behavior of a non-input. >>>>> Turing machines are only accountable for the behavior that their
inputs specify, they are never accountable for any non-inputs.

And this input specifies a program with code to abort, so it
specifies a halting program. When HHH does not see that, it fails.

I discovered a case where the correct simulation
and the direct execution have different halting
behaviors.

No, you dreamed, but could not prove it. Only by twisting the meaning
of the words, you could make yourself believing it.

(3) When I make a claim about DDD simulated by HHH and this is
changed to the behavior of the directly executed DDD this is
a dishonest tactic known as the strawman error.

When the input specifies a halting behaviour, it is an error to
close your eyes and pretend that it does not exist.

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

Executed HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
Then HHH kills the whole simulation process and returns 0

Counterfactual. HHH abors after a few cycles, when only one more
cycle is needed to complete the simulation, as proven by simulators
that do not abort the exact same input.

The above HHH aborts after ten recursive simulations
because people here did not understand that there were
any recursive simulation when I only show one or two.

That does not make any difference. We also see that you are cheating,
by not only changing the simulator, but also the simulated input.
World class simulators show that the original input, when correctly
simulated, reaches its final halt state after tree recursion.
The HHH that simulates 10 recursions would also reach the final halt
state for this same input.
But, because your are cheating, you changed the input, which now needs
eleven recursion to halt.
We see in this way, the, no matter how many recursions you simulate,
this method is unable to reach the final halt state that is specified
in the input when we construct a new DDD with this new HHH.

When N instructions of DDD are correctly emulated by every HHH
that can
possibly exist (technically this is an infinite set of HHH/DDD
pairs)
no emulated DDD can possibly halt and every directly executed DDD() >>>>>>> halts.

See, and I thought DDD was a concrete program filled in with HHH,
which aborts after two levels of simulation, not something that
calls "HHH" symbolically, producing many different programs.

I had to turn it into an infinite set of HHH/DDD
pairs so that it could be more easily understood
that DDD simulated by HHH cannot possibly halt.

When HHH detects the above non-halting behavior
pattern it kills the whole simulation process so
there is no stack unwinding.

There is no non-halting behaviour pattern, only a finite number more
than N instructions are needed to reach the final input *for this
input*.

counter-factual

_DDD()
[00002192] 55-a-a-a-a-a-a-a-a push ebp
[00002193] 8bec-a-a-a-a-a-a mov ebp,esp
[00002195] 6892210000 push 00002192-a // push DDD
[0000219a] e833f4ffff call 000015d2-a // call HHH
[0000219f] 83c404-a-a-a-a add esp,+04
[000021a2] 5d-a-a-a-a-a-a-a-a pop ebp
[000021a3] c3-a-a-a-a-a-a-a-a ret
Size in bytes:(0018) [000021a3]

WE have told you many times that it is incorrect to suggest that these
18 bytes describe the whole input for the simulator.
All functions called by DDD, directly or indirectly, also belong to
the input under test.

Every 5 instructions of DDD that are correctly emulated
end up in HHH at line one. One more instruction of
DDD emulates line two, one more emulates line three,
one more ends up at line four, one more ends up back
at line one.

Incorrect, the call ends up inside HHH. When you would correctly
follow the code of HHH in your simulator, keeping track of the
internal state of HHH and its conditional branch instruction, you
would see that after a few cycles, HHH is specified to abort and
return to DDD at line 5.
Then lines 6 and 7 would be simulated and the final halt state is
reached.
But HHH fails to do this correct simulation, because it prematurely
aborts before it can see that.
Then HHH uses your attitude: close its eyes and pretend that what is
not seen does not exist.

Proving that for all N the program specifies a halting behaviour,
but we can construct *another* input for which HHH fails again.
But you cheat by changing the input, which then needs more steps.

I do not cheat. I define the infinite set of HHH/DDD pairs
where HHH emulates N instructions of DDD and N is one element
of the natural numbers.

Each pair has a different input for the simulator. Each simulator
fails for the input constructed with its own version. But many of them
prove that the input constructed with other HHH versions, which have
less steps before the premature abort, have a final halt state that
can be reached.

Because HHH correctly predicts that DDD emulated by
HHH cannot possibly reach its own final state each HHH that
aborts after N instructions have been emulated is correct
to reject its input as non halting.

As usual incorrect claims without evidence.
The final state specified in the input can be reached by many
simulators, even many versions of HHH that simulate more cycles.
This proves that the final halt state is specified in the input.
If HHH cannot reach that specified halt state, it simply fails.

This shows that the infinite set is irrelevant.
One example if already enough to prove the failure of this method.
So, don't change the subject and lets stay at the HHH that aborts
after two cycles, which need a simulator that simulates at least three
cycles.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

Op 04.aug.2025 om 15:38 schreef olcott:

On 8/4/2025 7:33 AM, Fred. Zwarts wrote:

Op 02.aug.2025 om 16:17 schreef olcott:

On 8/2/2025 4:22 AM, Fred. Zwarts wrote:

Op 01.aug.2025 om 16:54 schreef olcott:

On 8/1/2025 2:11 AM, joes wrote:

Am Thu, 31 Jul 2025 20:03:15 -0500 schrieb olcott:

On 7/31/2025 7:37 PM, Richard Damon wrote:

On 7/31/25 8:18 PM, olcott wrote:

On 7/31/2025 7:07 PM, Richard Damon wrote:

On 7/31/25 11:50 AM, olcott wrote:

And that separate proccess, if left unaborted, would halt. But >>>>>>>>>> HHH
gives up and aborts it, so the process is Halting, not non- >>>>>>>>>> halting.

But the pattern isn't non-halting by the fact that DDD is >>>>>>>>>> shown to be
halting.

but since it is only finite recursion of partial simulation,
since the
first level WILL abort the process and end the recursion.

When N instructions of DDD are correctly emulated by every HHH >>>>>>>>> that
can possibly exist (technically this is an infinite set of HHH/DDD >>>>>>>>> pairs) no emulated DDD can possibly halt and every directly >>>>>>>>> executed
DDD() halts.

Wrong, your problem is you forget that all those DDD are different, >>>>>>> It is an infinite set with every HHH/DDD pair having the same

property
that each DDD cannot possibly halt.

Sure, but what about different HHH_n's simulating the same DDD?

_DDD()
[00002192] 55-a-a-a-a-a-a-a-a push ebp
[00002193] 8bec-a-a-a-a-a-a mov ebp,esp
[00002195] 6892210000 push 00002192-a // push DDD
[0000219a] e833f4ffff call 000015d2-a // call HHH
[0000219f] 83c404-a-a-a-a add esp,+04
[000021a2] 5d-a-a-a-a-a-a-a-a pop ebp
[000021a3] c3-a-a-a-a-a-a-a-a ret
Size in bytes:(0018) [000021a3]

Each element of the infinite set of HHH/DDD pairs
that emulates a natural number N number of instructions
of DDD never halts.

Because HHH aborts prematurely,

Try to prove that and you will find that
your proof is incoherent or has glaring gaps.

That has been proven multiple times, but you close your eyes for it.

Show every single step of the execution trace of DDD
such that DDD simulated by HHH that never aborts reaches
its own machine address of [000021a3].

That trace has been show when world-class simulators simulated this input.
Even the HHH that does not abort will show the trace.
But, of course, we can create another input, with another DDD using the
HHH that does not abort, for which this HHH fails.
But that is irrelevant.
We are talking about an HHH that aborts after two cycles. *That* is the
input. It is irrelevant to change the subject and start talking about
another input.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

On 8/4/25 10:05 PM, olcott wrote:

On 8/4/2025 8:58 PM, Richard Damon wrote:

On 8/4/25 9:45 PM, olcott wrote:

On 8/4/2025 8:41 PM, Richard Damon wrote:

On 8/4/25 9:31 PM, olcott wrote:

On 8/4/2025 8:25 PM, Richard Damon wrote:

On 8/4/25 9:42 AM, olcott wrote:

On 8/4/2025 7:47 AM, Fred. Zwarts wrote:

Op 02.aug.2025 om 16:16 schreef olcott:

On 8/2/2025 4:18 AM, Fred. Zwarts wrote:

Op 01.aug.2025 om 16:46 schreef olcott:

On 8/1/2025 1:53 AM, joes wrote:

Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott:

On 7/31/2025 7:07 PM, Richard Damon wrote:

On 7/31/25 11:50 AM, olcott wrote:

On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
-a-a> It is a lack of technical ability on your part which >>>>>>>>>>>>>>> is unable to
-a-a> judge whether such a correct simulation is possible. >>>>>>>>>>>>>>> Everybody
-a-a> else sees that it is not, so further questions about >>>>>>>>>>>>>>> it are
-a-a> non-sensical.
HHH emulates DDD in a separate process context. When this >>>>>>>>>>>>>>> DDD calls
HHH(DDD) the original HHH emulates this HHH in the DDD >>>>>>>>>>>>>>> process
context.

And that separate proccess, if left unaborted, would halt. >>>>>>>>>>>>>> But HHH
gives up and aborts it, so the process is Halting, not >>>>>>>>>>>>>> non- halting.

And HHH cannot simulate itself to its undeniable halting state. >>>>>>>>>>>>

This emulated HHH creates yet another process context to >>>>>>>>>>>>>>> emulate its
own DDD. When this DDD calls yet another HHH(DDD) this >>>>>>>>>>>>>>> provides enough
execution trace that the repeating pattern can be seen. >>>>>>>>>>>>>> But the pattern isn't non-halting by the fact that DDD is >>>>>>>>>>>>>> shown to be

halting.

*No not at all. Not in the least little bit* Recursive >>>>>>>>>>>>> simulation is
only a little more difficult than self recursion.

DDD halts if it weren't aborted.

(1) That is counter-factual. Neither HHH() nor DDD() nor DDD >>>>>>>>>>> simulated by HHH ever stops running unless HHH(DDD) aborts >>>>>>>>>>> its input.

It is irrelevant what a hypothetical non-input would do. HHH >>>>>>>>>> aborts, so DDD and HHH, both the directly executing and the >>>>>>>>>> simulated versions halt.

DDD correctly simulated by HHH cannot possibly reach
its own simulated "return" instruction final halt state
in 1 to infinity steps of correct simulation. When the
simulation is aborted the entire process is killed so
there is no stack unwinding.

(2) I have never been taking about DDD() the behavior of a >>>>>>>>>>> non- input.
Turing machines are only accountable for the behavior that their >>>>>>>>>>> inputs specify, they are never accountable for any non-inputs. >>>>>>>>>>

And this input specifies a program with code to abort, so it >>>>>>>>>> specifies a halting program. When HHH does not see that, it >>>>>>>>>> fails.

I discovered a case where the correct simulation
and the direct execution have different halting
behaviors.

No, you dreamed, but could not prove it. Only by twisting the >>>>>>>> meaning of the words, you could make yourself believing it.

(3) When I make a claim about DDD simulated by HHH and this is >>>>>>>>>>> changed to the behavior of the directly executed DDD this is >>>>>>>>>>> a dishonest tactic known as the strawman error.

When the input specifies a halting behaviour, it is an error >>>>>>>>>> to close your eyes and pretend that it does not exist.

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

Executed HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
Then HHH kills the whole simulation process and returns 0 >>>>>>>>>>

Counterfactual. HHH abors after a few cycles, when only one >>>>>>>>>> more cycle is needed to complete the simulation, as proven by >>>>>>>>>> simulators that do not abort the exact same input.

The above HHH aborts after ten recursive simulations
because people here did not understand that there were
any recursive simulation when I only show one or two.

That does not make any difference. We also see that you are
cheating, by not only changing the simulator, but also the
simulated input. World class simulators show that the original >>>>>>>> input, when correctly simulated, reaches its final halt state >>>>>>>> after tree recursion.
The HHH that simulates 10 recursions would also reach the final >>>>>>>> halt state for this same input.
But, because your are cheating, you changed the input, which now >>>>>>>> needs eleven recursion to halt.
We see in this way, the, no matter how many recursions you
simulate, this method is unable to reach the final halt state >>>>>>>> that is specified in the input when we construct a new DDD with >>>>>>>> this new HHH.

When N instructions of DDD are correctly emulated by every >>>>>>>>>>>>> HHH that can
possibly exist (technically this is an infinite set of HHH/ >>>>>>>>>>>>> DDD pairs)
no emulated DDD can possibly halt and every directly >>>>>>>>>>>>> executed DDD()
halts.

See, and I thought DDD was a concrete program filled in with >>>>>>>>>>>> HHH,
which aborts after two levels of simulation, not something that >>>>>>>>>>>> calls "HHH" symbolically, producing many different programs. >>>>>>>>>>>>

I had to turn it into an infinite set of HHH/DDD
pairs so that it could be more easily understood
that DDD simulated by HHH cannot possibly halt.

When HHH detects the above non-halting behavior
pattern it kills the whole simulation process so
there is no stack unwinding.

There is no non-halting behaviour pattern, only a finite
number more than N instructions are needed to reach the final >>>>>>>>>> input *for this input*.

counter-factual

_DDD()
[00002192] 55-a-a-a-a-a-a-a-a push ebp
[00002193] 8bec-a-a-a-a-a-a mov ebp,esp
[00002195] 6892210000 push 00002192-a // push DDD
[0000219a] e833f4ffff call 000015d2-a // call HHH
[0000219f] 83c404-a-a-a-a add esp,+04
[000021a2] 5d-a-a-a-a-a-a-a-a pop ebp
[000021a3] c3-a-a-a-a-a-a-a-a ret
Size in bytes:(0018) [000021a3]

WE have told you many times that it is incorrect to suggest that >>>>>>>> these 18 bytes describe the whole input for the simulator.
All functions called by DDD, directly or indirectly, also belong >>>>>>>> to the input under test.

Every 5 instructions of DDD that are correctly emulated
end up in HHH at line one. One more instruction of
DDD emulates line two, one more emulates line three,
one more ends up at line four, one more ends up back
at line one.

Incorrect, the call ends up inside HHH. When you would correctly >>>>>>>> follow the code of HHH in your simulator, keeping track of the >>>>>>>> internal state of HHH and its conditional branch instruction, >>>>>>>> you would see that after a few cycles, HHH is specified to abort >>>>>>>> and return to DDD at line 5.
Then lines 6 and 7 would be simulated and the final halt state >>>>>>>> is reached.
But HHH fails to do this correct simulation, because it
prematurely aborts before it can see that.
Then HHH uses your attitude: close its eyes and pretend that
what is not seen does not exist.

Proving that for all N the program specifies a halting
behaviour, but we can construct *another* input for which HHH >>>>>>>>>> fails again.
But you cheat by changing the input, which then needs more steps. >>>>>>>>>

I do not cheat. I define the infinite set of HHH/DDD pairs
where HHH emulates N instructions of DDD and N is one element >>>>>>>>> of the natural numbers.

Each pair has a different input for the simulator. Each
simulator fails for the input constructed with its own version. >>>>>>>> But many of them prove that the input constructed with other HHH >>>>>>>> versions, which have less steps before the premature abort, have >>>>>>>> a final halt state that can be reached.

Because HHH correctly predicts that DDD emulated by
HHH cannot possibly reach its own final state each HHH that
aborts after N instructions have been emulated is correct
to reject its input as non halting.

But it can't do that, as that HHH doesn't correct emulate this DDD. >>>>>>

HHH correctly emulates DDD until this emulated DDD
proves that it cannot possibly reach its own emulated
final halt state.

And Correctly until ... isn't correct.

In other words when HHH correctly emulates N instructions
of DDD you are claiming that HHH did not correctly emulate
N instructions of DDD and likewise 1 does not equal itself.

No, and you are just lying by changing my words.

I am paraphrasing so that we can get a mutual understanding.

You mean you are LYING by changing the meaning of them, just like you
falsely accuse everyone else.

Sorry, all you are doing is proving you are a Hypocritical Pathological
Liar that doesn't care about what it true.

I said that H didn't CORRCTLY EMULATE H, which means to have finished
the job.

When HHH correctly emulates N instructions of DDD
then HHH has correctly finished its job of correctly
emulating N instructions of DDD.

But its job wasn't to emulate N instructions of DDD, its job was to
predict if DDD will halt when run.

It seems you can't understand the basic words you are reading and
saying, because you just live in your own fantasy world were lies are acceptable and the rules don't matter.

I guess you are just showing that none of your work was based on what
you claim, and that you have no idea what the Halting Problem is about.

It seems the issue is that the Halting Problem isn't actually important
to you, just that it proves that you ideas of logic are just lies, so
you just try to use your lies to discredit it, but just discredit
yourself in the process.

Not understanding how actual Formal Logic works really does handicap you ability to talk about things based on it.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

On 8/5/2025 5:53 AM, Richard Damon wrote:

On 8/4/25 10:05 PM, olcott wrote:

On 8/4/2025 8:58 PM, Richard Damon wrote:

On 8/4/25 9:45 PM, olcott wrote:

In other words when HHH correctly emulates N instructions
of DDD you are claiming that HHH did not correctly emulate
N instructions of DDD and likewise 1 does not equal itself.

No, and you are just lying by changing my words.

I am paraphrasing so that we can get a mutual understanding.

You mean you are LYING by changing the meaning of them, just like you falsely accuse everyone else.

Sorry, all you are doing is proving you are a Hypocritical Pathological
Liar that doesn't care about what it true.

I said that H didn't CORRCTLY EMULATE H, which means to have finished
the job.

When HHH correctly emulates N instructions of DDD
then HHH has correctly finished its job of correctly
emulating N instructions of DDD.

But its job wasn't to emulate N instructions of DDD, its job was to
predict if DDD will halt when run.

*From the bottom of page 319 has been adapted to this* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf

Definition of Turing Machine -n applied
to its own machine description rf?-nrf-
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR,
if -n applied to rf?-nrf- halts, and
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn
if -n applied to rf?-nrf- does not halt.

*Lines 2 and 4 above*
*Does insist that -n.embedded_H report on its own behavior*

"The contradiction in Linz's (or Turing's) self-referential
halting construction only appears if one insists that the
machine can and must decide on its own behavior, which is
neither possible nor required."

https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8

The definition of Turing Machines proves that none of
them can directly report on their own behavior on the
basis that Turing machines do not take other Turing
machines as inputs and no actual Machine can be an
actual input to itself.

In those cases where the behavior specified by the
input does not agree with the behavior of the direct
execution the behavior of the input overrules.

The fact that this disagrees with what your learned
by rote is not an actual rebuttal. Learning by rote
is not the ultimate measure of truth.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

On 8/5/2025 5:53 AM, Richard Damon wrote:

On 8/4/25 10:05 PM, olcott wrote:

On 8/4/2025 8:58 PM, Richard Damon wrote:

On 8/4/25 9:45 PM, olcott wrote:

On 8/4/2025 8:41 PM, Richard Damon wrote:

On 8/4/25 9:31 PM, olcott wrote:

On 8/4/2025 8:25 PM, Richard Damon wrote:

On 8/4/25 9:42 AM, olcott wrote:

On 8/4/2025 7:47 AM, Fred. Zwarts wrote:

Op 02.aug.2025 om 16:16 schreef olcott:

On 8/2/2025 4:18 AM, Fred. Zwarts wrote:

Op 01.aug.2025 om 16:46 schreef olcott:

On 8/1/2025 1:53 AM, joes wrote:

Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott:

On 7/31/2025 7:07 PM, Richard Damon wrote:

On 7/31/25 11:50 AM, olcott wrote:

On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
-a-a> It is a lack of technical ability on your part which >>>>>>>>>>>>>>>> is unable to
-a-a> judge whether such a correct simulation is possible. >>>>>>>>>>>>>>>> Everybody
-a-a> else sees that it is not, so further questions about >>>>>>>>>>>>>>>> it are
-a-a> non-sensical.
HHH emulates DDD in a separate process context. When >>>>>>>>>>>>>>>> this DDD calls
HHH(DDD) the original HHH emulates this HHH in the DDD >>>>>>>>>>>>>>>> process
context.

And that separate proccess, if left unaborted, would >>>>>>>>>>>>>>> halt. But HHH
gives up and aborts it, so the process is Halting, not >>>>>>>>>>>>>>> non- halting.

And HHH cannot simulate itself to its undeniable halting >>>>>>>>>>>>> state.

This emulated HHH creates yet another process context to >>>>>>>>>>>>>>>> emulate its
own DDD. When this DDD calls yet another HHH(DDD) this >>>>>>>>>>>>>>>> provides enough
execution trace that the repeating pattern can be seen. >>>>>>>>>>>>>>> But the pattern isn't non-halting by the fact that DDD is >>>>>>>>>>>>>>> shown to be

halting.

*No not at all. Not in the least little bit* Recursive >>>>>>>>>>>>>> simulation is
only a little more difficult than self recursion.

DDD halts if it weren't aborted.

(1) That is counter-factual. Neither HHH() nor DDD() nor DDD >>>>>>>>>>>> simulated by HHH ever stops running unless HHH(DDD) aborts >>>>>>>>>>>> its input.

It is irrelevant what a hypothetical non-input would do. HHH >>>>>>>>>>> aborts, so DDD and HHH, both the directly executing and the >>>>>>>>>>> simulated versions halt.

DDD correctly simulated by HHH cannot possibly reach
its own simulated "return" instruction final halt state
in 1 to infinity steps of correct simulation. When the
simulation is aborted the entire process is killed so
there is no stack unwinding.

(2) I have never been taking about DDD() the behavior of a >>>>>>>>>>>> non- input.
Turing machines are only accountable for the behavior that >>>>>>>>>>>> their
inputs specify, they are never accountable for any non-inputs. >>>>>>>>>>>

And this input specifies a program with code to abort, so it >>>>>>>>>>> specifies a halting program. When HHH does not see that, it >>>>>>>>>>> fails.

I discovered a case where the correct simulation
and the direct execution have different halting
behaviors.

No, you dreamed, but could not prove it. Only by twisting the >>>>>>>>> meaning of the words, you could make yourself believing it.

(3) When I make a claim about DDD simulated by HHH and this is >>>>>>>>>>>> changed to the behavior of the directly executed DDD this is >>>>>>>>>>>> a dishonest tactic known as the strawman error.

When the input specifies a halting behaviour, it is an error >>>>>>>>>>> to close your eyes and pretend that it does not exist.

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

Executed HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
Then HHH kills the whole simulation process and returns 0 >>>>>>>>>>>

Counterfactual. HHH abors after a few cycles, when only one >>>>>>>>>>> more cycle is needed to complete the simulation, as proven by >>>>>>>>>>> simulators that do not abort the exact same input.

The above HHH aborts after ten recursive simulations
because people here did not understand that there were
any recursive simulation when I only show one or two.

That does not make any difference. We also see that you are >>>>>>>>> cheating, by not only changing the simulator, but also the
simulated input. World class simulators show that the original >>>>>>>>> input, when correctly simulated, reaches its final halt state >>>>>>>>> after tree recursion.
The HHH that simulates 10 recursions would also reach the final >>>>>>>>> halt state for this same input.
But, because your are cheating, you changed the input, which >>>>>>>>> now needs eleven recursion to halt.
We see in this way, the, no matter how many recursions you
simulate, this method is unable to reach the final halt state >>>>>>>>> that is specified in the input when we construct a new DDD with >>>>>>>>> this new HHH.

When N instructions of DDD are correctly emulated by every >>>>>>>>>>>>>> HHH that can
possibly exist (technically this is an infinite set of >>>>>>>>>>>>>> HHH/ DDD pairs)
no emulated DDD can possibly halt and every directly >>>>>>>>>>>>>> executed DDD()
halts.

See, and I thought DDD was a concrete program filled in >>>>>>>>>>>>> with HHH,
which aborts after two levels of simulation, not something >>>>>>>>>>>>> that
calls "HHH" symbolically, producing many different programs. >>>>>>>>>>>>>

I had to turn it into an infinite set of HHH/DDD
pairs so that it could be more easily understood
that DDD simulated by HHH cannot possibly halt.

When HHH detects the above non-halting behavior
pattern it kills the whole simulation process so
there is no stack unwinding.

There is no non-halting behaviour pattern, only a finite >>>>>>>>>>> number more than N instructions are needed to reach the final >>>>>>>>>>> input *for this input*.

counter-factual

_DDD()
[00002192] 55-a-a-a-a-a-a-a-a push ebp
[00002193] 8bec-a-a-a-a-a-a mov ebp,esp
[00002195] 6892210000 push 00002192-a // push DDD
[0000219a] e833f4ffff call 000015d2-a // call HHH
[0000219f] 83c404-a-a-a-a add esp,+04
[000021a2] 5d-a-a-a-a-a-a-a-a pop ebp
[000021a3] c3-a-a-a-a-a-a-a-a ret
Size in bytes:(0018) [000021a3]

WE have told you many times that it is incorrect to suggest >>>>>>>>> that these 18 bytes describe the whole input for the simulator. >>>>>>>>> All functions called by DDD, directly or indirectly, also
belong to the input under test.

Every 5 instructions of DDD that are correctly emulated
end up in HHH at line one. One more instruction of
DDD emulates line two, one more emulates line three,
one more ends up at line four, one more ends up back
at line one.

Incorrect, the call ends up inside HHH. When you would
correctly follow the code of HHH in your simulator, keeping >>>>>>>>> track of the internal state of HHH and its conditional branch >>>>>>>>> instruction, you would see that after a few cycles, HHH is
specified to abort and return to DDD at line 5.
Then lines 6 and 7 would be simulated and the final halt state >>>>>>>>> is reached.
But HHH fails to do this correct simulation, because it
prematurely aborts before it can see that.
Then HHH uses your attitude: close its eyes and pretend that >>>>>>>>> what is not seen does not exist.

Proving that for all N the program specifies a halting
behaviour, but we can construct *another* input for which HHH >>>>>>>>>>> fails again.
But you cheat by changing the input, which then needs more >>>>>>>>>>> steps.

I do not cheat. I define the infinite set of HHH/DDD pairs >>>>>>>>>> where HHH emulates N instructions of DDD and N is one element >>>>>>>>>> of the natural numbers.

Each pair has a different input for the simulator. Each
simulator fails for the input constructed with its own version. >>>>>>>>> But many of them prove that the input constructed with other >>>>>>>>> HHH versions, which have less steps before the premature abort, >>>>>>>>> have a final halt state that can be reached.

Because HHH correctly predicts that DDD emulated by
HHH cannot possibly reach its own final state each HHH that
aborts after N instructions have been emulated is correct
to reject its input as non halting.

But it can't do that, as that HHH doesn't correct emulate this DDD. >>>>>>>

HHH correctly emulates DDD until this emulated DDD
proves that it cannot possibly reach its own emulated
final halt state.

And Correctly until ... isn't correct.

In other words when HHH correctly emulates N instructions
of DDD you are claiming that HHH did not correctly emulate
N instructions of DDD and likewise 1 does not equal itself.

No, and you are just lying by changing my words.

I am paraphrasing so that we can get a mutual understanding.

You mean you are LYING by changing the meaning of them, just like you falsely accuse everyone else.

Sorry, all you are doing is proving you are a Hypocritical Pathological
Liar that doesn't care about what it true.

I said that H didn't CORRCTLY EMULATE H, which means to have finished
the job.

When HHH correctly emulates N instructions of DDD
then HHH has correctly finished its job of correctly
emulating N instructions of DDD.

But its job wasn't to emulate N instructions of DDD, its job was to
predict if DDD will halt when run.

The definition of a simulating halt decider stipulates otherwise.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

On 8/5/25 12:03 PM, olcott wrote:

On 8/5/2025 5:53 AM, Richard Damon wrote:

On 8/4/25 10:05 PM, olcott wrote:

On 8/4/2025 8:58 PM, Richard Damon wrote:

On 8/4/25 9:45 PM, olcott wrote:

In other words when HHH correctly emulates N instructions
of DDD you are claiming that HHH did not correctly emulate
N instructions of DDD and likewise 1 does not equal itself.

No, and you are just lying by changing my words.

I am paraphrasing so that we can get a mutual understanding.

You mean you are LYING by changing the meaning of them, just like you
falsely accuse everyone else.

Sorry, all you are doing is proving you are a Hypocritical
Pathological Liar that doesn't care about what it true.

I said that H didn't CORRCTLY EMULATE H, which means to have
finished the job.

When HHH correctly emulates N instructions of DDD
then HHH has correctly finished its job of correctly
emulating N instructions of DDD.

But its job wasn't to emulate N instructions of DDD, its job was to
predict if DDD will halt when run.

*From the bottom of page 319 has been adapted to this* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf

Definition of Turing Machine -n applied
to its own machine description rf?-nrf-
-a-a -n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR,
if -n applied to rf?-nrf- halts, and
-a-a -n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn
if -n applied to rf?-nrf- does not halt.

*Lines 2 and 4 above*
*Does insist that -n.embedded_H report on its own behavior*

-a-a "The contradiction in Linz's (or Turing's) self-referential
-a-a-a halting construction only appears if one insists that the
-a-a-a machine can and must decide on its own behavior, which is
-a-a-a neither possible nor required."

https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8

The definition of Turing Machines proves that none of
them can directly report on their own behavior on the
basis that Turing machines do not take other Turing
machines as inputs and no actual Machine can be an
actual input to itself.

Then you think Turing Machine can't report an the mathematics of
numbers, or by equivalence, computers can't process pictures, video,
audio or text, as the ACTUAL domain of computers as sets of 0s and 1s,
which none of those are, only their representaiton is.

In those cases where the behavior specified by the
input does not agree with the behavior of the direct
execution the behavior of the input overrules.

But the behavior of the input was DEFINED to be the behavior of the
machine it represents, which will exactly match the UTM simulation of
the input (by the definition of a UTM).

Thus, to claim the behavior of the input differs from the behavior of
the machine it was supposed to describe just shows that you made an
error, and are just lying.

The fact that this disagrees with what your learned
by rote is not an actual rebuttal. Learning by rote
is not the ultimate measure of truth.

No, it just shows that you are lying to yourself.

If the UTM simulation of the input doesn't match the machine that you
claimed it represented, then it wasn't actually the representation of
that machine.

Since YOU provided that input, it was YOU that made the error.

If there is no suitable input that can be given to the decider then you
just proved that you system isn't Turing Complete, as you just admitted
that UTMs don't exist in your system, or you decide is just incorrect
defined.

Sorry, you are just proving that you are just a liar.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

On 8/5/25 9:10 PM, olcott wrote:

On 8/5/2025 5:53 AM, Richard Damon wrote:

On 8/4/25 10:05 PM, olcott wrote:

On 8/4/2025 8:58 PM, Richard Damon wrote:

On 8/4/25 9:45 PM, olcott wrote:

On 8/4/2025 8:41 PM, Richard Damon wrote:

On 8/4/25 9:31 PM, olcott wrote:

On 8/4/2025 8:25 PM, Richard Damon wrote:

On 8/4/25 9:42 AM, olcott wrote:

On 8/4/2025 7:47 AM, Fred. Zwarts wrote:

Op 02.aug.2025 om 16:16 schreef olcott:

On 8/2/2025 4:18 AM, Fred. Zwarts wrote:

Op 01.aug.2025 om 16:46 schreef olcott:

On 8/1/2025 1:53 AM, joes wrote:

Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 7/31/2025 7:07 PM, Richard Damon wrote:

On 7/31/25 11:50 AM, olcott wrote:

On 7/29/2025 11:22 PM, Alan Mackenzie wrote: >>>>>>>>>>>>>>>>> -a-a> It is a lack of technical ability on your part >>>>>>>>>>>>>>>>> which is unable to
-a-a> judge whether such a correct simulation is >>>>>>>>>>>>>>>>> possible. Everybody
-a-a> else sees that it is not, so further questions >>>>>>>>>>>>>>>>> about it are
-a-a> non-sensical.
HHH emulates DDD in a separate process context. When >>>>>>>>>>>>>>>>> this DDD calls
HHH(DDD) the original HHH emulates this HHH in the DDD >>>>>>>>>>>>>>>>> process
context.

And that separate proccess, if left unaborted, would >>>>>>>>>>>>>>>> halt. But HHH
gives up and aborts it, so the process is Halting, not >>>>>>>>>>>>>>>> non- halting.

And HHH cannot simulate itself to its undeniable halting >>>>>>>>>>>>>> state.

This emulated HHH creates yet another process context >>>>>>>>>>>>>>>>> to emulate its
own DDD. When this DDD calls yet another HHH(DDD) this >>>>>>>>>>>>>>>>> provides enough
execution trace that the repeating pattern can be seen. >>>>>>>>>>>>>>>> But the pattern isn't non-halting by the fact that DDD >>>>>>>>>>>>>>>> is shown to be

halting.

*No not at all. Not in the least little bit* Recursive >>>>>>>>>>>>>>> simulation is
only a little more difficult than self recursion.

DDD halts if it weren't aborted.

(1) That is counter-factual. Neither HHH() nor DDD() nor DDD >>>>>>>>>>>>> simulated by HHH ever stops running unless HHH(DDD) aborts >>>>>>>>>>>>> its input.

It is irrelevant what a hypothetical non-input would do. HHH >>>>>>>>>>>> aborts, so DDD and HHH, both the directly executing and the >>>>>>>>>>>> simulated versions halt.

DDD correctly simulated by HHH cannot possibly reach
its own simulated "return" instruction final halt state
in 1 to infinity steps of correct simulation. When the
simulation is aborted the entire process is killed so
there is no stack unwinding.

(2) I have never been taking about DDD() the behavior of a >>>>>>>>>>>>> non- input.
Turing machines are only accountable for the behavior that >>>>>>>>>>>>> their
inputs specify, they are never accountable for any non-inputs. >>>>>>>>>>>>

And this input specifies a program with code to abort, so it >>>>>>>>>>>> specifies a halting program. When HHH does not see that, it >>>>>>>>>>>> fails.

I discovered a case where the correct simulation
and the direct execution have different halting
behaviors.

No, you dreamed, but could not prove it. Only by twisting the >>>>>>>>>> meaning of the words, you could make yourself believing it. >>>>>>>>>>

(3) When I make a claim about DDD simulated by HHH and this is >>>>>>>>>>>>> changed to the behavior of the directly executed DDD this is >>>>>>>>>>>>> a dishonest tactic known as the strawman error.

When the input specifies a halting behaviour, it is an error >>>>>>>>>>>> to close your eyes and pretend that it does not exist. >>>>>>>>>>>>

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

Executed HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
Then HHH kills the whole simulation process and returns 0 >>>>>>>>>>>>

Counterfactual. HHH abors after a few cycles, when only one >>>>>>>>>>>> more cycle is needed to complete the simulation, as proven >>>>>>>>>>>> by simulators that do not abort the exact same input.

The above HHH aborts after ten recursive simulations
because people here did not understand that there were
any recursive simulation when I only show one or two.

That does not make any difference. We also see that you are >>>>>>>>>> cheating, by not only changing the simulator, but also the >>>>>>>>>> simulated input. World class simulators show that the original >>>>>>>>>> input, when correctly simulated, reaches its final halt state >>>>>>>>>> after tree recursion.
The HHH that simulates 10 recursions would also reach the >>>>>>>>>> final halt state for this same input.
But, because your are cheating, you changed the input, which >>>>>>>>>> now needs eleven recursion to halt.
We see in this way, the, no matter how many recursions you >>>>>>>>>> simulate, this method is unable to reach the final halt state >>>>>>>>>> that is specified in the input when we construct a new DDD >>>>>>>>>> with this new HHH.

When N instructions of DDD are correctly emulated by >>>>>>>>>>>>>>> every HHH that can
possibly exist (technically this is an infinite set of >>>>>>>>>>>>>>> HHH/ DDD pairs)
no emulated DDD can possibly halt and every directly >>>>>>>>>>>>>>> executed DDD()
halts.

See, and I thought DDD was a concrete program filled in >>>>>>>>>>>>>> with HHH,
which aborts after two levels of simulation, not something >>>>>>>>>>>>>> that
calls "HHH" symbolically, producing many different programs. >>>>>>>>>>>>>>

I had to turn it into an infinite set of HHH/DDD
pairs so that it could be more easily understood
that DDD simulated by HHH cannot possibly halt.

When HHH detects the above non-halting behavior
pattern it kills the whole simulation process so
there is no stack unwinding.

There is no non-halting behaviour pattern, only a finite >>>>>>>>>>>> number more than N instructions are needed to reach the >>>>>>>>>>>> final input *for this input*.

counter-factual

_DDD()
[00002192] 55-a-a-a-a-a-a-a-a push ebp
[00002193] 8bec-a-a-a-a-a-a mov ebp,esp
[00002195] 6892210000 push 00002192-a // push DDD
[0000219a] e833f4ffff call 000015d2-a // call HHH
[0000219f] 83c404-a-a-a-a add esp,+04
[000021a2] 5d-a-a-a-a-a-a-a-a pop ebp
[000021a3] c3-a-a-a-a-a-a-a-a ret
Size in bytes:(0018) [000021a3]

WE have told you many times that it is incorrect to suggest >>>>>>>>>> that these 18 bytes describe the whole input for the simulator. >>>>>>>>>> All functions called by DDD, directly or indirectly, also >>>>>>>>>> belong to the input under test.

Every 5 instructions of DDD that are correctly emulated
end up in HHH at line one. One more instruction of
DDD emulates line two, one more emulates line three,
one more ends up at line four, one more ends up back
at line one.

Incorrect, the call ends up inside HHH. When you would
correctly follow the code of HHH in your simulator, keeping >>>>>>>>>> track of the internal state of HHH and its conditional branch >>>>>>>>>> instruction, you would see that after a few cycles, HHH is >>>>>>>>>> specified to abort and return to DDD at line 5.
Then lines 6 and 7 would be simulated and the final halt state >>>>>>>>>> is reached.
But HHH fails to do this correct simulation, because it
prematurely aborts before it can see that.
Then HHH uses your attitude: close its eyes and pretend that >>>>>>>>>> what is not seen does not exist.

Proving that for all N the program specifies a halting >>>>>>>>>>>> behaviour, but we can construct *another* input for which >>>>>>>>>>>> HHH fails again.
But you cheat by changing the input, which then needs more >>>>>>>>>>>> steps.

I do not cheat. I define the infinite set of HHH/DDD pairs >>>>>>>>>>> where HHH emulates N instructions of DDD and N is one element >>>>>>>>>>> of the natural numbers.

Each pair has a different input for the simulator. Each
simulator fails for the input constructed with its own
version. But many of them prove that the input constructed >>>>>>>>>> with other HHH versions, which have less steps before the >>>>>>>>>> premature abort, have a final halt state that can be reached. >>>>>>>>>

Because HHH correctly predicts that DDD emulated by
HHH cannot possibly reach its own final state each HHH that
aborts after N instructions have been emulated is correct
to reject its input as non halting.

But it can't do that, as that HHH doesn't correct emulate this DDD. >>>>>>>>

HHH correctly emulates DDD until this emulated DDD
proves that it cannot possibly reach its own emulated
final halt state.

And Correctly until ... isn't correct.

In other words when HHH correctly emulates N instructions
of DDD you are claiming that HHH did not correctly emulate
N instructions of DDD and likewise 1 does not equal itself.

No, and you are just lying by changing my words.

I am paraphrasing so that we can get a mutual understanding.

You mean you are LYING by changing the meaning of them, just like you
falsely accuse everyone else.

Sorry, all you are doing is proving you are a Hypocritical
Pathological Liar that doesn't care about what it true.

I said that H didn't CORRCTLY EMULATE H, which means to have
finished the job.

When HHH correctly emulates N instructions of DDD
then HHH has correctly finished its job of correctly
emulating N instructions of DDD.

But its job wasn't to emulate N instructions of DDD, its job was to
predict if DDD will halt when run.

The definition of a simulating halt decider stipulates otherwise.

Then they aren't Halt Decider, and you whole proof when up in a big puff
of smoke and lies.

Sorry, you do such a great job at putting your foot in your mouth and
proving you are just a liar.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

On 8/5/2025 9:48 PM, Richard Damon wrote:

On 8/5/25 9:10 PM, olcott wrote:

On 8/5/2025 5:53 AM, Richard Damon wrote:

On 8/4/25 10:05 PM, olcott wrote:

On 8/4/2025 8:58 PM, Richard Damon wrote:

On 8/4/25 9:45 PM, olcott wrote:

On 8/4/2025 8:41 PM, Richard Damon wrote:

On 8/4/25 9:31 PM, olcott wrote:

On 8/4/2025 8:25 PM, Richard Damon wrote:

On 8/4/25 9:42 AM, olcott wrote:

On 8/4/2025 7:47 AM, Fred. Zwarts wrote:

Op 02.aug.2025 om 16:16 schreef olcott:

On 8/2/2025 4:18 AM, Fred. Zwarts wrote:

Op 01.aug.2025 om 16:46 schreef olcott:

On 8/1/2025 1:53 AM, joes wrote:

Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott: >>>>>>>>>>>>>>>> On 7/31/2025 7:07 PM, Richard Damon wrote:

On 7/31/25 11:50 AM, olcott wrote:

On 7/29/2025 11:22 PM, Alan Mackenzie wrote: >>>>>>>>>>>>>>>>>> -a-a> It is a lack of technical ability on your part >>>>>>>>>>>>>>>>>> which is unable to
-a-a> judge whether such a correct simulation is >>>>>>>>>>>>>>>>>> possible. Everybody
-a-a> else sees that it is not, so further questions >>>>>>>>>>>>>>>>>> about it are
-a-a> non-sensical.
HHH emulates DDD in a separate process context. When >>>>>>>>>>>>>>>>>> this DDD calls
HHH(DDD) the original HHH emulates this HHH in the DDD >>>>>>>>>>>>>>>>>> process
context.

And that separate proccess, if left unaborted, would >>>>>>>>>>>>>>>>> halt. But HHH
gives up and aborts it, so the process is Halting, not >>>>>>>>>>>>>>>>> non- halting.

And HHH cannot simulate itself to its undeniable halting >>>>>>>>>>>>>>> state.

This emulated HHH creates yet another process context >>>>>>>>>>>>>>>>>> to emulate its
own DDD. When this DDD calls yet another HHH(DDD) this >>>>>>>>>>>>>>>>>> provides enough
execution trace that the repeating pattern can be seen. >>>>>>>>>>>>>>>>> But the pattern isn't non-halting by the fact that DDD >>>>>>>>>>>>>>>>> is shown to be

halting.

*No not at all. Not in the least little bit* Recursive >>>>>>>>>>>>>>>> simulation is
only a little more difficult than self recursion. >>>>>>>>>>>>>>

DDD halts if it weren't aborted.

(1) That is counter-factual. Neither HHH() nor DDD() nor DDD >>>>>>>>>>>>>> simulated by HHH ever stops running unless HHH(DDD) aborts >>>>>>>>>>>>>> its input.

It is irrelevant what a hypothetical non-input would do. >>>>>>>>>>>>> HHH aborts, so DDD and HHH, both the directly executing and >>>>>>>>>>>>> the simulated versions halt.

DDD correctly simulated by HHH cannot possibly reach
its own simulated "return" instruction final halt state >>>>>>>>>>>> in 1 to infinity steps of correct simulation. When the >>>>>>>>>>>> simulation is aborted the entire process is killed so
there is no stack unwinding.

(2) I have never been taking about DDD() the behavior of a >>>>>>>>>>>>>> non- input.
Turing machines are only accountable for the behavior that >>>>>>>>>>>>>> their
inputs specify, they are never accountable for any non- >>>>>>>>>>>>>> inputs.

And this input specifies a program with code to abort, so >>>>>>>>>>>>> it specifies a halting program. When HHH does not see that, >>>>>>>>>>>>> it fails.

I discovered a case where the correct simulation
and the direct execution have different halting
behaviors.

No, you dreamed, but could not prove it. Only by twisting the >>>>>>>>>>> meaning of the words, you could make yourself believing it. >>>>>>>>>>>

(3) When I make a claim about DDD simulated by HHH and >>>>>>>>>>>>>> this is
changed to the behavior of the directly executed DDD this is >>>>>>>>>>>>>> a dishonest tactic known as the strawman error.

When the input specifies a halting behaviour, it is an >>>>>>>>>>>>> error to close your eyes and pretend that it does not exist. >>>>>>>>>>>>>

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

Executed HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
Then HHH kills the whole simulation process and returns 0 >>>>>>>>>>>>>

Counterfactual. HHH abors after a few cycles, when only one >>>>>>>>>>>>> more cycle is needed to complete the simulation, as proven >>>>>>>>>>>>> by simulators that do not abort the exact same input. >>>>>>>>>>>>>

The above HHH aborts after ten recursive simulations
because people here did not understand that there were >>>>>>>>>>>> any recursive simulation when I only show one or two.

That does not make any difference. We also see that you are >>>>>>>>>>> cheating, by not only changing the simulator, but also the >>>>>>>>>>> simulated input. World class simulators show that the
original input, when correctly simulated, reaches its final >>>>>>>>>>> halt state after tree recursion.
The HHH that simulates 10 recursions would also reach the >>>>>>>>>>> final halt state for this same input.
But, because your are cheating, you changed the input, which >>>>>>>>>>> now needs eleven recursion to halt.
We see in this way, the, no matter how many recursions you >>>>>>>>>>> simulate, this method is unable to reach the final halt state >>>>>>>>>>> that is specified in the input when we construct a new DDD >>>>>>>>>>> with this new HHH.

When N instructions of DDD are correctly emulated by >>>>>>>>>>>>>>>> every HHH that can
possibly exist (technically this is an infinite set of >>>>>>>>>>>>>>>> HHH/ DDD pairs)
no emulated DDD can possibly halt and every directly >>>>>>>>>>>>>>>> executed DDD()
halts.

See, and I thought DDD was a concrete program filled in >>>>>>>>>>>>>>> with HHH,
which aborts after two levels of simulation, not >>>>>>>>>>>>>>> something that
calls "HHH" symbolically, producing many different programs. >>>>>>>>>>>>>>>

I had to turn it into an infinite set of HHH/DDD
pairs so that it could be more easily understood
that DDD simulated by HHH cannot possibly halt.

When HHH detects the above non-halting behavior
pattern it kills the whole simulation process so
there is no stack unwinding.

There is no non-halting behaviour pattern, only a finite >>>>>>>>>>>>> number more than N instructions are needed to reach the >>>>>>>>>>>>> final input *for this input*.

counter-factual

_DDD()
[00002192] 55-a-a-a-a-a-a-a-a push ebp
[00002193] 8bec-a-a-a-a-a-a mov ebp,esp
[00002195] 6892210000 push 00002192-a // push DDD
[0000219a] e833f4ffff call 000015d2-a // call HHH
[0000219f] 83c404-a-a-a-a add esp,+04
[000021a2] 5d-a-a-a-a-a-a-a-a pop ebp
[000021a3] c3-a-a-a-a-a-a-a-a ret
Size in bytes:(0018) [000021a3]

WE have told you many times that it is incorrect to suggest >>>>>>>>>>> that these 18 bytes describe the whole input for the simulator. >>>>>>>>>>> All functions called by DDD, directly or indirectly, also >>>>>>>>>>> belong to the input under test.

Every 5 instructions of DDD that are correctly emulated >>>>>>>>>>>> end up in HHH at line one. One more instruction of
DDD emulates line two, one more emulates line three,
one more ends up at line four, one more ends up back
at line one.

Incorrect, the call ends up inside HHH. When you would
correctly follow the code of HHH in your simulator, keeping >>>>>>>>>>> track of the internal state of HHH and its conditional branch >>>>>>>>>>> instruction, you would see that after a few cycles, HHH is >>>>>>>>>>> specified to abort and return to DDD at line 5.
Then lines 6 and 7 would be simulated and the final halt >>>>>>>>>>> state is reached.
But HHH fails to do this correct simulation, because it >>>>>>>>>>> prematurely aborts before it can see that.
Then HHH uses your attitude: close its eyes and pretend that >>>>>>>>>>> what is not seen does not exist.

Proving that for all N the program specifies a halting >>>>>>>>>>>>> behaviour, but we can construct *another* input for which >>>>>>>>>>>>> HHH fails again.
But you cheat by changing the input, which then needs more >>>>>>>>>>>>> steps.

I do not cheat. I define the infinite set of HHH/DDD pairs >>>>>>>>>>>> where HHH emulates N instructions of DDD and N is one element >>>>>>>>>>>> of the natural numbers.

Each pair has a different input for the simulator. Each >>>>>>>>>>> simulator fails for the input constructed with its own
version. But many of them prove that the input constructed >>>>>>>>>>> with other HHH versions, which have less steps before the >>>>>>>>>>> premature abort, have a final halt state that can be reached. >>>>>>>>>>

Because HHH correctly predicts that DDD emulated by
HHH cannot possibly reach its own final state each HHH that >>>>>>>>>> aborts after N instructions have been emulated is correct
to reject its input as non halting.

But it can't do that, as that HHH doesn't correct emulate this >>>>>>>>> DDD.

HHH correctly emulates DDD until this emulated DDD
proves that it cannot possibly reach its own emulated
final halt state.

And Correctly until ... isn't correct.

In other words when HHH correctly emulates N instructions
of DDD you are claiming that HHH did not correctly emulate
N instructions of DDD and likewise 1 does not equal itself.

No, and you are just lying by changing my words.

I am paraphrasing so that we can get a mutual understanding.

You mean you are LYING by changing the meaning of them, just like you
falsely accuse everyone else.

Sorry, all you are doing is proving you are a Hypocritical
Pathological Liar that doesn't care about what it true.

I said that H didn't CORRCTLY EMULATE H, which means to have
finished the job.

When HHH correctly emulates N instructions of DDD
then HHH has correctly finished its job of correctly
emulating N instructions of DDD.

But its job wasn't to emulate N instructions of DDD, its job was to
predict if DDD will halt when run.

The definition of a simulating halt decider stipulates otherwise.

Then they aren't Halt Decider, and you whole proof when up in a big puff
of smoke and lies.

It corrects the error of the requirement that
a halt decider reports on its own behavior.

"The contradiction in Linz's (or Turing's) self-referential
halting construction only appears if one insists that the
machine can and must decide on its own behavior, which is
neither possible nor required."

https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

Op 06.aug.2025 om 05:47 schreef olcott:

On 8/5/2025 9:48 PM, Richard Damon wrote:

On 8/5/25 9:10 PM, olcott wrote:

On 8/5/2025 5:53 AM, Richard Damon wrote:

On 8/4/25 10:05 PM, olcott wrote:

On 8/4/2025 8:58 PM, Richard Damon wrote:

On 8/4/25 9:45 PM, olcott wrote:

On 8/4/2025 8:41 PM, Richard Damon wrote:

On 8/4/25 9:31 PM, olcott wrote:

On 8/4/2025 8:25 PM, Richard Damon wrote:

On 8/4/25 9:42 AM, olcott wrote:

On 8/4/2025 7:47 AM, Fred. Zwarts wrote:

Op 02.aug.2025 om 16:16 schreef olcott:

On 8/2/2025 4:18 AM, Fred. Zwarts wrote:

Op 01.aug.2025 om 16:46 schreef olcott:

On 8/1/2025 1:53 AM, joes wrote:

Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott: >>>>>>>>>>>>>>>>> On 7/31/2025 7:07 PM, Richard Damon wrote:

On 7/31/25 11:50 AM, olcott wrote:

On 7/29/2025 11:22 PM, Alan Mackenzie wrote: >>>>>>>>>>>>>>>>>>> -a-a> It is a lack of technical ability on your part >>>>>>>>>>>>>>>>>>> which is unable to
-a-a> judge whether such a correct simulation is >>>>>>>>>>>>>>>>>>> possible. Everybody
-a-a> else sees that it is not, so further questions >>>>>>>>>>>>>>>>>>> about it are
-a-a> non-sensical.
HHH emulates DDD in a separate process context. When >>>>>>>>>>>>>>>>>>> this DDD calls
HHH(DDD) the original HHH emulates this HHH in the >>>>>>>>>>>>>>>>>>> DDD process
context.

And that separate proccess, if left unaborted, would >>>>>>>>>>>>>>>>>> halt. But HHH
gives up and aborts it, so the process is Halting, not >>>>>>>>>>>>>>>>>> non- halting.

And HHH cannot simulate itself to its undeniable halting >>>>>>>>>>>>>>>> state.

This emulated HHH creates yet another process context >>>>>>>>>>>>>>>>>>> to emulate its
own DDD. When this DDD calls yet another HHH(DDD) >>>>>>>>>>>>>>>>>>> this provides enough
execution trace that the repeating pattern can be seen. >>>>>>>>>>>>>>>>>> But the pattern isn't non-halting by the fact that DDD >>>>>>>>>>>>>>>>>> is shown to be

halting.

*No not at all. Not in the least little bit* Recursive >>>>>>>>>>>>>>>>> simulation is
only a little more difficult than self recursion. >>>>>>>>>>>>>>>

DDD halts if it weren't aborted.

(1) That is counter-factual. Neither HHH() nor DDD() nor DDD >>>>>>>>>>>>>>> simulated by HHH ever stops running unless HHH(DDD) aborts >>>>>>>>>>>>>>> its input.

It is irrelevant what a hypothetical non-input would do. >>>>>>>>>>>>>> HHH aborts, so DDD and HHH, both the directly executing >>>>>>>>>>>>>> and the simulated versions halt.

DDD correctly simulated by HHH cannot possibly reach >>>>>>>>>>>>> its own simulated "return" instruction final halt state >>>>>>>>>>>>> in 1 to infinity steps of correct simulation. When the >>>>>>>>>>>>> simulation is aborted the entire process is killed so >>>>>>>>>>>>> there is no stack unwinding.

(2) I have never been taking about DDD() the behavior of >>>>>>>>>>>>>>> a non- input.
Turing machines are only accountable for the behavior >>>>>>>>>>>>>>> that their
inputs specify, they are never accountable for any non- >>>>>>>>>>>>>>> inputs.

And this input specifies a program with code to abort, so >>>>>>>>>>>>>> it specifies a halting program. When HHH does not see >>>>>>>>>>>>>> that, it fails.

I discovered a case where the correct simulation
and the direct execution have different halting
behaviors.

No, you dreamed, but could not prove it. Only by twisting >>>>>>>>>>>> the meaning of the words, you could make yourself believing it. >>>>>>>>>>>>

(3) When I make a claim about DDD simulated by HHH and >>>>>>>>>>>>>>> this is
changed to the behavior of the directly executed DDD this is >>>>>>>>>>>>>>> a dishonest tactic known as the strawman error.

When the input specifies a halting behaviour, it is an >>>>>>>>>>>>>> error to close your eyes and pretend that it does not exist. >>>>>>>>>>>>>>

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

Executed HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
Then HHH kills the whole simulation process and returns 0 >>>>>>>>>>>>>>

Counterfactual. HHH abors after a few cycles, when only >>>>>>>>>>>>>> one more cycle is needed to complete the simulation, as >>>>>>>>>>>>>> proven by simulators that do not abort the exact same input. >>>>>>>>>>>>>>

The above HHH aborts after ten recursive simulations >>>>>>>>>>>>> because people here did not understand that there were >>>>>>>>>>>>> any recursive simulation when I only show one or two. >>>>>>>>>>>>

That does not make any difference. We also see that you are >>>>>>>>>>>> cheating, by not only changing the simulator, but also the >>>>>>>>>>>> simulated input. World class simulators show that the >>>>>>>>>>>> original input, when correctly simulated, reaches its final >>>>>>>>>>>> halt state after tree recursion.
The HHH that simulates 10 recursions would also reach the >>>>>>>>>>>> final halt state for this same input.
But, because your are cheating, you changed the input, which >>>>>>>>>>>> now needs eleven recursion to halt.
We see in this way, the, no matter how many recursions you >>>>>>>>>>>> simulate, this method is unable to reach the final halt >>>>>>>>>>>> state that is specified in the input when we construct a new >>>>>>>>>>>> DDD with this new HHH.

When N instructions of DDD are correctly emulated by >>>>>>>>>>>>>>>>> every HHH that can
possibly exist (technically this is an infinite set of >>>>>>>>>>>>>>>>> HHH/ DDD pairs)
no emulated DDD can possibly halt and every directly >>>>>>>>>>>>>>>>> executed DDD()
halts.

See, and I thought DDD was a concrete program filled in >>>>>>>>>>>>>>>> with HHH,
which aborts after two levels of simulation, not >>>>>>>>>>>>>>>> something that
calls "HHH" symbolically, producing many different >>>>>>>>>>>>>>>> programs.

I had to turn it into an infinite set of HHH/DDD >>>>>>>>>>>>>>> pairs so that it could be more easily understood >>>>>>>>>>>>>>> that DDD simulated by HHH cannot possibly halt.

When HHH detects the above non-halting behavior
pattern it kills the whole simulation process so >>>>>>>>>>>>>>> there is no stack unwinding.

There is no non-halting behaviour pattern, only a finite >>>>>>>>>>>>>> number more than N instructions are needed to reach the >>>>>>>>>>>>>> final input *for this input*.

counter-factual

_DDD()
[00002192] 55-a-a-a-a-a-a-a-a push ebp
[00002193] 8bec-a-a-a-a-a-a mov ebp,esp
[00002195] 6892210000 push 00002192-a // push DDD
[0000219a] e833f4ffff call 000015d2-a // call HHH
[0000219f] 83c404-a-a-a-a add esp,+04
[000021a2] 5d-a-a-a-a-a-a-a-a pop ebp
[000021a3] c3-a-a-a-a-a-a-a-a ret
Size in bytes:(0018) [000021a3]

WE have told you many times that it is incorrect to suggest >>>>>>>>>>>> that these 18 bytes describe the whole input for the simulator. >>>>>>>>>>>> All functions called by DDD, directly or indirectly, also >>>>>>>>>>>> belong to the input under test.

Every 5 instructions of DDD that are correctly emulated >>>>>>>>>>>>> end up in HHH at line one. One more instruction of
DDD emulates line two, one more emulates line three, >>>>>>>>>>>>> one more ends up at line four, one more ends up back >>>>>>>>>>>>> at line one.

Incorrect, the call ends up inside HHH. When you would >>>>>>>>>>>> correctly follow the code of HHH in your simulator, keeping >>>>>>>>>>>> track of the internal state of HHH and its conditional >>>>>>>>>>>> branch instruction, you would see that after a few cycles, >>>>>>>>>>>> HHH is specified to abort and return to DDD at line 5. >>>>>>>>>>>> Then lines 6 and 7 would be simulated and the final halt >>>>>>>>>>>> state is reached.
But HHH fails to do this correct simulation, because it >>>>>>>>>>>> prematurely aborts before it can see that.
Then HHH uses your attitude: close its eyes and pretend that >>>>>>>>>>>> what is not seen does not exist.

Proving that for all N the program specifies a halting >>>>>>>>>>>>>> behaviour, but we can construct *another* input for which >>>>>>>>>>>>>> HHH fails again.
But you cheat by changing the input, which then needs more >>>>>>>>>>>>>> steps.

I do not cheat. I define the infinite set of HHH/DDD pairs >>>>>>>>>>>>> where HHH emulates N instructions of DDD and N is one element >>>>>>>>>>>>> of the natural numbers.

Each pair has a different input for the simulator. Each >>>>>>>>>>>> simulator fails for the input constructed with its own >>>>>>>>>>>> version. But many of them prove that the input constructed >>>>>>>>>>>> with other HHH versions, which have less steps before the >>>>>>>>>>>> premature abort, have a final halt state that can be reached. >>>>>>>>>>>

Because HHH correctly predicts that DDD emulated by
HHH cannot possibly reach its own final state each HHH that >>>>>>>>>>> aborts after N instructions have been emulated is correct >>>>>>>>>>> to reject its input as non halting.

But it can't do that, as that HHH doesn't correct emulate this >>>>>>>>>> DDD.

HHH correctly emulates DDD until this emulated DDD
proves that it cannot possibly reach its own emulated
final halt state.

And Correctly until ... isn't correct.

In other words when HHH correctly emulates N instructions
of DDD you are claiming that HHH did not correctly emulate
N instructions of DDD and likewise 1 does not equal itself.

No, and you are just lying by changing my words.

I am paraphrasing so that we can get a mutual understanding.

You mean you are LYING by changing the meaning of them, just like
you falsely accuse everyone else.

Sorry, all you are doing is proving you are a Hypocritical
Pathological Liar that doesn't care about what it true.

I said that H didn't CORRCTLY EMULATE H, which means to have
finished the job.

When HHH correctly emulates N instructions of DDD
then HHH has correctly finished its job of correctly
emulating N instructions of DDD.

But its job wasn't to emulate N instructions of DDD, its job was to
predict if DDD will halt when run.

The definition of a simulating halt decider stipulates otherwise.

Then they aren't Halt Decider, and you whole proof when up in a big
puff of smoke and lies.

It corrects the error of the requirement that
a halt decider reports on its own behavior.

-a-a "The contradiction in Linz's (or Turing's) self-referential
-a-a-a halting construction only appears if one insists that the
-a-a-a machine can and must decide on its own behavior, which is
-a-a-a neither possible nor required."

https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8

That seems to be one of your misunderstanding. A decider must report on
the behaviour of its input, even if this behaviour resembles its own behaviour. That is very different from 'deciding on its own behaviour'.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

On 8/5/25 11:47 PM, olcott wrote:

On 8/5/2025 9:48 PM, Richard Damon wrote:

On 8/5/25 9:10 PM, olcott wrote:

On 8/5/2025 5:53 AM, Richard Damon wrote:

On 8/4/25 10:05 PM, olcott wrote:

On 8/4/2025 8:58 PM, Richard Damon wrote:

On 8/4/25 9:45 PM, olcott wrote:

On 8/4/2025 8:41 PM, Richard Damon wrote:

On 8/4/25 9:31 PM, olcott wrote:

On 8/4/2025 8:25 PM, Richard Damon wrote:

On 8/4/25 9:42 AM, olcott wrote:

On 8/4/2025 7:47 AM, Fred. Zwarts wrote:

Op 02.aug.2025 om 16:16 schreef olcott:

On 8/2/2025 4:18 AM, Fred. Zwarts wrote:

Op 01.aug.2025 om 16:46 schreef olcott:

On 8/1/2025 1:53 AM, joes wrote:

Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott: >>>>>>>>>>>>>>>>> On 7/31/2025 7:07 PM, Richard Damon wrote:

On 7/31/25 11:50 AM, olcott wrote:

On 7/29/2025 11:22 PM, Alan Mackenzie wrote: >>>>>>>>>>>>>>>>>>> -a-a> It is a lack of technical ability on your part >>>>>>>>>>>>>>>>>>> which is unable to
-a-a> judge whether such a correct simulation is >>>>>>>>>>>>>>>>>>> possible. Everybody
-a-a> else sees that it is not, so further questions >>>>>>>>>>>>>>>>>>> about it are
-a-a> non-sensical.
HHH emulates DDD in a separate process context. When >>>>>>>>>>>>>>>>>>> this DDD calls
HHH(DDD) the original HHH emulates this HHH in the >>>>>>>>>>>>>>>>>>> DDD process
context.

And that separate proccess, if left unaborted, would >>>>>>>>>>>>>>>>>> halt. But HHH
gives up and aborts it, so the process is Halting, not >>>>>>>>>>>>>>>>>> non- halting.

And HHH cannot simulate itself to its undeniable halting >>>>>>>>>>>>>>>> state.

This emulated HHH creates yet another process context >>>>>>>>>>>>>>>>>>> to emulate its
own DDD. When this DDD calls yet another HHH(DDD) >>>>>>>>>>>>>>>>>>> this provides enough
execution trace that the repeating pattern can be seen. >>>>>>>>>>>>>>>>>> But the pattern isn't non-halting by the fact that DDD >>>>>>>>>>>>>>>>>> is shown to be

halting.

*No not at all. Not in the least little bit* Recursive >>>>>>>>>>>>>>>>> simulation is
only a little more difficult than self recursion. >>>>>>>>>>>>>>>

DDD halts if it weren't aborted.

(1) That is counter-factual. Neither HHH() nor DDD() nor DDD >>>>>>>>>>>>>>> simulated by HHH ever stops running unless HHH(DDD) aborts >>>>>>>>>>>>>>> its input.

It is irrelevant what a hypothetical non-input would do. >>>>>>>>>>>>>> HHH aborts, so DDD and HHH, both the directly executing >>>>>>>>>>>>>> and the simulated versions halt.

DDD correctly simulated by HHH cannot possibly reach >>>>>>>>>>>>> its own simulated "return" instruction final halt state >>>>>>>>>>>>> in 1 to infinity steps of correct simulation. When the >>>>>>>>>>>>> simulation is aborted the entire process is killed so >>>>>>>>>>>>> there is no stack unwinding.

(2) I have never been taking about DDD() the behavior of >>>>>>>>>>>>>>> a non- input.
Turing machines are only accountable for the behavior >>>>>>>>>>>>>>> that their
inputs specify, they are never accountable for any non- >>>>>>>>>>>>>>> inputs.

And this input specifies a program with code to abort, so >>>>>>>>>>>>>> it specifies a halting program. When HHH does not see >>>>>>>>>>>>>> that, it fails.

I discovered a case where the correct simulation
and the direct execution have different halting
behaviors.

No, you dreamed, but could not prove it. Only by twisting >>>>>>>>>>>> the meaning of the words, you could make yourself believing it. >>>>>>>>>>>>

(3) When I make a claim about DDD simulated by HHH and >>>>>>>>>>>>>>> this is
changed to the behavior of the directly executed DDD this is >>>>>>>>>>>>>>> a dishonest tactic known as the strawman error.

When the input specifies a halting behaviour, it is an >>>>>>>>>>>>>> error to close your eyes and pretend that it does not exist. >>>>>>>>>>>>>>

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

Executed HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
Then HHH kills the whole simulation process and returns 0 >>>>>>>>>>>>>>

Counterfactual. HHH abors after a few cycles, when only >>>>>>>>>>>>>> one more cycle is needed to complete the simulation, as >>>>>>>>>>>>>> proven by simulators that do not abort the exact same input. >>>>>>>>>>>>>>

The above HHH aborts after ten recursive simulations >>>>>>>>>>>>> because people here did not understand that there were >>>>>>>>>>>>> any recursive simulation when I only show one or two. >>>>>>>>>>>>

That does not make any difference. We also see that you are >>>>>>>>>>>> cheating, by not only changing the simulator, but also the >>>>>>>>>>>> simulated input. World class simulators show that the >>>>>>>>>>>> original input, when correctly simulated, reaches its final >>>>>>>>>>>> halt state after tree recursion.
The HHH that simulates 10 recursions would also reach the >>>>>>>>>>>> final halt state for this same input.
But, because your are cheating, you changed the input, which >>>>>>>>>>>> now needs eleven recursion to halt.
We see in this way, the, no matter how many recursions you >>>>>>>>>>>> simulate, this method is unable to reach the final halt >>>>>>>>>>>> state that is specified in the input when we construct a new >>>>>>>>>>>> DDD with this new HHH.

When N instructions of DDD are correctly emulated by >>>>>>>>>>>>>>>>> every HHH that can
possibly exist (technically this is an infinite set of >>>>>>>>>>>>>>>>> HHH/ DDD pairs)
no emulated DDD can possibly halt and every directly >>>>>>>>>>>>>>>>> executed DDD()
halts.

See, and I thought DDD was a concrete program filled in >>>>>>>>>>>>>>>> with HHH,
which aborts after two levels of simulation, not >>>>>>>>>>>>>>>> something that
calls "HHH" symbolically, producing many different >>>>>>>>>>>>>>>> programs.

I had to turn it into an infinite set of HHH/DDD >>>>>>>>>>>>>>> pairs so that it could be more easily understood >>>>>>>>>>>>>>> that DDD simulated by HHH cannot possibly halt.

When HHH detects the above non-halting behavior
pattern it kills the whole simulation process so >>>>>>>>>>>>>>> there is no stack unwinding.

There is no non-halting behaviour pattern, only a finite >>>>>>>>>>>>>> number more than N instructions are needed to reach the >>>>>>>>>>>>>> final input *for this input*.

counter-factual

_DDD()
[00002192] 55-a-a-a-a-a-a-a-a push ebp
[00002193] 8bec-a-a-a-a-a-a mov ebp,esp
[00002195] 6892210000 push 00002192-a // push DDD
[0000219a] e833f4ffff call 000015d2-a // call HHH
[0000219f] 83c404-a-a-a-a add esp,+04
[000021a2] 5d-a-a-a-a-a-a-a-a pop ebp
[000021a3] c3-a-a-a-a-a-a-a-a ret
Size in bytes:(0018) [000021a3]

WE have told you many times that it is incorrect to suggest >>>>>>>>>>>> that these 18 bytes describe the whole input for the simulator. >>>>>>>>>>>> All functions called by DDD, directly or indirectly, also >>>>>>>>>>>> belong to the input under test.

Every 5 instructions of DDD that are correctly emulated >>>>>>>>>>>>> end up in HHH at line one. One more instruction of
DDD emulates line two, one more emulates line three, >>>>>>>>>>>>> one more ends up at line four, one more ends up back >>>>>>>>>>>>> at line one.

Incorrect, the call ends up inside HHH. When you would >>>>>>>>>>>> correctly follow the code of HHH in your simulator, keeping >>>>>>>>>>>> track of the internal state of HHH and its conditional >>>>>>>>>>>> branch instruction, you would see that after a few cycles, >>>>>>>>>>>> HHH is specified to abort and return to DDD at line 5. >>>>>>>>>>>> Then lines 6 and 7 would be simulated and the final halt >>>>>>>>>>>> state is reached.
But HHH fails to do this correct simulation, because it >>>>>>>>>>>> prematurely aborts before it can see that.
Then HHH uses your attitude: close its eyes and pretend that >>>>>>>>>>>> what is not seen does not exist.

Proving that for all N the program specifies a halting >>>>>>>>>>>>>> behaviour, but we can construct *another* input for which >>>>>>>>>>>>>> HHH fails again.
But you cheat by changing the input, which then needs more >>>>>>>>>>>>>> steps.

I do not cheat. I define the infinite set of HHH/DDD pairs >>>>>>>>>>>>> where HHH emulates N instructions of DDD and N is one element >>>>>>>>>>>>> of the natural numbers.

Each pair has a different input for the simulator. Each >>>>>>>>>>>> simulator fails for the input constructed with its own >>>>>>>>>>>> version. But many of them prove that the input constructed >>>>>>>>>>>> with other HHH versions, which have less steps before the >>>>>>>>>>>> premature abort, have a final halt state that can be reached. >>>>>>>>>>>

Because HHH correctly predicts that DDD emulated by
HHH cannot possibly reach its own final state each HHH that >>>>>>>>>>> aborts after N instructions have been emulated is correct >>>>>>>>>>> to reject its input as non halting.

But it can't do that, as that HHH doesn't correct emulate this >>>>>>>>>> DDD.

HHH correctly emulates DDD until this emulated DDD
proves that it cannot possibly reach its own emulated
final halt state.

And Correctly until ... isn't correct.

In other words when HHH correctly emulates N instructions
of DDD you are claiming that HHH did not correctly emulate
N instructions of DDD and likewise 1 does not equal itself.

No, and you are just lying by changing my words.

I am paraphrasing so that we can get a mutual understanding.

You mean you are LYING by changing the meaning of them, just like
you falsely accuse everyone else.

Sorry, all you are doing is proving you are a Hypocritical
Pathological Liar that doesn't care about what it true.

I said that H didn't CORRCTLY EMULATE H, which means to have
finished the job.

When HHH correctly emulates N instructions of DDD
then HHH has correctly finished its job of correctly
emulating N instructions of DDD.

But its job wasn't to emulate N instructions of DDD, its job was to
predict if DDD will halt when run.

The definition of a simulating halt decider stipulates otherwise.

Then they aren't Halt Decider, and you whole proof when up in a big
puff of smoke and lies.

It corrects the error of the requirement that
a halt decider reports on its own behavior.

But it isn't an error.

Halt Deciders need to answer about *ANY* program, and they are programs.

-a-a "The contradiction in Linz's (or Turing's) self-referential
-a-a-a halting construction only appears if one insists that the
-a-a-a machine can and must decide on its own behavior, which is
-a-a-a neither possible nor required."

https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8

Because you lied to it and said it was an error.

All you are doing is proving that you live in a world that is built on
your own fantasy.

It may be that it is a significant part of what makes it impossible, but
it is a valid part of the requirements, and your words just prove your stupidity.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

On 8/5/25 11:47 PM, olcott wrote:

On 8/5/2025 9:48 PM, Richard Damon wrote:

On 8/5/25 9:10 PM, olcott wrote:

On 8/5/2025 5:53 AM, Richard Damon wrote:

On 8/4/25 10:05 PM, olcott wrote:

On 8/4/2025 8:58 PM, Richard Damon wrote:

On 8/4/25 9:45 PM, olcott wrote:

On 8/4/2025 8:41 PM, Richard Damon wrote:

On 8/4/25 9:31 PM, olcott wrote:

On 8/4/2025 8:25 PM, Richard Damon wrote:

On 8/4/25 9:42 AM, olcott wrote:

On 8/4/2025 7:47 AM, Fred. Zwarts wrote:

Op 02.aug.2025 om 16:16 schreef olcott:

On 8/2/2025 4:18 AM, Fred. Zwarts wrote:

Op 01.aug.2025 om 16:46 schreef olcott:

On 8/1/2025 1:53 AM, joes wrote:

Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott: >>>>>>>>>>>>>>>>> On 7/31/2025 7:07 PM, Richard Damon wrote:

On 7/31/25 11:50 AM, olcott wrote:

On 7/29/2025 11:22 PM, Alan Mackenzie wrote: >>>>>>>>>>>>>>>>>>> -a-a> It is a lack of technical ability on your part >>>>>>>>>>>>>>>>>>> which is unable to
-a-a> judge whether such a correct simulation is >>>>>>>>>>>>>>>>>>> possible. Everybody
-a-a> else sees that it is not, so further questions >>>>>>>>>>>>>>>>>>> about it are
-a-a> non-sensical.
HHH emulates DDD in a separate process context. When >>>>>>>>>>>>>>>>>>> this DDD calls
HHH(DDD) the original HHH emulates this HHH in the >>>>>>>>>>>>>>>>>>> DDD process
context.

And that separate proccess, if left unaborted, would >>>>>>>>>>>>>>>>>> halt. But HHH
gives up and aborts it, so the process is Halting, not >>>>>>>>>>>>>>>>>> non- halting.

And HHH cannot simulate itself to its undeniable halting >>>>>>>>>>>>>>>> state.

This emulated HHH creates yet another process context >>>>>>>>>>>>>>>>>>> to emulate its
own DDD. When this DDD calls yet another HHH(DDD) >>>>>>>>>>>>>>>>>>> this provides enough
execution trace that the repeating pattern can be seen. >>>>>>>>>>>>>>>>>> But the pattern isn't non-halting by the fact that DDD >>>>>>>>>>>>>>>>>> is shown to be

halting.

*No not at all. Not in the least little bit* Recursive >>>>>>>>>>>>>>>>> simulation is
only a little more difficult than self recursion. >>>>>>>>>>>>>>>

DDD halts if it weren't aborted.

(1) That is counter-factual. Neither HHH() nor DDD() nor DDD >>>>>>>>>>>>>>> simulated by HHH ever stops running unless HHH(DDD) aborts >>>>>>>>>>>>>>> its input.

It is irrelevant what a hypothetical non-input would do. >>>>>>>>>>>>>> HHH aborts, so DDD and HHH, both the directly executing >>>>>>>>>>>>>> and the simulated versions halt.

DDD correctly simulated by HHH cannot possibly reach >>>>>>>>>>>>> its own simulated "return" instruction final halt state >>>>>>>>>>>>> in 1 to infinity steps of correct simulation. When the >>>>>>>>>>>>> simulation is aborted the entire process is killed so >>>>>>>>>>>>> there is no stack unwinding.

(2) I have never been taking about DDD() the behavior of >>>>>>>>>>>>>>> a non- input.
Turing machines are only accountable for the behavior >>>>>>>>>>>>>>> that their
inputs specify, they are never accountable for any non- >>>>>>>>>>>>>>> inputs.

And this input specifies a program with code to abort, so >>>>>>>>>>>>>> it specifies a halting program. When HHH does not see >>>>>>>>>>>>>> that, it fails.

I discovered a case where the correct simulation
and the direct execution have different halting
behaviors.

No, you dreamed, but could not prove it. Only by twisting >>>>>>>>>>>> the meaning of the words, you could make yourself believing it. >>>>>>>>>>>>

(3) When I make a claim about DDD simulated by HHH and >>>>>>>>>>>>>>> this is
changed to the behavior of the directly executed DDD this is >>>>>>>>>>>>>>> a dishonest tactic known as the strawman error.

When the input specifies a halting behaviour, it is an >>>>>>>>>>>>>> error to close your eyes and pretend that it does not exist. >>>>>>>>>>>>>>

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

Executed HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
Then HHH kills the whole simulation process and returns 0 >>>>>>>>>>>>>>

Counterfactual. HHH abors after a few cycles, when only >>>>>>>>>>>>>> one more cycle is needed to complete the simulation, as >>>>>>>>>>>>>> proven by simulators that do not abort the exact same input. >>>>>>>>>>>>>>

The above HHH aborts after ten recursive simulations >>>>>>>>>>>>> because people here did not understand that there were >>>>>>>>>>>>> any recursive simulation when I only show one or two. >>>>>>>>>>>>

That does not make any difference. We also see that you are >>>>>>>>>>>> cheating, by not only changing the simulator, but also the >>>>>>>>>>>> simulated input. World class simulators show that the >>>>>>>>>>>> original input, when correctly simulated, reaches its final >>>>>>>>>>>> halt state after tree recursion.
The HHH that simulates 10 recursions would also reach the >>>>>>>>>>>> final halt state for this same input.
But, because your are cheating, you changed the input, which >>>>>>>>>>>> now needs eleven recursion to halt.
We see in this way, the, no matter how many recursions you >>>>>>>>>>>> simulate, this method is unable to reach the final halt >>>>>>>>>>>> state that is specified in the input when we construct a new >>>>>>>>>>>> DDD with this new HHH.

When N instructions of DDD are correctly emulated by >>>>>>>>>>>>>>>>> every HHH that can
possibly exist (technically this is an infinite set of >>>>>>>>>>>>>>>>> HHH/ DDD pairs)
no emulated DDD can possibly halt and every directly >>>>>>>>>>>>>>>>> executed DDD()
halts.

See, and I thought DDD was a concrete program filled in >>>>>>>>>>>>>>>> with HHH,
which aborts after two levels of simulation, not >>>>>>>>>>>>>>>> something that
calls "HHH" symbolically, producing many different >>>>>>>>>>>>>>>> programs.

I had to turn it into an infinite set of HHH/DDD >>>>>>>>>>>>>>> pairs so that it could be more easily understood >>>>>>>>>>>>>>> that DDD simulated by HHH cannot possibly halt.

When HHH detects the above non-halting behavior
pattern it kills the whole simulation process so >>>>>>>>>>>>>>> there is no stack unwinding.

There is no non-halting behaviour pattern, only a finite >>>>>>>>>>>>>> number more than N instructions are needed to reach the >>>>>>>>>>>>>> final input *for this input*.

counter-factual

_DDD()
[00002192] 55-a-a-a-a-a-a-a-a push ebp
[00002193] 8bec-a-a-a-a-a-a mov ebp,esp
[00002195] 6892210000 push 00002192-a // push DDD
[0000219a] e833f4ffff call 000015d2-a // call HHH
[0000219f] 83c404-a-a-a-a add esp,+04
[000021a2] 5d-a-a-a-a-a-a-a-a pop ebp
[000021a3] c3-a-a-a-a-a-a-a-a ret
Size in bytes:(0018) [000021a3]

WE have told you many times that it is incorrect to suggest >>>>>>>>>>>> that these 18 bytes describe the whole input for the simulator. >>>>>>>>>>>> All functions called by DDD, directly or indirectly, also >>>>>>>>>>>> belong to the input under test.

Every 5 instructions of DDD that are correctly emulated >>>>>>>>>>>>> end up in HHH at line one. One more instruction of
DDD emulates line two, one more emulates line three, >>>>>>>>>>>>> one more ends up at line four, one more ends up back >>>>>>>>>>>>> at line one.

Incorrect, the call ends up inside HHH. When you would >>>>>>>>>>>> correctly follow the code of HHH in your simulator, keeping >>>>>>>>>>>> track of the internal state of HHH and its conditional >>>>>>>>>>>> branch instruction, you would see that after a few cycles, >>>>>>>>>>>> HHH is specified to abort and return to DDD at line 5. >>>>>>>>>>>> Then lines 6 and 7 would be simulated and the final halt >>>>>>>>>>>> state is reached.
But HHH fails to do this correct simulation, because it >>>>>>>>>>>> prematurely aborts before it can see that.
Then HHH uses your attitude: close its eyes and pretend that >>>>>>>>>>>> what is not seen does not exist.

Proving that for all N the program specifies a halting >>>>>>>>>>>>>> behaviour, but we can construct *another* input for which >>>>>>>>>>>>>> HHH fails again.
But you cheat by changing the input, which then needs more >>>>>>>>>>>>>> steps.

I do not cheat. I define the infinite set of HHH/DDD pairs >>>>>>>>>>>>> where HHH emulates N instructions of DDD and N is one element >>>>>>>>>>>>> of the natural numbers.

Each pair has a different input for the simulator. Each >>>>>>>>>>>> simulator fails for the input constructed with its own >>>>>>>>>>>> version. But many of them prove that the input constructed >>>>>>>>>>>> with other HHH versions, which have less steps before the >>>>>>>>>>>> premature abort, have a final halt state that can be reached. >>>>>>>>>>>

Because HHH correctly predicts that DDD emulated by
HHH cannot possibly reach its own final state each HHH that >>>>>>>>>>> aborts after N instructions have been emulated is correct >>>>>>>>>>> to reject its input as non halting.

But it can't do that, as that HHH doesn't correct emulate this >>>>>>>>>> DDD.

HHH correctly emulates DDD until this emulated DDD
proves that it cannot possibly reach its own emulated
final halt state.

And Correctly until ... isn't correct.

In other words when HHH correctly emulates N instructions
of DDD you are claiming that HHH did not correctly emulate
N instructions of DDD and likewise 1 does not equal itself.

No, and you are just lying by changing my words.

I am paraphrasing so that we can get a mutual understanding.

You mean you are LYING by changing the meaning of them, just like
you falsely accuse everyone else.

Sorry, all you are doing is proving you are a Hypocritical
Pathological Liar that doesn't care about what it true.

I said that H didn't CORRCTLY EMULATE H, which means to have
finished the job.

When HHH correctly emulates N instructions of DDD
then HHH has correctly finished its job of correctly
emulating N instructions of DDD.

But its job wasn't to emulate N instructions of DDD, its job was to
predict if DDD will halt when run.

The definition of a simulating halt decider stipulates otherwise.

Then they aren't Halt Decider, and you whole proof when up in a big
puff of smoke and lies.

It corrects the error of the requirement that
a halt decider reports on its own behavior.

Which isn't an error, but is a valid part of the requirments.

-a-a "The contradiction in Linz's (or Turing's) self-referential
-a-a-a halting construction only appears if one insists that the
-a-a-a machine can and must decide on its own behavior, which is
-a-a-a neither possible nor required."

https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8

Since you LIED to it by saying that Halt Deciders aren't responsible for
an input that is itself, the answer it gives is invalid.

In fact, one fatal flaw with your analysis, is that the decider isn't
being asked about "itself" but a string that represents a program that includes itself as part of it, and in actuality, if we were in a Turing Complete system like the proglem is, there is no way for the decider to
detect this fact. Your decider can only do so because you put
restrictions in your system (that make it not Turing Complete) to let
you do that detection.

Sorry, you are just proving your stupidity.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

On 8/6/2025 4:00 AM, Fred. Zwarts wrote:

Op 06.aug.2025 om 05:47 schreef olcott:

It corrects the error of the requirement that
a halt decider reports on its own behavior.

-a-a-a "The contradiction in Linz's (or Turing's) self-referential
-a-a-a-a halting construction only appears if one insists that the
-a-a-a-a machine can and must decide on its own behavior, which is
-a-a-a-a neither possible nor required."

https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8

That seems to be one of your misunderstanding. A decider must report on
the behaviour of its input, even if this behaviour resembles its own behaviour. That is very different from 'deciding on its own behaviour'.

*This is my correction*
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR
if rf?-nrf- rf?-nrf- simulated by -n.embedded_H reaches
its simulated final halt state of rf?-n.qnrf-, and

-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn
if rf?-nrf- rf?-nrf- simulated by -n.embedded_H cannot possibly
reach its simulated final halt state of rf?-n.qnrf-.

*This is the original erroneous one*
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR,
if -n applied to rf?-nrf- halts, and
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn
if -n applied to rf?-nrf- does not halt.

*Lines two and four requires -n.embedded_H to report on its own behavior*
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

On 8/6/25 7:39 AM, olcott wrote:

On 8/6/2025 4:00 AM, Fred. Zwarts wrote:

Op 06.aug.2025 om 05:47 schreef olcott:

It corrects the error of the requirement that
a halt decider reports on its own behavior.

-a-a-a "The contradiction in Linz's (or Turing's) self-referential
-a-a-a-a halting construction only appears if one insists that the
-a-a-a-a machine can and must decide on its own behavior, which is
-a-a-a-a neither possible nor required."

https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8

That seems to be one of your misunderstanding. A decider must report
on the behaviour of its input, even if this behaviour resembles its
own behaviour. That is very different from 'deciding on its own
behaviour'.

*This is my correction*
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR
-a-a if rf?-nrf- rf?-nrf- simulated by -n.embedded_H reaches
-a-a its simulated final halt state of rf?-n.qnrf-, and

-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn
-a-a if rf?-nrf- rf?-nrf- simulated by -n.embedded_H cannot possibly
-a-a reach its simulated final halt state of rf?-n.qnrf-.

*This is the original erroneous one*
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR,
-a-a if -n applied to rf?-nrf- halts, and
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn
-a-a if -n applied to rf?-nrf- does not halt.

*Lines two and four requires -n.embedded_H to report on its own behavior*

Which is valid.

And you are just stupid to think otherwise.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

On 8/6/2025 5:54 AM, Richard Damon wrote:

On 8/5/25 11:47 PM, olcott wrote:

It corrects the error of the requirement that
a halt decider reports on its own behavior.

But it isn't an error.

Halt Deciders need to answer about *ANY* program, and they are programs.

-a-a-a "The contradiction in Linz's (or Turing's) self-referential
-a-a-a-a halting construction only appears if one insists that the
-a-a-a-a machine can and must decide on its own behavior, which is
-a-a-a-a neither possible nor required."

https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8

Because you lied to it and said it was an error.

The above paragraph is proved true by the meaning of its words.
When we ask a Turing machine to report on its own behavior we
are assuming that its Turing Machine description is an accurate
proxy for this behavior. When there are exceptions to this rule
then we cannot possibly ask a Turing machine about its own behavior.
This is easily corrected:

-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR
if rf?-nrf- rf?-nrf- simulated by -n.embedded_H reaches
its simulated final halt state of rf?-n.qnrf-, and

-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn
if rf?-nrf- rf?-nrf- simulated by -n.embedded_H cannot possibly
reach its simulated final halt state of rf?-n.qnrf-.

When we use the above standard then a halt decider
will always report on the actual behavior that its
input actually specifies.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

On 8/6/2025 6:07 AM, Richard Damon wrote:

On 8/5/25 11:47 PM, olcott wrote:

On 8/5/2025 9:48 PM, Richard Damon wrote:

On 8/5/25 9:10 PM, olcott wrote:

On 8/5/2025 5:53 AM, Richard Damon wrote:

On 8/4/25 10:05 PM, olcott wrote:

On 8/4/2025 8:58 PM, Richard Damon wrote:

On 8/4/25 9:45 PM, olcott wrote:

On 8/4/2025 8:41 PM, Richard Damon wrote:

On 8/4/25 9:31 PM, olcott wrote:

On 8/4/2025 8:25 PM, Richard Damon wrote:

On 8/4/25 9:42 AM, olcott wrote:

On 8/4/2025 7:47 AM, Fred. Zwarts wrote:

Op 02.aug.2025 om 16:16 schreef olcott:

On 8/2/2025 4:18 AM, Fred. Zwarts wrote:

Op 01.aug.2025 om 16:46 schreef olcott:

On 8/1/2025 1:53 AM, joes wrote:

Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>> On 7/31/2025 7:07 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>> On 7/31/25 11:50 AM, olcott wrote:

On 7/29/2025 11:22 PM, Alan Mackenzie wrote: >>>>>>>>>>>>>>>>>>>> -a-a> It is a lack of technical ability on your part >>>>>>>>>>>>>>>>>>>> which is unable to
-a-a> judge whether such a correct simulation is >>>>>>>>>>>>>>>>>>>> possible. Everybody
-a-a> else sees that it is not, so further questions >>>>>>>>>>>>>>>>>>>> about it are
-a-a> non-sensical.
HHH emulates DDD in a separate process context. When >>>>>>>>>>>>>>>>>>>> this DDD calls
HHH(DDD) the original HHH emulates this HHH in the >>>>>>>>>>>>>>>>>>>> DDD process
context.

And that separate proccess, if left unaborted, would >>>>>>>>>>>>>>>>>>> halt. But HHH
gives up and aborts it, so the process is Halting, >>>>>>>>>>>>>>>>>>> not non- halting.

And HHH cannot simulate itself to its undeniable >>>>>>>>>>>>>>>>> halting state.

This emulated HHH creates yet another process >>>>>>>>>>>>>>>>>>>> context to emulate its
own DDD. When this DDD calls yet another HHH(DDD) >>>>>>>>>>>>>>>>>>>> this provides enough
execution trace that the repeating pattern can be seen. >>>>>>>>>>>>>>>>>>> But the pattern isn't non-halting by the fact that >>>>>>>>>>>>>>>>>>> DDD is shown to be

halting.

*No not at all. Not in the least little bit* Recursive >>>>>>>>>>>>>>>>>> simulation is
only a little more difficult than self recursion. >>>>>>>>>>>>>>>>

DDD halts if it weren't aborted.

(1) That is counter-factual. Neither HHH() nor DDD() nor >>>>>>>>>>>>>>>> DDD
simulated by HHH ever stops running unless HHH(DDD) aborts >>>>>>>>>>>>>>>> its input.

It is irrelevant what a hypothetical non-input would do. >>>>>>>>>>>>>>> HHH aborts, so DDD and HHH, both the directly executing >>>>>>>>>>>>>>> and the simulated versions halt.

DDD correctly simulated by HHH cannot possibly reach >>>>>>>>>>>>>> its own simulated "return" instruction final halt state >>>>>>>>>>>>>> in 1 to infinity steps of correct simulation. When the >>>>>>>>>>>>>> simulation is aborted the entire process is killed so >>>>>>>>>>>>>> there is no stack unwinding.

(2) I have never been taking about DDD() the behavior of >>>>>>>>>>>>>>>> a non- input.
Turing machines are only accountable for the behavior >>>>>>>>>>>>>>>> that their
inputs specify, they are never accountable for any non- >>>>>>>>>>>>>>>> inputs.

And this input specifies a program with code to abort, so >>>>>>>>>>>>>>> it specifies a halting program. When HHH does not see >>>>>>>>>>>>>>> that, it fails.

I discovered a case where the correct simulation
and the direct execution have different halting
behaviors.

No, you dreamed, but could not prove it. Only by twisting >>>>>>>>>>>>> the meaning of the words, you could make yourself believing >>>>>>>>>>>>> it.

(3) When I make a claim about DDD simulated by HHH and >>>>>>>>>>>>>>>> this is
changed to the behavior of the directly executed DDD >>>>>>>>>>>>>>>> this is
a dishonest tactic known as the strawman error. >>>>>>>>>>>>>>>

When the input specifies a halting behaviour, it is an >>>>>>>>>>>>>>> error to close your eyes and pretend that it does not exist. >>>>>>>>>>>>>>>

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

Executed HHH simulates DDD that calls HHH(DDD) >>>>>>>>>>>>>>>> that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
Then HHH kills the whole simulation process and returns 0 >>>>>>>>>>>>>>>

Counterfactual. HHH abors after a few cycles, when only >>>>>>>>>>>>>>> one more cycle is needed to complete the simulation, as >>>>>>>>>>>>>>> proven by simulators that do not abort the exact same input. >>>>>>>>>>>>>>>

The above HHH aborts after ten recursive simulations >>>>>>>>>>>>>> because people here did not understand that there were >>>>>>>>>>>>>> any recursive simulation when I only show one or two. >>>>>>>>>>>>>

That does not make any difference. We also see that you are >>>>>>>>>>>>> cheating, by not only changing the simulator, but also the >>>>>>>>>>>>> simulated input. World class simulators show that the >>>>>>>>>>>>> original input, when correctly simulated, reaches its final >>>>>>>>>>>>> halt state after tree recursion.
The HHH that simulates 10 recursions would also reach the >>>>>>>>>>>>> final halt state for this same input.
But, because your are cheating, you changed the input, >>>>>>>>>>>>> which now needs eleven recursion to halt.
We see in this way, the, no matter how many recursions you >>>>>>>>>>>>> simulate, this method is unable to reach the final halt >>>>>>>>>>>>> state that is specified in the input when we construct a >>>>>>>>>>>>> new DDD with this new HHH.

When N instructions of DDD are correctly emulated by >>>>>>>>>>>>>>>>>> every HHH that can
possibly exist (technically this is an infinite set of >>>>>>>>>>>>>>>>>> HHH/ DDD pairs)
no emulated DDD can possibly halt and every directly >>>>>>>>>>>>>>>>>> executed DDD()
halts.

See, and I thought DDD was a concrete program filled in >>>>>>>>>>>>>>>>> with HHH,
which aborts after two levels of simulation, not >>>>>>>>>>>>>>>>> something that
calls "HHH" symbolically, producing many different >>>>>>>>>>>>>>>>> programs.

I had to turn it into an infinite set of HHH/DDD >>>>>>>>>>>>>>>> pairs so that it could be more easily understood >>>>>>>>>>>>>>>> that DDD simulated by HHH cannot possibly halt. >>>>>>>>>>>>>>>>
When HHH detects the above non-halting behavior >>>>>>>>>>>>>>>> pattern it kills the whole simulation process so >>>>>>>>>>>>>>>> there is no stack unwinding.

There is no non-halting behaviour pattern, only a finite >>>>>>>>>>>>>>> number more than N instructions are needed to reach the >>>>>>>>>>>>>>> final input *for this input*.

counter-factual

_DDD()
[00002192] 55-a-a-a-a-a-a-a-a push ebp
[00002193] 8bec-a-a-a-a-a-a mov ebp,esp
[00002195] 6892210000 push 00002192-a // push DDD
[0000219a] e833f4ffff call 000015d2-a // call HHH
[0000219f] 83c404-a-a-a-a add esp,+04
[000021a2] 5d-a-a-a-a-a-a-a-a pop ebp
[000021a3] c3-a-a-a-a-a-a-a-a ret
Size in bytes:(0018) [000021a3]

WE have told you many times that it is incorrect to suggest >>>>>>>>>>>>> that these 18 bytes describe the whole input for the >>>>>>>>>>>>> simulator.
All functions called by DDD, directly or indirectly, also >>>>>>>>>>>>> belong to the input under test.

Every 5 instructions of DDD that are correctly emulated >>>>>>>>>>>>>> end up in HHH at line one. One more instruction of >>>>>>>>>>>>>> DDD emulates line two, one more emulates line three, >>>>>>>>>>>>>> one more ends up at line four, one more ends up back >>>>>>>>>>>>>> at line one.

Incorrect, the call ends up inside HHH. When you would >>>>>>>>>>>>> correctly follow the code of HHH in your simulator, keeping >>>>>>>>>>>>> track of the internal state of HHH and its conditional >>>>>>>>>>>>> branch instruction, you would see that after a few cycles, >>>>>>>>>>>>> HHH is specified to abort and return to DDD at line 5. >>>>>>>>>>>>> Then lines 6 and 7 would be simulated and the final halt >>>>>>>>>>>>> state is reached.
But HHH fails to do this correct simulation, because it >>>>>>>>>>>>> prematurely aborts before it can see that.
Then HHH uses your attitude: close its eyes and pretend >>>>>>>>>>>>> that what is not seen does not exist.

Proving that for all N the program specifies a halting >>>>>>>>>>>>>>> behaviour, but we can construct *another* input for which >>>>>>>>>>>>>>> HHH fails again.
But you cheat by changing the input, which then needs >>>>>>>>>>>>>>> more steps.

I do not cheat. I define the infinite set of HHH/DDD pairs >>>>>>>>>>>>>> where HHH emulates N instructions of DDD and N is one element >>>>>>>>>>>>>> of the natural numbers.

Each pair has a different input for the simulator. Each >>>>>>>>>>>>> simulator fails for the input constructed with its own >>>>>>>>>>>>> version. But many of them prove that the input constructed >>>>>>>>>>>>> with other HHH versions, which have less steps before the >>>>>>>>>>>>> premature abort, have a final halt state that can be reached. >>>>>>>>>>>>

Because HHH correctly predicts that DDD emulated by
HHH cannot possibly reach its own final state each HHH that >>>>>>>>>>>> aborts after N instructions have been emulated is correct >>>>>>>>>>>> to reject its input as non halting.

But it can't do that, as that HHH doesn't correct emulate >>>>>>>>>>> this DDD.

HHH correctly emulates DDD until this emulated DDD
proves that it cannot possibly reach its own emulated
final halt state.

And Correctly until ... isn't correct.

In other words when HHH correctly emulates N instructions
of DDD you are claiming that HHH did not correctly emulate
N instructions of DDD and likewise 1 does not equal itself.

No, and you are just lying by changing my words.

I am paraphrasing so that we can get a mutual understanding.

You mean you are LYING by changing the meaning of them, just like
you falsely accuse everyone else.

Sorry, all you are doing is proving you are a Hypocritical
Pathological Liar that doesn't care about what it true.

I said that H didn't CORRCTLY EMULATE H, which means to have
finished the job.

When HHH correctly emulates N instructions of DDD
then HHH has correctly finished its job of correctly
emulating N instructions of DDD.

But its job wasn't to emulate N instructions of DDD, its job was to >>>>> predict if DDD will halt when run.

The definition of a simulating halt decider stipulates otherwise.

Then they aren't Halt Decider, and you whole proof when up in a big
puff of smoke and lies.

It corrects the error of the requirement that
a halt decider reports on its own behavior.

Which isn't an error, but is a valid part of the requirments.

-a-a-a "The contradiction in Linz's (or Turing's) self-referential
-a-a-a-a halting construction only appears if one insists that the
-a-a-a-a machine can and must decide on its own behavior, which is
-a-a-a-a neither possible nor required."

https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8

Since you LIED to it by saying that Halt Deciders aren't responsible for
an input that is itself, the answer it gives is invalid.

Truth has no lie.

The above paragraph is proved true by the meaning of its words.
When we ask a Turing machine to report on its own behavior we
are assuming that its Turing Machine description is an accurate
proxy for this behavior. When there are exceptions to this rule
then we cannot possibly ask a Turing machine about its own behavior.
This is easily corrected:

-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR
if rf?-nrf- rf?-nrf- simulated by -n.embedded_H reaches
its simulated final halt state of rf?-n.qnrf-, and

-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn
if rf?-nrf- rf?-nrf- simulated by -n.embedded_H cannot possibly
reach its simulated final halt state of rf?-n.qnrf-.

When we use the above standard then a halt decider
will always report on the actual behavior that its
input actually specifies.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

On 8/6/2025 6:41 AM, Richard Damon wrote:

On 8/6/25 7:39 AM, olcott wrote:

On 8/6/2025 4:00 AM, Fred. Zwarts wrote:

Op 06.aug.2025 om 05:47 schreef olcott:

It corrects the error of the requirement that
a halt decider reports on its own behavior.

-a-a-a "The contradiction in Linz's (or Turing's) self-referential
-a-a-a-a halting construction only appears if one insists that the
-a-a-a-a machine can and must decide on its own behavior, which is
-a-a-a-a neither possible nor required."

https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8

That seems to be one of your misunderstanding. A decider must report
on the behaviour of its input, even if this behaviour resembles its
own behaviour. That is very different from 'deciding on its own
behaviour'.

*This is my correction*
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR
-a-a-a if rf?-nrf- rf?-nrf- simulated by -n.embedded_H reaches
-a-a-a its simulated final halt state of rf?-n.qnrf-, and

-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn
-a-a-a if rf?-nrf- rf?-nrf- simulated by -n.embedded_H cannot possibly
-a-a-a reach its simulated final halt state of rf?-n.qnrf-.

*This is the original erroneous one*
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR,
-a-a-a if -n applied to rf?-nrf- halts, and
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn
-a-a-a if -n applied to rf?-nrf- does not halt.

*Lines two and four requires -n.embedded_H to report on its own behavior*

Which is valid.

And you are just stupid to think otherwise.

It is only valid when Turing machine deciders can
take themselves as inputs.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

On 8/6/2025 6:41 AM, Richard Damon wrote:

On 8/6/25 7:39 AM, olcott wrote:

On 8/6/2025 4:00 AM, Fred. Zwarts wrote:

Op 06.aug.2025 om 05:47 schreef olcott:

It corrects the error of the requirement that
a halt decider reports on its own behavior.

-a-a-a "The contradiction in Linz's (or Turing's) self-referential
-a-a-a-a halting construction only appears if one insists that the
-a-a-a-a machine can and must decide on its own behavior, which is
-a-a-a-a neither possible nor required."

https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8

That seems to be one of your misunderstanding. A decider must report
on the behaviour of its input, even if this behaviour resembles its
own behaviour. That is very different from 'deciding on its own
behaviour'.

*This is my correction*
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR
-a-a-a if rf?-nrf- rf?-nrf- simulated by -n.embedded_H reaches
-a-a-a its simulated final halt state of rf?-n.qnrf-, and

-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn
-a-a-a if rf?-nrf- rf?-nrf- simulated by -n.embedded_H cannot possibly
-a-a-a reach its simulated final halt state of rf?-n.qnrf-.

*This is the original erroneous one*
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR,
-a-a-a if -n applied to rf?-nrf- halts, and
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn
-a-a-a if -n applied to rf?-nrf- does not halt.

*Lines two and four requires -n.embedded_H to report on its own behavior*

Which is valid.

typedef void (*ptr)();
int HHH(ptr P);

int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}

A halt decider is required to report on the actual behavior
that its input actually specifies.

After N steps of DD correctly emulated by HHH the
non-terminating pattern of recursive emulation emerges
on the basis of the structure of the relationship
between HHH and DD. There never has been any actual
need for an infinite emulation to see this pattern.

And you are just stupid to think otherwise.

Things people say when they have no actual reasoning
to back up their position.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

On 8/6/25 8:18 AM, olcott wrote:

On 8/6/2025 6:41 AM, Richard Damon wrote:

On 8/6/25 7:39 AM, olcott wrote:

On 8/6/2025 4:00 AM, Fred. Zwarts wrote:

Op 06.aug.2025 om 05:47 schreef olcott:

It corrects the error of the requirement that
a halt decider reports on its own behavior.

-a-a-a "The contradiction in Linz's (or Turing's) self-referential
-a-a-a-a halting construction only appears if one insists that the
-a-a-a-a machine can and must decide on its own behavior, which is
-a-a-a-a neither possible nor required."

https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8

That seems to be one of your misunderstanding. A decider must report
on the behaviour of its input, even if this behaviour resembles its
own behaviour. That is very different from 'deciding on its own
behaviour'.

*This is my correction*
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR
-a-a-a if rf?-nrf- rf?-nrf- simulated by -n.embedded_H reaches
-a-a-a its simulated final halt state of rf?-n.qnrf-, and

-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn
-a-a-a if rf?-nrf- rf?-nrf- simulated by -n.embedded_H cannot possibly
-a-a-a reach its simulated final halt state of rf?-n.qnrf-.

*This is the original erroneous one*
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR,
-a-a-a if -n applied to rf?-nrf- halts, and
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn
-a-a-a if -n applied to rf?-nrf- does not halt.

*Lines two and four requires -n.embedded_H to report on its own behavior* >>>

Which is valid.

And you are just stupid to think otherwise.

It is only valid when Turing machine deciders can
take themselves as inputs.

They only need to take representation of themselves as input.

Your are just proving you are too stupid to understand how they work and
what representations mean.

Of course, you have proved that level of stupidity with many other
similar errors.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

On 8/6/25 9:52 AM, olcott wrote:

On 8/6/2025 6:41 AM, Richard Damon wrote:

On 8/6/25 7:39 AM, olcott wrote:

On 8/6/2025 4:00 AM, Fred. Zwarts wrote:

Op 06.aug.2025 om 05:47 schreef olcott:

It corrects the error of the requirement that
a halt decider reports on its own behavior.

-a-a-a "The contradiction in Linz's (or Turing's) self-referential
-a-a-a-a halting construction only appears if one insists that the
-a-a-a-a machine can and must decide on its own behavior, which is
-a-a-a-a neither possible nor required."

https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8

That seems to be one of your misunderstanding. A decider must report
on the behaviour of its input, even if this behaviour resembles its
own behaviour. That is very different from 'deciding on its own
behaviour'.

*This is my correction*
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR
-a-a-a if rf?-nrf- rf?-nrf- simulated by -n.embedded_H reaches
-a-a-a its simulated final halt state of rf?-n.qnrf-, and

-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn
-a-a-a if rf?-nrf- rf?-nrf- simulated by -n.embedded_H cannot possibly
-a-a-a reach its simulated final halt state of rf?-n.qnrf-.

*This is the original erroneous one*
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR,
-a-a-a if -n applied to rf?-nrf- halts, and
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn
-a-a-a if -n applied to rf?-nrf- does not halt.

*Lines two and four requires -n.embedded_H to report on its own behavior* >>>

Which is valid.

typedef void (*ptr)();
int HHH(ptr P);

int DD()
{
-a int Halt_Status = HHH(DD);
-a if (Halt_Status)
-a-a-a HERE: goto HERE;
-a return Halt_Status;
}

A halt decider is required to report on the actual behavior
that its input actually specifies.

After N steps of DD correctly emulated by HHH the
non-terminating pattern of recursive emulation emerges
on the basis of the structure of the relationship
between HHH and DD. There never has been any actual
need for an infinite emulation to see this pattern.

Except that pattern isn't a non-termination pattern, just shows that you
don't know what truth actually means.

We can see that it isn't, as when we UTM simulate the input. it halts.

Note, it is the EXACT same input, which includes the code of the HHH
that aborted because it thought it found a non-halting pattern.

And you are just stupid to think otherwise.

Things people say when they have no actual reasoning
to back up their position.

I guess you are too stupid to notice that I also include a real reason
for you error, something YOU don't do, as you only can repeat you error,
as you have no real basis for your claims but your own lies.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

On 8/6/25 7:53 AM, olcott wrote:

On 8/6/2025 5:54 AM, Richard Damon wrote:

On 8/5/25 11:47 PM, olcott wrote:

It corrects the error of the requirement that
a halt decider reports on its own behavior.

But it isn't an error.

Halt Deciders need to answer about *ANY* program, and they are programs.

-a-a-a "The contradiction in Linz's (or Turing's) self-referential
-a-a-a-a halting construction only appears if one insists that the
-a-a-a-a machine can and must decide on its own behavior, which is
-a-a-a-a neither possible nor required."

https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8

Because you lied to it and said it was an error.

The above paragraph is proved true by the meaning of its words.
When we ask a Turing machine to report on its own behavior we
are assuming that its Turing Machine description is an accurate
proxy for this behavior. When there are exceptions to this rule
then we cannot possibly ask a Turing machine about its own behavior.
This is easily corrected:

But the existance of UTMs means that it IS possible to make a perfect
proxy, as the UTM can completely recreate the behavior of ANY machine
from its Turing Machine Description.

All you are doing is admitting that you think errors and lies are ok.

-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR
-a-a if rf?-nrf- rf?-nrf- simulated by -n.embedded_H reaches
-a-a its simulated final halt state of rf?-n.qnrf-, and

-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn
-a-a if rf?-nrf- rf?-nrf- simulated by -n.embedded_H cannot possibly
-a-a reach its simulated final halt state of rf?-n.qnrf-.

When we use the above standard then a halt decider
will always report on the actual behavior that its
input actually specifies.

Nope, just proves that you don't understand the meaning of your own
words, and think logic doesn't work, so you make up lies.

Which just describes the world you have put yourself into.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

On 8/6/25 7:57 AM, olcott wrote:

On 8/6/2025 6:07 AM, Richard Damon wrote:

On 8/5/25 11:47 PM, olcott wrote:

On 8/5/2025 9:48 PM, Richard Damon wrote:

On 8/5/25 9:10 PM, olcott wrote:

On 8/5/2025 5:53 AM, Richard Damon wrote:

On 8/4/25 10:05 PM, olcott wrote:

On 8/4/2025 8:58 PM, Richard Damon wrote:

On 8/4/25 9:45 PM, olcott wrote:

On 8/4/2025 8:41 PM, Richard Damon wrote:

On 8/4/25 9:31 PM, olcott wrote:

On 8/4/2025 8:25 PM, Richard Damon wrote:

On 8/4/25 9:42 AM, olcott wrote:

On 8/4/2025 7:47 AM, Fred. Zwarts wrote:

Op 02.aug.2025 om 16:16 schreef olcott:

On 8/2/2025 4:18 AM, Fred. Zwarts wrote:

Op 01.aug.2025 om 16:46 schreef olcott:

On 8/1/2025 1:53 AM, joes wrote:

Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>>> On 7/31/2025 7:07 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 7/31/25 11:50 AM, olcott wrote:

On 7/29/2025 11:22 PM, Alan Mackenzie wrote: >>>>>>>>>>>>>>>>>>>>> -a-a> It is a lack of technical ability on your part >>>>>>>>>>>>>>>>>>>>> which is unable to
-a-a> judge whether such a correct simulation is >>>>>>>>>>>>>>>>>>>>> possible. Everybody
-a-a> else sees that it is not, so further questions >>>>>>>>>>>>>>>>>>>>> about it are
-a-a> non-sensical.
HHH emulates DDD in a separate process context. >>>>>>>>>>>>>>>>>>>>> When this DDD calls
HHH(DDD) the original HHH emulates this HHH in the >>>>>>>>>>>>>>>>>>>>> DDD process
context.

And that separate proccess, if left unaborted, would >>>>>>>>>>>>>>>>>>>> halt. But HHH
gives up and aborts it, so the process is Halting, >>>>>>>>>>>>>>>>>>>> not non- halting.

And HHH cannot simulate itself to its undeniable >>>>>>>>>>>>>>>>>> halting state.

This emulated HHH creates yet another process >>>>>>>>>>>>>>>>>>>>> context to emulate its
own DDD. When this DDD calls yet another HHH(DDD) >>>>>>>>>>>>>>>>>>>>> this provides enough
execution trace that the repeating pattern can be >>>>>>>>>>>>>>>>>>>>> seen.

But the pattern isn't non-halting by the fact that >>>>>>>>>>>>>>>>>>>> DDD is shown to be
halting.

*No not at all. Not in the least little bit* >>>>>>>>>>>>>>>>>>> Recursive simulation is
only a little more difficult than self recursion. >>>>>>>>>>>>>>>>>

DDD halts if it weren't aborted.

(1) That is counter-factual. Neither HHH() nor DDD() >>>>>>>>>>>>>>>>> nor DDD
simulated by HHH ever stops running unless HHH(DDD) aborts >>>>>>>>>>>>>>>>> its input.

It is irrelevant what a hypothetical non-input would do. >>>>>>>>>>>>>>>> HHH aborts, so DDD and HHH, both the directly executing >>>>>>>>>>>>>>>> and the simulated versions halt.

DDD correctly simulated by HHH cannot possibly reach >>>>>>>>>>>>>>> its own simulated "return" instruction final halt state >>>>>>>>>>>>>>> in 1 to infinity steps of correct simulation. When the >>>>>>>>>>>>>>> simulation is aborted the entire process is killed so >>>>>>>>>>>>>>> there is no stack unwinding.

(2) I have never been taking about DDD() the behavior >>>>>>>>>>>>>>>>> of a non- input.
Turing machines are only accountable for the behavior >>>>>>>>>>>>>>>>> that their
inputs specify, they are never accountable for any non- >>>>>>>>>>>>>>>>> inputs.

And this input specifies a program with code to abort, >>>>>>>>>>>>>>>> so it specifies a halting program. When HHH does not see >>>>>>>>>>>>>>>> that, it fails.

I discovered a case where the correct simulation >>>>>>>>>>>>>>> and the direct execution have different halting
behaviors.

No, you dreamed, but could not prove it. Only by twisting >>>>>>>>>>>>>> the meaning of the words, you could make yourself >>>>>>>>>>>>>> believing it.

(3) When I make a claim about DDD simulated by HHH and >>>>>>>>>>>>>>>>> this is
changed to the behavior of the directly executed DDD >>>>>>>>>>>>>>>>> this is
a dishonest tactic known as the strawman error. >>>>>>>>>>>>>>>>

When the input specifies a halting behaviour, it is an >>>>>>>>>>>>>>>> error to close your eyes and pretend that it does not >>>>>>>>>>>>>>>> exist.

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

Executed HHH simulates DDD that calls HHH(DDD) >>>>>>>>>>>>>>>>> that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
Then HHH kills the whole simulation process and returns 0 >>>>>>>>>>>>>>>>

Counterfactual. HHH abors after a few cycles, when only >>>>>>>>>>>>>>>> one more cycle is needed to complete the simulation, as >>>>>>>>>>>>>>>> proven by simulators that do not abort the exact same >>>>>>>>>>>>>>>> input.

The above HHH aborts after ten recursive simulations >>>>>>>>>>>>>>> because people here did not understand that there were >>>>>>>>>>>>>>> any recursive simulation when I only show one or two. >>>>>>>>>>>>>>

That does not make any difference. We also see that you >>>>>>>>>>>>>> are cheating, by not only changing the simulator, but also >>>>>>>>>>>>>> the simulated input. World class simulators show that the >>>>>>>>>>>>>> original input, when correctly simulated, reaches its >>>>>>>>>>>>>> final halt state after tree recursion.
The HHH that simulates 10 recursions would also reach the >>>>>>>>>>>>>> final halt state for this same input.
But, because your are cheating, you changed the input, >>>>>>>>>>>>>> which now needs eleven recursion to halt.
We see in this way, the, no matter how many recursions you >>>>>>>>>>>>>> simulate, this method is unable to reach the final halt >>>>>>>>>>>>>> state that is specified in the input when we construct a >>>>>>>>>>>>>> new DDD with this new HHH.

When N instructions of DDD are correctly emulated by >>>>>>>>>>>>>>>>>>> every HHH that can
possibly exist (technically this is an infinite set >>>>>>>>>>>>>>>>>>> of HHH/ DDD pairs)
no emulated DDD can possibly halt and every directly >>>>>>>>>>>>>>>>>>> executed DDD()
halts.

See, and I thought DDD was a concrete program filled >>>>>>>>>>>>>>>>>> in with HHH,
which aborts after two levels of simulation, not >>>>>>>>>>>>>>>>>> something that
calls "HHH" symbolically, producing many different >>>>>>>>>>>>>>>>>> programs.

I had to turn it into an infinite set of HHH/DDD >>>>>>>>>>>>>>>>> pairs so that it could be more easily understood >>>>>>>>>>>>>>>>> that DDD simulated by HHH cannot possibly halt. >>>>>>>>>>>>>>>>>
When HHH detects the above non-halting behavior >>>>>>>>>>>>>>>>> pattern it kills the whole simulation process so >>>>>>>>>>>>>>>>> there is no stack unwinding.

There is no non-halting behaviour pattern, only a finite >>>>>>>>>>>>>>>> number more than N instructions are needed to reach the >>>>>>>>>>>>>>>> final input *for this input*.

counter-factual

_DDD()
[00002192] 55-a-a-a-a-a-a-a-a push ebp
[00002193] 8bec-a-a-a-a-a-a mov ebp,esp
[00002195] 6892210000 push 00002192-a // push DDD >>>>>>>>>>>>>>> [0000219a] e833f4ffff call 000015d2-a // call HHH >>>>>>>>>>>>>>> [0000219f] 83c404-a-a-a-a add esp,+04
[000021a2] 5d-a-a-a-a-a-a-a-a pop ebp
[000021a3] c3-a-a-a-a-a-a-a-a ret
Size in bytes:(0018) [000021a3]

WE have told you many times that it is incorrect to >>>>>>>>>>>>>> suggest that these 18 bytes describe the whole input for >>>>>>>>>>>>>> the simulator.
All functions called by DDD, directly or indirectly, also >>>>>>>>>>>>>> belong to the input under test.

Every 5 instructions of DDD that are correctly emulated >>>>>>>>>>>>>>> end up in HHH at line one. One more instruction of >>>>>>>>>>>>>>> DDD emulates line two, one more emulates line three, >>>>>>>>>>>>>>> one more ends up at line four, one more ends up back >>>>>>>>>>>>>>> at line one.

Incorrect, the call ends up inside HHH. When you would >>>>>>>>>>>>>> correctly follow the code of HHH in your simulator, >>>>>>>>>>>>>> keeping track of the internal state of HHH and its >>>>>>>>>>>>>> conditional branch instruction, you would see that after a >>>>>>>>>>>>>> few cycles, HHH is specified to abort and return to DDD at >>>>>>>>>>>>>> line 5.
Then lines 6 and 7 would be simulated and the final halt >>>>>>>>>>>>>> state is reached.
But HHH fails to do this correct simulation, because it >>>>>>>>>>>>>> prematurely aborts before it can see that.
Then HHH uses your attitude: close its eyes and pretend >>>>>>>>>>>>>> that what is not seen does not exist.

Proving that for all N the program specifies a halting >>>>>>>>>>>>>>>> behaviour, but we can construct *another* input for >>>>>>>>>>>>>>>> which HHH fails again.
But you cheat by changing the input, which then needs >>>>>>>>>>>>>>>> more steps.

I do not cheat. I define the infinite set of HHH/DDD pairs >>>>>>>>>>>>>>> where HHH emulates N instructions of DDD and N is one >>>>>>>>>>>>>>> element
of the natural numbers.

Each pair has a different input for the simulator. Each >>>>>>>>>>>>>> simulator fails for the input constructed with its own >>>>>>>>>>>>>> version. But many of them prove that the input constructed >>>>>>>>>>>>>> with other HHH versions, which have less steps before the >>>>>>>>>>>>>> premature abort, have a final halt state that can be reached. >>>>>>>>>>>>>

Because HHH correctly predicts that DDD emulated by
HHH cannot possibly reach its own final state each HHH that >>>>>>>>>>>>> aborts after N instructions have been emulated is correct >>>>>>>>>>>>> to reject its input as non halting.

But it can't do that, as that HHH doesn't correct emulate >>>>>>>>>>>> this DDD.

HHH correctly emulates DDD until this emulated DDD
proves that it cannot possibly reach its own emulated
final halt state.

And Correctly until ... isn't correct.

In other words when HHH correctly emulates N instructions
of DDD you are claiming that HHH did not correctly emulate
N instructions of DDD and likewise 1 does not equal itself.

No, and you are just lying by changing my words.

I am paraphrasing so that we can get a mutual understanding.

You mean you are LYING by changing the meaning of them, just like >>>>>> you falsely accuse everyone else.

Sorry, all you are doing is proving you are a Hypocritical
Pathological Liar that doesn't care about what it true.

I said that H didn't CORRCTLY EMULATE H, which means to have
finished the job.

When HHH correctly emulates N instructions of DDD
then HHH has correctly finished its job of correctly
emulating N instructions of DDD.

But its job wasn't to emulate N instructions of DDD, its job was
to predict if DDD will halt when run.

The definition of a simulating halt decider stipulates otherwise.

Then they aren't Halt Decider, and you whole proof when up in a big
puff of smoke and lies.

It corrects the error of the requirement that
a halt decider reports on its own behavior.

Which isn't an error, but is a valid part of the requirments.

-a-a-a "The contradiction in Linz's (or Turing's) self-referential
-a-a-a-a halting construction only appears if one insists that the
-a-a-a-a machine can and must decide on its own behavior, which is
-a-a-a-a neither possible nor required."

https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8

Since you LIED to it by saying that Halt Deciders aren't responsible
for an input that is itself, the answer it gives is invalid.

Truth has no lie.

And lies are not truth.

The above paragraph is proved true by the meaning of its words.

Nope, since you don't understand what "the behavior of the input" means.

When we ask a Turing machine to report on its own behavior we
are assuming that its Turing Machine description is an accurate
proxy for this behavior. When there are exceptions to this rule
then we cannot possibly ask a Turing machine about its own behavior.

Which the existance of UTMS proves they are accurate proxies.

All you are doing is proving you can't understand Turing Complete
systems because they use concepts beyoud your ability.

This is easily corrected:

-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR
-a-a if rf?-nrf- rf?-nrf- simulated by -n.embedded_H reaches
-a-a its simulated final halt state of rf?-n.qnrf-, and

-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn
-a-a if rf?-nrf- rf?-nrf- simulated by -n.embedded_H cannot possibly
-a-a reach its simulated final halt state of rf?-n.qnrf-.

When we use the above standard then a halt decider
will always report on the actual behavior that its
input actually specifies.

Which just proves you like to LIE because you don't understand the truth.

Note, the fact you even TRY to change the meaning of fundamental terms
in a system just proves you don't understand the meaning of a formal system.

Rmember, ZFC is a NEW system, not a fixing of Niave Set Theory within
its system.

If you want to change the definition, you need to do the same thing, a
TOTALLY define your new POOPS, something I don't think you can do, as
you don't understand formal logic well enough.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

On 8/6/2025 9:13 PM, Richard Damon wrote:

On 8/6/25 8:18 AM, olcott wrote:

On 8/6/2025 6:41 AM, Richard Damon wrote:

On 8/6/25 7:39 AM, olcott wrote:

On 8/6/2025 4:00 AM, Fred. Zwarts wrote:

Op 06.aug.2025 om 05:47 schreef olcott:

It corrects the error of the requirement that
a halt decider reports on its own behavior.

-a-a-a "The contradiction in Linz's (or Turing's) self-referential >>>>>> -a-a-a-a halting construction only appears if one insists that the >>>>>> -a-a-a-a machine can and must decide on its own behavior, which is >>>>>> -a-a-a-a neither possible nor required."

https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8

That seems to be one of your misunderstanding. A decider must
report on the behaviour of its input, even if this behaviour
resembles its own behaviour. That is very different from 'deciding
on its own behaviour'.

*This is my correction*
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR
-a-a-a if rf?-nrf- rf?-nrf- simulated by -n.embedded_H reaches
-a-a-a its simulated final halt state of rf?-n.qnrf-, and

-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn
-a-a-a if rf?-nrf- rf?-nrf- simulated by -n.embedded_H cannot possibly >>>> -a-a-a reach its simulated final halt state of rf?-n.qnrf-.

*This is the original erroneous one*
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR,
-a-a-a if -n applied to rf?-nrf- halts, and
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn
-a-a-a if -n applied to rf?-nrf- does not halt.

*Lines two and four requires -n.embedded_H to report on its own
behavior*

Which is valid.

And you are just stupid to think otherwise.

It is only valid when Turing machine deciders can
take themselves as inputs.

They only need to take representation of themselves as input.

-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR,
if -n applied to rf?-nrf- halts, and

-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn
if -n applied to rf?-nrf- does not halt.

The Linz proof has -n take its own machine description
as input (this is fine) yet requires -n.embedded_H to
directly report on its own behavior. No TM can ever
do that.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

On 8/6/2025 9:27 PM, Richard Damon wrote:

On 8/6/25 7:53 AM, olcott wrote:

On 8/6/2025 5:54 AM, Richard Damon wrote:

On 8/5/25 11:47 PM, olcott wrote:

It corrects the error of the requirement that
a halt decider reports on its own behavior.

But it isn't an error.

Halt Deciders need to answer about *ANY* program, and they are programs. >>>

-a-a-a "The contradiction in Linz's (or Turing's) self-referential
-a-a-a-a halting construction only appears if one insists that the
-a-a-a-a machine can and must decide on its own behavior, which is
-a-a-a-a neither possible nor required."

https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8

Because you lied to it and said it was an error.

The above paragraph is proved true by the meaning of its words.
When we ask a Turing machine to report on its own behavior we
are assuming that its Turing Machine description is an accurate
proxy for this behavior. When there are exceptions to this rule
then we cannot possibly ask a Turing machine about its own behavior.
This is easily corrected:

But the existance of UTMs means that it IS possible to make a perfect
proxy, as the UTM can completely recreate the behavior of ANY machine
from its Turing Machine Description.

All you are doing is admitting that you think errors and lies are ok.

-n.q0 rf?-nrf- reo* -n.UTM rf?-nrf- rf?-nrf- reo* -n.qy,
-n.q0 rf?-nrf- reo* -n.UTM rf?-nrf- rf?-nrf- reo* -n.qn

After a finite number of correct simulations the UTM
will reach its final state yet no simulated UTM ever
reaches its own final state.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

Op 07.aug.2025 om 05:15 schreef olcott:

On 8/6/2025 9:13 PM, Richard Damon wrote:

On 8/6/25 8:18 AM, olcott wrote:

On 8/6/2025 6:41 AM, Richard Damon wrote:

On 8/6/25 7:39 AM, olcott wrote:

On 8/6/2025 4:00 AM, Fred. Zwarts wrote:

Op 06.aug.2025 om 05:47 schreef olcott:

It corrects the error of the requirement that
a halt decider reports on its own behavior.

-a-a-a "The contradiction in Linz's (or Turing's) self-referential >>>>>>> -a-a-a-a halting construction only appears if one insists that the >>>>>>> -a-a-a-a machine can and must decide on its own behavior, which is >>>>>>> -a-a-a-a neither possible nor required."

https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8

That seems to be one of your misunderstanding. A decider must
report on the behaviour of its input, even if this behaviour
resembles its own behaviour. That is very different from 'deciding >>>>>> on its own behaviour'.

*This is my correction*
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR
-a-a-a if rf?-nrf- rf?-nrf- simulated by -n.embedded_H reaches
-a-a-a its simulated final halt state of rf?-n.qnrf-, and

-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn
-a-a-a if rf?-nrf- rf?-nrf- simulated by -n.embedded_H cannot possibly >>>>> -a-a-a reach its simulated final halt state of rf?-n.qnrf-.

*This is the original erroneous one*
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR,
-a-a-a if -n applied to rf?-nrf- halts, and
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn
-a-a-a if -n applied to rf?-nrf- does not halt.

*Lines two and four requires -n.embedded_H to report on its own
behavior*

Which is valid.

And you are just stupid to think otherwise.

It is only valid when Turing machine deciders can
take themselves as inputs.

They only need to take representation of themselves as input.

-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR,
if -n applied to rf?-nrf- halts, and

-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn
if -n applied to rf?-nrf- does not halt.

The Linz proof has -n take its own machine description
as input (this is fine) yet requires -n.embedded_H to
directly report on its own behavior. No TM can ever
do that.

That is your mistake. It does not require to report on its own
behaviour, but on the behaviour of -n. It is irrelevant whether the
behaviour of -n resembles that of embedded_H.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

Op 07.aug.2025 om 05:24 schreef olcott:

On 8/6/2025 9:27 PM, Richard Damon wrote:

On 8/6/25 7:53 AM, olcott wrote:

On 8/6/2025 5:54 AM, Richard Damon wrote:

On 8/5/25 11:47 PM, olcott wrote:

It corrects the error of the requirement that
a halt decider reports on its own behavior.

But it isn't an error.

Halt Deciders need to answer about *ANY* program, and they are
programs.

-a-a-a "The contradiction in Linz's (or Turing's) self-referential
-a-a-a-a halting construction only appears if one insists that the
-a-a-a-a machine can and must decide on its own behavior, which is
-a-a-a-a neither possible nor required."

https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8

Because you lied to it and said it was an error.

The above paragraph is proved true by the meaning of its words.
When we ask a Turing machine to report on its own behavior we
are assuming that its Turing Machine description is an accurate
proxy for this behavior. When there are exceptions to this rule
then we cannot possibly ask a Turing machine about its own behavior.
This is easily corrected:

But the existance of UTMs means that it IS possible to make a perfect
proxy, as the UTM can completely recreate the behavior of ANY machine
from its Turing Machine Description.

All you are doing is admitting that you think errors and lies are ok.

-a-a -n.q0 rf?-nrf- reo* -n.UTM rf?-nrf- rf?-nrf- reo* -n.qy,
-a-a -n.q0 rf?-nrf- reo* -n.UTM rf?-nrf- rf?-nrf- reo* -n.qn

After a finite number of correct simulations the UTM
will reach its final state yet no simulated UTM ever
reaches its own final state.

Indeed, that is the proof that such a simulation fails.
No simulator exists that is able to simulate correctly all halting
programs up to the end,because it fails to simulate correctly code that resembles its own code.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

On 8/6/25 11:15 PM, olcott wrote:

On 8/6/2025 9:13 PM, Richard Damon wrote:

On 8/6/25 8:18 AM, olcott wrote:

On 8/6/2025 6:41 AM, Richard Damon wrote:

On 8/6/25 7:39 AM, olcott wrote:

On 8/6/2025 4:00 AM, Fred. Zwarts wrote:

Op 06.aug.2025 om 05:47 schreef olcott:

It corrects the error of the requirement that
a halt decider reports on its own behavior.

-a-a-a "The contradiction in Linz's (or Turing's) self-referential >>>>>>> -a-a-a-a halting construction only appears if one insists that the >>>>>>> -a-a-a-a machine can and must decide on its own behavior, which is >>>>>>> -a-a-a-a neither possible nor required."

https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8

That seems to be one of your misunderstanding. A decider must
report on the behaviour of its input, even if this behaviour
resembles its own behaviour. That is very different from 'deciding >>>>>> on its own behaviour'.

*This is my correction*
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR
-a-a-a if rf?-nrf- rf?-nrf- simulated by -n.embedded_H reaches
-a-a-a its simulated final halt state of rf?-n.qnrf-, and

-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn
-a-a-a if rf?-nrf- rf?-nrf- simulated by -n.embedded_H cannot possibly >>>>> -a-a-a reach its simulated final halt state of rf?-n.qnrf-.

*This is the original erroneous one*
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR,
-a-a-a if -n applied to rf?-nrf- halts, and
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn
-a-a-a if -n applied to rf?-nrf- does not halt.

*Lines two and four requires -n.embedded_H to report on its own
behavior*

Which is valid.

And you are just stupid to think otherwise.

It is only valid when Turing machine deciders can
take themselves as inputs.

They only need to take representation of themselves as input.

-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR,
if -n applied to rf?-nrf- halts, and

-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn
if -n applied to rf?-nrf- does not halt.

The Linz proof has -n take its own machine description
as input (this is fine) yet requires -n.embedded_H to
directly report on its own behavior. No TM can ever
do that.

You claim that, but you are wrong.

First, H isn't being asked to report on "its own" behavior, but the
behavior of a program that contains it.

Second, if your claim *IS* true, then you are just stating that it MUST
be defintionally impossible for a Halt Decider to exist, as Halt
Deciders, by their definition, need to answer about ANY program, but
since they are programs, they need to answer about themselves.

Also, Mr Flibble has show, that assuming that the decider is able to
detect this pattern, (that the input is calling a copy of the decider),
that there IS a method to determine the answer in many cases, that is if
there IS a possible answer that it can give.

Thus, your claim is just false on its face.

The fact that we can come up with a case that the decider can't
correctly answer doesn't, as your ignorant mind thinks, mean that the
question isn't valid, because the problem always included the
possibility that the answer is that "NO decider can answer this question
for every possible input."

And that *IS* the correct answer, that the problem is just
non-computable, and thus all you arguments about "computable functions"
are just category errors, as we were never dealing with a computable
function, but asking if something WAS a computable function.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

On 8/6/25 11:24 PM, olcott wrote:

On 8/6/2025 9:27 PM, Richard Damon wrote:

On 8/6/25 7:53 AM, olcott wrote:

On 8/6/2025 5:54 AM, Richard Damon wrote:

On 8/5/25 11:47 PM, olcott wrote:

It corrects the error of the requirement that
a halt decider reports on its own behavior.

But it isn't an error.

Halt Deciders need to answer about *ANY* program, and they are
programs.

-a-a-a "The contradiction in Linz's (or Turing's) self-referential
-a-a-a-a halting construction only appears if one insists that the
-a-a-a-a machine can and must decide on its own behavior, which is
-a-a-a-a neither possible nor required."

https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8

Because you lied to it and said it was an error.

The above paragraph is proved true by the meaning of its words.
When we ask a Turing machine to report on its own behavior we
are assuming that its Turing Machine description is an accurate
proxy for this behavior. When there are exceptions to this rule
then we cannot possibly ask a Turing machine about its own behavior.
This is easily corrected:

But the existance of UTMs means that it IS possible to make a perfect
proxy, as the UTM can completely recreate the behavior of ANY machine
from its Turing Machine Description.

All you are doing is admitting that you think errors and lies are ok.

-a-a -n.q0 rf?-nrf- reo* -n.UTM rf?-nrf- rf?-nrf- reo* -n.qy,
-a-a -n.q0 rf?-nrf- reo* -n.UTM rf?-nrf- rf?-nrf- reo* -n.qn

After a finite number of correct simulations the UTM
will reach its final state yet no simulated UTM ever
reaches its own final state.

But that isn't the input we have.

And, can you show the case you claim? That the UTM *WILL* reach a final
state for this case?

And your notation is just incorrect as UTM isn't a machine that goes to
Qn or Qy, but a state with a tape representing the input H^ at its final
state and the representation of the final tape of H^

All you are doing is proving you just don't know what you are talking about.

Since UTMs aren't defined to have a Qy and Qn state, you can't build an
H^ on one.

All you are doing is proving your complete stupidity and ignorance of
the subject. That you just parrot words you aquired without
understanding by rote in meaningless statements, making you dumber than
an AI, which at least took time to be trained to make it statements, at
least most of the time, appear to make sense, because it DID study the material.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

On 8/7/2025 4:11 AM, Fred. Zwarts wrote:

Op 07.aug.2025 om 05:15 schreef olcott:

-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR,
if -n applied to rf?-nrf- halts, and

-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn
if -n applied to rf?-nrf- does not halt.

The Linz proof has -n take its own machine description
as input (this is fine) yet requires -n.embedded_H to
directly report on its own behavior. No TM can ever
do that.

That is your mistake. It does not require to report on its own
behaviour, but on the behaviour of -n.

That *is* its own behavior.
-n.embedded_H *is* an aspect of -n.
-n.embedded_H does correctly report on the behavior
specified by its input rf?-nrf- rf?-nrf- as measured by its
correct simulation of this input.

It is irrelevant whether the
behaviour of -n resembles that of embedded_H.

--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

On 8/7/2025 4:14 AM, Fred. Zwarts wrote:

Op 07.aug.2025 om 05:24 schreef olcott:

On 8/6/2025 9:27 PM, Richard Damon wrote:

On 8/6/25 7:53 AM, olcott wrote:

On 8/6/2025 5:54 AM, Richard Damon wrote:

On 8/5/25 11:47 PM, olcott wrote:

It corrects the error of the requirement that
a halt decider reports on its own behavior.

But it isn't an error.

Halt Deciders need to answer about *ANY* program, and they are
programs.

-a-a-a "The contradiction in Linz's (or Turing's) self-referential >>>>>> -a-a-a-a halting construction only appears if one insists that the >>>>>> -a-a-a-a machine can and must decide on its own behavior, which is >>>>>> -a-a-a-a neither possible nor required."

https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8

Because you lied to it and said it was an error.

The above paragraph is proved true by the meaning of its words.
When we ask a Turing machine to report on its own behavior we
are assuming that its Turing Machine description is an accurate
proxy for this behavior. When there are exceptions to this rule
then we cannot possibly ask a Turing machine about its own behavior.
This is easily corrected:

But the existance of UTMs means that it IS possible to make a perfect
proxy, as the UTM can completely recreate the behavior of ANY machine
from its Turing Machine Description.

All you are doing is admitting that you think errors and lies are ok.

-a-a-a -n.q0 rf?-nrf- reo* -n.UTM rf?-nrf- rf?-nrf- reo* -n.qy,
-a-a-a -n.q0 rf?-nrf- reo* -n.UTM rf?-nrf- rf?-nrf- reo* -n.qn

After a finite number of correct simulations the UTM
will reach its final state yet no simulated UTM ever
reaches its own final state.

Indeed, that is the proof that such a simulation fails.
No simulator exists that is able to simulate correctly all halting
programs up to the end,because it fails to simulate correctly code that resembles its own code.

*You are confusing two distinctly different notions*

No simulator can correctly simulate an input that has a
pathological relationship to itself until this simulated
input reaches its simulated final halt state because this
simulated final halt state is unreachable by this correctly
simulated input.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

On 8/7/25 9:39 AM, olcott wrote:

On 8/7/2025 4:11 AM, Fred. Zwarts wrote:

Op 07.aug.2025 om 05:15 schreef olcott:

-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR,
if -n applied to rf?-nrf- halts, and

-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn
if -n applied to rf?-nrf- does not halt.

The Linz proof has -n take its own machine description
as input (this is fine) yet requires -n.embedded_H to
directly report on its own behavior. No TM can ever
do that.

That is your mistake. It does not require to report on its own
behaviour, but on the behaviour of -n.

That *is* its own behavior.

No it isn't, unless you think you are just your big toe.

-n.embedded_H *is* an aspect of -n.

But it isn't -n

-n.embedded_H does correctly report on the behavior
specified by its input rf?-nrf- rf?-nrf- as measured by its
correct simulation of this input.

No, it doesn't, because it doesn't correctly simulate it, and the
hypothetical H (That isn't actually H) doesn't simulate the same input,
as the program the input represent contains the H that is deciding it,
and thus you can't look at the behavior of the hypothectical H emulation
of its input, as it is a different input.

You keep on making that lie, because you try to redefine what correct simulation means, but of course, you can only use "correct simulation"
as a proxy for the behavior of the program the input represents with the specifically defined definition of it.

So, all you are doing is showing you don't know the meaning of the words
you are using, or even that words HAVE correct meanings.

It is irrelevant whether the behaviour of -n resembles that of embedded_H.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

On 8/7/25 9:44 AM, olcott wrote:

On 8/7/2025 4:14 AM, Fred. Zwarts wrote:

Op 07.aug.2025 om 05:24 schreef olcott:

On 8/6/2025 9:27 PM, Richard Damon wrote:

On 8/6/25 7:53 AM, olcott wrote:

On 8/6/2025 5:54 AM, Richard Damon wrote:

On 8/5/25 11:47 PM, olcott wrote:

It corrects the error of the requirement that
a halt decider reports on its own behavior.

But it isn't an error.

Halt Deciders need to answer about *ANY* program, and they are
programs.

-a-a-a "The contradiction in Linz's (or Turing's) self-referential >>>>>>> -a-a-a-a halting construction only appears if one insists that the >>>>>>> -a-a-a-a machine can and must decide on its own behavior, which is >>>>>>> -a-a-a-a neither possible nor required."

https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8

Because you lied to it and said it was an error.

The above paragraph is proved true by the meaning of its words.
When we ask a Turing machine to report on its own behavior we
are assuming that its Turing Machine description is an accurate
proxy for this behavior. When there are exceptions to this rule
then we cannot possibly ask a Turing machine about its own behavior. >>>>> This is easily corrected:

But the existance of UTMs means that it IS possible to make a
perfect proxy, as the UTM can completely recreate the behavior of
ANY machine from its Turing Machine Description.

All you are doing is admitting that you think errors and lies are ok.

-a-a-a -n.q0 rf?-nrf- reo* -n.UTM rf?-nrf- rf?-nrf- reo* -n.qy,
-a-a-a -n.q0 rf?-nrf- reo* -n.UTM rf?-nrf- rf?-nrf- reo* -n.qn

After a finite number of correct simulations the UTM
will reach its final state yet no simulated UTM ever
reaches its own final state.

Indeed, that is the proof that such a simulation fails.
No simulator exists that is able to simulate correctly all halting
programs up to the end,because it fails to simulate correctly code
that resembles its own code.

*You are confusing two distinctly different notions*

No simulator can correctly simulate an input that has a
pathological relationship to itself until this simulated
input reaches its simulated final halt state because this
simulated final halt state is unreachable by this correctly
simulated input.

Right, which means that the behavior of a deciders correct simulation
can't be the criteria of a decider, because it just can't do it.

IT must ALWAYS be the behavior of the program described, or the behavior
of a correct simulaiton done by some OTHER machine, which won't have
that pathological relationship.

Thus, you are just admitting that your premise that you can do that is
just wrong, and thus is just nonsense.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

Op 07.aug.2025 om 15:39 schreef olcott:

On 8/7/2025 4:11 AM, Fred. Zwarts wrote:

Op 07.aug.2025 om 05:15 schreef olcott:

-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR,
if -n applied to rf?-nrf- halts, and

-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn
if -n applied to rf?-nrf- does not halt.

The Linz proof has -n take its own machine description
as input (this is fine) yet requires -n.embedded_H to
directly report on its own behavior. No TM can ever
do that.

That is your mistake. It does not require to report on its own
behaviour, but on the behaviour of -n.

That *is* its own behavior.

That is your mistake. It is not its own behaviour, but that of -n (which resembles its own behaviour). That is a fundamental difference.
When it is unable to analyse the behaviour that resembles its own
behaviour, it fails due to a limitation in its analysis. A decider is
required to analyse any behaviour, even if it resembles its own behaviour.

-n.embedded_H *is* an aspect of -n.
-n.embedded_H does correctly report on the behavior
specified by its input rf?-nrf- rf?-nrf- as measured by its
correct simulation of this input.

It is irrelevant whether the behaviour of -n resembles that of embedded_H.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

Op 07.aug.2025 om 15:44 schreef olcott:

On 8/7/2025 4:14 AM, Fred. Zwarts wrote:

Op 07.aug.2025 om 05:24 schreef olcott:

On 8/6/2025 9:27 PM, Richard Damon wrote:

On 8/6/25 7:53 AM, olcott wrote:

On 8/6/2025 5:54 AM, Richard Damon wrote:

On 8/5/25 11:47 PM, olcott wrote:

It corrects the error of the requirement that
a halt decider reports on its own behavior.

But it isn't an error.

Halt Deciders need to answer about *ANY* program, and they are
programs.

-a-a-a "The contradiction in Linz's (or Turing's) self-referential >>>>>>> -a-a-a-a halting construction only appears if one insists that the >>>>>>> -a-a-a-a machine can and must decide on its own behavior, which is >>>>>>> -a-a-a-a neither possible nor required."

https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8

Because you lied to it and said it was an error.

The above paragraph is proved true by the meaning of its words.
When we ask a Turing machine to report on its own behavior we
are assuming that its Turing Machine description is an accurate
proxy for this behavior. When there are exceptions to this rule
then we cannot possibly ask a Turing machine about its own behavior. >>>>> This is easily corrected:

But the existance of UTMs means that it IS possible to make a
perfect proxy, as the UTM can completely recreate the behavior of
ANY machine from its Turing Machine Description.

All you are doing is admitting that you think errors and lies are ok.

-a-a-a -n.q0 rf?-nrf- reo* -n.UTM rf?-nrf- rf?-nrf- reo* -n.qy,
-a-a-a -n.q0 rf?-nrf- reo* -n.UTM rf?-nrf- rf?-nrf- reo* -n.qn

After a finite number of correct simulations the UTM
will reach its final state yet no simulated UTM ever
reaches its own final state.

Indeed, that is the proof that such a simulation fails.
No simulator exists that is able to simulate correctly all halting
programs up to the end,because it fails to simulate correctly code
that resembles its own code.

*You are confusing two distinctly different notions*

As usual incorrect claims without evidence.>

No simulator can correctly simulate an input that has a
pathological relationship to itself until this simulated
input reaches its simulated final halt state because this
simulated final halt state is unreachable by this correctly
simulated input.

Indeed, such a simulator must fail, but not because the final halt state
does not exist, but because the simulator is unable to reach that final
halt state specified in the input, where other simulators prove that
such a final halt state is specified in the input.
This proves that simulation is not the right tool for such an analysis.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: sci.logic

On 8/6/25 11:24 PM, olcott wrote:

On 8/6/2025 9:27 PM, Richard Damon wrote:

On 8/6/25 7:53 AM, olcott wrote:

On 8/6/2025 5:54 AM, Richard Damon wrote:

On 8/5/25 11:47 PM, olcott wrote:

It corrects the error of the requirement that
a halt decider reports on its own behavior.

But it isn't an error.

Halt Deciders need to answer about *ANY* program, and they are
programs.

-a-a-a "The contradiction in Linz's (or Turing's) self-referential
-a-a-a-a halting construction only appears if one insists that the
-a-a-a-a machine can and must decide on its own behavior, which is
-a-a-a-a neither possible nor required."

https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8

Because you lied to it and said it was an error.

The above paragraph is proved true by the meaning of its words.
When we ask a Turing machine to report on its own behavior we
are assuming that its Turing Machine description is an accurate
proxy for this behavior. When there are exceptions to this rule
then we cannot possibly ask a Turing machine about its own behavior.
This is easily corrected:

But the existance of UTMs means that it IS possible to make a perfect
proxy, as the UTM can completely recreate the behavior of ANY machine
from its Turing Machine Description.

All you are doing is admitting that you think errors and lies are ok.

-a-a -n.q0 rf?-nrf- reo* -n.UTM rf?-nrf- rf?-nrf- reo* -n.qy,
-a-a -n.q0 rf?-nrf- reo* -n.UTM rf?-nrf- rf?-nrf- reo* -n.qn

After a finite number of correct simulations the UTM
will reach its final state yet no simulated UTM ever
reaches its own final state.

But that isn't the input we have.

And, can you show the case you claim? That the UTM *WILL* reach a final
state for this case?

And your notation is just incorrect as UTM isn't a machine that goes to
Qn or Qy, but a state with a tape representing the input H^ at its final
state and the representation of the final tape of H^

All you are doing is proving you just don't know what you are talking about.

Since UTMs aren't defined to have a Qy and Qn state, you can't build an
H^ on one.

All you are doing is proving your complete stupidity and ignorance of
the subject. That you just parrot words you aquired without
understanding by rote in meaningless statements, making you dumber than
an AI, which at least took time to be trained to make it statements, at
least most of the time, appear to make sense, because it DID study the material.
--- Synchronet 3.21a-Linux NewsLink 1.2