olcott <polcott333@gmail.com> wrote:
On 7/29/2025 5:49 PM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/29/2025 2:39 AM, Fred. Zwarts wrote:
[ .... ]
As usual incorrect claims without evidence.
Your dreams are no verified facts. HHH aborts before the simulation
would reach the final halt state in a finite number of steps, as proven >>>>> by world-class simulators using exactly the same input. The infinity is >>>>> only in your dreams.
HHH(DDD) must simulate itself simulating DDD because DDD calls HHH(DDD)
HHH1(DDD) must NOT simulate itself simulating DDD because DDD DOES NOT >>>> CALL HHH1(DDD)
At this point I think that you are a fucking liar.
As has been established elsewhere in this thread, you are no position to >>> call anybody else here a liar. Glass house inhabitants, throwing stones, >>> and all that.
And you used to distinguish yourself from other cranks by sticking to
decorous language, and generally being courteous. Not any more. That is >>> a most unwelcome change.
void DDD()
{
HHH(DDD);
return;
}
*That not one single person here*
(besides those that I invited from the C groups)
acknowledges that DDD simulated by HHH specifies
recursive simulation
cannot be reasonably attributed to anything besides
willful deception.
Foul mouthed lying on your part. It can be attributed to your lack of
self awareness and lack of technical ability. Everybody here but you can
see that.
On 7/29/2025 9:35 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/29/2025 5:49 PM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/29/2025 2:39 AM, Fred. Zwarts wrote:
[ .... ]
As usual incorrect claims without evidence.
Your dreams are no verified facts. HHH aborts before the simulation >>>>>> would reach the final halt state in a finite number of steps, as proven >>>>>> by world-class simulators using exactly the same input. The infinity is >>>>>> only in your dreams.
HHH(DDD) must simulate itself simulating DDD because DDD calls HHH(DDD)
HHH1(DDD) must NOT simulate itself simulating DDD because DDD DOES NOT >>>>> CALL HHH1(DDD)
At this point I think that you are a fucking liar.
As has been established elsewhere in this thread, you are no position to >>>> call anybody else here a liar. Glass house inhabitants, throwing stones, >>>> and all that.
And you used to distinguish yourself from other cranks by sticking to
decorous language, and generally being courteous. Not any more. That is >>>> a most unwelcome change.
void DDD()
{
HHH(DDD);
return;
}
*That not one single person here*
(besides those that I invited from the C groups)
acknowledges that DDD simulated by HHH specifies
recursive simulation
cannot be reasonably attributed to anything besides
willful deception.
Foul mouthed lying on your part. It can be attributed to your lack of
self awareness and lack of technical ability. Everybody here but you can
see that.
It is not any lack of technical ability that determines
whether or not DDD correctly simulated by HHH can or
cannot reach its own "return" instruction final halt state.
Instead of addressing this you used the dishonest dodge
of ad hominem attack. It is for this exact same reason
that I am justified in calling out liars.
As soon as the first person utterly gives up dishonestly
trolling me and gives my work an actual fair review I
will treat that person with kindness and respect.
I tried kindness and respect for many years and the trolls
took this as weakness to be exploited.
----
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/29/2025 9:35 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/29/2025 5:49 PM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/29/2025 2:39 AM, Fred. Zwarts wrote:
[ .... ]
As usual incorrect claims without evidence.
Your dreams are no verified facts. HHH aborts before the simulation >>>>>>> would reach the final halt state in a finite number of steps, as proven >>>>>>> by world-class simulators using exactly the same input. The infinity is >>>>>>> only in your dreams.
HHH(DDD) must simulate itself simulating DDD because DDD calls HHH(DDD)
HHH1(DDD) must NOT simulate itself simulating DDD because DDD DOES NOT >>>>>> CALL HHH1(DDD)
At this point I think that you are a fucking liar.
As has been established elsewhere in this thread, you are no position to >>>>> call anybody else here a liar. Glass house inhabitants, throwing stones, >>>>> and all that.
And you used to distinguish yourself from other cranks by sticking to >>>>> decorous language, and generally being courteous. Not any more. That is >>>>> a most unwelcome change.
void DDD()
{
HHH(DDD);
return;
}
*That not one single person here*
(besides those that I invited from the C groups)
acknowledges that DDD simulated by HHH specifies
recursive simulation
cannot be reasonably attributed to anything besides
willful deception.
Foul mouthed lying on your part. It can be attributed to your lack of
self awareness and lack of technical ability. Everybody here but you can >>> see that.
It is not any lack of technical ability that determines
whether or not DDD correctly simulated by HHH can or
cannot reach its own "return" instruction final halt state.
It is a lack of technical ability on your part which is unable to judge whether such a correct simulation is possible. Everybody else sees that
it is not, so further questions about it are non-sensical.
On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/29/2025 9:35 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/29/2025 5:49 PM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/29/2025 2:39 AM, Fred. Zwarts wrote:
[ .... ]
As usual incorrect claims without evidence.
Your dreams are no verified facts. HHH aborts before the simulation >>>>>>>> would reach the final halt state in a finite number of steps, as >>>>>>>> proven
by world-class simulators using exactly the same input. The
infinity is
only in your dreams.
HHH(DDD) must simulate itself simulating DDD because DDD calls
HHH(DDD)
HHH1(DDD) must NOT simulate itself simulating DDD because DDD
DOES NOT
CALL HHH1(DDD)
At this point I think that you are a fucking liar.
As has been established elsewhere in this thread, you are no
position to
call anybody else here a liar. Glass house inhabitants, throwing >>>>>> stones,
and all that.
And you used to distinguish yourself from other cranks by sticking to >>>>>> decorous language, and generally being courteous. Not any more. >>>>>> That is
a most unwelcome change.
void DDD()
{
HHH(DDD);
return;
}
*That not one single person here*
(besides those that I invited from the C groups)
acknowledges that DDD simulated by HHH specifies
recursive simulation
cannot be reasonably attributed to anything besides
willful deception.
Foul mouthed lying on your part. It can be attributed to your lack of >>>> self awareness and lack of technical ability. Everybody here but
you can
see that.
It is not any lack of technical ability that determines
whether or not DDD correctly simulated by HHH can or
cannot reach its own "return" instruction final halt state.
It is a lack of technical ability on your part which is unable to judge
whether such a correct simulation is possible. Everybody else sees that
it is not, so further questions about it are non-sensical.
void DDD()
{
HHH(DDD);
return;
}
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
I have no idea why are are saying the something
that is trivial is impossible.
When HHH emulates: "push ebp" then HHH has correctly
emulated the first instruction of DDD correctly.
Perhaps you have an ACM email address and don't--- Synchronet 3.21a-Linux NewsLink 1.2
know very much about programming?
On 7/29/2025 9:35 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/29/2025 5:49 PM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/29/2025 2:39 AM, Fred. Zwarts wrote:
[ .... ]
As usual incorrect claims without evidence.
Your dreams are no verified facts. HHH aborts before the simulation >>>>>> would reach the final halt state in a finite number of steps, as
proven
by world-class simulators using exactly the same input. The
infinity is
only in your dreams.
HHH(DDD) must simulate itself simulating DDD because DDD calls
HHH(DDD)
HHH1(DDD) must NOT simulate itself simulating DDD because DDD DOES NOT >>>>> CALL HHH1(DDD)
At this point I think that you are a fucking liar.
As has been established elsewhere in this thread, you are no
position to
call anybody else here a liar. Glass house inhabitants, throwing
stones,
and all that.
And you used to distinguish yourself from other cranks by sticking to
decorous language, and generally being courteous. Not any more.
That is
a most unwelcome change.
void DDD()
{
HHH(DDD);
return;
}
*That not one single person here*
(besides those that I invited from the C groups)
acknowledges that DDD simulated by HHH specifies
recursive simulation
cannot be reasonably attributed to anything besides
willful deception.
Foul mouthed lying on your part. It can be attributed to your lack of
self awareness and lack of technical ability. Everybody here but you can >> see that.
It is not any lack of technical ability that determines
whether or not DDD correctly simulated by HHH can or
cannot reach its own "return" instruction final halt state.
Instead of addressing this you used the dishonest dodge
of ad hominem attack. It is for this exact same reason
that I am justified in calling out liars.
As soon as the first person utterly gives up dishonestly
trolling me and gives my work an actual fair review I
will treat that person with kindness and respect.
I tried kindness and respect for many years and the trolls
took this as weakness to be exploited.
On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/29/2025 9:35 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/29/2025 5:49 PM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/29/2025 2:39 AM, Fred. Zwarts wrote:
[ .... ]
As usual incorrect claims without evidence.
Your dreams are no verified facts. HHH aborts before the simulation >>>>>>>> would reach the final halt state in a finite number of steps, as >>>>>>>> proven
by world-class simulators using exactly the same input. The
infinity is
only in your dreams.
HHH(DDD) must simulate itself simulating DDD because DDD calls
HHH(DDD)
HHH1(DDD) must NOT simulate itself simulating DDD because DDD
DOES NOT
CALL HHH1(DDD)
At this point I think that you are a fucking liar.
As has been established elsewhere in this thread, you are no
position to
call anybody else here a liar. Glass house inhabitants, throwing >>>>>> stones,
and all that.
And you used to distinguish yourself from other cranks by sticking to >>>>>> decorous language, and generally being courteous. Not any more. >>>>>> That is
a most unwelcome change.
void DDD()
{
HHH(DDD);
return;
}
*That not one single person here*
(besides those that I invited from the C groups)
acknowledges that DDD simulated by HHH specifies
recursive simulation
cannot be reasonably attributed to anything besides
willful deception.
Foul mouthed lying on your part. It can be attributed to your lack of >>>> self awareness and lack of technical ability. Everybody here but
you can
see that.
It is not any lack of technical ability that determines
whether or not DDD correctly simulated by HHH can or
cannot reach its own "return" instruction final halt state.
It is a lack of technical ability on your part which is unable to judge
whether such a correct simulation is possible. Everybody else sees that
it is not, so further questions about it are non-sensical.
void DDD()
{
HHH(DDD);
return;
}
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
I have no idea why are are saying the something
that is trivial is impossible.
When HHH emulates: "push ebp" then HHH has correctly
emulated the first instruction of DDD correctly.
Perhaps you have an ACM email address and don't
know very much about programming?
Op 30.jul.2025 om 07:00 schreef olcott:
On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/29/2025 9:35 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/29/2025 5:49 PM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/29/2025 2:39 AM, Fred. Zwarts wrote:
[ .... ]
As usual incorrect claims without evidence.
Your dreams are no verified facts. HHH aborts before the
simulation
would reach the final halt state in a finite number of steps, >>>>>>>>> as proven
by world-class simulators using exactly the same input. The >>>>>>>>> infinity is
only in your dreams.
HHH(DDD) must simulate itself simulating DDD because DDD calls >>>>>>>> HHH(DDD)
HHH1(DDD) must NOT simulate itself simulating DDD because DDD >>>>>>>> DOES NOT
CALL HHH1(DDD)
At this point I think that you are a fucking liar.
As has been established elsewhere in this thread, you are no
position to
call anybody else here a liar. Glass house inhabitants, throwing >>>>>>> stones,
and all that.
And you used to distinguish yourself from other cranks by
sticking to
decorous language, and generally being courteous. Not any more. >>>>>>> That is
a most unwelcome change.
void DDD()
{
HHH(DDD);
return;
}
*That not one single person here*
(besides those that I invited from the C groups)
acknowledges that DDD simulated by HHH specifies
recursive simulation
cannot be reasonably attributed to anything besides
willful deception.
Foul mouthed lying on your part. It can be attributed to your lack of >>>>> self awareness and lack of technical ability. Everybody here but
you can
see that.
It is not any lack of technical ability that determines
whether or not DDD correctly simulated by HHH can or
cannot reach its own "return" instruction final halt state.
It is a lack of technical ability on your part which is unable to judge
whether such a correct simulation is possible. Everybody else sees that >>> it is not, so further questions about it are non-sensical.
void DDD()
{
HHH(DDD);
return;
}
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
I have no idea why are are saying the something
that is trivial is impossible.
When HHH emulates: "push ebp" then HHH has correctly
emulated the first instruction of DDD correctly.
Simulating a few instructions does not make the whole simulation
correct.
In contrast, the failure to simulate a single instruction
correctly, makes the whole simulation incorrect.
In this case it is the failure to simulate the call instruction.
The
simulation aborts at this point, where the semantics of the x86 language requires the execution of the next instruction.
recursion specifies non-halting, makes the whole simulation incorrect
and, what is worse, the conclusion of non-halting behaviour fails.
Further irrelevant claims without evidence ignored.--
Perhaps you have an ACM email address and don't
know very much about programming?
On 7/29/25 10:49 PM, olcott wrote:
On 7/29/2025 9:35 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/29/2025 5:49 PM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/29/2025 2:39 AM, Fred. Zwarts wrote:
[ .... ]
As usual incorrect claims without evidence.
Your dreams are no verified facts. HHH aborts before the simulation >>>>>>> would reach the final halt state in a finite number of steps, as >>>>>>> proven
by world-class simulators using exactly the same input. The
infinity is
only in your dreams.
HHH(DDD) must simulate itself simulating DDD because DDD calls
HHH(DDD)
HHH1(DDD) must NOT simulate itself simulating DDD because DDD DOES >>>>>> NOT
CALL HHH1(DDD)
At this point I think that you are a fucking liar.
As has been established elsewhere in this thread, you are no
position to
call anybody else here a liar. Glass house inhabitants, throwing
stones,
and all that.
And you used to distinguish yourself from other cranks by sticking to >>>>> decorous language, and generally being courteous. Not any more.
That is
a most unwelcome change.
void DDD()
{
HHH(DDD);
return;
}
*That not one single person here*
(besides those that I invited from the C groups)
acknowledges that DDD simulated by HHH specifies
recursive simulation
cannot be reasonably attributed to anything besides
willful deception.
Foul mouthed lying on your part. It can be attributed to your lack of
self awareness and lack of technical ability. Everybody here but you
can
see that.
It is not any lack of technical ability that determines
whether or not DDD correctly simulated by HHH can or
cannot reach its own "return" instruction final halt state.
Yes, it IS YOUR lack of technical ability the shows that you don't know
what you are talking about.
Since your HHH doesn't do a correct simulation per the definition of the field, you claim that it does is just a lie.
And logic based on lies is just unsound.
Instead of addressing this you used the dishonest dodge
of ad hominem attack. It is for this exact same reason
that I am justified in calling out liars.
No, the fact that you keep on misusing words is our justification for calling you a lair.
Trying to use your lies to justify calling someone else a liar just
shows your own stupidity.
As soon as the first person utterly gives up dishonestly
trolling me and gives my work an actual fair review I
will treat that person with kindness and respect.
Sorry, but it is YOU that has been dishonestly trolling, and thus YOU
are the one that has lost the right to be treated with kindness and
respect.
I tried kindness and respect for many years and the trolls
took this as weakness to be exploited.
But still kept your ignorant lies.
Sorry, you have killed any hope of being respected, and cemented your
place in the trashheap of history.
You have proved that you turned yourself into an intentional idiot, with
no idea of the actual meaning of the word, because you were afraid that
the TRUTH would brainwash you into thinking about reality.
On 7/30/2025 4:09 AM, Fred. Zwarts wrote:
Op 30.jul.2025 om 07:00 schreef olcott:
On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/29/2025 9:35 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/29/2025 5:49 PM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/29/2025 2:39 AM, Fred. Zwarts wrote:
[ .... ]
As usual incorrect claims without evidence.
Your dreams are no verified facts. HHH aborts before the
simulation
would reach the final halt state in a finite number of steps, >>>>>>>>>> as proven
by world-class simulators using exactly the same input. The >>>>>>>>>> infinity is
only in your dreams.
HHH(DDD) must simulate itself simulating DDD because DDD calls >>>>>>>>> HHH(DDD)
HHH1(DDD) must NOT simulate itself simulating DDD because DDD >>>>>>>>> DOES NOT
CALL HHH1(DDD)
At this point I think that you are a fucking liar.
As has been established elsewhere in this thread, you are no
position to
call anybody else here a liar. Glass house inhabitants,
throwing stones,
and all that.
And you used to distinguish yourself from other cranks by
sticking to
decorous language, and generally being courteous. Not any more. >>>>>>>> That is
a most unwelcome change.
void DDD()
{
HHH(DDD);
return;
}
*That not one single person here*
(besides those that I invited from the C groups)
acknowledges that DDD simulated by HHH specifies
recursive simulation
cannot be reasonably attributed to anything besides
willful deception.
Foul mouthed lying on your part. It can be attributed to your
lack of
self awareness and lack of technical ability. Everybody here but >>>>>> you can
see that.
It is not any lack of technical ability that determines
whether or not DDD correctly simulated by HHH can or
cannot reach its own "return" instruction final halt state.
It is a lack of technical ability on your part which is unable to judge >>>> whether such a correct simulation is possible. Everybody else sees
that
it is not, so further questions about it are non-sensical.
void DDD()
{
HHH(DDD);
return;
}
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
I have no idea why are are saying the something
that is trivial is impossible.
When HHH emulates: "push ebp" then HHH has correctly
emulated the first instruction of DDD correctly.
Simulating a few instructions does not make the whole simulation correct.
Simulating N instructions correctly does mean that
these N instructions were simulated correctly.
In contrast, the failure to simulate a single instruction correctly,
makes the whole simulation incorrect.
In this case it is the failure to simulate the call instruction.
My code conclusively proves that HHH does simulate
itself simulating DDD. That you do not understand
this code well enough to understand that is less
than no rebuttal at all.
The simulation aborts at this point, where the semantics of the x86
language requires the execution of the next instruction.
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) It detects a non-terminating behavior pattern then it aborts its simulation and returns 0,
(b) Its simulated input reaches its simulated "return" statement then it returns 1.
My code conclusively proves that HHH does simulate itself
simulating DDD until any sufficiently competent person can
correctly determine a repeating pattern that cannot possibly
reach its own "return" statement final halt state even with
an infinite simulation.
That you do not understand this code well enough to
understand that is less than no rebuttal at all. https://github.com/plolcott/x86utm/blob/master/Halt7.c
When it does detect this pattern then it kills the
whole DDD process so that there is no stack unwinding.
; This premature abort, based on the incorrect assumption that a finite
recursion specifies non-halting, makes the whole simulation incorrect
and, what is worse, the conclusion of non-halting behaviour fails.
HHH uses exactly same process on this function.
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
as it does this function.
void DDD()
{
HHH(DDD);
return;
}
HHH has no idea that DDD is calling itself.
HHH just sees that DDD is calling the same function
with the same parameter twice in sequence, just like
Infinite_Recursion().
Further irrelevant claims without evidence ignored.
Perhaps you have an ACM email address and don't
know very much about programming?
On 7/30/25 10:12 AM, olcott wrote:
On 7/30/2025 4:09 AM, Fred. Zwarts wrote:
Op 30.jul.2025 om 07:00 schreef olcott:
On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/29/2025 9:35 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/29/2025 5:49 PM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/29/2025 2:39 AM, Fred. Zwarts wrote:
[ .... ]
As usual incorrect claims without evidence.
Your dreams are no verified facts. HHH aborts before the >>>>>>>>>>> simulation
would reach the final halt state in a finite number of steps, >>>>>>>>>>> as proven
by world-class simulators using exactly the same input. The >>>>>>>>>>> infinity is
only in your dreams.
HHH(DDD) must simulate itself simulating DDD because DDD calls >>>>>>>>>> HHH(DDD)
HHH1(DDD) must NOT simulate itself simulating DDD because DDD >>>>>>>>>> DOES NOT
CALL HHH1(DDD)
At this point I think that you are a fucking liar.
As has been established elsewhere in this thread, you are no >>>>>>>>> position to
call anybody else here a liar. Glass house inhabitants,
throwing stones,
and all that.
And you used to distinguish yourself from other cranks by
sticking to
decorous language, and generally being courteous. Not any >>>>>>>>> more. That is
a most unwelcome change.
void DDD()
{
HHH(DDD);
return;
}
*That not one single person here*
(besides those that I invited from the C groups)
acknowledges that DDD simulated by HHH specifies
recursive simulation
cannot be reasonably attributed to anything besides
willful deception.
Foul mouthed lying on your part. It can be attributed to your >>>>>>> lack of
self awareness and lack of technical ability. Everybody here but >>>>>>> you can
see that.
It is not any lack of technical ability that determines
whether or not DDD correctly simulated by HHH can or
cannot reach its own "return" instruction final halt state.
It is a lack of technical ability on your part which is unable to
judge
whether such a correct simulation is possible. Everybody else sees >>>>> that
it is not, so further questions about it are non-sensical.
void DDD()
{
HHH(DDD);
return;
}
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
I have no idea why are are saying the something
that is trivial is impossible.
When HHH emulates: "push ebp" then HHH has correctly
emulated the first instruction of DDD correctly.
Simulating a few instructions does not make the whole simulation
correct.
Simulating N instructions correctly does mean that
these N instructions were simulated correctly.
But not that *ALL* of it was simulated correctly.
On 7/30/2025 6:10 AM, Richard Damon wrote:
On 7/29/25 10:49 PM, olcott wrote:
On 7/29/2025 9:35 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/29/2025 5:49 PM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/29/2025 2:39 AM, Fred. Zwarts wrote:
[ .... ]
As usual incorrect claims without evidence.
Your dreams are no verified facts. HHH aborts before the simulation >>>>>>>> would reach the final halt state in a finite number of steps, as >>>>>>>> proven
by world-class simulators using exactly the same input. The
infinity is
only in your dreams.
HHH(DDD) must simulate itself simulating DDD because DDD calls
HHH(DDD)
HHH1(DDD) must NOT simulate itself simulating DDD because DDD
DOES NOT
CALL HHH1(DDD)
At this point I think that you are a fucking liar.
As has been established elsewhere in this thread, you are no
position to
call anybody else here a liar. Glass house inhabitants, throwing >>>>>> stones,
and all that.
And you used to distinguish yourself from other cranks by sticking to >>>>>> decorous language, and generally being courteous. Not any more. >>>>>> That is
a most unwelcome change.
void DDD()
{
HHH(DDD);
return;
}
*That not one single person here*
(besides those that I invited from the C groups)
acknowledges that DDD simulated by HHH specifies
recursive simulation
cannot be reasonably attributed to anything besides
willful deception.
Foul mouthed lying on your part. It can be attributed to your lack of >>>> self awareness and lack of technical ability. Everybody here but
you can
see that.
It is not any lack of technical ability that determines
whether or not DDD correctly simulated by HHH can or
cannot reach its own "return" instruction final halt state.
Yes, it IS YOUR lack of technical ability the shows that you don't
know what you are talking about.
The function does do what it does do even if no one knows this.
Since your HHH doesn't do a correct simulation per the definition of
the field, you claim that it does is just a lie.
HHH does emulate N x86 instructions of DDD correctly.
This includes the x86 instructions of DDD emulated by
the emulated HHH. No one can possibly correctly show
otherwise.
And logic based on lies is just unsound.
That you cannot even point out one mistake makes
you calling me a liar libelous. Instead of any
name calling try to stick with the actual facts.
Instead of addressing this you used the dishonest dodge
of ad hominem attack. It is for this exact same reason
that I am justified in calling out liars.
No, the fact that you keep on misusing words is our justification for
calling you a lair.
There has never been any material mistake in anything
that I have said and you cannot show otherwise. The
reason that you resort to ad hominem attacks is that
you know that I never made any actual material mistakes.
*This is what I mean by proof*
*A proof is any sequence of steps deriving a necessary result*
The sequence of steps that I refer to is the execution trace
specified by the x86 instructions of my code.
Trying to use your lies to justify calling someone else a liar just
shows your own stupidity.
You cannot even point to a single mistake.
If you had a sound basis then you could use
that and have no need of any ad hominem or insults.
As soon as the first person utterly gives up dishonestly
trolling me and gives my work an actual fair review I
will treat that person with kindness and respect.
Sorry, but it is YOU that has been dishonestly trolling, and thus YOU
are the one that has lost the right to be treated with kindness and
respect.
I tried kindness and respect for many years and the trolls
took this as weakness to be exploited.
But still kept your ignorant lies.
That you cannot even correctly point to a single mistake
and that you calling me a liar anyway is libelous.
May you reap whatever you sow.
Sorry, you have killed any hope of being respected, and cemented your
place in the trashheap of history.
You have proved that you turned yourself into an intentional idiot,
with no idea of the actual meaning of the word, because you were
afraid that the TRUTH would brainwash you into thinking about reality.
On 7/30/2025 6:26 PM, Richard Damon wrote:
On 7/30/25 10:12 AM, olcott wrote:
On 7/30/2025 4:09 AM, Fred. Zwarts wrote:
Op 30.jul.2025 om 07:00 schreef olcott:
On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/29/2025 9:35 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/29/2025 5:49 PM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/29/2025 2:39 AM, Fred. Zwarts wrote:
[ .... ]
As usual incorrect claims without evidence.
Your dreams are no verified facts. HHH aborts before the >>>>>>>>>>>> simulation
would reach the final halt state in a finite number of >>>>>>>>>>>> steps, as proven
by world-class simulators using exactly the same input. The >>>>>>>>>>>> infinity is
only in your dreams.
HHH(DDD) must simulate itself simulating DDD because DDD >>>>>>>>>>> calls HHH(DDD)
HHH1(DDD) must NOT simulate itself simulating DDD because DDD >>>>>>>>>>> DOES NOT
CALL HHH1(DDD)
At this point I think that you are a fucking liar.
As has been established elsewhere in this thread, you are no >>>>>>>>>> position to
call anybody else here a liar. Glass house inhabitants, >>>>>>>>>> throwing stones,
and all that.
And you used to distinguish yourself from other cranks by >>>>>>>>>> sticking to
decorous language, and generally being courteous. Not any >>>>>>>>>> more. That is
a most unwelcome change.
void DDD()
{
HHH(DDD);
return;
}
*That not one single person here*
(besides those that I invited from the C groups)
acknowledges that DDD simulated by HHH specifies
recursive simulation
cannot be reasonably attributed to anything besides
willful deception.
Foul mouthed lying on your part. It can be attributed to your >>>>>>>> lack of
self awareness and lack of technical ability. Everybody here >>>>>>>> but you can
see that.
It is not any lack of technical ability that determines
whether or not DDD correctly simulated by HHH can or
cannot reach its own "return" instruction final halt state.
It is a lack of technical ability on your part which is unable to >>>>>> judge
whether such a correct simulation is possible. Everybody else
sees that
it is not, so further questions about it are non-sensical.
void DDD()
{
HHH(DDD);
return;
}
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
I have no idea why are are saying the something
that is trivial is impossible.
When HHH emulates: "push ebp" then HHH has correctly
emulated the first instruction of DDD correctly.
Simulating a few instructions does not make the whole simulation
correct.
Simulating N instructions correctly does mean that
these N instructions were simulated correctly.
But not that *ALL* of it was simulated correctly.
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
Neither was all of the instructions of the above
simulated correctly. When N instructions are simulated
correctly the repeating pattern emerges.
void DDD()
{
HHH(DDD);
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)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
and then HHH finally aborts its simulation.
On 7/30/25 7:46 PM, olcott wrote:
On 7/30/2025 6:26 PM, Richard Damon wrote:
On 7/30/25 10:12 AM, olcott wrote:
On 7/30/2025 4:09 AM, Fred. Zwarts wrote:
Op 30.jul.2025 om 07:00 schreef olcott:
On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/29/2025 9:35 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/29/2025 5:49 PM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/29/2025 2:39 AM, Fred. Zwarts wrote:
[ .... ]
As usual incorrect claims without evidence.
Your dreams are no verified facts. HHH aborts before the >>>>>>>>>>>>> simulation
would reach the final halt state in a finite number of >>>>>>>>>>>>> steps, as proven
by world-class simulators using exactly the same input. The >>>>>>>>>>>>> infinity is
only in your dreams.
HHH(DDD) must simulate itself simulating DDD because DDD >>>>>>>>>>>> calls HHH(DDD)
HHH1(DDD) must NOT simulate itself simulating DDD because >>>>>>>>>>>> DDD DOES NOT
CALL HHH1(DDD)
At this point I think that you are a fucking liar.
As has been established elsewhere in this thread, you are no >>>>>>>>>>> position to
call anybody else here a liar. Glass house inhabitants, >>>>>>>>>>> throwing stones,
and all that.
And you used to distinguish yourself from other cranks by >>>>>>>>>>> sticking to
decorous language, and generally being courteous. Not any >>>>>>>>>>> more. That is
a most unwelcome change.
void DDD()
{
HHH(DDD);
return;
}
*That not one single person here*
(besides those that I invited from the C groups)
acknowledges that DDD simulated by HHH specifies
recursive simulation
cannot be reasonably attributed to anything besides
willful deception.
Foul mouthed lying on your part. It can be attributed to your >>>>>>>>> lack of
self awareness and lack of technical ability. Everybody here >>>>>>>>> but you can
see that.
It is not any lack of technical ability that determines
whether or not DDD correctly simulated by HHH can or
cannot reach its own "return" instruction final halt state.
It is a lack of technical ability on your part which is unable to >>>>>>> judge
whether such a correct simulation is possible. Everybody else >>>>>>> sees that
it is not, so further questions about it are non-sensical.
void DDD()
{
HHH(DDD);
return;
}
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
I have no idea why are are saying the something
that is trivial is impossible.
When HHH emulates: "push ebp" then HHH has correctly
emulated the first instruction of DDD correctly.
Simulating a few instructions does not make the whole simulation
correct.
Simulating N instructions correctly does mean that
these N instructions were simulated correctly.
But not that *ALL* of it was simulated correctly.
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
Neither was all of the instructions of the above
simulated correctly. When N instructions are simulated
correctly the repeating pattern emerges.
So?
void DDD()
{
HHH(DDD);
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)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
Nope, the first HHH simulated will abort the simulation before we getNot at all. My encoded HHH aborts as soon as it
here.
In comp.theory olcott <polcott333@gmail.com> wrote:
It is not any lack of technical ability that determines
whether or not DDD correctly simulated by HHH can or
cannot reach its own "return" instruction final halt state.
It is a lack of technical ability on your part which is unable to judge whether such a correct simulation is possible. Everybody else sees that
it is not, so further questions about it are non-sensical.
On 7/30/2025 7:07 PM, Richard Damon wrote:
On 7/30/25 7:46 PM, olcott wrote:Not at all. My encoded HHH aborts as soon as it
On 7/30/2025 6:26 PM, Richard Damon wrote:
On 7/30/25 10:12 AM, olcott wrote:
On 7/30/2025 4:09 AM, Fred. Zwarts wrote:
Op 30.jul.2025 om 07:00 schreef olcott:
On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/29/2025 9:35 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/29/2025 5:49 PM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/29/2025 2:39 AM, Fred. Zwarts wrote:
[ .... ]
As usual incorrect claims without evidence.
Your dreams are no verified facts. HHH aborts before the >>>>>>>>>>>>>> simulation
would reach the final halt state in a finite number of >>>>>>>>>>>>>> steps, as proven
by world-class simulators using exactly the same input. >>>>>>>>>>>>>> The infinity is
only in your dreams.
HHH(DDD) must simulate itself simulating DDD because DDD >>>>>>>>>>>>> calls HHH(DDD)
HHH1(DDD) must NOT simulate itself simulating DDD because >>>>>>>>>>>>> DDD DOES NOT
CALL HHH1(DDD)
At this point I think that you are a fucking liar.
As has been established elsewhere in this thread, you are no >>>>>>>>>>>> position to
call anybody else here a liar. Glass house inhabitants, >>>>>>>>>>>> throwing stones,
and all that.
And you used to distinguish yourself from other cranks by >>>>>>>>>>>> sticking to
decorous language, and generally being courteous. Not any >>>>>>>>>>>> more. That is
a most unwelcome change.
void DDD()
{
HHH(DDD);
return;
}
*That not one single person here*
(besides those that I invited from the C groups)
acknowledges that DDD simulated by HHH specifies
recursive simulation
cannot be reasonably attributed to anything besides
willful deception.
Foul mouthed lying on your part. It can be attributed to your >>>>>>>>>> lack of
self awareness and lack of technical ability. Everybody here >>>>>>>>>> but you can
see that.
It is not any lack of technical ability that determines
whether or not DDD correctly simulated by HHH can or
cannot reach its own "return" instruction final halt state.
It is a lack of technical ability on your part which is unable >>>>>>>> to judge
whether such a correct simulation is possible. Everybody else >>>>>>>> sees that
it is not, so further questions about it are non-sensical.
void DDD()
{
HHH(DDD);
return;
}
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
I have no idea why are are saying the something
that is trivial is impossible.
When HHH emulates: "push ebp" then HHH has correctly
emulated the first instruction of DDD correctly.
Simulating a few instructions does not make the whole simulation
correct.
Simulating N instructions correctly does mean that
these N instructions were simulated correctly.
But not that *ALL* of it was simulated correctly.
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
Neither was all of the instructions of the above
simulated correctly. When N instructions are simulated
correctly the repeating pattern emerges.
So?
void DDD()
{
HHH(DDD);
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)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
Nope, the first HHH simulated will abort the simulation before we get
here.
sees the pattern repeat once. It could have been
encoded to wait until it sees this same pattern
repeat ten times. That you keep pretending to never
see the pattern is quite dishonest. This might
cost your own soul. I would never risk this.
On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
void DDD()
{
HHH(DDD);
return;
}
It is not any lack of technical ability that determines
whether or not DDD correctly simulated by HHH can or
cannot reach its own "return" instruction final halt state.
It is a lack of technical ability on your part which is unable to judge
whether such a correct simulation is possible. Everybody else sees that
it is not, so further questions about it are non-sensical.
The notion of cooperative multi-tasking should be fully
understood by anyone with a computer science degree. If
most people here have much less than that then this may
be very difficult to understand.
https://en.wikipedia.org/wiki/Cooperative_multitasking
I wrote a time slicing x86 function for the original
MSDOS 3.0. This required intercepting the clock interrupt.
I did a lot of interrupt intercept programming back in
the 1980's.
I used this to create the Software Master program that
enabled one program to control another through the command
line interface. Much more powerful than a DOS batch file
because it could see the text on the display screen at
the B800:0000H fixed address. Then MS Windows came out making
Software Master Obsolete.
The x86utm operating system that I wrote uses cooperative
multi-tasking. It enables any C function to emulate the
x86 machine language of another other C function in debug
step mode.
Before it does this it creates a separate simulation
context having its own set of 16 virtual registers and
its own virtual stack.
_DDD()
[0000219e] 55 push ebp
[0000219f] 8bec mov ebp,esp
[000021a1] 689e210000 push 0000219e // push DDD
[000021a6] e843f4ffff call 000015ee // call HHH
[000021ab] 83c404 add esp,+04
[000021ae] 5d pop ebp
[000021af] c3 ret
Size in bytes:(0018) [000021af]
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.
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.
*The above is proven right here* https://github.com/plolcott/x86utm/blob/master/Halt7.c
Directly executed HHH emulates DDD that calls an emulated HHH(DDD)
that emulates another DDD instance that calls another HHH(DDD).
machine stack stack machine assembly
address address data code language
======== ======== ======== ========== ============= [000021be][00103872][00000000] 55 push ebp [000021bf][00103872][00000000] 8bec mov ebp,esp [000021c1][0010386e][0000219e] 689e210000 push 0000219e // push DDD [000021c6][0010386a][000021cb] e823f4ffff call 000015ee // call HHH
New slave_stack at:103916
Begin Local Halt Decider Simulation Execution Trace Stored at:11391e [0000219e][0011390e][00113912] 55 push ebp [0000219f][0011390e][00113912] 8bec mov ebp,esp [000021a1][0011390a][0000219e] 689e210000 push 0000219e // push DDD [000021a6][00113906][000021ab] e843f4ffff call 000015ee // call HHH
New slave_stack at:14e33e
[0000219e][0015e336][0015e33a] 55 push ebp [0000219f][0015e336][0015e33a] 8bec mov ebp,esp [000021a1][0015e332][0000219e] 689e210000 push 0000219e // push DDD [000021a6][0015e32e][000021ab] e843f4ffff call 000015ee // call HHH
176 pages of the full execution trace are shown here. https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
On 7/30/25 10:08 PM, olcott wrote:
On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
void DDD()
{
HHH(DDD);
return;
}
It is not any lack of technical ability that determines
whether or not DDD correctly simulated by HHH can or
cannot reach its own "return" instruction final halt state.
It is a lack of technical ability on your part which is unable to judge
whether such a correct simulation is possible. Everybody else sees that >>> it is not, so further questions about it are non-sensical.
The notion of cooperative multi-tasking should be fully
understood by anyone with a computer science degree. If
most people here have much less than that then this may
be very difficult to understand.
Sure, but you don't "trace" a program by going cross process.
https://en.wikipedia.org/wiki/Cooperative_multitasking
The x86utm operating system that I wrote uses cooperative
multi-tasking. It enables any C function to emulate the
x86 machine language of another other C function in debug
step mode.
So? What does that have to do with the correct simulation of one
specific program?
When simulating DDD, we need to look at each instruciton executed in the context of THAT PROCESS. That will watch every instruction of the HHH
that it calls and is thus part of that process.
We watch HHH doing the simulation, not the results of that simulation
Before it does this it creates a separate simulation
context having its own set of 16 virtual registers and
its own virtual stack.
Right, which isn't part of the program being simulated,
_DDD()
[0000219e] 55 push ebp
[0000219f] 8bec mov ebp,esp
[000021a1] 689e210000 push 0000219e // push DDD
[000021a6] e843f4ffff call 000015ee // call HHH
[000021ab] 83c404 add esp,+04
[000021ae] 5d pop ebp
[000021af] c3 ret
Size in bytes:(0018) [000021af]
Which isn't a program, and can't be simulated past the call instruction.
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.
When it call HHH, that HHH is PART OF THE PROCESS OF DDD.
Not something "new"
You don't understand what you are talking about, but just add fluff and smoke to hide your lies.
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.
Which we don't actually care about, what we care abput it the original process of DDD, which includes the HHH that it calls.
*The above is proven right here*
https://github.com/plolcott/x86utm/blob/master/Halt7.c
Directly executed HHH emulates DDD that calls an emulated HHH(DDD)
that emulates another DDD instance that calls another HHH(DDD).
And the only emulation that is the emulation of the input is that first emulation, NOT any of the other levels of emulation.
Sorry, you are just proving you don't understand the basics of what a program is.
Am Thu, 31 Jul 2025 00:55:18 -0500 schrieb olcott:
On 7/31/2025 12:46 AM, joes wrote:
Am Thu, 31 Jul 2025 00:40:17 -0500 schrieb olcott:
On 7/31/2025 12:36 AM, joes wrote:
Am Wed, 30 Jul 2025 20:00:34 -0500 schrieb olcott:
On 7/30/2025 7:07 PM, Richard Damon wrote:
On 7/30/25 7:46 PM, olcott wrote:
Excellent question! DDD is not a template that calls its own simulatorHow can the exact same unchanged sequence of machine code bytes beNo, you can't change the input depending on the simulator.They all use the exact same machine code otherwise that is cheating.Yes, exactly. I snipped it above to that.executed HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
Nope, the first HHH simulated will abort the simulation before we >>>>>>> get here.Not at all. My encoded HHH aborts as soon as it sees the pattern
repeat once.
It could have been encoded to wait until it sees this same pattern >>>>>> repeat ten times.Yes, it could. In which case it would only see 3 repetitions before
the simulated HHH aborts (incorrectly, because it still only waits
for 2 repetitions).
different than it is?
or whatever HHH refers to. It is a concrete program that calls your particular implementation which aborts after the second repetition.
If you then try to modify *the simulator* (not the name "HHH") you
must keep DDD fixed, including its version of HHH. Otherwise you are
not simulating the same program.
On 7/30/2025 4:09 AM, Fred. Zwarts wrote:
Op 30.jul.2025 om 07:00 schreef olcott:
On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/29/2025 9:35 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/29/2025 5:49 PM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/29/2025 2:39 AM, Fred. Zwarts wrote:
[ .... ]
As usual incorrect claims without evidence.
Your dreams are no verified facts. HHH aborts before the
simulation
would reach the final halt state in a finite number of steps, >>>>>>>>>> as proven
by world-class simulators using exactly the same input. The >>>>>>>>>> infinity is
only in your dreams.
HHH(DDD) must simulate itself simulating DDD because DDD calls >>>>>>>>> HHH(DDD)
HHH1(DDD) must NOT simulate itself simulating DDD because DDD >>>>>>>>> DOES NOT
CALL HHH1(DDD)
At this point I think that you are a fucking liar.
As has been established elsewhere in this thread, you are no
position to
call anybody else here a liar. Glass house inhabitants,
throwing stones,
and all that.
And you used to distinguish yourself from other cranks by
sticking to
decorous language, and generally being courteous. Not any more. >>>>>>>> That is
a most unwelcome change.
void DDD()
{
HHH(DDD);
return;
}
*That not one single person here*
(besides those that I invited from the C groups)
acknowledges that DDD simulated by HHH specifies
recursive simulation
cannot be reasonably attributed to anything besides
willful deception.
Foul mouthed lying on your part. It can be attributed to your
lack of
self awareness and lack of technical ability. Everybody here but >>>>>> you can
see that.
It is not any lack of technical ability that determines
whether or not DDD correctly simulated by HHH can or
cannot reach its own "return" instruction final halt state.
It is a lack of technical ability on your part which is unable to judge >>>> whether such a correct simulation is possible. Everybody else sees
that
it is not, so further questions about it are non-sensical.
void DDD()
{
HHH(DDD);
return;
}
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
I have no idea why are are saying the something
that is trivial is impossible.
When HHH emulates: "push ebp" then HHH has correctly
emulated the first instruction of DDD correctly.
Simulating a few instructions does not make the whole simulation correct.
Simulating N instructions correctly does mean that
these N instructions were simulated correctly.
In contrast, the failure to simulate a single instruction correctly,
makes the whole simulation incorrect.
In this case it is the failure to simulate the call instruction.
My code conclusively proves that HHH does simulate
itself simulating DDD. That you do not understand
this code well enough to understand that is less
than no rebuttal at all.
The simulation aborts at this point, where the semantics of the x86
language requires the execution of the next instruction.
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) It detects a non-terminating behavior pattern then it aborts its simulation and returns 0,
(b) Its simulated input reaches its simulated "return" statement then it returns 1.
My code conclusively proves that HHH does simulate itself
simulating DDD until any sufficiently competent person can
correctly determine a repeating pattern that cannot possibly
reach its own "return" statement final halt state even with
an infinite simulation.
That you do not understand this code well enough to
understand that is less than no rebuttal at all.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
When it does detect this pattern then it kills the
whole DDD process so that there is no stack unwinding.
; This premature abort, based on the incorrect assumption that a finite
recursion specifies non-halting, makes the whole simulation incorrect
and, what is worse, the conclusion of non-halting behaviour fails.
HHH uses exactly same process on this function.
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
as it does this function.
void DDD()
{
HHH(DDD);
return;
}
HHH has no idea that DDD is calling itself.
HHH just sees that DDD is calling the same function
with the same parameter twice in sequence,
just like
Infinite_Recursion().
Further irrelevant claims without evidence ignored.
Perhaps you have an ACM email address and don't
know very much about programming?
Op 30.jul.2025 om 16:12 schreef olcott:It sees recursive simulation that can never reach the halt state.
On 7/30/2025 4:09 AM, Fred. Zwarts wrote:
Simulating N instructions correctly does mean that
these N instructions were simulated correctly.
Nobody denies that, but it does not make te whole simulation correct.
In contrast, the failure to simulate a single instruction correctly,
makes the whole simulation incorrect.
In this case it is the failure to simulate the call instruction.
My code conclusively proves that HHH does simulate
itself simulating DDD. That you do not understand
this code well enough to understand that is less
than no rebuttal at all.
Incorrect claims, as usual.
I do understand it and in fact better that you do. You do not understand that the simulation is not correct when the simulation is not completed.
You also do not understand that a finite recursion does not imply non- halting.
The simulation aborts at this point, where the semantics of the x86
language requires the execution of the next instruction.
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) It detects a non-terminating behavior pattern then it aborts its
simulation and returns 0,
Incorrect. It aborts when it sees a finite recursion.
The programmer
forgot to cont the conditional branch instruction, so that it
incorrectly reports non-halting.
(b) Its simulated input reaches its simulated "return" statement then
it returns 1.
My code conclusively proves that HHH does simulate itself
simulating DDD until any sufficiently competent person can
correctly determine a repeating pattern that cannot possibly
reach its own "return" statement final halt state even with
an infinite simulation.
Incorrect repeated claim, as usual. Any competent person knows that a
finite recursion, or a finite repeating pattern, does not mean non- termination.
Better simulators also show that after the finite recursion, the final
halt state is reachable.
That HHH is unable to reach the final halt state, therefore, is a
failure of HHH.
That you do not understand this code well enough to
understand that is less than no rebuttal at all.
As usual, incorrect repeated claim, without any evidence.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
The HHH that is called by DDD in the simulation, is the HHH that aborts
and returns. So, the input for the simulation specifies a halting program. That HHH fails to see the whole specification, does not change the specification.
Your huge mistake is that you think that what HHH does not see, does not exist.
When it does detect this pattern then it kills the
whole DDD process so that there is no stack unwinding.
But there was no need to do so. Other simulators show that when the simulation is not killed, the final halt state is reached.
> This premature abort, based on the incorrect assumption that a finite >>> recursion specifies non-halting, makes the whole simulation incorrect
and, what is worse, the conclusion of non-halting behaviour fails.
HHH uses exactly same process on this function.
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
as it does this function.
Incorrect, it more like:
void Finite_Recursion (int N) {
if (N > 0) Finite_Recursion (N - 1);
printf ("Olcott thinks this is never printed.\n");
}
Because we know that HHH, also the simulated HHH, is programmed to abort after a few cycles.
void DDD()
{
HHH(DDD);
return;
}
HHH has no idea that DDD is calling itself.
Programs have no ideas. They do what is coded.
When you still want to think about ideas: DDD has no idea that HHH will simulate itself recursively. It expects HHH to return.
HHH just sees that DDD is calling the same function
with the same parameter twice in sequence,
but a good simulator would see that the internal state of HHH has been changed, which would influence the conditional branch instructions.
just like
Finite_Recursion, not like:
Infinite_Recursion().
Further irrelevant claims without evidence ignored.
Perhaps you have an ACM email address and don't
know very much about programming?
On 7/30/2025 9:26 PM, Richard Damon wrote:
On 7/30/25 10:08 PM, olcott wrote:
On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
void DDD()
{
HHH(DDD);
return;
}
It is not any lack of technical ability that determines
whether or not DDD correctly simulated by HHH can or
cannot reach its own "return" instruction final halt state.
It is a lack of technical ability on your part which is unable to judge >>>> whether such a correct simulation is possible. Everybody else sees
that
it is not, so further questions about it are non-sensical.
The notion of cooperative multi-tasking should be fully
understood by anyone with a computer science degree. If
most people here have much less than that then this may
be very difficult to understand.
Sure, but you don't "trace" a program by going cross process.
DDD and HHH retain the exact same machine addresses
thus can be traced across processes.
https://en.wikipedia.org/wiki/Cooperative_multitasking
<snip>
The x86utm operating system that I wrote uses cooperative
multi-tasking. It enables any C function to emulate the
x86 machine language of another other C function in debug
step mode.
So? What does that have to do with the correct simulation of one
specific program?
If people here have much less than a computer science
degree and have never heard of any kind of multi-tasking
that may lead them to believe that HHH cannot emulate
itself emulating DDD.
People cold honestly believe that this is impossible
entirely on the basis of their lack of sufficient
technical competence.
When simulating DDD, we need to look at each instruciton executed in
the context of THAT PROCESS. That will watch every instruction of the
HHH that it calls and is thus part of that process.
We watch HHH doing the simulation, not the results of that simulation
Right if you want to see the actual behavior of DDD
you must make sure to not look at this behavior because
that might mislead you into telling the truth.
Before it does this it creates a separate simulation
context having its own set of 16 virtual registers and
its own virtual stack.
Right, which isn't part of the program being simulated,
HHH is the master process of all processes.
DDD is the immediate slave process.
_DDD()
[0000219e] 55 push ebp
[0000219f] 8bec mov ebp,esp
[000021a1] 689e210000 push 0000219e // push DDD
[000021a6] e843f4ffff call 000015ee // call HHH
[000021ab] 83c404 add esp,+04
[000021ae] 5d pop ebp
[000021af] c3 ret
Size in bytes:(0018) [000021af]
Which isn't a program, and can't be simulated past the call instruction.
The recursive structure of DDD cannot be easily seen
when buried in hundreds of pages of extraneous detail.
So far not one person here could ever understand
one half of one page of text when given three years
to understand it.
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.
When it call HHH, that HHH is PART OF THE PROCESS OF DDD.
Not something "new"
When HHH emulates DDD it creates a new process context
allocating memory for this process context. The first
simulated HHH uses this same new process context.
You don't understand what you are talking about, but just add fluff
and smoke to hide your lies.
It that was true you could point to an actual mistake.
That ignorant people think that your own misconceptions
are my mistake is their mistake.
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.
Which we don't actually care about, what we care abput it the original
process of DDD, which includes the HHH that it calls.
We only care about whether the original input to
HHH(DDD) can possibly reach its own simulated final
halt state.
We cannot possibly get there while some people
(through their ignorance) honestly believe that HHH
cannot possibly emulate itself emulating DDD.
When this *is* understood then we understand why
DDD correctly simulated by HHH cannot possibly halt.
*The above is proven right here*
https://github.com/plolcott/x86utm/blob/master/Halt7.c
Directly executed HHH emulates DDD that calls an emulated HHH(DDD)
that emulates another DDD instance that calls another HHH(DDD).
And the only emulation that is the emulation of the input is that
first emulation, NOT any of the other levels of emulation.
*Counter-factual*
The executed HHH(DDD) emulates DDD and also emulates
another HHH in the same process context as this DDD.
This emulated HHH creates another process context and
emulates another DDD. This DDD calls another HHH(DDD)
in its same process context.
All of the above actually occurs in the fully operational code.
Sorry, you are just proving you don't understand the basics of what a
program is.
The notion of a program in C with global variables and such
is not what I am going for. That diverges from the Turing
model of computation.
If we merely examine all of the behavior that the input to
HHH(DDD) specifies it does specify exactly what I said above
in *Counter-factual*
The rest is merely you proving that you did not
understand the half page of text that you have
had three years to understand.
It is a lack of technical ability on your
part which is unable to judge whether such
a correct simulation is possible. Everybody
else sees that it is not, so further questions
about it are non-sensical.
On 7/30/25 11:38 PM, olcott wrote:
If people here have much less than a computer science
degree and have never heard of any kind of multi-tasking
that may lead them to believe that HHH cannot emulate
itself emulating DDD.
Who said that?
It is a lack of technical ability on your
part which is unable to judge whether such
a correct simulation is possible. Everybody
else sees that it is not, so further questions
about it are non-sensical.
Oh, and this multi-tasling system wzs very badly done, as it forces all
the code to use the same memory space. Maybe that is because your
experience was with older processors that couldn't handle themselves the seperate memory spacee. Note, the code of x86utm that you started with didn't require that the code being simulated be at the physical memory address that it represents, That limitation is something you added to
the system because you apparently don't understand the abstraction of virtual addresses.
When simulating DDD, we need to look at each instruciton executed in
the context of THAT PROCESS. That will watch every instruction of the
HHH that it calls and is thus part of that process.
We watch HHH doing the simulation, not the results of that simulation
Right if you want to see the actual behavior of DDD
you must make sure to not look at this behavior because
that might mislead you into telling the truth.
And that behavior is DEFINED to be what it does when RUN, or COMPLETELY simulted.
SInce that WILL HALT, DDD is HALTING, and saying anything else is just a lie.
That HHH doesn't simulate it to that point, is an error in HHH, not a problem with DDD.
Before it does this it creates a separate simulation
context having its own set of 16 virtual registers and
its own virtual stack.
Right, which isn't part of the program being simulated,
HHH is the master process of all processes.
DDD is the immediate slave process.
No it isn't.
You may be trying to implement it that way, but DDD is DEFINED as a
totally independent process, which HHH is trying to determine what it
will do by looking at its code.
_DDD()
[0000219e] 55 push ebp
[0000219f] 8bec mov ebp,esp
[000021a1] 689e210000 push 0000219e // push DDD
[000021a6] e843f4ffff call 000015ee // call HHH
[000021ab] 83c404 add esp,+04
[000021ae] 5d pop ebp
[000021af] c3 ret
Size in bytes:(0018) [000021af]
Which isn't a program, and can't be simulated past the call instruction. >>>
The recursive structure of DDD cannot be easily seen
when buried in hundreds of pages of extraneous detail.
Thats YOUR problem.
LYING about what happens, just shows that you are a liar.
So far not one person here could ever understand
one half of one page of text when given three years
to understand it.
No, the one person here that doesn't understand that trace is YOU.
Because you keep on lying to yourself about what you are doing.
On 7/30/25 9:00 PM, olcott wrote:
On 7/30/2025 7:07 PM, Richard Damon wrote:
On 7/30/25 7:46 PM, olcott wrote:Not at all. My encoded HHH aborts as soon as it
On 7/30/2025 6:26 PM, Richard Damon wrote:
On 7/30/25 10:12 AM, olcott wrote:
On 7/30/2025 4:09 AM, Fred. Zwarts wrote:
Op 30.jul.2025 om 07:00 schreef olcott:
On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/29/2025 9:35 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/29/2025 5:49 PM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>> On 7/29/2025 2:39 AM, Fred. Zwarts wrote:
[ .... ]
As usual incorrect claims without evidence.
Your dreams are no verified facts. HHH aborts before the >>>>>>>>>>>>>>> simulation
would reach the final halt state in a finite number of >>>>>>>>>>>>>>> steps, as proven
by world-class simulators using exactly the same input. >>>>>>>>>>>>>>> The infinity is
only in your dreams.
HHH(DDD) must simulate itself simulating DDD because DDD >>>>>>>>>>>>>> calls HHH(DDD)
HHH1(DDD) must NOT simulate itself simulating DDD because >>>>>>>>>>>>>> DDD DOES NOT
CALL HHH1(DDD)
At this point I think that you are a fucking liar.
As has been established elsewhere in this thread, you are >>>>>>>>>>>>> no position to
call anybody else here a liar. Glass house inhabitants, >>>>>>>>>>>>> throwing stones,
and all that.
And you used to distinguish yourself from other cranks by >>>>>>>>>>>>> sticking to
decorous language, and generally being courteous. Not any >>>>>>>>>>>>> more. That is
a most unwelcome change.
void DDD()
{
HHH(DDD);
return;
}
*That not one single person here*
(besides those that I invited from the C groups)
acknowledges that DDD simulated by HHH specifies
recursive simulation
cannot be reasonably attributed to anything besides
willful deception.
Foul mouthed lying on your part. It can be attributed to >>>>>>>>>>> your lack of
self awareness and lack of technical ability. Everybody here >>>>>>>>>>> but you can
see that.
It is not any lack of technical ability that determinesIt is a lack of technical ability on your part which is unable >>>>>>>>> to judge
whether or not DDD correctly simulated by HHH can or
cannot reach its own "return" instruction final halt state. >>>>>>>>>
whether such a correct simulation is possible. Everybody else >>>>>>>>> sees that
it is not, so further questions about it are non-sensical.
void DDD()
{
HHH(DDD);
return;
}
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
I have no idea why are are saying the something
that is trivial is impossible.
When HHH emulates: "push ebp" then HHH has correctly
emulated the first instruction of DDD correctly.
Simulating a few instructions does not make the whole simulation >>>>>>> correct.
Simulating N instructions correctly does mean that
these N instructions were simulated correctly.
But not that *ALL* of it was simulated correctly.
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
Neither was all of the instructions of the above
simulated correctly. When N instructions are simulated
correctly the repeating pattern emerges.
So?
void DDD()
{
HHH(DDD);
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)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
Nope, the first HHH simulated will abort the simulation before we get
here.
sees the pattern repeat once. It could have been
encoded to wait until it sees this same pattern
repeat ten times. That you keep pretending to never
see the pattern is quite dishonest. This might
cost your own soul. I would never risk this.
Right, so you LIED about what happens.
And the first simulated HHH, when correctly (and thus completely
simulated) WILL abort when I said.
Again, all you are doing is proving your logic is based on LIES
On 7/30/25 11:38 PM, olcott wrote:
On 7/30/2025 9:26 PM, Richard Damon wrote:
On 7/30/25 10:08 PM, olcott wrote:DDD and HHH retain the exact same machine addresses thus can be traced
On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
void DDD()
{
HHH(DDD);
return;
}
The notion of cooperative multi-tasking should be fully understood byIt is not any lack of technical ability that determines whether or >>>>>> not DDD correctly simulated by HHH can or cannot reach its own
"return" instruction final halt state.
It is a lack of technical ability on your part which is unable to
judge whether such a correct simulation is possible. Everybody else >>>>> sees that it is not, so further questions about it are non-sensical. >>>>>
anyone with a computer science degree. If most people here have much
less than that then this may be very difficult to understand.
Sure, but you don't "trace" a program by going cross process.
across processes.
Doesn't mean that is what you are to do.
HHH is supposed to simulate DDD, and all of DDD which include HHH, to determine what that program will do.
Since HHH does a CONDINTIONAL simulation of its input, it is important
to keep track of that conditionality. Something you forget when you stop looking at the trace of it, and only at the trace of what it is doing, something that has no bearing on the behavior of the simulated HHH.
<snip>https://en.wikipedia.org/wiki/Cooperative_multitasking
So, you admit that you talking about multi-tasking was irrelevent.
If people here have much less than a computer science degree and have
The x86utm operating system that I wrote uses cooperative
multi-tasking. It enables any C function to emulate the x86 machine
language of another other C function in debug step mode.
So? What does that have to do with the correct simulation of one
specific program?
never heard of any kind of multi-tasking that may lead them to believe
that HHH cannot emulate itself emulating DDD.
Who said that?
The problem is the question is what the first level DDD does, which has
code, from HHH, to CONDITIONALLY simulate a copy of itself.
Since that code will abort the simulation if it thinks it will not be halting,
People cold honestly believe that this is impossible entirely on the
basis of their lack of sufficient technical competence.
No, people see that *YOUR* implementation gets the wrong answer, because
you assume a wrong criteria\.
Oh, and this multi-tasling system wzs very badly done, as it forces all
the code to use the same memory space. Maybe that is because your
experience was with older processors that couldn't handle themselves the seperate memory spacee. Note, the code of x86utm that you started with
didn't require that the code being simulated be at the physical memory address that it represents, That limitation is something you added to
the system because you apparently don't understand the abstraction of
virtual addresses.
When simulating DDD, we need to look at each instruciton executed inRight if you want to see the actual behavior of DDD you must make sure
the context of THAT PROCESS. That will watch every instruction of the
HHH that it calls and is thus part of that process.
We watch HHH doing the simulation, not the results of that simulation
to not look at this behavior because that might mislead you into
telling the truth.
And that behavior is DEFINED to be what it does when RUN, or COMPLETELY simulted.
SInce that WILL HALT, DDD is HALTING, and saying anything else is just a
lie.
That HHH doesn't simulate it to that point, is an error in HHH, not a
problem with DDD.
HHH is the master process of all processes.Before it does this it creates a separate simulation context having
its own set of 16 virtual registers and its own virtual stack.
Right, which isn't part of the program being simulated,
DDD is the immediate slave process.
No it isn't.
You may be trying to implement it that way, but DDD is DEFINED as a
totally independent process, which HHH is trying to determine what it
will do by looking at its code.
The recursive structure of DDD cannot be easily seen when buried in_DDD()
[0000219e] 55 push ebp [0000219f] 8bec mov
ebp,esp [000021a1] 689e210000 push 0000219e // push DDD
[000021a6] e843f4ffff call 000015ee // call HHH [000021ab]
83c404 add esp,+04 [000021ae] 5d pop ebp
[000021af] c3 ret Size in bytes:(0018) [000021af] >>>
Which isn't a program, and can't be simulated past the call
instruction.
hundreds of pages of extraneous detail.
Thats YOUR problem.
LYING about what happens, just shows that you are a liar.
So far not one person here could ever understand one half of one page
of text when given three years to understand it.
No, the one person here that doesn't understand that trace is YOU.
Because you keep on lying to yourself about what you are doing.
On 7/30/25 11:38 PM, olcott wrote:
So far not one person here could ever understand
one half of one page of text when given three years
to understand it.
No, the one person here that doesn't understand that trace is YOU.
On 7/30/2025 9:18 PM, Richard Damon wrote:
On 7/30/25 9:00 PM, olcott wrote:
On 7/30/2025 7:07 PM, Richard Damon wrote:
On 7/30/25 7:46 PM, olcott wrote:Not at all. My encoded HHH aborts as soon as it
On 7/30/2025 6:26 PM, Richard Damon wrote:
On 7/30/25 10:12 AM, olcott wrote:
On 7/30/2025 4:09 AM, Fred. Zwarts wrote:
Op 30.jul.2025 om 07:00 schreef olcott:
On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/29/2025 9:35 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/29/2025 5:49 PM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>> On 7/29/2025 2:39 AM, Fred. Zwarts wrote:
[ .... ]
As usual incorrect claims without evidence.
Your dreams are no verified facts. HHH aborts before the >>>>>>>>>>>>>>>> simulation
would reach the final halt state in a finite number of >>>>>>>>>>>>>>>> steps, as proven
by world-class simulators using exactly the same input. >>>>>>>>>>>>>>>> The infinity is
only in your dreams.
HHH(DDD) must simulate itself simulating DDD because DDD >>>>>>>>>>>>>>> calls HHH(DDD)
HHH1(DDD) must NOT simulate itself simulating DDD because >>>>>>>>>>>>>>> DDD DOES NOT
CALL HHH1(DDD)
At this point I think that you are a fucking liar.
As has been established elsewhere in this thread, you are >>>>>>>>>>>>>> no position to
call anybody else here a liar. Glass house inhabitants, >>>>>>>>>>>>>> throwing stones,
and all that.
And you used to distinguish yourself from other cranks by >>>>>>>>>>>>>> sticking to
decorous language, and generally being courteous. Not any >>>>>>>>>>>>>> more. That is
a most unwelcome change.
void DDD()
{
HHH(DDD);
return;
}
*That not one single person here*
(besides those that I invited from the C groups)
acknowledges that DDD simulated by HHH specifies
recursive simulation
cannot be reasonably attributed to anything besides
willful deception.
Foul mouthed lying on your part. It can be attributed to >>>>>>>>>>>> your lack of
self awareness and lack of technical ability. Everybody >>>>>>>>>>>> here but you can
see that.
It is not any lack of technical ability that determinesIt is a lack of technical ability on your part which is unable >>>>>>>>>> to judge
whether or not DDD correctly simulated by HHH can or
cannot reach its own "return" instruction final halt state. >>>>>>>>>>
whether such a correct simulation is possible. Everybody else >>>>>>>>>> sees that
it is not, so further questions about it are non-sensical. >>>>>>>>>>
void DDD()
{
HHH(DDD);
return;
}
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
I have no idea why are are saying the something
that is trivial is impossible.
When HHH emulates: "push ebp" then HHH has correctly
emulated the first instruction of DDD correctly.
Simulating a few instructions does not make the whole simulation >>>>>>>> correct.
Simulating N instructions correctly does mean that
these N instructions were simulated correctly.
But not that *ALL* of it was simulated correctly.
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
Neither was all of the instructions of the above
simulated correctly. When N instructions are simulated
correctly the repeating pattern emerges.
So?
void DDD()
{
HHH(DDD);
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)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
Nope, the first HHH simulated will abort the simulation before we
get here.
sees the pattern repeat once. It could have been
encoded to wait until it sees this same pattern
repeat ten times. That you keep pretending to never
see the pattern is quite dishonest. This might
cost your own soul. I would never risk this.
Right, so you LIED about what happens.
I had to emphasize the repeating pattern enough
so that you could see it. When I only show you
a little bit of it you pretend that it does not exist.
And the first simulated HHH, when correctly (and thus completely
simulated) WILL abort when I said.
Again, all you are doing is proving your logic is based on LIES
That you call me a liar may by itself condemn you to Hell.
On 7/31/25 12:15 PM, olcott wrote:
On 7/30/2025 9:18 PM, Richard Damon wrote:
On 7/30/25 9:00 PM, olcott wrote:
On 7/30/2025 7:07 PM, Richard Damon wrote:
On 7/30/25 7:46 PM, olcott wrote:Not at all. My encoded HHH aborts as soon as it
On 7/30/2025 6:26 PM, Richard Damon wrote:
On 7/30/25 10:12 AM, olcott wrote:
On 7/30/2025 4:09 AM, Fred. Zwarts wrote:
Op 30.jul.2025 om 07:00 schreef olcott:
On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/29/2025 9:35 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/29/2025 5:49 PM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>> On 7/29/2025 2:39 AM, Fred. Zwarts wrote:
[ .... ]
As usual incorrect claims without evidence.
Your dreams are no verified facts. HHH aborts before >>>>>>>>>>>>>>>>> the simulation
would reach the final halt state in a finite number of >>>>>>>>>>>>>>>>> steps, as proven
by world-class simulators using exactly the same input. >>>>>>>>>>>>>>>>> The infinity is
only in your dreams.
HHH(DDD) must simulate itself simulating DDD because DDD >>>>>>>>>>>>>>>> calls HHH(DDD)
HHH1(DDD) must NOT simulate itself simulating DDD >>>>>>>>>>>>>>>> because DDD DOES NOT
CALL HHH1(DDD)
At this point I think that you are a fucking liar.
As has been established elsewhere in this thread, you are >>>>>>>>>>>>>>> no position to
call anybody else here a liar. Glass house inhabitants, >>>>>>>>>>>>>>> throwing stones,
and all that.
And you used to distinguish yourself from other cranks by >>>>>>>>>>>>>>> sticking to
decorous language, and generally being courteous. Not >>>>>>>>>>>>>>> any more. That is
a most unwelcome change.
void DDD()
{
HHH(DDD);
return;
}
*That not one single person here*
(besides those that I invited from the C groups)
acknowledges that DDD simulated by HHH specifies
recursive simulation
cannot be reasonably attributed to anything besides >>>>>>>>>>>>>> willful deception.
Foul mouthed lying on your part. It can be attributed to >>>>>>>>>>>>> your lack of
self awareness and lack of technical ability. Everybody >>>>>>>>>>>>> here but you can
see that.
It is not any lack of technical ability that determines >>>>>>>>>>>> whether or not DDD correctly simulated by HHH can orIt is a lack of technical ability on your part which is >>>>>>>>>>> unable to judge
cannot reach its own "return" instruction final halt state. >>>>>>>>>>>
whether such a correct simulation is possible. Everybody >>>>>>>>>>> else sees that
it is not, so further questions about it are non-sensical. >>>>>>>>>>>
void DDD()
{
HHH(DDD);
return;
}
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
I have no idea why are are saying the something
that is trivial is impossible.
When HHH emulates: "push ebp" then HHH has correctly
emulated the first instruction of DDD correctly.
Simulating a few instructions does not make the whole
simulation correct.
Simulating N instructions correctly does mean that
these N instructions were simulated correctly.
But not that *ALL* of it was simulated correctly.
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
Neither was all of the instructions of the above
simulated correctly. When N instructions are simulated
correctly the repeating pattern emerges.
So?
void DDD()
{
HHH(DDD);
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)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
Nope, the first HHH simulated will abort the simulation before we
get here.
sees the pattern repeat once. It could have been
encoded to wait until it sees this same pattern
repeat ten times. That you keep pretending to never
see the pattern is quite dishonest. This might
cost your own soul. I would never risk this.
Right, so you LIED about what happens.
I had to emphasize the repeating pattern enough
so that you could see it. When I only show you
a little bit of it you pretend that it does not exist.
In other words, you are just admitting that you think LYING is
appropriate when making an arguement.
*We are only addressing this one point in this thread*
On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
It is a lack of technical ability on your
part which is unable to judge whether such
a correct simulation is possible. Everybody
else sees that it is not, so further questions
about it are 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.
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.
void DDD()
{
HHH(DDD);
return;
}
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
On 7/31/2025 6:32 AM, Richard Damon wrote:
On 7/30/25 11:38 PM, olcott wrote:
If people here have much less than a computer science
degree and have never heard of any kind of multi-tasking
that may lead them to believe that HHH cannot emulate
itself emulating DDD.
Who said that?
On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
It is a lack of technical ability on your
part which is unable to judge whether such
a correct simulation is possible. Everybody
else sees that it is not, so further questions
about it are non-sensical.
Oh, and this multi-tasling system wzs very badly done, as it forces
all the code to use the same memory space. Maybe that is because your
experience was with older processors that couldn't handle themselves
the seperate memory spacee. Note, the code of x86utm that you started
with didn't require that the code being simulated be at the physical
memory address that it represents, That limitation is something you
added to the system because you apparently don't understand the
abstraction of virtual addresses.
The whole point is to show that HHH does emulate itself
emulating DDD because so many people believe this is
impossible. *All of the above critique is off-topic*
*It merely distracts attention away from the point*
When simulating DDD, we need to look at each instruciton executed in
the context of THAT PROCESS. That will watch every instruction of
the HHH that it calls and is thus part of that process.
We watch HHH doing the simulation, not the results of that simulation
Right if you want to see the actual behavior of DDD
you must make sure to not look at this behavior because
that might mislead you into telling the truth.
And that behavior is DEFINED to be what it does when RUN, or
COMPLETELY simulted.
*Not at all you never get this correctly even*
*when you have been corrected hundreds of times*
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) It detects a non-terminating behavior pattern then it aborts its simulation and returns 0,
(b) Its simulated input reaches its simulated "return" statement then it returns 1.
SInce that WILL HALT, DDD is HALTING, and saying anything else is just
a lie.
*Not at all you never get this correctly even*
*when you have been corrected hundreds of times*
We are only measuring whether or not DDD correctly
simulated by HHH can possibly reach its own simulated
final halt state.
That HHH doesn't simulate it to that point, is an error in HHH, not a
problem with DDD.
That merely shows that you do not understand what
is actually occurring.
void DDD()
{
HHH(DDD);
return;
}
*When HHH simulates ten instructions of DDD it goes like this*
Executed HHH(DDD) simulates DDD that calls HHH(DDD)
Simulated HHH(DDD) simulates DDD that calls HHH(DDD)
Simulated HHH(DDD) simulates DDD that calls HHH(DDD)
Simulated HHH(DDD) simulates DDD that calls HHH(DDD)
Simulated HHH(DDD) simulates DDD that calls HHH(DDD)
Simulated HHH(DDD) simulates DDD that calls HHH(DDD)
Simulated HHH(DDD) simulates DDD that calls HHH(DDD)
Simulated HHH(DDD) simulates DDD that calls HHH(DDD)
Simulated HHH(DDD) simulates DDD that calls HHH(DDD)
Simulated HHH(DDD) simulates DDD that calls HHH(DDD)
Before it does this it creates a separate simulation
context having its own set of 16 virtual registers and
its own virtual stack.
Right, which isn't part of the program being simulated,
HHH is the master process of all processes.
DDD is the immediate slave process.
No it isn't.
You may be trying to implement it that way, but DDD is DEFINED as a
totally independent process, which HHH is trying to determine what it
will do by looking at its code.
HHH(DDD) the slave DDD is not a totally independent process
it requires HHH to pump its process at each of its instructions.
_DDD()
[0000219e] 55 push ebp
[0000219f] 8bec mov ebp,esp
[000021a1] 689e210000 push 0000219e // push DDD
[000021a6] e843f4ffff call 000015ee // call HHH
[000021ab] 83c404 add esp,+04
[000021ae] 5d pop ebp
[000021af] c3 ret
Size in bytes:(0018) [000021af]
Which isn't a program, and can't be simulated past the call
instruction.
The recursive structure of DDD cannot be easily seen
when buried in hundreds of pages of extraneous detail.
Thats YOUR problem.
It has always been your mistake that I have corrected
many many times that you believe that HHH and DDD are
not in the same global block of memory of Halt7.obj.
LYING about what happens, just shows that you are a liar.
No this is actually a case of your own dementia.
When I correct your false assumptions hundreds of
times at some point you should remember that I
corrected you at least once.
*Its either dementia or persistent dishonesty*
So far not one person here could ever understand
one half of one page of text when given three years
to understand it.
No, the one person here that doesn't understand that trace is YOU.
Because you keep on lying to yourself about what you are doing.
That your dementia causes you to always forget my corrections
to your false assumptions is not any mistake on my part.
People that fully understand cooperative multi-taking will
understand that I am correct.
*It is comprehension of this that is the point of this thread*
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.
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.
On 7/31/2025 6:32 AM, Richard Damon wrote:
On 7/30/25 11:38 PM, olcott wrote:
So far not one person here could ever understand
one half of one page of text when given three years
to understand it.
No, the one person here that doesn't understand that trace is YOU.
*That you keep disagreeing with this verified fact*
*does not count as any rebuttal at all*
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.
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.
On 7/31/25 11:50 AM, olcott wrote:
*We are only addressing this one point in this thread*
On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
It is a lack of technical ability on your
part which is unable to judge whether such
a correct simulation is possible. Everybody
else sees that it is not, so further questions
about it are 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.
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.
On 7/31/2025 6:41 PM, Richard Damon wrote:
On 7/31/25 12:15 PM, olcott wrote:
On 7/30/2025 9:18 PM, Richard Damon wrote:
On 7/30/25 9:00 PM, olcott wrote:
On 7/30/2025 7:07 PM, Richard Damon wrote:
On 7/30/25 7:46 PM, olcott wrote:Not at all. My encoded HHH aborts as soon as it
On 7/30/2025 6:26 PM, Richard Damon wrote:
On 7/30/25 10:12 AM, olcott wrote:
On 7/30/2025 4:09 AM, Fred. Zwarts wrote:
Op 30.jul.2025 om 07:00 schreef olcott:
On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/29/2025 9:35 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 7/29/2025 5:49 PM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>> On 7/29/2025 2:39 AM, Fred. Zwarts wrote:
[ .... ]
As usual incorrect claims without evidence. >>>>>>>>>>>>>>>>>> Your dreams are no verified facts. HHH aborts before >>>>>>>>>>>>>>>>>> the simulation
would reach the final halt state in a finite number of >>>>>>>>>>>>>>>>>> steps, as proven
by world-class simulators using exactly the same >>>>>>>>>>>>>>>>>> input. The infinity is
only in your dreams.
HHH(DDD) must simulate itself simulating DDD because >>>>>>>>>>>>>>>>> DDD calls HHH(DDD)
HHH1(DDD) must NOT simulate itself simulating DDD >>>>>>>>>>>>>>>>> because DDD DOES NOT
CALL HHH1(DDD)
At this point I think that you are a fucking liar. >>>>>>>>>>>>As has been established elsewhere in this thread, you >>>>>>>>>>>>>>>> are no position to
call anybody else here a liar. Glass house inhabitants, >>>>>>>>>>>>>>>> throwing stones,
and all that.
And you used to distinguish yourself from other cranks >>>>>>>>>>>>>>>> by sticking to
decorous language, and generally being courteous. Not >>>>>>>>>>>>>>>> any more. That is
a most unwelcome change.
void DDD()
{
HHH(DDD);
return;
}
*That not one single person here*
(besides those that I invited from the C groups) >>>>>>>>>>>>>>> acknowledges that DDD simulated by HHH specifies >>>>>>>>>>>>>>> recursive simulation
cannot be reasonably attributed to anything besides >>>>>>>>>>>>>>> willful deception.
Foul mouthed lying on your part. It can be attributed to >>>>>>>>>>>>>> your lack of
self awareness and lack of technical ability. Everybody >>>>>>>>>>>>>> here but you can
see that.
It is not any lack of technical ability that determines >>>>>>>>>>>>> whether or not DDD correctly simulated by HHH can or >>>>>>>>>>>>> cannot reach its own "return" instruction final halt state. >>>>>>>>>>>>It is a lack of technical ability on your part which is >>>>>>>>>>>> unable to judge
whether such a correct simulation is possible. Everybody >>>>>>>>>>>> else sees that
it is not, so further questions about it are non-sensical. >>>>>>>>>>>>
void DDD()
{
HHH(DDD);
return;
}
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
I have no idea why are are saying the something
that is trivial is impossible.
When HHH emulates: "push ebp" then HHH has correctly
emulated the first instruction of DDD correctly.
Simulating a few instructions does not make the whole
simulation correct.
Simulating N instructions correctly does mean that
these N instructions were simulated correctly.
But not that *ALL* of it was simulated correctly.
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
Neither was all of the instructions of the above
simulated correctly. When N instructions are simulated
correctly the repeating pattern emerges.
So?
void DDD()
{
HHH(DDD);
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)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
Nope, the first HHH simulated will abort the simulation before we >>>>>> get here.
sees the pattern repeat once. It could have been
encoded to wait until it sees this same pattern
repeat ten times. That you keep pretending to never
see the pattern is quite dishonest. This might
cost your own soul. I would never risk this.
Right, so you LIED about what happens.
I had to emphasize the repeating pattern enough
so that you could see it. When I only show you
a little bit of it you pretend that it does not exist.
In other words, you are just admitting that you think LYING is
appropriate when making an arguement.
Of every HHH that can possibly exist one of them does
not stop simulating until after ten recursive simulations.
*That you cannot possibly imagine this DOES NOT MAKE ME A LIAR*
On 7/31/2025 7:07 PM, Richard Damon wrote:
On 7/31/25 11:50 AM, olcott wrote:
*We are only addressing this one point in this thread*
On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
It is a lack of technical ability on your
part which is unable to judge whether such
a correct simulation is possible. Everybody
else sees that it is not, so further questions
about it are 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.
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. Do you understand self-recursion?
What is the classic example of self-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.
On 7/31/25 8:18 PM, olcott wrote:It is an infinite set with every HHH/DDD pair having
On 7/31/2025 7:07 PM, Richard Damon wrote:
On 7/31/25 11:50 AM, olcott wrote:
*We are only addressing this one point in this thread*
On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
It is a lack of technical ability on your
part which is unable to judge whether such
a correct simulation is possible. Everybody
else sees that it is not, so further questions
about it are 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.
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*
Of course it is,
The pattern can't be non-halting if it occurs in a halting program.
Recursive simulation is only a little more difficult
than self recursion. Do you understand self-recursion?
What is the classic example of self-recursion?
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,
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/29/2025 9:35 PM, Alan Mackenzie wrote:
It is not any lack of technical ability that determines
whether or not DDD correctly simulated by HHH can or
cannot reach its own "return" instruction final halt state.
It is a lack of technical ability on your part which is unable to judge whether such a correct simulation is possible. Everybody else sees that
it is not, so further questions about it are non-sensical.
On 7/31/2025 2:20 AM, Fred. Zwarts wrote:
Op 30.jul.2025 om 16:12 schreef olcott:It sees recursive simulation that can never reach the halt state.
On 7/30/2025 4:09 AM, Fred. Zwarts wrote:
Simulating N instructions correctly does mean that
these N instructions were simulated correctly.
Nobody denies that, but it does not make te whole simulation correct.
In contrast, the failure to simulate a single instruction correctly,
makes the whole simulation incorrect.
In this case it is the failure to simulate the call instruction.
My code conclusively proves that HHH does simulate
itself simulating DDD. That you do not understand
this code well enough to understand that is less
than no rebuttal at all.
Incorrect claims, as usual.
I do understand it and in fact better that you do. You do not
understand that the simulation is not correct when the simulation is
not completed.
You also do not understand that a finite recursion does not imply non-
halting.
The simulation aborts at this point, where the semantics of the x86
language requires the execution of the next instruction.
Simulating Termination Analyzer HHH correctly simulates its input until: >>> (a) It detects a non-terminating behavior pattern then it aborts its
simulation and returns 0,
Incorrect. It aborts when it sees a finite recursion.
The programmer forgot to count the conditional branch instruction, so
that it incorrectly reports non-halting.
(b) Its simulated input reaches its simulated "return" statement then
it returns 1.
My code conclusively proves that HHH does simulate itself
simulating DDD until any sufficiently competent person can
correctly determine a repeating pattern that cannot possibly
reach its own "return" statement final halt state even with
an infinite simulation.
Incorrect repeated claim, as usual. Any competent person knows that a
finite recursion, or a finite repeating pattern, does not mean non-
termination.
Better simulators also show that after the finite recursion, the final
halt state is reachable.
That HHH is unable to reach the final halt state, therefore, is a
failure of HHH.
That you do not understand this code well enough to
understand that is less than no rebuttal at all.
As usual, incorrect repeated claim, without any evidence.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
The HHH that is called by DDD in the simulation, is the HHH that
aborts and returns. So, the input for the simulation specifies a
halting program.
That HHH fails to see the whole specification, does not change the
specification.
Your huge mistake is that you think that what HHH does not see, does
not exist.
When it does detect this pattern then it kills the
whole DDD process so that there is no stack unwinding.
But there was no need to do so. Other simulators show that when the
simulation is not killed, the final halt state is reached.
> This premature abort, based on the incorrect assumption that a
finite
recursion specifies non-halting, makes the whole simulation
incorrect and, what is worse, the conclusion of non-halting
behaviour fails.
HHH uses exactly same process on this function.
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
as it does this function.
Incorrect, it more like:
void Finite_Recursion (int N) {
if (N > 0) Finite_Recursion (N - 1);
printf ("Olcott thinks this is never printed.\n");
}
Because we know that HHH, also the simulated HHH, is programmed to
abort after a few cycles.
void DDD()
{
HHH(DDD);
return;
}
HHH has no idea that DDD is calling itself.
Programs have no ideas. They do what is coded.
When you still want to think about ideas: DDD has no idea that HHH
will simulate itself recursively. It expects HHH to return.
HHH just sees that DDD is calling the same function
with the same parameter twice in sequence,
but a good simulator would see that the internal state of HHH has been
changed, which would influence the conditional branch instructions.
just like
Finite_Recursion, not like:
Infinite_Recursion().
Further irrelevant claims without evidence ignored.
Perhaps you have an ACM email address and don't
know very much about programming?
On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
In comp.theory olcott <polcott333@gmail.com> wrote:
On 7/29/2025 9:35 PM, Alan Mackenzie wrote:
It is not any lack of technical ability that determines
whether or not DDD correctly simulated by HHH can or
cannot reach its own "return" instruction final halt state.
It is a lack of technical ability on your part which is unable to judge
whether such a correct simulation is possible. Everybody else sees that
it is not, so further questions about it are non-sensical.
void DDD()
{
HHH(DDD);
return;
}
Anyone with a bachelor's degree in computer science
would understand the notion of multi-tasking. This
is not the sort of trivial detail that would be
forgotten.
The way that HHH does simulate an instance of DDD
and then an instance of itself simulating another
instance of DDD is cooperative multi-tasking.
Universal Turing Machine (UTM) having the x86
language as its Machine description language. https://github.com/plolcott/x86utm
HHH calls the x86utm to create a separate process
context with 16 virtual registers and a virtual
stack for DDD. HHH emulates DDD and an instance
of itself in this same process context.
That anyone would say this is impossible would
mean that their knowledge of computer science
is much less than anyone with a Bachelor's degree
in computer science.
On 7/31/2025 7:37 PM, Richard Damon wrote:
On 7/31/25 8:18 PM, olcott wrote:It is an infinite set with every HHH/DDD pair having
On 7/31/2025 7:07 PM, Richard Damon wrote:
On 7/31/25 11:50 AM, olcott wrote:
*We are only addressing this one point in this thread*
On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
It is a lack of technical ability on your
part which is unable to judge whether such
a correct simulation is possible. Everybody
else sees that it is not, so further questions
about it are 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.
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*
Of course it is,
The pattern can't be non-halting if it occurs in a halting program.
Recursive simulation is only a little more difficult
than self recursion. Do you understand self-recursion?
What is the classic example of self-recursion?
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,
the same property that each DDD cannot possibly halt.
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:And that separate proccess, if left unaborted, would halt. But HHH
; It is a lack of technical ability on your part which is unable to >>>> > judge whether such a correct simulation is possible. EverybodyHHH emulates DDD in a separate process context. When this DDD calls
; else sees that it is not, so further questions about it are
; non-sensical.
HHH(DDD) the original HHH emulates this HHH in the DDD process
context.
gives up and aborts it, so the process is Halting, not non-halting.
And HHH cannot simulate itself to its undeniable halting state.
*No not at all. Not in the least little bit* Recursive simulation isThis emulated HHH creates yet another process context to emulate itsBut the pattern isn't non-halting by the fact that DDD is shown to be
own DDD. When this DDD calls yet another HHH(DDD) this provides enough >>>> execution trace that the repeating pattern can be seen.
halting.
only a little more difficult than self recursion.
DDD halts if it weren't aborted.
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.
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.
It is an infinite set with every HHH/DDD pair having the same propertyWhen N instructions of DDD are correctly emulated by every HHH thatWrong, your problem is you forget that all those DDD are different,
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.
that each DDD cannot possibly halt.
Sure, but what about different HHH_n's simulating the same DDD?
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:And that separate proccess, if left unaborted, would halt. But HHH
> It is a lack of technical ability on your part which is unable to >>>>> > judge whether such a correct simulation is possible. Everybody >>>>> > else sees that it is not, so further questions about it are
> 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.
gives up and aborts it, so the process is Halting, not non-halting.
And HHH cannot simulate itself to its undeniable halting state.
*No not at all. Not in the least little bit* Recursive simulation isThis 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.
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.
(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.
(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.
void DDD()
{
HHH(DDD);
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
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.
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.
It is an infinite set with every HHH/DDD pair having the same propertyWhen N instructions of DDD are correctly emulated by every HHH thatWrong, your problem is you forget that all those DDD are different,
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.
that each DDD cannot possibly halt.
Sure, but what about different HHH_n's simulating the same DDD?
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 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. The machine code bytes of DDD remain
that same. The only thing that changes is the code of
HHH at machine address 000015d2.
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:And that separate proccess, if left unaborted, would halt. But HHH
> It is a lack of technical ability on your part which is unable to >>>>> > judge whether such a correct simulation is possible. Everybody >>>>> > else sees that it is not, so further questions about it are
> 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.
gives up and aborts it, so the process is Halting, not non-halting.
And HHH cannot simulate itself to its undeniable halting state.
*No not at all. Not in the least little bit* Recursive simulation isThis 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.
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.
(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.
(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.
void DDD()
{
HHH(DDD);
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
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.
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.
It is an infinite set with every HHH/DDD pair having the same propertyWhen N instructions of DDD are correctly emulated by every HHH thatWrong, your problem is you forget that all those DDD are different,
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.
that each DDD cannot possibly halt.
Sure, but what about different HHH_n's simulating the same DDD?
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 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.
The machine code bytes of DDD remain
that same.
The only thing that changes is the code of
HHH at machine address 000015d2.
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:And that separate proccess, if left unaborted, would halt. But HHH
> It is a lack of technical ability on your part which is unable to >>>>>> > judge whether such a correct simulation is possible. Everybody >>>>>> > else sees that it is not, so further questions about it are
> 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.
gives up and aborts it, so the process is Halting, not non-halting.
And HHH cannot simulate itself to its undeniable halting state.
*No not at all. Not in the least little bit* Recursive simulation isThis emulated HHH creates yet another process context to emulate its >>>>>> own DDD. When this DDD calls yet another HHH(DDD) this providesBut the pattern isn't non-halting by the fact that DDD is shown to be >>>>> halting.
enough
execution trace that the repeating pattern can be seen.
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.
(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.
(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()
{
HHH(DDD);
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.
There is no non-halting behaviour pattern, only a finite number more
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.
than N instructions are needed to reach the final input *for this input*.
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.
Op 01.aug.2025 om 16:54 schreef olcott:Try to prove that and you will find that
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.
It is an infinite set with every HHH/DDD pair having the same property >>>> that each DDD cannot possibly halt.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,
Sure, but what about different HHH_n's simulating the same DDD?
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 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,
On 8/2/2025 4:22 AM, Fred. Zwarts wrote:
Op 01.aug.2025 om 16:54 schreef olcott:Try to prove that and you will find that
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 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 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,
your proof is incoherent or has glaring gaps.
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:And that separate proccess, if left unaborted, would halt. But HHH >>>>>> gives up and aborts it, so the process is Halting, not non-halting.
> It is a lack of technical ability on your part which is
unable to
> judge whether such a correct simulation is possible. Everybody >>>>>>> > else sees that it is not, so further questions about it are >>>>>>> > 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 HHH cannot simulate itself to its undeniable halting state.
*No not at all. Not in the least little bit* Recursive simulation is >>>>> only a little more difficult than self recursion.This emulated HHH creates yet another process context to emulate its >>>>>>> own DDD. When this DDD calls yet another HHH(DDD) this provides >>>>>>> enoughBut the pattern isn't non-halting by the fact that DDD is shown to be >>>>>> halting.
execution trace that the repeating pattern can be seen.
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.
(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()
{
HHH(DDD);
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.
There is no non-halting behaviour pattern, only a finite number more
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.
than N instructions are needed to reach the final input *for this input*.
counter-factual
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
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.
Each pair has a different input for the simulator. Each simulator failsProving 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.
Op 02.aug.2025 om 16:17 schreef olcott:
On 8/2/2025 4:22 AM, Fred. Zwarts wrote:That has been proven multiple times, but you close your eyes for it.
Op 01.aug.2025 om 16:54 schreef olcott:Try to prove that and you will find that
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.
propertyWhen 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 directlyWrong, your problem is you forget that all those DDD are different, >>>>>> It is an infinite set with every HHH/DDD pair having the same
executed
DDD() halts.
that each DDD cannot possibly halt.
Sure, but what about different HHH_n's simulating the same DDD?
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 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,
your proof is incoherent or has glaring gaps.
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:And HHH cannot simulate itself to its undeniable halting state.
On 7/31/25 11:50 AM, olcott wrote:
On 7/29/2025 11:22 PM, Alan Mackenzie 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. >>>>
> It is a lack of technical ability on your part which is >>>>>>>> unable to
> judge whether such a correct simulation is possible. Everybody >>>>>>>> > else sees that it is not, so further questions about it are >>>>>>>> > 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.
*No not at all. Not in the least little bit* Recursive simulation is >>>>>> only a little more difficult than self recursion.This emulated HHH creates yet another process context to emulate >>>>>>>> itsBut the pattern isn't non-halting by the fact that DDD is shown >>>>>>> to be
own DDD. When this DDD calls yet another HHH(DDD) this provides >>>>>>>> enough
execution trace that the repeating pattern can be seen.
halting.
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()
{
HHH(DDD);
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.
There is no non-halting behaviour pattern, only a finite number more
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.
than N instructions are needed to reach the final input *for this
input*.
counter-factual
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 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.
Each pair has a different input for the simulator. Each simulator fails
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.
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.
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.
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:And HHH cannot simulate itself to its undeniable halting state.
On 7/31/25 11:50 AM, olcott wrote:
On 7/29/2025 11:22 PM, Alan Mackenzie 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. >>>>>
> It is a lack of technical ability on your part which is >>>>>>>>> unable to
> judge whether such a correct simulation is possible. >>>>>>>>> Everybody
> else sees that it is not, so further questions about it are >>>>>>>>> > 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.
*No not at all. Not in the least little bit* Recursive simulation is >>>>>>> only a little more difficult than self recursion.This emulated HHH creates yet another process context toBut the pattern isn't non-halting by the fact that DDD is shown >>>>>>>> to be
emulate its
own DDD. When this DDD calls yet another HHH(DDD) this provides >>>>>>>>> enough
execution trace that the repeating pattern can be seen.
halting.
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()
{
HHH(DDD);
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.
There is no non-halting behaviour pattern, only a finite number more
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.
than N instructions are needed to reach the final input *for this
input*.
counter-factual
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 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.
Each pair has a different input for the simulator. Each simulator
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.
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.
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.
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:And that separate proccess, if left unaborted, would halt. But HHH >>>>>>>>> gives up and aborts it, so the process is Halting, not non- >>>>>>>>> halting.
> It is a lack of technical ability on your part which is >>>>>>>>>> unable to
> judge whether such a correct simulation is possible. >>>>>>>>>> Everybody
> else sees that it is not, so further questions about it are >>>>>>>>>> > 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 HHH cannot simulate itself to its undeniable halting state.
*No not at all. Not in the least little bit* RecursiveThis emulated HHH creates yet another process context toBut the pattern isn't non-halting by the fact that DDD is shown >>>>>>>>> to be
emulate its
own DDD. When this DDD calls yet another HHH(DDD) this
provides enough
execution trace that the repeating pattern can be seen.
halting.
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()
{
HHH(DDD);
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.
There is no non-halting behaviour pattern, only a finite number
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.
more than N instructions are needed to reach the final input *for
this input*.
counter-factual
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 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.
Each pair has a different input for the simulator. Each simulator
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.
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.
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:And that separate proccess, if left unaborted, would halt. But >>>>>>>>>> HHH
> It is a lack of technical ability on your part which is >>>>>>>>>>> unable to
> judge whether such a correct simulation is possible. >>>>>>>>>>> Everybody
> else sees that it is not, so further questions about it are >>>>>>>>>>> > 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.
gives up and aborts it, so the process is Halting, not non- >>>>>>>>>> halting.
And HHH cannot simulate itself to its undeniable halting state. >>>>>>>>
*No not at all. Not in the least little bit* RecursiveThis emulated HHH creates yet another process context to >>>>>>>>>>> emulate itsBut the pattern isn't non-halting by the fact that DDD is >>>>>>>>>> shown to be
own DDD. When this DDD calls yet another HHH(DDD) this
provides enough
execution trace that the repeating pattern can be seen.
halting.
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()
{
HHH(DDD);
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.
There is no non-halting behaviour pattern, only a finite number
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.
more than N instructions are needed to reach the final input *for >>>>>> this input*.
counter-factual
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 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.
Each pair has a different input for the simulator. Each simulator
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.
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.
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:And that separate proccess, if left unaborted, would halt. >>>>>>>>>>> But HHH
> It is a lack of technical ability on your part which is >>>>>>>>>>>> unable to
> judge whether such a correct simulation is possible. >>>>>>>>>>>> Everybody
> else sees that it is not, so further questions about it are >>>>>>>>>>>> > 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.
gives up and aborts it, so the process is Halting, not non- >>>>>>>>>>> halting.
And HHH cannot simulate itself to its undeniable halting state. >>>>>>>>>
*No not at all. Not in the least little bit* RecursiveThis emulated HHH creates yet another process context to >>>>>>>>>>>> emulate itshalting.
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
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()
{
HHH(DDD);
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.
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*.
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.
counter-factual
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 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.
Each pair has a different input for the simulator. Each simulator
Proving that for all N the program specifies a halting behaviour, >>>>>>> but we can construct *another* input for which HHH fails again.I do not cheat. I define the infinite set of HHH/DDD pairs
But you cheat by changing the input, which then needs more steps. >>>>>>
where HHH emulates N instructions of DDD and N is one element
of the natural numbers.
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.
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:And that separate proccess, if left unaborted, would halt. >>>>>>>>>>>> But HHH
> It is a lack of technical ability on your part which is >>>>>>>>>>>>> unable to
> judge whether such a correct simulation is possible. >>>>>>>>>>>>> Everybody
> else sees that it is not, so further questions about it >>>>>>>>>>>>> are
> 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.
gives up and aborts it, so the process is Halting, not non- >>>>>>>>>>>> halting.
And HHH cannot simulate itself to its undeniable halting state. >>>>>>>>>>
*No not at all. Not in the least little bit* RecursiveThis emulated HHH creates yet another process context to >>>>>>>>>>>>> emulate itshalting.
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
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()
{
HHH(DDD);
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.
There is no non-halting behaviour pattern, only a finite number >>>>>>>> more than N instructions are needed to reach the final input
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.
*for this input*.
counter-factual
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 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.
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,
Proving that for all N the program specifies a haltingI do not cheat. I define the infinite set of HHH/DDD pairs
behaviour, but we can construct *another* input for which HHH >>>>>>>> fails again.
But you cheat by changing the input, which then needs more steps. >>>>>>>
where HHH emulates N instructions of DDD and N is one element
of the natural numbers.
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.
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:And that separate proccess, if left unaborted, would halt. >>>>>>>>>>>>> But HHH
> It is a lack of technical ability on your part which >>>>>>>>>>>>>> is unable to
> judge whether such a correct simulation is possible. >>>>>>>>>>>>>> Everybody
> else sees that it is not, so further questions about >>>>>>>>>>>>>> it are
> 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.
gives up and aborts it, so the process is Halting, not non- >>>>>>>>>>>>> halting.
And HHH cannot simulate itself to its undeniable halting state. >>>>>>>>>>>
*No not at all. Not in the least little bit* Recursive >>>>>>>>>>>> simulation isThis emulated HHH creates yet another process context to >>>>>>>>>>>>>> emulate itshalting.
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
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()
{
HHH(DDD);
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.
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*.
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.
counter-factual
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 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.
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,
Proving that for all N the program specifies a haltingI do not cheat. I define the infinite set of HHH/DDD pairs
behaviour, but we can construct *another* input for which HHH >>>>>>>>> fails again.
But you cheat by changing the input, which then needs more steps. >>>>>>>>
where HHH emulates N instructions of DDD and N is one element
of the natural numbers.
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.
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:And HHH cannot simulate itself to its undeniable halting state.
On 7/31/25 11:50 AM, olcott wrote:
On 7/29/2025 11:22 PM, Alan Mackenzie 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. >>>>>
> It is a lack of technical ability on your part which is >>>>>>>>> unable to
> judge whether such a correct simulation is possible. >>>>>>>>> Everybody
> else sees that it is not, so further questions about it are >>>>>>>>> > 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.
*No not at all. Not in the least little bit* Recursive simulation is >>>>>>> only a little more difficult than self recursion.This emulated HHH creates yet another process context toBut the pattern isn't non-halting by the fact that DDD is shown >>>>>>>> to be
emulate its
own DDD. When this DDD calls yet another HHH(DDD) this provides >>>>>>>>> enough
execution trace that the repeating pattern can be seen.
halting.
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()
{
HHH(DDD);
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.
There is no non-halting behaviour pattern, only a finite number more
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.
than N instructions are needed to reach the final input *for this
input*.
counter-factual
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 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.
Each pair has a different input for the simulator. Each simulator
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.
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.
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.
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:That has been proven multiple times, but you close your eyes for it.
Op 01.aug.2025 om 16:54 schreef olcott:Try to prove that and you will find that
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.
propertyWhen N instructions of DDD are correctly emulated by every HHH >>>>>>>>> thatWrong, your problem is you forget that all those DDD are different, >>>>>>> It is an infinite set with every HHH/DDD pair having the same
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.
that each DDD cannot possibly halt.
Sure, but what about different HHH_n's simulating the same DDD?
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 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,
your proof is incoherent or has glaring gaps.
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].
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:And that separate proccess, if left unaborted, would halt. >>>>>>>>>>>>>> But HHH
> It is a lack of technical ability on your part which >>>>>>>>>>>>>>> is unable to
> judge whether such a correct simulation is possible. >>>>>>>>>>>>>>> Everybody
> else sees that it is not, so further questions about >>>>>>>>>>>>>>> it are
> 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.
gives up and aborts it, so the process is Halting, not >>>>>>>>>>>>>> non- halting.
And HHH cannot simulate itself to its undeniable halting state. >>>>>>>>>>>>
*No not at all. Not in the least little bit* Recursive >>>>>>>>>>>>> simulation isThis emulated HHH creates yet another process context to >>>>>>>>>>>>>>> emulate itshalting.
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
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.
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.
void DDD()
{
HHH(DDD);
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 >>>>>>>>>>
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.
There is no non-halting behaviour pattern, only a finite
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.
number more than N instructions are needed to reach the final >>>>>>>>>> input *for this input*.
counter-factual
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 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.
Each pair has a different input for the simulator. Each
Proving that for all N the program specifies a haltingI do not cheat. I define the infinite set of HHH/DDD pairs
behaviour, but we can construct *another* input for which HHH >>>>>>>>>> fails again.
But you cheat by changing the input, which then needs more steps. >>>>>>>>>
where HHH emulates N instructions of DDD and N is one element >>>>>>>>> of the natural numbers.
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.
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.
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:And that separate proccess, if left unaborted, would >>>>>>>>>>>>>>> halt. But HHH
> It is a lack of technical ability on your part which >>>>>>>>>>>>>>>> is unable to
> judge whether such a correct simulation is possible. >>>>>>>>>>>>>>>> Everybody
> else sees that it is not, so further questions about >>>>>>>>>>>>>>>> it are
> 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.
gives up and aborts it, so the process is Halting, not >>>>>>>>>>>>>>> non- halting.
And HHH cannot simulate itself to its undeniable halting >>>>>>>>>>>>> state.
*No not at all. Not in the least little bit* Recursive >>>>>>>>>>>>>> simulation isThis emulated HHH creates yet another process context to >>>>>>>>>>>>>>>> emulate itshalting.
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
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.
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.
void DDD()
{
HHH(DDD);
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 >>>>>>>>>>>
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.
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*.
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.
counter-factual
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 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.
Each pair has a different input for the simulator. Each
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.
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.
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 Ĥ applied
to its own machine description ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt.
*Lines 2 and 4 above*
*Does insist that Ĥ.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.
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:Because HHH correctly predicts that DDD emulated by
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: >>>>>>>>>>>>>>>>> > It is a lack of technical ability on your part >>>>>>>>>>>>>>>>> which is unable toAnd that separate proccess, if left unaborted, would >>>>>>>>>>>>>>>> halt. But HHH
> judge whether such a correct simulation is >>>>>>>>>>>>>>>>> possible. Everybody
> else sees that it is not, so further questions >>>>>>>>>>>>>>>>> about it are
> 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.
gives up and aborts it, so the process is Halting, not >>>>>>>>>>>>>>>> non- halting.
And HHH cannot simulate itself to its undeniable halting >>>>>>>>>>>>>> state.
*No not at all. Not in the least little bit* Recursive >>>>>>>>>>>>>>> simulation isThis emulated HHH creates yet another process context >>>>>>>>>>>>>>>>> to emulate itshalting.
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
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. >>>>>>>>>>>>
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.
void DDD()
{
HHH(DDD);
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 >>>>>>>>>>>>
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.
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*.
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.
counter-factual
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 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.
Each pair has a different input for the simulator. Each
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.
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. >>>>>>>>>
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.
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:Because HHH correctly predicts that DDD emulated by
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: >>>>>>>>>>>>>>>>>> > It is a lack of technical ability on your part >>>>>>>>>>>>>>>>>> which is unable toAnd that separate proccess, if left unaborted, would >>>>>>>>>>>>>>>>> halt. But HHH
> judge whether such a correct simulation is >>>>>>>>>>>>>>>>>> possible. Everybody
> else sees that it is not, so further questions >>>>>>>>>>>>>>>>>> about it are
> 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.
gives up and aborts it, so the process is Halting, not >>>>>>>>>>>>>>>>> non- halting.
And HHH cannot simulate itself to its undeniable halting >>>>>>>>>>>>>>> state.
DDD halts if it weren't aborted.*No not at all. Not in the least little bit* Recursive >>>>>>>>>>>>>>>> simulation isThis emulated HHH creates yet another process context >>>>>>>>>>>>>>>>>> to emulate itshalting.
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
only a little more difficult than self recursion. >>>>>>>>>>>>>>
(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. >>>>>>>>>>>>>
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. >>>>>>>>>>>>>
void DDD()
{
HHH(DDD);
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 >>>>>>>>>>>>>
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.
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*.
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.
counter-factual
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 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.
Each pair has a different input for the simulator. Each >>>>>>>>>>> simulator fails for the input constructed with its own
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.
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. >>>>>>>>>>
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.
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:Because HHH correctly predicts that DDD emulated by
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: >>>>>>>>>>>>>>>>>>> > It is a lack of technical ability on your part >>>>>>>>>>>>>>>>>>> which is unable toAnd that separate proccess, if left unaborted, would >>>>>>>>>>>>>>>>>> halt. But HHH
> judge whether such a correct simulation is >>>>>>>>>>>>>>>>>>> possible. Everybody
> else sees that it is not, so further questions >>>>>>>>>>>>>>>>>>> about it are
> 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.
gives up and aborts it, so the process is Halting, not >>>>>>>>>>>>>>>>>> non- halting.
And HHH cannot simulate itself to its undeniable halting >>>>>>>>>>>>>>>> state.
DDD halts if it weren't aborted.*No not at all. Not in the least little bit* Recursive >>>>>>>>>>>>>>>>> simulation isThis emulated HHH creates yet another process context >>>>>>>>>>>>>>>>>>> to emulate itshalting.
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
only a little more difficult than self recursion. >>>>>>>>>>>>>>>
(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. >>>>>>>>>>>>
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.
(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. >>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>
void DDD()
{
HHH(DDD);
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 >>>>>>>>>>>>>>
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. >>>>>>>>>>>>
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.
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*.
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.
counter-factual
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 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.
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. >>>>>>>>>>>
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.
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
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:Because HHH correctly predicts that DDD emulated by
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: >>>>>>>>>>>>>>>>>>> > It is a lack of technical ability on your part >>>>>>>>>>>>>>>>>>> which is unable toAnd that separate proccess, if left unaborted, would >>>>>>>>>>>>>>>>>> halt. But HHH
> judge whether such a correct simulation is >>>>>>>>>>>>>>>>>>> possible. Everybody
> else sees that it is not, so further questions >>>>>>>>>>>>>>>>>>> about it are
> 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.
gives up and aborts it, so the process is Halting, not >>>>>>>>>>>>>>>>>> non- halting.
And HHH cannot simulate itself to its undeniable halting >>>>>>>>>>>>>>>> state.
DDD halts if it weren't aborted.*No not at all. Not in the least little bit* Recursive >>>>>>>>>>>>>>>>> simulation isThis emulated HHH creates yet another process context >>>>>>>>>>>>>>>>>>> to emulate itshalting.
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
only a little more difficult than self recursion. >>>>>>>>>>>>>>>
(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. >>>>>>>>>>>>
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.
(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. >>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>
void DDD()
{
HHH(DDD);
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 >>>>>>>>>>>>>>
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. >>>>>>>>>>>>
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.
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*.
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.
counter-factual
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 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.
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. >>>>>>>>>>>
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.
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
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:Because HHH correctly predicts that DDD emulated by
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: >>>>>>>>>>>>>>>>>>> > It is a lack of technical ability on your part >>>>>>>>>>>>>>>>>>> which is unable toAnd that separate proccess, if left unaborted, would >>>>>>>>>>>>>>>>>> halt. But HHH
> judge whether such a correct simulation is >>>>>>>>>>>>>>>>>>> possible. Everybody
> else sees that it is not, so further questions >>>>>>>>>>>>>>>>>>> about it are
> 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.
gives up and aborts it, so the process is Halting, not >>>>>>>>>>>>>>>>>> non- halting.
And HHH cannot simulate itself to its undeniable halting >>>>>>>>>>>>>>>> state.
DDD halts if it weren't aborted.*No not at all. Not in the least little bit* Recursive >>>>>>>>>>>>>>>>> simulation isThis emulated HHH creates yet another process context >>>>>>>>>>>>>>>>>>> to emulate itshalting.
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
only a little more difficult than self recursion. >>>>>>>>>>>>>>>
(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. >>>>>>>>>>>>
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.
(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. >>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>
void DDD()
{
HHH(DDD);
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 >>>>>>>>>>>>>>
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. >>>>>>>>>>>>
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.
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*.
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.
counter-factual
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 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.
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. >>>>>>>>>>>
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.
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
Op 06.aug.2025 om 05:47 schreef olcott:*This is my correction*
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
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'.
On 8/6/2025 4:00 AM, Fred. Zwarts wrote:
Op 06.aug.2025 om 05:47 schreef olcott:*This is my correction*
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
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'.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
its simulated final halt state of ⟨Ĥ.qn⟩, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly
reach its simulated final halt state of ⟨Ĥ.qn⟩.
*This is the original erroneous one*
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt.
*Lines two and four requires Ĥ.embedded_H to report on its own behavior*
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.
"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
Because you lied to it and said it was an error.
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:Because HHH correctly predicts that DDD emulated by
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: >>>>>>>>>>>>>>>>>>>> > It is a lack of technical ability on your part >>>>>>>>>>>>>>>>>>>> which is unable toAnd that separate proccess, if left unaborted, would >>>>>>>>>>>>>>>>>>> halt. But HHH
> judge whether such a correct simulation is >>>>>>>>>>>>>>>>>>>> possible. Everybody
> else sees that it is not, so further questions >>>>>>>>>>>>>>>>>>>> about it are
> 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.
gives up and aborts it, so the process is Halting, >>>>>>>>>>>>>>>>>>> not non- halting.
And HHH cannot simulate itself to its undeniable >>>>>>>>>>>>>>>>> halting state.
DDD halts if it weren't aborted.*No not at all. Not in the least little bit* Recursive >>>>>>>>>>>>>>>>>> simulation isThis emulated HHH creates yet another process >>>>>>>>>>>>>>>>>>>> context to emulate itshalting.
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
only a little more difficult than self recursion. >>>>>>>>>>>>>>>>
(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.
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.
When the input specifies a halting behaviour, it is an >>>>>>>>>>>>>>> error to close your eyes and pretend that it does not exist. >>>>>>>>>>>>>>>
(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. >>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>>
void DDD()
{
HHH(DDD);
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 >>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>
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.
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*.
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.
counter-factual
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 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.
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. >>>>>>>>>>>>
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.
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.
"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
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.
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:*This is my correction*
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
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'.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
its simulated final halt state of ⟨Ĥ.qn⟩, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly
reach its simulated final halt state of ⟨Ĥ.qn⟩.
*This is the original erroneous one*
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt.
*Lines two and four requires Ĥ.embedded_H to report on its own behavior*
Which is valid.
And you are just stupid to think otherwise.
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:*This is my correction*
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
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'.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
its simulated final halt state of ⟨Ĥ.qn⟩, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly
reach its simulated final halt state of ⟨Ĥ.qn⟩.
*This is the original erroneous one*
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt.
*Lines two and four requires Ĥ.embedded_H to report on its own behavior*
Which is valid.
And you are just stupid to think otherwise.
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:*This is my correction*
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
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'.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
its simulated final halt state of ⟨Ĥ.qn⟩, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly
reach its simulated final halt state of ⟨Ĥ.qn⟩.
*This is the original erroneous one*
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt.
*Lines two and four requires Ĥ.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.
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:*This is my correction*
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
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'.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
its simulated final halt state of ⟨Ĥ.qn⟩, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly
reach its simulated final halt state of ⟨Ĥ.qn⟩.
*This is the original erroneous one*
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt.
*Lines two and four requires Ĥ.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.
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.
"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
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:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
its simulated final halt state of ⟨Ĥ.qn⟩, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly
reach its simulated final halt state of ⟨Ĥ.qn⟩.
When we use the above standard then a halt decider
will always report on the actual behavior that its
input actually specifies.
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:Because HHH correctly predicts that DDD emulated by
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: >>>>>>>>>>>>>>>>>>>>> > It is a lack of technical ability on your part >>>>>>>>>>>>>>>>>>>>> which is unable toAnd that separate proccess, if left unaborted, would >>>>>>>>>>>>>>>>>>>> halt. But HHH
> judge whether such a correct simulation is >>>>>>>>>>>>>>>>>>>>> possible. Everybody
> else sees that it is not, so further questions >>>>>>>>>>>>>>>>>>>>> about it are
> 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.
gives up and aborts it, so the process is Halting, >>>>>>>>>>>>>>>>>>>> not non- halting.
And HHH cannot simulate itself to its undeniable >>>>>>>>>>>>>>>>>> halting state.
DDD halts if it weren't aborted.*No not at all. Not in the least little bit* >>>>>>>>>>>>>>>>>>> Recursive simulation isThis emulated HHH creates yet another process >>>>>>>>>>>>>>>>>>>>> context to emulate itsBut the pattern isn't non-halting by the fact that >>>>>>>>>>>>>>>>>>>> DDD is shown to be
own DDD. When this DDD calls yet another HHH(DDD) >>>>>>>>>>>>>>>>>>>>> this provides enough
execution trace that the repeating pattern can be >>>>>>>>>>>>>>>>>>>>> seen.
halting.
only a little more difficult than self recursion. >>>>>>>>>>>>>>>>>
(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.
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.
When the input specifies a halting behaviour, it is an >>>>>>>>>>>>>>>> error to close your eyes and pretend that it does not >>>>>>>>>>>>>>>> exist.
(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. >>>>>>>>>>>>>>>>
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.
void DDD()
{
HHH(DDD);
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 >>>>>>>>>>>>>>>>
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. >>>>>>>>>>>>>>
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.
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*.
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.
counter-factual
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD >>>>>>>>>>>>>>> [0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>>>> [0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 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.
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. >>>>>>>>>>>>>
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.
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.
"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
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:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
its simulated final halt state of ⟨Ĥ.qn⟩, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly
reach its simulated final halt state of ⟨Ĥ.qn⟩.
When we use the above standard then a halt decider
will always report on the actual behavior that its
input actually specifies.
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. >>>
"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
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.
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.
"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
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.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy,
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.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.
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.
"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
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.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy,
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.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.
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.
"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
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.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy,
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.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.
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.
"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
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.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy,
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.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.
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.
"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
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.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy,
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.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.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,064 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 148:15:54 |
| Calls: | 13,691 |
| Calls today: | 1 |
| Files: | 186,936 |
| D/L today: |
33 files (6,120K bytes) |
| Messages: | 2,410,934 |