On 7/29/25 9:24 PM, olcott wrote:
On 7/29/2025 5:37 PM, Richard Damon wrote:
On 7/29/25 12:53 PM, olcott wrote:
On 7/28/2025 8:56 PM, Richard Damon wrote:
On 7/28/25 7:58 PM, olcott wrote:
On 7/28/2025 6:49 PM, Richard Damon wrote:
On 7/28/25 7:20 PM, olcott wrote:
On 7/28/2025 5:57 PM, Richard Damon wrote:
On 7/28/25 9:54 AM, olcott wrote:
On 7/28/2025 8:21 AM, joes wrote:
Am Mon, 28 Jul 2025 07:11:11 -0500 schrieb olcott:
On 7/28/2025 2:30 AM, joes wrote:
Am Sun, 27 Jul 2025 21:58:05 -0500 schrieb olcott:
On 7/27/2025 9:48 PM, Richard Damon wrote:
On 7/27/25 8:20 PM, olcott wrote:
HHH is never changed.Yeah, so when you change HHH to abort later, you also >>>>>>>>>>>>> change DDD.By itself I mean the exact same machine code bytes at the >>>>>>>>>>>>>> exact sameWhen DDD is emulated by HHH1 it need not emulate itself >>>>>>>>>>>>>>>> at all.But "itself" doesn't matter to x86 instructions,
machine address.
It is changed in the hypothetical unaborted simulation. HHH >>>>>>>>>>> is reporting
on UTM(HHH', DDD) where HHH' calls UTM(DDD), and not on the >>>>>>>>>>> halting DDD,
and definitely not on HHH(DDD), itself.
All halt deciders are required to predict the behavior
of their input. HHH does correctly predict that DDD correctly >>>>>>>>>> simulated by HHH cannot possibly reach its own simulated
"return" instruction final halt state.
How is it a "correct prediction" if it sees something different >>>>>>>>> than what that DDD does.
What DDD does is keep calling HHH(DDD) in recursive
simulation until HHH kills this whole process.
But the behavior of the program continues past that (something
you don't seem to understand) and that behavior will also have
its HHH terminate the DDD it is simulating and return 0 to DDD
and then Halt.
Your problem is you don't understand that the simulating HHH
doesn't define the behavior of DDD, it is the execution of DDD
that defines what a correct simulation of it is.
Remember, to have simulated that DDD, it must have include the >>>>>>>>> code of the HHH that it was based on, which is the HHH that >>>>>>>>> made the prediction, and thus returns 0, so DDD will halt.
We are not asking: Does DDD() halt.
That is (as it turns out) an incorrect question.
No, that is EXACTLY the question.
I guess you are just admitting that you whole world is based on >>>>>>> LYING about what things are supposed to be.
Turing machines cannot directly report on the behavior
of other Turing machines they can at best indirectly
report on the behavior of Turing machines through the
proxy of finite string machine descriptions such as ⟨M⟩.
Right, and HHH was given the equivalenet of (M) by being given
the code of *ALL* of DDD
I guess you don't understand that fact, even though you CLAIM the >>>>>>> input is the proper representation of DDD.
Thus the behavior specified by the input finite string
overrules and supersedes the behavior of the direct
execution.
No, it is DEFINED to be the behavior of the direct execution of >>>>>>> the program it represent.
*That has always been the fatal flaw of all of the proofs*
No, your failure to follow the rules is what makes you just a liar.
_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]
When the above code is in the same memory space as HHH
such that DDD calls HHH(DDD) and then HHH does emulate
itself emulating DDD then this does specify recursive
emulation.
Anyone or anything that disagrees would be disagreeing
with the definition of the x86 language.
So, if HHH accesses that memory, it becomes part of the input.
It becomes part of the input in the sense that the
correct simulation of the input to HHH(DDD) is not
the same as the correct simulation of the input to
HHH1(DDD) because DDD only calls HHH(DDD) and does
not call HHH1(DDD).
DDD correctly simulated by HHH cannot possibly
halt thus HHH(DDD)==0 is correct.
DDD correctly simulated by HHH1 does halt thus
HHH(DDD)==1 is correct.
It either *IS* or it *ISN'T* there is no middle.
On 7/29/2025 8:51 PM, Richard Damon wrote:Indeed. But there are different reasons:
On 7/29/25 9:24 PM, olcott wrote:
On 7/29/2025 5:37 PM, Richard Damon wrote:
On 7/29/25 12:53 PM, olcott wrote:
On 7/28/2025 8:56 PM, Richard Damon wrote:
On 7/28/25 7:58 PM, olcott wrote:
On 7/28/2025 6:49 PM, Richard Damon wrote:
On 7/28/25 7:20 PM, olcott wrote:
On 7/28/2025 5:57 PM, Richard Damon wrote:
On 7/28/25 9:54 AM, olcott wrote:
On 7/28/2025 8:21 AM, joes wrote:
Am Mon, 28 Jul 2025 07:11:11 -0500 schrieb olcott:
On 7/28/2025 2:30 AM, joes wrote:
Am Sun, 27 Jul 2025 21:58:05 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 7/27/2025 9:48 PM, Richard Damon wrote:
On 7/27/25 8:20 PM, olcott wrote:
HHH is never changed.Yeah, so when you change HHH to abort later, you also >>>>>>>>>>>>>> change DDD.machine address.When DDD is emulated by HHH1 it need not emulate itself >>>>>>>>>>>>>>>>> at all.But "itself" doesn't matter to x86 instructions, >>>>>>>>>>>>>>> By itself I mean the exact same machine code bytes at the >>>>>>>>>>>>>>> exact same
It is changed in the hypothetical unaborted simulation. HHH >>>>>>>>>>>> is reporting
on UTM(HHH', DDD) where HHH' calls UTM(DDD), and not on the >>>>>>>>>>>> halting DDD,
and definitely not on HHH(DDD), itself.
All halt deciders are required to predict the behavior
of their input. HHH does correctly predict that DDD correctly >>>>>>>>>>> simulated by HHH cannot possibly reach its own simulated >>>>>>>>>>> "return" instruction final halt state.
How is it a "correct prediction" if it sees something
different than what that DDD does.
What DDD does is keep calling HHH(DDD) in recursive
simulation until HHH kills this whole process.
But the behavior of the program continues past that (something >>>>>>>> you don't seem to understand) and that behavior will also have >>>>>>>> its HHH terminate the DDD it is simulating and return 0 to DDD >>>>>>>> and then Halt.
Your problem is you don't understand that the simulating HHH
doesn't define the behavior of DDD, it is the execution of DDD >>>>>>>> that defines what a correct simulation of it is.
Remember, to have simulated that DDD, it must have include the >>>>>>>>>> code of the HHH that it was based on, which is the HHH that >>>>>>>>>> made the prediction, and thus returns 0, so DDD will halt. >>>>>>>>>>
We are not asking: Does DDD() halt.
That is (as it turns out) an incorrect question.
No, that is EXACTLY the question.
I guess you are just admitting that you whole world is based on >>>>>>>> LYING about what things are supposed to be.
Turing machines cannot directly report on the behavior
of other Turing machines they can at best indirectly
report on the behavior of Turing machines through the
proxy of finite string machine descriptions such as ⟨M⟩.
Right, and HHH was given the equivalenet of (M) by being given >>>>>>>> the code of *ALL* of DDD
I guess you don't understand that fact, even though you CLAIM >>>>>>>> the input is the proper representation of DDD.
Thus the behavior specified by the input finite string
overrules and supersedes the behavior of the direct
execution.
No, it is DEFINED to be the behavior of the direct execution of >>>>>>>> the program it represent.
*That has always been the fatal flaw of all of the proofs*
No, your failure to follow the rules is what makes you just a liar. >>>>>>
_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]
When the above code is in the same memory space as HHH
such that DDD calls HHH(DDD) and then HHH does emulate
itself emulating DDD then this does specify recursive
emulation.
Anyone or anything that disagrees would be disagreeing
with the definition of the x86 language.
So, if HHH accesses that memory, it becomes part of the input.
It becomes part of the input in the sense that the
correct simulation of the input to HHH(DDD) is not
the same as the correct simulation of the input to
HHH1(DDD) because DDD only calls HHH(DDD) and does
not call HHH1(DDD).
DDD correctly simulated by HHH cannot possibly
halt thus HHH(DDD)==0 is correct.
DDD correctly simulated by HHH1 does halt thus
HHH(DDD)==1 is correct.
It either *IS* or it *ISN'T* there is no middle.
This just occurred to me:
*HHH(DDD)==0 is also correct for another different reason*
Even if we construed the HHH that DDD calls a part of the
program under test it is true that neither the simulated
DDD nor the simulated HHH cannot possibly reach their own
final halt state.
On 7/29/2025 8:51 PM, Richard Damon wrote:
On 7/29/25 9:24 PM, olcott wrote:
On 7/29/2025 5:37 PM, Richard Damon wrote:
On 7/29/25 12:53 PM, olcott wrote:
On 7/28/2025 8:56 PM, Richard Damon wrote:
On 7/28/25 7:58 PM, olcott wrote:
On 7/28/2025 6:49 PM, Richard Damon wrote:
On 7/28/25 7:20 PM, olcott wrote:
On 7/28/2025 5:57 PM, Richard Damon wrote:
On 7/28/25 9:54 AM, olcott wrote:
On 7/28/2025 8:21 AM, joes wrote:
Am Mon, 28 Jul 2025 07:11:11 -0500 schrieb olcott:
On 7/28/2025 2:30 AM, joes wrote:
Am Sun, 27 Jul 2025 21:58:05 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 7/27/2025 9:48 PM, Richard Damon wrote:
On 7/27/25 8:20 PM, olcott wrote:
HHH is never changed.Yeah, so when you change HHH to abort later, you also >>>>>>>>>>>>>> change DDD.machine address.When DDD is emulated by HHH1 it need not emulate itself >>>>>>>>>>>>>>>>> at all.But "itself" doesn't matter to x86 instructions, >>>>>>>>>>>>>>> By itself I mean the exact same machine code bytes at the >>>>>>>>>>>>>>> exact same
It is changed in the hypothetical unaborted simulation. HHH >>>>>>>>>>>> is reporting
on UTM(HHH', DDD) where HHH' calls UTM(DDD), and not on the >>>>>>>>>>>> halting DDD,
and definitely not on HHH(DDD), itself.
All halt deciders are required to predict the behavior
of their input. HHH does correctly predict that DDD correctly >>>>>>>>>>> simulated by HHH cannot possibly reach its own simulated >>>>>>>>>>> "return" instruction final halt state.
How is it a "correct prediction" if it sees something
different than what that DDD does.
What DDD does is keep calling HHH(DDD) in recursive
simulation until HHH kills this whole process.
But the behavior of the program continues past that (something >>>>>>>> you don't seem to understand) and that behavior will also have >>>>>>>> its HHH terminate the DDD it is simulating and return 0 to DDD >>>>>>>> and then Halt.
Your problem is you don't understand that the simulating HHH
doesn't define the behavior of DDD, it is the execution of DDD >>>>>>>> that defines what a correct simulation of it is.
Remember, to have simulated that DDD, it must have include the >>>>>>>>>> code of the HHH that it was based on, which is the HHH that >>>>>>>>>> made the prediction, and thus returns 0, so DDD will halt. >>>>>>>>>>
We are not asking: Does DDD() halt.
That is (as it turns out) an incorrect question.
No, that is EXACTLY the question.
I guess you are just admitting that you whole world is based on >>>>>>>> LYING about what things are supposed to be.
Turing machines cannot directly report on the behavior
of other Turing machines they can at best indirectly
report on the behavior of Turing machines through the
proxy of finite string machine descriptions such as ⟨M⟩.
Right, and HHH was given the equivalenet of (M) by being given >>>>>>>> the code of *ALL* of DDD
I guess you don't understand that fact, even though you CLAIM >>>>>>>> the input is the proper representation of DDD.
Thus the behavior specified by the input finite string
overrules and supersedes the behavior of the direct
execution.
No, it is DEFINED to be the behavior of the direct execution of >>>>>>>> the program it represent.
*That has always been the fatal flaw of all of the proofs*
No, your failure to follow the rules is what makes you just a liar. >>>>>>
_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]
When the above code is in the same memory space as HHH
such that DDD calls HHH(DDD) and then HHH does emulate
itself emulating DDD then this does specify recursive
emulation.
Anyone or anything that disagrees would be disagreeing
with the definition of the x86 language.
So, if HHH accesses that memory, it becomes part of the input.
It becomes part of the input in the sense that the
correct simulation of the input to HHH(DDD) is not
the same as the correct simulation of the input to
HHH1(DDD) because DDD only calls HHH(DDD) and does
not call HHH1(DDD).
DDD correctly simulated by HHH cannot possibly
halt thus HHH(DDD)==0 is correct.
DDD correctly simulated by HHH1 does halt thus
HHH(DDD)==1 is correct.
It either *IS* or it *ISN'T* there is no middle.
This just occurred to me:
*HHH(DDD)==0 is also correct for another different reason*
Even if we construed the HHH that DDD calls a part of the
program under test it is true that neither the simulated
DDD nor the simulated HHH cannot possibly reach their own
final halt state.
Op 30.jul.2025 om 05:12 schreef olcott:*I challenge you to show a premature abort*
Indeed. But there are different reasons:
This just occurred to me:
*HHH(DDD)==0 is also correct for another different reason*
Even if we construed the HHH that DDD calls a part of the
program under test it is true that neither the simulated
DDD nor the simulated HHH cannot possibly reach their own
final halt state.
The simulating HHH fails to reach the final halt state of the simulation because it does a premature abort,
based on the wrong assumption that a
finite recursion specifies non-halting.
Then the simulating HHH does
reach its own halt state when it reports non-halting.
The simulated HHH, that has a similar final halt state after it aborts,
does not reach it own final halt state, because the simulating HHH does
not allow it to reach it by the premature abort done by the simulating HHH.
On 7/29/25 11:12 PM, olcott wrote:
On 7/29/2025 8:51 PM, Richard Damon wrote:
On 7/29/25 9:24 PM, olcott wrote:
On 7/29/2025 5:37 PM, Richard Damon wrote:
On 7/29/25 12:53 PM, olcott wrote:
On 7/28/2025 8:56 PM, Richard Damon wrote:
On 7/28/25 7:58 PM, olcott wrote:
On 7/28/2025 6:49 PM, Richard Damon wrote:
On 7/28/25 7:20 PM, olcott wrote:
On 7/28/2025 5:57 PM, Richard Damon wrote:
On 7/28/25 9:54 AM, olcott wrote:
On 7/28/2025 8:21 AM, joes wrote:
Am Mon, 28 Jul 2025 07:11:11 -0500 schrieb olcott:
On 7/28/2025 2:30 AM, joes wrote:
Am Sun, 27 Jul 2025 21:58:05 -0500 schrieb olcott: >>>>>>>>>>>>>>>> On 7/27/2025 9:48 PM, Richard Damon wrote:
On 7/27/25 8:20 PM, olcott wrote:
HHH is never changed.Yeah, so when you change HHH to abort later, you also >>>>>>>>>>>>>>> change DDD.machine address.When DDD is emulated by HHH1 it need not emulate >>>>>>>>>>>>>>>>>> itself at all.But "itself" doesn't matter to x86 instructions, >>>>>>>>>>>>>>>> By itself I mean the exact same machine code bytes at >>>>>>>>>>>>>>>> the exact same
It is changed in the hypothetical unaborted simulation. HHH >>>>>>>>>>>>> is reporting
on UTM(HHH', DDD) where HHH' calls UTM(DDD), and not on the >>>>>>>>>>>>> halting DDD,
and definitely not on HHH(DDD), itself.
All halt deciders are required to predict the behavior >>>>>>>>>>>> of their input. HHH does correctly predict that DDD correctly >>>>>>>>>>>> simulated by HHH cannot possibly reach its own simulated >>>>>>>>>>>> "return" instruction final halt state.
How is it a "correct prediction" if it sees something
different than what that DDD does.
What DDD does is keep calling HHH(DDD) in recursive
simulation until HHH kills this whole process.
But the behavior of the program continues past that (something >>>>>>>>> you don't seem to understand) and that behavior will also have >>>>>>>>> its HHH terminate the DDD it is simulating and return 0 to DDD >>>>>>>>> and then Halt.
Your problem is you don't understand that the simulating HHH >>>>>>>>> doesn't define the behavior of DDD, it is the execution of DDD >>>>>>>>> that defines what a correct simulation of it is.
Remember, to have simulated that DDD, it must have include >>>>>>>>>>> the code of the HHH that it was based on, which is the HHH >>>>>>>>>>> that made the prediction, and thus returns 0, so DDD will halt. >>>>>>>>>>>
We are not asking: Does DDD() halt.
That is (as it turns out) an incorrect question.
No, that is EXACTLY the question.
I guess you are just admitting that you whole world is based on >>>>>>>>> LYING about what things are supposed to be.
Right, and HHH was given the equivalenet of (M) by being given >>>>>>>>> the code of *ALL* of DDD
Turing machines cannot directly report on the behavior
of other Turing machines they can at best indirectly
report on the behavior of Turing machines through the
proxy of finite string machine descriptions such as ⟨M⟩. >>>>>>>>>
I guess you don't understand that fact, even though you CLAIM >>>>>>>>> the input is the proper representation of DDD.
Thus the behavior specified by the input finite string
overrules and supersedes the behavior of the direct
execution.
No, it is DEFINED to be the behavior of the direct execution of >>>>>>>>> the program it represent.
*That has always been the fatal flaw of all of the proofs*
No, your failure to follow the rules is what makes you just a liar. >>>>>>>
_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]
When the above code is in the same memory space as HHH
such that DDD calls HHH(DDD) and then HHH does emulate
itself emulating DDD then this does specify recursive
emulation.
Anyone or anything that disagrees would be disagreeing
with the definition of the x86 language.
So, if HHH accesses that memory, it becomes part of the input.
It becomes part of the input in the sense that the
correct simulation of the input to HHH(DDD) is not
the same as the correct simulation of the input to
HHH1(DDD) because DDD only calls HHH(DDD) and does
not call HHH1(DDD).
DDD correctly simulated by HHH cannot possibly
halt thus HHH(DDD)==0 is correct.
DDD correctly simulated by HHH1 does halt thus
HHH(DDD)==1 is correct.
It either *IS* or it *ISN'T* there is no middle.
This just occurred to me:
*HHH(DDD)==0 is also correct for another different reason*
Even if we construed the HHH that DDD calls a part of the
program under test it is true that neither the simulated
DDD nor the simulated HHH cannot possibly reach their own
final halt state.
Sure they do, when correctly simulated. What doens't happne is that the PARTIAL simulation (and thus not correct) of HHH can't reach that state.
On Wed, 2025-07-30 at 10:43 -0500, olcott wrote:
On 7/30/2025 10:23 AM, joes wrote:
Am Wed, 30 Jul 2025 10:02:05 -0500 schrieb olcott:
On 7/30/2025 5:59 AM, Richard Damon wrote:
On 7/29/25 11:12 PM, olcott wrote:
We have been over this too many times. If DDD was incorrectly emulated >>>> by HHH then you could show the exact x86 instruction of DDD that wasThis just occurred to me:Sure they do, when correctly simulated. What doens't happne is that the >>>>> PARTIAL simulation (and thus not correct) of HHH can't reach that
*HHH(DDD)==0 is also correct for another different reason*
Even if we construed the HHH that DDD calls a part of the program
under test it is true that neither the simulated DDD nor the simulated >>>>>> HHH cannot possibly reach their own final halt state.
state.
emulated incorrectly when DDD is emulated by HHH or when DDD is emulated >>>> by the emulated HHH.
Yeah, we have. The second call to HHH is not simulated.
I proved that the emulated HHH does emulate DDD correctly
and you simply ignored this proof.
You are shown not qualified to use 'prove' word and 'correct'. You have no valid base.
On 7/30/2025 5:59 AM, Richard Damon wrote:
On 7/29/25 11:12 PM, olcott wrote:
On 7/29/2025 8:51 PM, Richard Damon wrote:
On 7/29/25 9:24 PM, olcott wrote:
On 7/29/2025 5:37 PM, Richard Damon wrote:
On 7/29/25 12:53 PM, olcott wrote:
On 7/28/2025 8:56 PM, Richard Damon wrote:
On 7/28/25 7:58 PM, olcott wrote:
On 7/28/2025 6:49 PM, Richard Damon wrote:
On 7/28/25 7:20 PM, olcott wrote:
On 7/28/2025 5:57 PM, Richard Damon wrote:
On 7/28/25 9:54 AM, olcott wrote:
On 7/28/2025 8:21 AM, joes wrote:
Am Mon, 28 Jul 2025 07:11:11 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 7/28/2025 2:30 AM, joes wrote:
Am Sun, 27 Jul 2025 21:58:05 -0500 schrieb olcott: >>>>>>>>>>>>>>>>> On 7/27/2025 9:48 PM, Richard Damon wrote:
On 7/27/25 8:20 PM, olcott wrote:
HHH is never changed.Yeah, so when you change HHH to abort later, you also >>>>>>>>>>>>>>>> change DDD.machine address.When DDD is emulated by HHH1 it need not emulate >>>>>>>>>>>>>>>>>>> itself at all.But "itself" doesn't matter to x86 instructions, >>>>>>>>>>>>>>>>> By itself I mean the exact same machine code bytes at >>>>>>>>>>>>>>>>> the exact same
It is changed in the hypothetical unaborted simulation. >>>>>>>>>>>>>> HHH is reporting
on UTM(HHH', DDD) where HHH' calls UTM(DDD), and not on >>>>>>>>>>>>>> the halting DDD,
and definitely not on HHH(DDD), itself.
All halt deciders are required to predict the behavior >>>>>>>>>>>>> of their input. HHH does correctly predict that DDD correctly >>>>>>>>>>>>> simulated by HHH cannot possibly reach its own simulated >>>>>>>>>>>>> "return" instruction final halt state.
How is it a "correct prediction" if it sees something >>>>>>>>>>>> different than what that DDD does.
What DDD does is keep calling HHH(DDD) in recursive
simulation until HHH kills this whole process.
But the behavior of the program continues past that (something >>>>>>>>>> you don't seem to understand) and that behavior will also have >>>>>>>>>> its HHH terminate the DDD it is simulating and return 0 to DDD >>>>>>>>>> and then Halt.
Your problem is you don't understand that the simulating HHH >>>>>>>>>> doesn't define the behavior of DDD, it is the execution of DDD >>>>>>>>>> that defines what a correct simulation of it is.
Remember, to have simulated that DDD, it must have include >>>>>>>>>>>> the code of the HHH that it was based on, which is the HHH >>>>>>>>>>>> that made the prediction, and thus returns 0, so DDD will halt. >>>>>>>>>>>>
We are not asking: Does DDD() halt.
That is (as it turns out) an incorrect question.
No, that is EXACTLY the question.
I guess you are just admitting that you whole world is based >>>>>>>>>> on LYING about what things are supposed to be.
Right, and HHH was given the equivalenet of (M) by being given >>>>>>>>>> the code of *ALL* of DDD
Turing machines cannot directly report on the behavior
of other Turing machines they can at best indirectly
report on the behavior of Turing machines through the
proxy of finite string machine descriptions such as ⟨M⟩. >>>>>>>>>>
I guess you don't understand that fact, even though you CLAIM >>>>>>>>>> the input is the proper representation of DDD.
Thus the behavior specified by the input finite string
overrules and supersedes the behavior of the direct
execution.
No, it is DEFINED to be the behavior of the direct execution >>>>>>>>>> of the program it represent.
*That has always been the fatal flaw of all of the proofs*
No, your failure to follow the rules is what makes you just a liar. >>>>>>>>
_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]
When the above code is in the same memory space as HHH
such that DDD calls HHH(DDD) and then HHH does emulate
itself emulating DDD then this does specify recursive
emulation.
Anyone or anything that disagrees would be disagreeing
with the definition of the x86 language.
So, if HHH accesses that memory, it becomes part of the input.
It becomes part of the input in the sense that the
correct simulation of the input to HHH(DDD) is not
the same as the correct simulation of the input to
HHH1(DDD) because DDD only calls HHH(DDD) and does
not call HHH1(DDD).
DDD correctly simulated by HHH cannot possibly
halt thus HHH(DDD)==0 is correct.
DDD correctly simulated by HHH1 does halt thus
HHH(DDD)==1 is correct.
It either *IS* or it *ISN'T* there is no middle.
This just occurred to me:
*HHH(DDD)==0 is also correct for another different reason*
Even if we construed the HHH that DDD calls a part of the
program under test it is true that neither the simulated
DDD nor the simulated HHH cannot possibly reach their own
final halt state.
Sure they do, when correctly simulated. What doens't happne is that
the PARTIAL simulation (and thus not correct) of HHH can't reach that
state.
_DDD()
[0000219e] 55 push ebp
[0000219f] 8bec mov ebp,esp
[000021a1] 689e210000 push 0000219e
[000021a6] e843f4ffff call 000015ee
[000021ab] 83c404 add esp,+04
[000021ae] 5d pop ebp
[000021af] c3 ret
Size in bytes:(0018) [000021af]
We have been over this too many times. If DDD was
incorrectly emulated by HHH then you could show
the exact x86 instruction of DDD that was emulated
incorrectly when DDD is emulated by HHH or when
DDD is emulated by the emulated HHH.
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
That you never made any attempt at an actual rebuttal
seems to prove that you know you are wrong.
On 7/30/25 11:02 AM, olcott wrote:
_DDD()
[0000219e] 55 push ebp
[0000219f] 8bec mov ebp,esp
[000021a1] 689e210000 push 0000219e
[000021a6] e843f4ffff call 000015ee
[000021ab] 83c404 add esp,+04
[000021ae] 5d pop ebp
[000021af] c3 ret
Size in bytes:(0018) [000021af]
cant' be the full input as not simuatable.
We have been over this too many times. If DDD was
incorrectly emulated by HHH then you could show
the exact x86 instruction of DDD that was emulated
incorrectly when DDD is emulated by HHH or when
DDD is emulated by the emulated HHH.
The Call HHH instruction below.
Or the last instruction it simulates (which is also a call HHH
instruction) in the full trace.
Since the CORRECT simulation of a call instruction includes the
execution of the instruction referenced by the call instruction.
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
Not a correct simulation of the call HHH instruction.
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
On 7/30/2025 6:58 PM, Richard Damon wrote:
On 7/30/25 11:02 AM, olcott wrote:
_DDD()
[0000219e] 55 push ebp
[0000219f] 8bec mov ebp,esp
[000021a1] 689e210000 push 0000219e
[000021a6] e843f4ffff call 000015ee
[000021ab] 83c404 add esp,+04
[000021ae] 5d pop ebp
[000021af] c3 ret
Size in bytes:(0018) [000021af]
cant' be the full input as not simuatable.
We have been over this too many times. If DDD was
incorrectly emulated by HHH then you could show
the exact x86 instruction of DDD that was emulated
incorrectly when DDD is emulated by HHH or when
DDD is emulated by the emulated HHH.
The Call HHH instruction below.
Or the last instruction it simulates (which is also a call HHH
instruction) in the full trace.
Since the CORRECT simulation of a call instruction includes the
execution of the instruction referenced by the call instruction.
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
Not a correct simulation of the call HHH instruction.
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
The above proves that HHH does emulate itself emulating
DDD correctly in that the emulated HHH does emulate DDD
correctly.
It also shows the repeating pattern that DDD correctly
emulated by DDD derives.
Without even having an implemented HHH we can still
see that DDD emulated by an emulated HHH would produce
this same same repeating pattern.
On 7/30/25 8:42 PM, olcott wrote:
On 7/30/2025 6:58 PM, Richard Damon wrote:
On 7/30/25 11:02 AM, olcott wrote:
_DDD()
[0000219e] 55 push ebp
[0000219f] 8bec mov ebp,esp
[000021a1] 689e210000 push 0000219e
[000021a6] e843f4ffff call 000015ee
[000021ab] 83c404 add esp,+04
[000021ae] 5d pop ebp
[000021af] c3 ret
Size in bytes:(0018) [000021af]
cant' be the full input as not simuatable.
We have been over this too many times. If DDD was
incorrectly emulated by HHH then you could show
the exact x86 instruction of DDD that was emulated
incorrectly when DDD is emulated by HHH or when
DDD is emulated by the emulated HHH.
The Call HHH instruction below.
Or the last instruction it simulates (which is also a call HHH
instruction) in the full trace.
Since the CORRECT simulation of a call instruction includes the
execution of the instruction referenced by the call instruction.
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
Not a correct simulation of the call HHH instruction.
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
The above proves that HHH does emulate itself emulating
DDD correctly in that the emulated HHH does emulate DDD
correctly.
No, because you don't show the simulation of the code of HHH.
I guess you don't know what that means.
It also shows the repeating pattern that DDD correctly
emulated by DDD derives.
But that isn't what actually happens. the second copy doesn't actually happen in the actual simulation of the input.
Without even having an implemented HHH we can still
see that DDD emulated by an emulated HHH would produce
this same same repeating pattern.
But if HHH isn't implements, you can't HAVE DDD as a valid input.
All you are doing is proving you are just lying about what you are doing.
You are just proving that your whold argument is based on category
errors and lies.
On 7/30/2025 9:16 PM, Richard Damon wrote:
On 7/30/25 8:42 PM, olcott wrote:
On 7/30/2025 6:58 PM, Richard Damon wrote:
On 7/30/25 11:02 AM, olcott wrote:
_DDD()
[0000219e] 55 push ebp
[0000219f] 8bec mov ebp,esp
[000021a1] 689e210000 push 0000219e
[000021a6] e843f4ffff call 000015ee
[000021ab] 83c404 add esp,+04
[000021ae] 5d pop ebp
[000021af] c3 ret
Size in bytes:(0018) [000021af]
cant' be the full input as not simuatable.
We have been over this too many times. If DDD was
incorrectly emulated by HHH then you could show
the exact x86 instruction of DDD that was emulated
incorrectly when DDD is emulated by HHH or when
DDD is emulated by the emulated HHH.
The Call HHH instruction below.
Or the last instruction it simulates (which is also a call HHH
instruction) in the full trace.
Since the CORRECT simulation of a call instruction includes the
execution of the instruction referenced by the call instruction.
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
Not a correct simulation of the call HHH instruction.
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
The above proves that HHH does emulate itself emulating
DDD correctly in that the emulated HHH does emulate DDD
correctly.
No, because you don't show the simulation of the code of HHH.
Mixing the above 8 instructions in with another 176
pages of instructions does not help understanding
things.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
We can know that HHH did correctly emulate itself
emulating DDD because this emulated HHH does derive
the correct first four instructions of DDD.
I guess you don't know what that means.
It also shows the repeating pattern that DDD correctly
emulated by DDD derives.
But that isn't what actually happens. the second copy doesn't actually
happen in the actual simulation of the input.
Counter-factual and this proves that it is counter-factual https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Without even having an implemented HHH we can still
see that DDD emulated by an emulated HHH would produce
this same same repeating pattern.
But if HHH isn't implements, you can't HAVE DDD as a valid input.
HHH is implemented yet too difficult for you to
understand so we verify that DDD does emulate
itself emulating DDD in that its emulated DDD
does emulate the first four instructions of DDD
as shown above.
All you are doing is proving you are just lying about what you are doing.
That you call me a liar could get you condemned to actual Hell.
Revelations 21:8
...all liars, their lot shall be in the lake that burns
with fire and sulphur, which is the second death.”
You are just proving that your whold argument is based on category
errors and lies.
That you keep changing the words that I say to make your
rebuttal easier is the strawman deception can could get you
condemned to actual Hell.
On 7/31/25 12:26 PM, olcott wrote:
On 7/30/2025 9:16 PM, Richard Damon wrote:
On 7/30/25 8:42 PM, olcott wrote:
On 7/30/2025 6:58 PM, Richard Damon wrote:
On 7/30/25 11:02 AM, olcott wrote:
_DDD()
[0000219e] 55 push ebp
[0000219f] 8bec mov ebp,esp
[000021a1] 689e210000 push 0000219e
[000021a6] e843f4ffff call 000015ee
[000021ab] 83c404 add esp,+04
[000021ae] 5d pop ebp
[000021af] c3 ret
Size in bytes:(0018) [000021af]
cant' be the full input as not simuatable.
We have been over this too many times. If DDD was
incorrectly emulated by HHH then you could show
the exact x86 instruction of DDD that was emulated
incorrectly when DDD is emulated by HHH or when
DDD is emulated by the emulated HHH.
The Call HHH instruction below.
Or the last instruction it simulates (which is also a call HHH
instruction) in the full trace.
Since the CORRECT simulation of a call instruction includes the
execution of the instruction referenced by the call instruction.
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
Not a correct simulation of the call HHH instruction.
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 >>>>>>
The above proves that HHH does emulate itself emulating
DDD correctly in that the emulated HHH does emulate DDD
correctly.
No, because you don't show the simulation of the code of HHH.
Mixing the above 8 instructions in with another 176
pages of instructions does not help understanding
things.
And FAILING to do it is just a lie.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Which, as has been pointed out, NOT the trace generated by HHH
simulating DDD, as it begins at main, which HHH NEVER simulates.
On 7/31/2025 6:34 PM, Richard Damon wrote:
On 7/31/25 12:26 PM, olcott wrote:
On 7/30/2025 9:16 PM, Richard Damon wrote:
On 7/30/25 8:42 PM, olcott wrote:
On 7/30/2025 6:58 PM, Richard Damon wrote:
On 7/30/25 11:02 AM, olcott wrote:
_DDD()
[0000219e] 55 push ebp
[0000219f] 8bec mov ebp,esp
[000021a1] 689e210000 push 0000219e
[000021a6] e843f4ffff call 000015ee
[000021ab] 83c404 add esp,+04
[000021ae] 5d pop ebp
[000021af] c3 ret
Size in bytes:(0018) [000021af]
cant' be the full input as not simuatable.
We have been over this too many times. If DDD was
incorrectly emulated by HHH then you could show
the exact x86 instruction of DDD that was emulated
incorrectly when DDD is emulated by HHH or when
DDD is emulated by the emulated HHH.
The Call HHH instruction below.
Or the last instruction it simulates (which is also a call HHH
instruction) in the full trace.
Since the CORRECT simulation of a call instruction includes the
execution of the instruction referenced by the call instruction.
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
Not a correct simulation of the call HHH instruction.
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 >>>>>>>
The above proves that HHH does emulate itself emulating
DDD correctly in that the emulated HHH does emulate DDD
correctly.
No, because you don't show the simulation of the code of HHH.
Mixing the above 8 instructions in with another 176
pages of instructions does not help understanding
things.
And FAILING to do it is just a lie.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Which, as has been pointed out, NOT the trace generated by HHH
simulating DDD, as it begins at main, which HHH NEVER simulates.
HHH simulates DDD then simulates a different instance
of itself simulating a different instance of DDD which
calls another different instance of HHH(DDD)...
On 7/30/2025 4:23 AM, Fred. Zwarts wrote:
Op 30.jul.2025 om 05:12 schreef olcott:*I challenge you to show a premature abort*
Indeed. But there are different reasons:
This just occurred to me:
*HHH(DDD)==0 is also correct for another different reason*
Even if we construed the HHH that DDD calls a part of the
program under test it is true that neither the simulated
DDD nor the simulated HHH cannot possibly reach their own
final halt state.
The simulating HHH fails to reach the final halt state of the
simulation because it does a premature abort,
_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 been over this too many times. If it actually
is a premature abort then you could specify the number
of N instructions of DDD that must be correctly emulated
by HHH such that DDD reaches its own final halt state.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
Failing to do that proves that you are wrong.
Because we have been over this so many times I am
convinced that you already know that you are wrong
and are just trolling me.
There is no stack unwinding when HHH sees DDD calls the
same function with the same parameter twice in sequence.
At this point HHH kills the whole DDD process including
all recursive emulations.
based on the wrong assumption that a finite recursion specifies non-
halting.
Halting is defined as reaching the "return" statement
final halt state. It is not defined as stopping running
for any reason otherwise both of these would be determined
to be halting:
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
Because they stop running as soon as their process it killed.
Then the simulating HHH does reach its own halt state when it reports
non-halting.
Yet neither the simulated DDD nor the simulated HHH
can possibly reach their own final halt state
The simulated HHH, that has a similar final halt state after it aborts,
The simulated HHH cannot possibly abort because the directly
executed HHH is always one whole recursive simulation ahead
thus reaching its abort criteria first.
After HHH sees that its simulated DDD is calling the same
function with the same parameter twice in sequence it kills
the whole simulated process. Even if it waited to see this
35 times in sequence the next inner one would have only seen
it 34 times, thus has not met its own abort criteria.
does not reach it own final halt state, because the simulating HHH
does not allow it to reach it by the premature abort done by the
simulating HHH.
You cannot prove that your use of the term "premature abort"
is anything besides a misconception. *See above challenge*
Op 30.jul.2025 om 16:52 schreef olcott:
On 7/30/2025 4:23 AM, Fred. Zwarts wrote:
Op 30.jul.2025 om 05:12 schreef olcott:*I challenge you to show a premature abort*
Indeed. But there are different reasons:
This just occurred to me:
*HHH(DDD)==0 is also correct for another different reason*
Even if we construed the HHH that DDD calls a part of the
program under test it is true that neither the simulated
DDD nor the simulated HHH cannot possibly reach their own
final halt state.
The simulating HHH fails to reach the final halt state of the
simulation because it does a premature abort,
This has been presented tro you many times, but you close your eyes for
it and pretend that it does not exist.>
_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 that the suggestion that these 18 bytes are the whole
input is misleading and incorrect. The input also includes all function called by DDD, directly or indirectly, including the HHH that aborts
after a few cycles.
This input specifies a halting program as other correct simulators and direct execution prove.
We have been over this too many times. If it actually
is a premature abort then you could specify the number
of N instructions of DDD that must be correctly emulated
by HHH such that DDD reaches its own final halt state.
As usual a false claim.
On 8/1/2025 4:00 AM, Fred. Zwarts wrote:
Op 30.jul.2025 om 16:52 schreef olcott:
On 7/30/2025 4:23 AM, Fred. Zwarts wrote:
Op 30.jul.2025 om 05:12 schreef olcott:*I challenge you to show a premature abort*
Indeed. But there are different reasons:
This just occurred to me:
*HHH(DDD)==0 is also correct for another different reason*
Even if we construed the HHH that DDD calls a part of the
program under test it is true that neither the simulated
DDD nor the simulated HHH cannot possibly reach their own
final halt state.
The simulating HHH fails to reach the final halt state of the
simulation because it does a premature abort,
This has been presented tro you many times, but you close your eyes
for it and pretend that it does not exist.>
_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 that the suggestion that these 18 bytes are the whole
input is misleading and incorrect. The input also includes all
function called by DDD, directly or indirectly, including the HHH that
aborts after a few cycles.
This input specifies a halting program as other correct simulators and
direct execution prove.
Neither the directly executed HHH() the directly executed DDD()
not DDD correctly simulated by HHH can possibly ever stop running
unless HHH(DDD) aborts the simulation of its input.
Turing machine halt deciders are only accountable for the
behavior that their inputs specifies thus the behavior
of non-input direct executions has always been outside
of their domain. The DDD correctly simulated by HHH cannot
possibly halt proves that HHH is correct to reject its input.
We have been over this too many times. If it actually
is a premature abort then you could specify the number
of N instructions of DDD that must be correctly emulated
by HHH such that DDD reaches its own final halt state.
As usual a false claim.
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]
If there is an actual *premature abort* then there
is a specific point in the execution trace where
DDD correctly simulated by HHH stops running without
ever being aborted. Otherwise you are using the term
*premature abort* incorrectly.
Am Fri, 01 Aug 2025 10:12:35 -0500 schrieb olcott:
If there is an actual *premature abort* then there is a specific point
in the execution trace where DDD correctly simulated by HHH stops
running without ever being aborted.
Yes, after 12 instructions of DDD only or just before the third
recursive simulation.
On 8/1/2025 10:26 AM, joes wrote:
Am Fri, 01 Aug 2025 10:12:35 -0500 schrieb olcott:Everyone keeps dishonestly changing my words from
If there is an actual *premature abort* then there is a specific point
in the execution trace where DDD correctly simulated by HHH stops
running without ever being aborted.
Yes, after 12 instructions of DDD only or just before the third
recursive simulation.
(a) DDD correctly simulated by HHH (can't possibly halt)
(b) The directly executed DDD (that halts).
Turing machine deciders do not have directly executed
Turing machines in their domain. They only have finite
string machine description in their domain.
This means that when the behavior specified by the correct
simulation of the input disagrees with the behavior of the
direct execution of DDD() it is the behavior specified by
the input that overrules and supersedes.
On 8/1/25 11:44 AM, olcott wrote:
On 8/1/2025 10:26 AM, joes wrote:
Am Fri, 01 Aug 2025 10:12:35 -0500 schrieb olcott:Everyone keeps dishonestly changing my words from
If there is an actual *premature abort* then there is a specific point >>>> in the execution trace where DDD correctly simulated by HHH stops
running without ever being aborted.
Yes, after 12 instructions of DDD only or just before the third
recursive simulation.
(a) DDD correctly simulated by HHH (can't possibly halt)
No, it is that THIS HHH doesn't correctly simulate THIS DDD,
On 8/1/2025 11:00 AM, Richard Damon wrote:
On 8/1/25 11:44 AM, olcott wrote:
On 8/1/2025 10:26 AM, joes wrote:
Am Fri, 01 Aug 2025 10:12:35 -0500 schrieb olcott:Everyone keeps dishonestly changing my words from
If there is an actual *premature abort* then there is a specific point >>>>> in the execution trace where DDD correctly simulated by HHH stops
running without ever being aborted.
Yes, after 12 instructions of DDD only or just before the third
recursive simulation.
(a) DDD correctly simulated by HHH (can't possibly halt)
No, it is that THIS HHH doesn't correctly simulate THIS DDD,
The outermost directly executed HHH does correctly
simulate N instructions of DDD and an instance of
itself in the same separate process context that it
created for DDD.
The correctly simulated instance of itself creates
yet another process context to simulate its own
instance of DDD.
On 8/1/2025 4:00 AM, Fred. Zwarts wrote:
Op 30.jul.2025 om 16:52 schreef olcott:
On 7/30/2025 4:23 AM, Fred. Zwarts wrote:
Op 30.jul.2025 om 05:12 schreef olcott:*I challenge you to show a premature abort*
Indeed. But there are different reasons:
This just occurred to me:
*HHH(DDD)==0 is also correct for another different reason*
Even if we construed the HHH that DDD calls a part of the
program under test it is true that neither the simulated
DDD nor the simulated HHH cannot possibly reach their own
final halt state.
The simulating HHH fails to reach the final halt state of the
simulation because it does a premature abort,
This has been presented tro you many times, but you close your eyes
for it and pretend that it does not exist.>
_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 that the suggestion that these 18 bytes are the whole
input is misleading and incorrect. The input also includes all
function called by DDD, directly or indirectly, including the HHH that
aborts after a few cycles.
This input specifies a halting program as other correct simulators and
direct execution prove.
Neither the directly executed HHH() the directly executed DDD()
not DDD correctly simulated by HHH can possibly ever stop running
unless HHH(DDD) aborts the simulation of its input.
Turing machine halt deciders are only accountable for the
behavior that their inputs specifies thus the behavior
of non-input direct executions has always been outside
of their domain. The DDD correctly simulated by HHH cannot
possibly halt proves that HHH is correct to reject its input.
Illogical, counter-factual and incorrect claim without evidence.
We have been over this too many times. If it actually
is a premature abort then you could specify the number
of N instructions of DDD that must be correctly emulated
by HHH such that DDD reaches its own final halt state.
As usual a false claim.
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]
If there is an actual *premature abort* then there
is a specific point in the execution trace where
DDD correctly simulated by HHH stops running without
ever being aborted. Otherwise you are using the term
*premature abort* incorrectly.
Op 01.aug.2025 om 17:12 schreef olcott:
On 8/1/2025 4:00 AM, Fred. Zwarts wrote:
Op 30.jul.2025 om 16:52 schreef olcott:
On 7/30/2025 4:23 AM, Fred. Zwarts wrote:
Op 30.jul.2025 om 05:12 schreef olcott:*I challenge you to show a premature abort*
Indeed. But there are different reasons:
This just occurred to me:
*HHH(DDD)==0 is also correct for another different reason*
Even if we construed the HHH that DDD calls a part of the
program under test it is true that neither the simulated
DDD nor the simulated HHH cannot possibly reach their own
final halt state.
The simulating HHH fails to reach the final halt state of the
simulation because it does a premature abort,
This has been presented tro you many times, but you close your eyes
for it and pretend that it does not exist.>
_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 that the suggestion that these 18 bytes are the
whole input is misleading and incorrect. The input also includes all
function called by DDD, directly or indirectly, including the HHH
that aborts after a few cycles.
This input specifies a halting program as other correct simulators
and direct execution prove.
Neither the directly executed HHH() the directly executed DDD()
not DDD correctly simulated by HHH can possibly ever stop running
unless HHH(DDD) aborts the simulation of its input.
It is an irrelevant change of subject to imagine a hypothetical non-
input that has no abort code.
Turing machine halt deciders are only accountable for the
behavior that their inputs specifies thus the behavior
of non-input direct executions has always been outside
of their domain. The DDD correctly simulated by HHH cannot
possibly halt proves that HHH is correct to reject its input.
No, it shows that HHH fails to reach the final halt state, where a
simulator (even when named HHH) that does not abort,has no problem to
reach the final halt state.
We have been over this too many times. If it actually
is a premature abort then you could specify the number
of N instructions of DDD that must be correctly emulated
by HHH such that DDD reaches its own final halt state.
As usual a false claim.
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]
If there is an actual *premature abort* then there
is a specific point in the execution trace where
DDD correctly simulated by HHH stops running without
ever being aborted. Otherwise you are using the term
*premature abort* incorrectly.
Illogical, counter-factual and incorrect claim without evidence.
It is exactly the premature abort that causes that the final halt state
is not reached. Of, course the trace of that prematurely aborted
simulation does not show the last part of a correct simulation.
But a comparison with a correct simulation done by e.g. HHH1, shows the exact point where the final halt state is reached and where HHH does the premature abort.
On 8/2/2025 4:30 AM, Fred. Zwarts wrote:
Op 01.aug.2025 om 17:12 schreef olcott:
On 8/1/2025 4:00 AM, Fred. Zwarts wrote:
Op 30.jul.2025 om 16:52 schreef olcott:
On 7/30/2025 4:23 AM, Fred. Zwarts wrote:
Op 30.jul.2025 om 05:12 schreef olcott:*I challenge you to show a premature abort*
Indeed. But there are different reasons:
This just occurred to me:
*HHH(DDD)==0 is also correct for another different reason*
Even if we construed the HHH that DDD calls a part of the
program under test it is true that neither the simulated
DDD nor the simulated HHH cannot possibly reach their own
final halt state.
The simulating HHH fails to reach the final halt state of the
simulation because it does a premature abort,
This has been presented tro you many times, but you close your eyes
for it and pretend that it does not exist.>
_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 that the suggestion that these 18 bytes are the
whole input is misleading and incorrect. The input also includes all
function called by DDD, directly or indirectly, including the HHH
that aborts after a few cycles.
This input specifies a halting program as other correct simulators
and direct execution prove.
Neither the directly executed HHH() the directly executed DDD()
not DDD correctly simulated by HHH can possibly ever stop running
unless HHH(DDD) aborts the simulation of its input.
It is an irrelevant change of subject to imagine a hypothetical non-
input that has no abort code.
*Not according to the leading author of theory of computation textbooks*
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
would never stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
Turing machine halt deciders are only accountable for the
behavior that their inputs specifies thus the behavior
of non-input direct executions has always been outside
of their domain. The DDD correctly simulated by HHH cannot
possibly halt proves that HHH is correct to reject its input.
No, it shows that HHH fails to reach the final halt state, where a
simulator (even when named HHH) that does not abort,has no problem to
reach the final halt state.
Where the Hell are you getting that from?
_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]
Prove your statement on this code.
We have been over this too many times. If it actually
is a premature abort then you could specify the number
of N instructions of DDD that must be correctly emulated
by HHH such that DDD reaches its own final halt state.
As usual a false claim.
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]
If there is an actual *premature abort* then there
is a specific point in the execution trace where
DDD correctly simulated by HHH stops running without
ever being aborted. Otherwise you are using the term
*premature abort* incorrectly.
Illogical, counter-factual and incorrect claim without evidence.
What do you mean by premature abort?
The actual word "premature" means too early.
If the abort is too early then there is a point
in the execution trace that is not too early.
It is exactly the premature abort that causes that the final halt
state is not reached. Of, course the trace of that prematurely aborted
simulation does not show the last part of a correct simulation.
In other words when DDD calls its own simulator HHH in
recursive simulation this is exactly the same thing as
DDD never calling its own simulator HHH1 in recursive
simulation?
Sounds like 1984 newspeak to me.
https://en.wikipedia.org/wiki/Newspeak
But a comparison with a correct simulation done by e.g. HHH1, shows
the exact point where the final halt state is reached and where HHH
does the premature abort.
Sysop: | DaiTengu |
---|---|
Location: | Appleton, WI |
Users: | 1,064 |
Nodes: | 10 (0 / 10) |
Uptime: | 146:20:50 |
Calls: | 13,691 |
Calls today: | 1 |
Files: | 186,935 |
D/L today: |
22 files (1,452K bytes) |
Messages: | 2,410,869 |