On 4/24/2025 6:14 PM, Richard Damon wrote:
On 4/24/25 5:13 PM, olcott wrote:
On 4/24/2025 5:59 AM, Richard Damon wrote:
On 4/23/25 11:22 PM, polcott333 wrote:
On 4/23/2025 9:41 PM, Richard Damon wrote:
On 4/23/25 11:32 AM, olcott wrote:
On 4/23/2025 6:25 AM, joes wrote:
Am Tue, 22 Apr 2025 13:51:48 -0500 schrieb olcott:
On 4/22/2025 1:07 PM, Fred. Zwarts wrote:No, DD halts (when executed directly). HHH is not a halt
Op 22.apr.2025 om 18:28 schreef olcott:
On 4/22/2025 7:57 AM, joes wrote:
Am Tue, 15 Apr 2025 15:44:06 -0500 schrieb olcott:
libx86emu <is> a correct x86 processor and does emulate its >>>>>>>>>>> inputsYou continue to stupidly insist that int sum(int x, int y) >>>>>>>>>>>>> {return xWhat else is it missing that the processor uses to execute it? >>>>>>>>>>>>
+ y; }
returns 7 for sum(3,2) because you incorrectly understand >>>>>>>>>>>>> how these
things fundamentally work.
It is stupidly wrong to expect HHH(DD) report on the direct >>>>>>>>>>>>> execution of DD when you are not telling it one damn thing >>>>>>>>>>>>> about
this direct execution.
correctly.
The key thing here is that Olcott consistently does not
understand that
HHH is given a finite string input that according to the
semantics of
the x86 language specifies a halting program,
That is stupidly incorrect.
decider, not even
for DD only.
People here stupidly assume that the outputs are not required to >>>>>>>>> correspond to the inputs.But the direct execution of DD is computable from its description. >>>>>>>>
Not as an input to HHH.
But neither the "direct execution" or the "simulation by HHH" are
"inputs" to HHH. What is the input is the representation of the
program to be decided on.
When HHH computes halting for DD is is only allowed
to apply the finite string transformations specified
by the x86 language to the machine code of DD.
It is only ABLE to apply them.
The input to HHH(DD) does specify the recursive emulation
of DD including HHH emulating itself emulating DD when
one applies the finite string transformation rules of the
x86 language to THE INPUT to HHH(DD).
Yes, the input specifies FINITE recusive PARTIAL emulation, as the
HHH that DD calls will emulate only a few instructions of DD and
then return,
*You are technically incompetent on this point*
When the finite string transformation rules of the
x86 language are applied to the input to HHH(DD)
THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE
not even after an infinite number of emulated steps.
Sure it does, just after the point that HHH gives up on those
transformation and aborts its (now incorrect) emulation of the input.
THAT IS COUNTER FACTUAL !!!
The directly executed DD has zero recursive invocations.
DD emulated by HHH has one recursive invocation.
Did you know that zero does not equal one?
On 4/24/2025 6:14 PM, Richard Damon wrote:
On 4/24/25 5:13 PM, olcott wrote:
On 4/24/2025 5:59 AM, Richard Damon wrote:
On 4/23/25 11:22 PM, polcott333 wrote:
On 4/23/2025 9:41 PM, Richard Damon wrote:
On 4/23/25 11:32 AM, olcott wrote:
On 4/23/2025 6:25 AM, joes wrote:
Am Tue, 22 Apr 2025 13:51:48 -0500 schrieb olcott:
On 4/22/2025 1:07 PM, Fred. Zwarts wrote:No, DD halts (when executed directly). HHH is not a halt
Op 22.apr.2025 om 18:28 schreef olcott:
On 4/22/2025 7:57 AM, joes wrote:
Am Tue, 15 Apr 2025 15:44:06 -0500 schrieb olcott:
libx86emu <is> a correct x86 processor and does emulate its >>>>>>>>>>> inputsYou continue to stupidly insist that int sum(int x, int y) >>>>>>>>>>>>> {return xWhat else is it missing that the processor uses to execute it? >>>>>>>>>>>>
+ y; }
returns 7 for sum(3,2) because you incorrectly understand >>>>>>>>>>>>> how these
things fundamentally work.
It is stupidly wrong to expect HHH(DD) report on the direct >>>>>>>>>>>>> execution of DD when you are not telling it one damn thing >>>>>>>>>>>>> about
this direct execution.
correctly.
The key thing here is that Olcott consistently does not
understand that
HHH is given a finite string input that according to the
semantics of
the x86 language specifies a halting program,
That is stupidly incorrect.
decider, not even
for DD only.
People here stupidly assume that the outputs are not required to >>>>>>>>> correspond to the inputs.But the direct execution of DD is computable from its description. >>>>>>>>
Not as an input to HHH.
But neither the "direct execution" or the "simulation by HHH" are
"inputs" to HHH. What is the input is the representation of the
program to be decided on.
When HHH computes halting for DD is is only allowed
to apply the finite string transformations specified
by the x86 language to the machine code of DD.
It is only ABLE to apply them.
The input to HHH(DD) does specify the recursive emulation
of DD including HHH emulating itself emulating DD when
one applies the finite string transformation rules of the
x86 language to THE INPUT to HHH(DD).
Yes, the input specifies FINITE recusive PARTIAL emulation, as the
HHH that DD calls will emulate only a few instructions of DD and
then return,
*You are technically incompetent on this point*
When the finite string transformation rules of the
x86 language are applied to the input to HHH(DD)
THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE
not even after an infinite number of emulated steps.
Sure it does, just after the point that HHH gives up on those
transformation and aborts its (now incorrect) emulation of the input.
THAT IS COUNTER FACTUAL !!!
The directly executed DD has zero recursive invocations.
DD emulated by HHH has one recursive invocation.
Did you know that zero does not equal one?
On 4/24/2025 7:07 PM, Richard Damon wrote:
On 4/24/25 7:58 PM, olcott wrote:
On 4/24/2025 6:14 PM, Richard Damon wrote:
On 4/24/25 5:13 PM, olcott wrote:
On 4/24/2025 5:59 AM, Richard Damon wrote:
On 4/23/25 11:22 PM, polcott333 wrote:
On 4/23/2025 9:41 PM, Richard Damon wrote:
On 4/23/25 11:32 AM, olcott wrote:
On 4/23/2025 6:25 AM, joes wrote:
Am Tue, 22 Apr 2025 13:51:48 -0500 schrieb olcott:
On 4/22/2025 1:07 PM, Fred. Zwarts wrote:No, DD halts (when executed directly). HHH is not a halt
Op 22.apr.2025 om 18:28 schreef olcott:
On 4/22/2025 7:57 AM, joes wrote:
Am Tue, 15 Apr 2025 15:44:06 -0500 schrieb olcott:
libx86emu <is> a correct x86 processor and does emulate its >>>>>>>>>>>>> inputsYou continue to stupidly insist that int sum(int x, int >>>>>>>>>>>>>>> y) {return xWhat else is it missing that the processor uses to execute >>>>>>>>>>>>>> it?
+ y; }
returns 7 for sum(3,2) because you incorrectly understand >>>>>>>>>>>>>>> how these
things fundamentally work.
It is stupidly wrong to expect HHH(DD) report on the direct >>>>>>>>>>>>>>> execution of DD when you are not telling it one damn >>>>>>>>>>>>>>> thing about
this direct execution.
correctly.
The key thing here is that Olcott consistently does not >>>>>>>>>>>> understand that
HHH is given a finite string input that according to the >>>>>>>>>>>> semantics of
the x86 language specifies a halting program,
That is stupidly incorrect.
decider, not even
for DD only.
People here stupidly assume that the outputs are not required to >>>>>>>>>>> correspond to the inputs.But the direct execution of DD is computable from its
description.
Not as an input to HHH.
But neither the "direct execution" or the "simulation by HHH"
are "inputs" to HHH. What is the input is the representation of >>>>>>>> the program to be decided on.
When HHH computes halting for DD is is only allowed
to apply the finite string transformations specified
by the x86 language to the machine code of DD.
It is only ABLE to apply them.
The input to HHH(DD) does specify the recursive emulation
of DD including HHH emulating itself emulating DD when
one applies the finite string transformation rules of the
x86 language to THE INPUT to HHH(DD).
Yes, the input specifies FINITE recusive PARTIAL emulation, as the >>>>>> HHH that DD calls will emulate only a few instructions of DD and
then return,
*You are technically incompetent on this point*
When the finite string transformation rules of the
x86 language are applied to the input to HHH(DD)
THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE
not even after an infinite number of emulated steps.
Sure it does, just after the point that HHH gives up on those
transformation and aborts its (now incorrect) emulation of the input.
THAT IS COUNTER FACTUAL !!!
The directly executed DD has zero recursive invocations.
DD emulated by HHH has one recursive invocation.
Did you know that zero does not equal one?
But the direct execution DOES have a recursiove invocation, as DD
calls HHH(DD) that emulated DD, just like the directly exeucted HHH
will emulate DD calling HHH(DD).
The call from the directly executed DD to HHH(DD)
immediately returns and DD reaches its final halt state.
The call to HHH(DD) from DD emulated by HHH causes
HHH to emulate itself emulating DD.
On 4/24/2025 7:07 PM, Richard Damon wrote:
On 4/24/25 7:58 PM, olcott wrote:
On 4/24/2025 6:14 PM, Richard Damon wrote:
On 4/24/25 5:13 PM, olcott wrote:
On 4/24/2025 5:59 AM, Richard Damon wrote:
On 4/23/25 11:22 PM, polcott333 wrote:
On 4/23/2025 9:41 PM, Richard Damon wrote:
On 4/23/25 11:32 AM, olcott wrote:
On 4/23/2025 6:25 AM, joes wrote:
Am Tue, 22 Apr 2025 13:51:48 -0500 schrieb olcott:
On 4/22/2025 1:07 PM, Fred. Zwarts wrote:No, DD halts (when executed directly). HHH is not a halt
Op 22.apr.2025 om 18:28 schreef olcott:
On 4/22/2025 7:57 AM, joes wrote:
Am Tue, 15 Apr 2025 15:44:06 -0500 schrieb olcott:
libx86emu <is> a correct x86 processor and does emulate its >>>>>>>>>>>>> inputsYou continue to stupidly insist that int sum(int x, int >>>>>>>>>>>>>>> y) {return xWhat else is it missing that the processor uses to execute >>>>>>>>>>>>>> it?
+ y; }
returns 7 for sum(3,2) because you incorrectly understand >>>>>>>>>>>>>>> how these
things fundamentally work.
It is stupidly wrong to expect HHH(DD) report on the direct >>>>>>>>>>>>>>> execution of DD when you are not telling it one damn >>>>>>>>>>>>>>> thing about
this direct execution.
correctly.
The key thing here is that Olcott consistently does not >>>>>>>>>>>> understand that
HHH is given a finite string input that according to the >>>>>>>>>>>> semantics of
the x86 language specifies a halting program,
That is stupidly incorrect.
decider, not even
for DD only.
People here stupidly assume that the outputs are not required to >>>>>>>>>>> correspond to the inputs.But the direct execution of DD is computable from its
description.
Not as an input to HHH.
But neither the "direct execution" or the "simulation by HHH"
are "inputs" to HHH. What is the input is the representation of >>>>>>>> the program to be decided on.
When HHH computes halting for DD is is only allowed
to apply the finite string transformations specified
by the x86 language to the machine code of DD.
It is only ABLE to apply them.
The input to HHH(DD) does specify the recursive emulation
of DD including HHH emulating itself emulating DD when
one applies the finite string transformation rules of the
x86 language to THE INPUT to HHH(DD).
Yes, the input specifies FINITE recusive PARTIAL emulation, as the >>>>>> HHH that DD calls will emulate only a few instructions of DD and
then return,
*You are technically incompetent on this point*
When the finite string transformation rules of the
x86 language are applied to the input to HHH(DD)
THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE
not even after an infinite number of emulated steps.
Sure it does, just after the point that HHH gives up on those
transformation and aborts its (now incorrect) emulation of the input.
THAT IS COUNTER FACTUAL !!!
The directly executed DD has zero recursive invocations.
DD emulated by HHH has one recursive invocation.
Did you know that zero does not equal one?
But the direct execution DOES have a recursiove invocation, as DD
calls HHH(DD) that emulated DD, just like the directly exeucted HHH
will emulate DD calling HHH(DD).
The call from the directly executed DD to HHH(DD)
immediately returns and DD reaches its final halt state.
The call to HHH(DD) from DD emulated by HHH causes
HHH to emulate itself emulating DD. DD cannot possibly
reach its final halt state without violating the finite
string transformation rules of the x86 language.
On 4/25/2025 8:36 AM, Richard Damon wrote:
On 4/25/25 9:08 AM, olcott wrote:
On 4/24/2025 7:07 PM, Richard Damon wrote:
On 4/24/25 7:58 PM, olcott wrote:
On 4/24/2025 6:14 PM, Richard Damon wrote:
On 4/24/25 5:13 PM, olcott wrote:
On 4/24/2025 5:59 AM, Richard Damon wrote:
On 4/23/25 11:22 PM, polcott333 wrote:
On 4/23/2025 9:41 PM, Richard Damon wrote:
On 4/23/25 11:32 AM, olcott wrote:
On 4/23/2025 6:25 AM, joes wrote:
Am Tue, 22 Apr 2025 13:51:48 -0500 schrieb olcott:
On 4/22/2025 1:07 PM, Fred. Zwarts wrote:No, DD halts (when executed directly). HHH is not a halt >>>>>>>>>>>> decider, not even
Op 22.apr.2025 om 18:28 schreef olcott:
On 4/22/2025 7:57 AM, joes wrote:
Am Tue, 15 Apr 2025 15:44:06 -0500 schrieb olcott: >>>>>>>>>>>>libx86emu <is> a correct x86 processor and does emulate >>>>>>>>>>>>>>> its inputs
You continue to stupidly insist that int sum(int x, int >>>>>>>>>>>>>>>>> y) {return xWhat else is it missing that the processor uses to >>>>>>>>>>>>>>>> execute it?
+ y; }
returns 7 for sum(3,2) because you incorrectly >>>>>>>>>>>>>>>>> understand how these
things fundamentally work.
It is stupidly wrong to expect HHH(DD) report on the >>>>>>>>>>>>>>>>> direct
execution of DD when you are not telling it one damn >>>>>>>>>>>>>>>>> thing about
this direct execution.
correctly.
The key thing here is that Olcott consistently does not >>>>>>>>>>>>>> understand that
HHH is given a finite string input that according to the >>>>>>>>>>>>>> semantics of
the x86 language specifies a halting program,
That is stupidly incorrect.
for DD only.
People here stupidly assume that the outputs are not >>>>>>>>>>>>> required toBut the direct execution of DD is computable from its
correspond to the inputs.
description.
Not as an input to HHH.
But neither the "direct execution" or the "simulation by HHH" >>>>>>>>>> are "inputs" to HHH. What is the input is the representation >>>>>>>>>> of the program to be decided on.
When HHH computes halting for DD is is only allowed
to apply the finite string transformations specified
by the x86 language to the machine code of DD.
It is only ABLE to apply them.
The input to HHH(DD) does specify the recursive emulation
of DD including HHH emulating itself emulating DD when
one applies the finite string transformation rules of the
x86 language to THE INPUT to HHH(DD).
Yes, the input specifies FINITE recusive PARTIAL emulation, as >>>>>>>> the HHH that DD calls will emulate only a few instructions of DD >>>>>>>> and then return,
*You are technically incompetent on this point*
When the finite string transformation rules of the
x86 language are applied to the input to HHH(DD)
THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE
not even after an infinite number of emulated steps.
Sure it does, just after the point that HHH gives up on those
transformation and aborts its (now incorrect) emulation of the input. >>>>>>
THAT IS COUNTER FACTUAL !!!
The directly executed DD has zero recursive invocations.
DD emulated by HHH has one recursive invocation.
Did you know that zero does not equal one?
But the direct execution DOES have a recursiove invocation, as DD
calls HHH(DD) that emulated DD, just like the directly exeucted HHH
will emulate DD calling HHH(DD).
The call from the directly executed DD to HHH(DD)
immediately returns and DD reaches its final halt state.
No it doesn't,
I will say that more accurately.
The call from the directly executed DD returns.
The call from DD emulated by HHH to HHH(DD)
(according to the finite string transformation
rules of the x86 language) CANNOT POSSIBLY RETURN.
On 4/25/2025 8:30 AM, Fred. Zwarts wrote:
Op 25.apr.2025 om 15:08 schreef olcott:
On 4/24/2025 7:07 PM, Richard Damon wrote:
On 4/24/25 7:58 PM, olcott wrote:
On 4/24/2025 6:14 PM, Richard Damon wrote:
On 4/24/25 5:13 PM, olcott wrote:
On 4/24/2025 5:59 AM, Richard Damon wrote:
On 4/23/25 11:22 PM, polcott333 wrote:
On 4/23/2025 9:41 PM, Richard Damon wrote:
On 4/23/25 11:32 AM, olcott wrote:
On 4/23/2025 6:25 AM, joes wrote:
Am Tue, 22 Apr 2025 13:51:48 -0500 schrieb olcott:
On 4/22/2025 1:07 PM, Fred. Zwarts wrote:No, DD halts (when executed directly). HHH is not a halt >>>>>>>>>>>> decider, not even
Op 22.apr.2025 om 18:28 schreef olcott:
On 4/22/2025 7:57 AM, joes wrote:
Am Tue, 15 Apr 2025 15:44:06 -0500 schrieb olcott: >>>>>>>>>>>>libx86emu <is> a correct x86 processor and does emulate >>>>>>>>>>>>>>> its inputs
You continue to stupidly insist that int sum(int x, int >>>>>>>>>>>>>>>>> y) {return xWhat else is it missing that the processor uses to >>>>>>>>>>>>>>>> execute it?
+ y; }
returns 7 for sum(3,2) because you incorrectly >>>>>>>>>>>>>>>>> understand how these
things fundamentally work.
It is stupidly wrong to expect HHH(DD) report on the >>>>>>>>>>>>>>>>> direct
execution of DD when you are not telling it one damn >>>>>>>>>>>>>>>>> thing about
this direct execution.
correctly.
The key thing here is that Olcott consistently does not >>>>>>>>>>>>>> understand that
HHH is given a finite string input that according to the >>>>>>>>>>>>>> semantics of
the x86 language specifies a halting program,
That is stupidly incorrect.
for DD only.
People here stupidly assume that the outputs are not >>>>>>>>>>>>> required toBut the direct execution of DD is computable from its
correspond to the inputs.
description.
Not as an input to HHH.
But neither the "direct execution" or the "simulation by HHH" >>>>>>>>>> are "inputs" to HHH. What is the input is the representation >>>>>>>>>> of the program to be decided on.
When HHH computes halting for DD is is only allowed
to apply the finite string transformations specified
by the x86 language to the machine code of DD.
It is only ABLE to apply them.
The input to HHH(DD) does specify the recursive emulation
of DD including HHH emulating itself emulating DD when
one applies the finite string transformation rules of the
x86 language to THE INPUT to HHH(DD).
Yes, the input specifies FINITE recusive PARTIAL emulation, as >>>>>>>> the HHH that DD calls will emulate only a few instructions of DD >>>>>>>> and then return,
*You are technically incompetent on this point*
When the finite string transformation rules of the
x86 language are applied to the input to HHH(DD)
THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE
not even after an infinite number of emulated steps.
Sure it does, just after the point that HHH gives up on those
transformation and aborts its (now incorrect) emulation of the input. >>>>>>
THAT IS COUNTER FACTUAL !!!
The directly executed DD has zero recursive invocations.
DD emulated by HHH has one recursive invocation.
Did you know that zero does not equal one?
But the direct execution DOES have a recursiove invocation, as DD
calls HHH(DD) that emulated DD, just like the directly exeucted HHH
will emulate DD calling HHH(DD).
The call from the directly executed DD to HHH(DD)
... causes HHH to simulate DD. In this simulation DD calls HHH, but
the simulating HHH aborts and after that ...
immediately returns and DD reaches its final halt state.
The call to HHH(DD) from DD emulated by HHH causes
HHH to emulate itself emulating DD.
The simulating HHH prevents the simulated DD to call the simulated
HHH, so that it prevents DD to reach its end.
This is against the rules of the x86 language.
One call returns that other call cannot possibly return.
Are you merely troll?
On 4/25/2025 1:50 PM, Richard Damon wrote:
On 4/25/25 2:42 PM, olcott wrote:
On 4/25/2025 8:36 AM, Richard Damon wrote:
On 4/25/25 9:08 AM, olcott wrote:
On 4/24/2025 7:07 PM, Richard Damon wrote:
On 4/24/25 7:58 PM, olcott wrote:
On 4/24/2025 6:14 PM, Richard Damon wrote:
On 4/24/25 5:13 PM, olcott wrote:
On 4/24/2025 5:59 AM, Richard Damon wrote:
On 4/23/25 11:22 PM, polcott333 wrote:
On 4/23/2025 9:41 PM, Richard Damon wrote:
On 4/23/25 11:32 AM, olcott wrote:
On 4/23/2025 6:25 AM, joes wrote:
Am Tue, 22 Apr 2025 13:51:48 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 4/22/2025 1:07 PM, Fred. Zwarts wrote:
No, DD halts (when executed directly). HHH is not a halt >>>>>>>>>>>>>> decider, not evenOp 22.apr.2025 om 18:28 schreef olcott:
On 4/22/2025 7:57 AM, joes wrote:
Am Tue, 15 Apr 2025 15:44:06 -0500 schrieb olcott: >>>>>>>>>>>>>>libx86emu <is> a correct x86 processor and does emulate >>>>>>>>>>>>>>>>> its inputs
You continue to stupidly insist that int sum(int x, >>>>>>>>>>>>>>>>>>> int y) {return xWhat else is it missing that the processor uses to >>>>>>>>>>>>>>>>>> execute it?
+ y; }
returns 7 for sum(3,2) because you incorrectly >>>>>>>>>>>>>>>>>>> understand how these
things fundamentally work.
It is stupidly wrong to expect HHH(DD) report on the >>>>>>>>>>>>>>>>>>> direct
execution of DD when you are not telling it one damn >>>>>>>>>>>>>>>>>>> thing about
this direct execution.
correctly.
The key thing here is that Olcott consistently does not >>>>>>>>>>>>>>>> understand that
HHH is given a finite string input that according to the >>>>>>>>>>>>>>>> semantics of
the x86 language specifies a halting program,
That is stupidly incorrect.
for DD only.
People here stupidly assume that the outputs are not >>>>>>>>>>>>>>> required toBut the direct execution of DD is computable from its >>>>>>>>>>>>>> description.
correspond to the inputs.
Not as an input to HHH.
But neither the "direct execution" or the "simulation by >>>>>>>>>>>> HHH" are "inputs" to HHH. What is the input is the
representation of the program to be decided on.
When HHH computes halting for DD is is only allowed
to apply the finite string transformations specified >>>>>>>>>>>>> by the x86 language to the machine code of DD.
It is only ABLE to apply them.
The input to HHH(DD) does specify the recursive emulation >>>>>>>>>>> of DD including HHH emulating itself emulating DD when
one applies the finite string transformation rules of the >>>>>>>>>>> x86 language to THE INPUT to HHH(DD).
Yes, the input specifies FINITE recusive PARTIAL emulation, as >>>>>>>>>> the HHH that DD calls will emulate only a few instructions of >>>>>>>>>> DD and then return,
*You are technically incompetent on this point*
When the finite string transformation rules of the
x86 language are applied to the input to HHH(DD)
THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE
not even after an infinite number of emulated steps.
Sure it does, just after the point that HHH gives up on those
transformation and aborts its (now incorrect) emulation of the >>>>>>>> input.
THAT IS COUNTER FACTUAL !!!
The directly executed DD has zero recursive invocations.
DD emulated by HHH has one recursive invocation.
Did you know that zero does not equal one?
But the direct execution DOES have a recursiove invocation, as DD
calls HHH(DD) that emulated DD, just like the directly exeucted
HHH will emulate DD calling HHH(DD).
The call from the directly executed DD to HHH(DD)
immediately returns and DD reaches its final halt state.
No it doesn't,
I will say that more accurately.
The call from the directly executed DD returns.
yes
The call from DD emulated by HHH to HHH(DD)
(according to the finite string transformation
rules of the x86 language) CANNOT POSSIBLY RETURN.
But only becuase HHH stopped before it does,
*It is really not that hard*
Many C programmers said they get this (two of them
with masters degrees in computer science)
Is there any hypothetical HHH that emulates 0 to ∞
steps of DD where DD reaches its final halt state?
No !!!
On 4/25/2025 8:36 AM, Richard Damon wrote:Indeed, HHH is programmed such that it fails to reach the end of the
On 4/25/25 9:08 AM, olcott wrote:
On 4/24/2025 7:07 PM, Richard Damon wrote:
On 4/24/25 7:58 PM, olcott wrote:
On 4/24/2025 6:14 PM, Richard Damon wrote:
On 4/24/25 5:13 PM, olcott wrote:
On 4/24/2025 5:59 AM, Richard Damon wrote:
On 4/23/25 11:22 PM, polcott333 wrote:
On 4/23/2025 9:41 PM, Richard Damon wrote:
On 4/23/25 11:32 AM, olcott wrote:
On 4/23/2025 6:25 AM, joes wrote:
Am Tue, 22 Apr 2025 13:51:48 -0500 schrieb olcott:
On 4/22/2025 1:07 PM, Fred. Zwarts wrote:No, DD halts (when executed directly). HHH is not a halt >>>>>>>>>>>> decider, not even
Op 22.apr.2025 om 18:28 schreef olcott:
On 4/22/2025 7:57 AM, joes wrote:
Am Tue, 15 Apr 2025 15:44:06 -0500 schrieb olcott: >>>>>>>>>>>>libx86emu <is> a correct x86 processor and does emulate >>>>>>>>>>>>>>> its inputs
You continue to stupidly insist that int sum(int x, int >>>>>>>>>>>>>>>>> y) {return xWhat else is it missing that the processor uses to >>>>>>>>>>>>>>>> execute it?
+ y; }
returns 7 for sum(3,2) because you incorrectly >>>>>>>>>>>>>>>>> understand how these
things fundamentally work.
It is stupidly wrong to expect HHH(DD) report on the >>>>>>>>>>>>>>>>> direct
execution of DD when you are not telling it one damn >>>>>>>>>>>>>>>>> thing about
this direct execution.
correctly.
The key thing here is that Olcott consistently does not >>>>>>>>>>>>>> understand that
HHH is given a finite string input that according to the >>>>>>>>>>>>>> semantics of
the x86 language specifies a halting program,
That is stupidly incorrect.
for DD only.
People here stupidly assume that the outputs are not >>>>>>>>>>>>> required toBut the direct execution of DD is computable from its
correspond to the inputs.
description.
Not as an input to HHH.
But neither the "direct execution" or the "simulation by HHH" >>>>>>>>>> are "inputs" to HHH. What is the input is the representation >>>>>>>>>> of the program to be decided on.
When HHH computes halting for DD is is only allowed
to apply the finite string transformations specified
by the x86 language to the machine code of DD.
It is only ABLE to apply them.
The input to HHH(DD) does specify the recursive emulation
of DD including HHH emulating itself emulating DD when
one applies the finite string transformation rules of the
x86 language to THE INPUT to HHH(DD).
Yes, the input specifies FINITE recusive PARTIAL emulation, as >>>>>>>> the HHH that DD calls will emulate only a few instructions of DD >>>>>>>> and then return,
*You are technically incompetent on this point*
When the finite string transformation rules of the
x86 language are applied to the input to HHH(DD)
THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE
not even after an infinite number of emulated steps.
Sure it does, just after the point that HHH gives up on those
transformation and aborts its (now incorrect) emulation of the input. >>>>>>
THAT IS COUNTER FACTUAL !!!
The directly executed DD has zero recursive invocations.
DD emulated by HHH has one recursive invocation.
Did you know that zero does not equal one?
But the direct execution DOES have a recursiove invocation, as DD
calls HHH(DD) that emulated DD, just like the directly exeucted HHH
will emulate DD calling HHH(DD).
The call from the directly executed DD to HHH(DD)
immediately returns and DD reaches its final halt state.
No it doesn't,
I will say that more accurately.
The call from the directly executed DD returns.
The call from DD emulated by HHH to HHH(DD)
(according to the finite string transformation
rules of the x86 language) CANNOT POSSIBLY RETURN.
On 4/26/2025 3:56 AM, Fred. Zwarts wrote:
Op 25.apr.2025 om 20:42 schreef olcott:
On 4/25/2025 8:36 AM, Richard Damon wrote:Indeed, HHH is programmed such that it fails to reach the end
On 4/25/25 9:08 AM, olcott wrote:
On 4/24/2025 7:07 PM, Richard Damon wrote:
On 4/24/25 7:58 PM, olcott wrote:
On 4/24/2025 6:14 PM, Richard Damon wrote:
On 4/24/25 5:13 PM, olcott wrote:
On 4/24/2025 5:59 AM, Richard Damon wrote:
On 4/23/25 11:22 PM, polcott333 wrote:
On 4/23/2025 9:41 PM, Richard Damon wrote:
On 4/23/25 11:32 AM, olcott wrote:
On 4/23/2025 6:25 AM, joes wrote:
Am Tue, 22 Apr 2025 13:51:48 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 4/22/2025 1:07 PM, Fred. Zwarts wrote:
No, DD halts (when executed directly). HHH is not a halt >>>>>>>>>>>>>> decider, not evenOp 22.apr.2025 om 18:28 schreef olcott:
On 4/22/2025 7:57 AM, joes wrote:
Am Tue, 15 Apr 2025 15:44:06 -0500 schrieb olcott: >>>>>>>>>>>>>>libx86emu <is> a correct x86 processor and does emulate >>>>>>>>>>>>>>>>> its inputs
You continue to stupidly insist that int sum(int x, >>>>>>>>>>>>>>>>>>> int y) {return xWhat else is it missing that the processor uses to >>>>>>>>>>>>>>>>>> execute it?
+ y; }
returns 7 for sum(3,2) because you incorrectly >>>>>>>>>>>>>>>>>>> understand how these
things fundamentally work.
It is stupidly wrong to expect HHH(DD) report on the >>>>>>>>>>>>>>>>>>> direct
execution of DD when you are not telling it one damn >>>>>>>>>>>>>>>>>>> thing about
this direct execution.
correctly.
The key thing here is that Olcott consistently does not >>>>>>>>>>>>>>>> understand that
HHH is given a finite string input that according to the >>>>>>>>>>>>>>>> semantics of
the x86 language specifies a halting program,
That is stupidly incorrect.
for DD only.
People here stupidly assume that the outputs are not >>>>>>>>>>>>>>> required toBut the direct execution of DD is computable from its >>>>>>>>>>>>>> description.
correspond to the inputs.
Not as an input to HHH.
But neither the "direct execution" or the "simulation by >>>>>>>>>>>> HHH" are "inputs" to HHH. What is the input is the
representation of the program to be decided on.
When HHH computes halting for DD is is only allowed
to apply the finite string transformations specified >>>>>>>>>>>>> by the x86 language to the machine code of DD.
It is only ABLE to apply them.
The input to HHH(DD) does specify the recursive emulation >>>>>>>>>>> of DD including HHH emulating itself emulating DD when
one applies the finite string transformation rules of the >>>>>>>>>>> x86 language to THE INPUT to HHH(DD).
Yes, the input specifies FINITE recusive PARTIAL emulation, as >>>>>>>>>> the HHH that DD calls will emulate only a few instructions of >>>>>>>>>> DD and then return,
*You are technically incompetent on this point*
When the finite string transformation rules of the
x86 language are applied to the input to HHH(DD)
THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE
not even after an infinite number of emulated steps.
Sure it does, just after the point that HHH gives up on those
transformation and aborts its (now incorrect) emulation of the >>>>>>>> input.
THAT IS COUNTER FACTUAL !!!
The directly executed DD has zero recursive invocations.
DD emulated by HHH has one recursive invocation.
Did you know that zero does not equal one?
But the direct execution DOES have a recursiove invocation, as DD
calls HHH(DD) that emulated DD, just like the directly exeucted
HHH will emulate DD calling HHH(DD).
The call from the directly executed DD to HHH(DD)
immediately returns and DD reaches its final halt state.
No it doesn't,
I will say that more accurately.
The call from the directly executed DD returns.
The call from DD emulated by HHH to HHH(DD)
(according to the finite string transformation
rules of the x86 language) CANNOT POSSIBLY RETURN.
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
When any HHH emulates DD according to the finite
string transformation rules specified by the x86
language (the line of demarcation between correct
and incorrect emulation) no emulated DD can possibly
reach its final halt state and halt.
On 4/26/2025 1:19 PM, Fred. Zwarts wrote:Indeed, HHH violates those rules, because it aborts a finite recursion.
Op 26.apr.2025 om 18:15 schreef olcott:>>
_DD()This behaviour of HHH blocks the analysis of the behaviour of DD.
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local
[00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
When any HHH emulates DD according to the finite
string transformation rules specified by the x86
language (the line of demarcation between correct
and incorrect emulation) no emulated DD can possibly
reach its final halt state and halt.
This failure of HHH shows that it is not the right tool to analyse DD.
There are other tools that have no problem to reach the final end.
*You are clueless about this thus WILL NEVER GET IT*
"according to the finite string transformation rules
specified by the x86 language."
On 4/27/2025 4:51 AM, Mikko wrote:
On 2025-04-26 16:15:44 +0000, olcott said:
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local
[00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
When any HHH emulates DD according to the finite
string transformation rules specified by the x86
language (the line of demarcation between correct
and incorrect emulation) no emulated DD can possibly
reach its final halt state and halt.
There is a type error above. First DD is introduced as a proper name.
But later it is used in the phrase "no emulated DD" where the rules
of the language require a generic name.
*This of this as an axiom schema*
No DD correctly emulated by any HHH can possibly
reach its final halt state. This conclusively
proves that every HHH is correct to reject its
input DD as non-halting.
On 4/27/2025 4:51 AM, Mikko wrote:
On 2025-04-26 16:15:44 +0000, olcott said:
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local
[00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
When any HHH emulates DD according to the finite
string transformation rules specified by the x86
language (the line of demarcation between correct
and incorrect emulation) no emulated DD can possibly
reach its final halt state and halt.
There is a type error above. First DD is introduced as a proper name.
But later it is used in the phrase "no emulated DD" where the rules
of the language require a generic name.
*This of this as an axiom schema*
No DD correctly emulated by any HHH can possibly
reach its final halt state. This conclusively
proves that every HHH is correct to reject its
input DD as non-halting.
On 4/28/2025 1:37 PM, dbush wrote:
On 4/28/2025 2:32 PM, olcott wrote:
On 4/28/2025 11:11 AM, dbush wrote:
On 4/28/2025 12:10 PM, olcott wrote:
On 4/28/2025 4:05 AM, Mikko wrote:
On 2025-04-27 18:23:03 +0000, olcott said:
On 4/27/2025 4:51 AM, Mikko wrote:
On 2025-04-26 16:15:44 +0000, olcott said:
_DD()
[00002133] 55 push ebp ; housekeeping >>>>>>>>> [00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local
[00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
When any HHH emulates DD according to the finite
string transformation rules specified by the x86
language (the line of demarcation between correct
and incorrect emulation) no emulated DD can possibly
reach its final halt state and halt.
There is a type error above. First DD is introduced as a proper >>>>>>>> name.
But later it is used in the phrase "no emulated DD" where the rules >>>>>>>> of the language require a generic name.
*This of this as an axiom schema*
No DD correctly emulated by any HHH can possibly
reach its final halt state. This conclusively
proves that every HHH is correct to reject its
input DD as non-halting.
That cannot be used as a schema before you specify what symbols in >>>>>> it are
placeholders and what replacements can be used for the placeholders. >>>>>>
I have gone over this many hundreds of times
do you not remember anything that I already said?
int DD()
{
int Halt_Status = EEE(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
When each element of the set of x86 emulators
named EEE
Changing the input is not allowed.
Hypothetical possibilities numbskull.
So you're hypothesizing changing the input.
Changing the input, hypothetically or otherwise, is not allowed.
Examining the infinite set of HHH/DD pairs simultaneously
IS NOT CHANGING THE INPUT DUMBO.
On 4/28/2025 2:10 PM, dbush wrote:
On 4/28/2025 3:03 PM, olcott wrote:
On 4/28/2025 1:37 PM, dbush wrote:
On 4/28/2025 2:32 PM, olcott wrote:
On 4/28/2025 11:11 AM, dbush wrote:
On 4/28/2025 12:10 PM, olcott wrote:
On 4/28/2025 4:05 AM, Mikko wrote:
On 2025-04-27 18:23:03 +0000, olcott said:
On 4/27/2025 4:51 AM, Mikko wrote:
On 2025-04-26 16:15:44 +0000, olcott said:
_DD()
[00002133] 55 push ebp ; housekeeping >>>>>>>>>>> [00002134] 8bec mov ebp,esp ; housekeeping >>>>>>>>>>> [00002136] 51 push ecx ; make space for local
[00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
When any HHH emulates DD according to the finite
string transformation rules specified by the x86
language (the line of demarcation between correct
and incorrect emulation) no emulated DD can possibly
reach its final halt state and halt.
There is a type error above. First DD is introduced as a
proper name.
But later it is used in the phrase "no emulated DD" where the >>>>>>>>>> rules
of the language require a generic name.
*This of this as an axiom schema*
No DD correctly emulated by any HHH can possibly
reach its final halt state. This conclusively
proves that every HHH is correct to reject its
input DD as non-halting.
That cannot be used as a schema before you specify what symbols >>>>>>>> in it are
placeholders and what replacements can be used for the
placeholders.
I have gone over this many hundreds of times
do you not remember anything that I already said?
int DD()
{
int Halt_Status = EEE(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
When each element of the set of x86 emulators
named EEE
Changing the input is not allowed.
Hypothetical possibilities numbskull.
So you're hypothesizing changing the input.
Changing the input, hypothetically or otherwise, is not allowed.
Examining the infinite set of HHH/DD pairs simultaneously
IS NOT CHANGING THE INPUT DUMBO.
When DD runs, HHH runs. So HHH is part of the input. So when you
hypothesize changing HHH, you're hypothesizing changing the input.
Changing the input, hypothetically or otherwise, is not allowed.
Simultaneously examining the infinite set of HHH/DD pairs
IS NOT CHANGING THE INPUT DUMBO.
Simultaneously examining the infinite set of HHH/DD pairs
IS NOT CHANGING THE INPUT DUMBO.
Simultaneously examining the infinite set of HHH/DD pairs
IS NOT CHANGING THE INPUT DUMBO.
Simultaneously examining the infinite set of HHH/DD pairs
IS NOT CHANGING THE INPUT DUMBO.
Simultaneously examining the infinite set of HHH/DD pairs
IS NOT CHANGING THE INPUT DUMBO.
HHH[0] emulates zero instructions of DD
HHH[1] emulates one instructions of DD
HHH[n] emulates n instructions of DD
HHH[∞] emulates ∞ instructions of DD
Each DD has the exactly same machine code
and each HHH is at the same machine address.
...
Flibble and I did not solve the Halting Problem
On 4/28/2025 3:02 PM, dbush wrote:
On 4/28/2025 3:53 PM, olcott wrote:
On 4/28/2025 2:10 PM, dbush wrote:
On 4/28/2025 3:03 PM, olcott wrote:
On 4/28/2025 1:37 PM, dbush wrote:
On 4/28/2025 2:32 PM, olcott wrote:
On 4/28/2025 11:11 AM, dbush wrote:
On 4/28/2025 12:10 PM, olcott wrote:
On 4/28/2025 4:05 AM, Mikko wrote:
On 2025-04-27 18:23:03 +0000, olcott said:
On 4/27/2025 4:51 AM, Mikko wrote:
On 2025-04-26 16:15:44 +0000, olcott said:
_DD()
[00002133] 55 push ebp ; housekeeping >>>>>>>>>>>>> [00002134] 8bec mov ebp,esp ; housekeeping >>>>>>>>>>>>> [00002136] 51 push ecx ; make space for local
[00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
When any HHH emulates DD according to the finite
string transformation rules specified by the x86
language (the line of demarcation between correct
and incorrect emulation) no emulated DD can possibly >>>>>>>>>>>>> reach its final halt state and halt.
There is a type error above. First DD is introduced as a >>>>>>>>>>>> proper name.
But later it is used in the phrase "no emulated DD" where >>>>>>>>>>>> the rules
of the language require a generic name.
*This of this as an axiom schema*
No DD correctly emulated by any HHH can possibly
reach its final halt state. This conclusively
proves that every HHH is correct to reject its
input DD as non-halting.
That cannot be used as a schema before you specify what
symbols in it are
placeholders and what replacements can be used for the
placeholders.
I have gone over this many hundreds of times
do you not remember anything that I already said?
int DD()
{
int Halt_Status = EEE(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
When each element of the set of x86 emulators
named EEE
Changing the input is not allowed.
Hypothetical possibilities numbskull.
So you're hypothesizing changing the input.
Changing the input, hypothetically or otherwise, is not allowed.
Examining the infinite set of HHH/DD pairs simultaneously
IS NOT CHANGING THE INPUT DUMBO.
When DD runs, HHH runs. So HHH is part of the input. So when you
hypothesize changing HHH, you're hypothesizing changing the input.
Changing the input, hypothetically or otherwise, is not allowed.
HHH[0] emulates zero instructions of DD
HHH[1] emulates one instructions of DD
HHH[n] emulates n instructions of DD
HHH[∞] emulates ∞ instructions of DD
FALSE:
HHH[0] emulates zero instructions of DD[0]
HHH[1] emulates one instructions of DD[1]
HHH[n] emulates n instructions of DD[n]
HHH[∞] emulates ∞ instructions of DD[∞]
Each DD has the exactly same machine code
False, because the algorithm DD consists of the machine code of the
function DD, the function HHH, and the machine code of everything that
HHH calls down to the OS level.
You can look at it that way.
So when you hypothesize changing the code of the function HHH, you're
hypothesizing changing the input algorithm DD.
Changing the input is not allowed.
Of the freaking infinite set of every damn HHH/DDBecause they all were prevented to halt by HHH, which aborts the
pair that can possibly exist where DD is emulated
by HHH according to the finite string transformation
rules of the x86 language NOT A DAMN ONE OF THE EMULATED DD HALTS.
...
Flibble and I did not solve the Halting Problem
On 4/28/2025 4:05 AM, Mikko wrote:
On 2025-04-27 18:23:03 +0000, olcott said:
On 4/27/2025 4:51 AM, Mikko wrote:
On 2025-04-26 16:15:44 +0000, olcott said:
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local >>>>> [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
When any HHH emulates DD according to the finite
string transformation rules specified by the x86
language (the line of demarcation between correct
and incorrect emulation) no emulated DD can possibly
reach its final halt state and halt.
There is a type error above. First DD is introduced as a proper name.
But later it is used in the phrase "no emulated DD" where the rules
of the language require a generic name.
*This of this as an axiom schema*
No DD correctly emulated by any HHH can possibly
reach its final halt state. This conclusively
proves that every HHH is correct to reject its
input DD as non-halting.
That cannot be used as a schema before you specify what symbols in it are
placeholders and what replacements can be used for the placeholders.
I have gone over this many hundreds of times
do you not remember anything that I already said?
int DD()
{
int Halt_Status = EEE(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
When each element of the set of x86 emulators
named EEE emulates from 0 to ∞ instructions of
DD no DD ever reaches its final halt state.
It has taken you guys three years to continue
to fail to understand what many C programmers knew
in five minutes.
DD correctly emulated by HHH DOES NOT HALT.
On 4/28/2025 11:11 AM, dbush wrote:
On 4/28/2025 12:10 PM, olcott wrote:
On 4/28/2025 4:05 AM, Mikko wrote:
On 2025-04-27 18:23:03 +0000, olcott said:
On 4/27/2025 4:51 AM, Mikko wrote:
On 2025-04-26 16:15:44 +0000, olcott said:
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local >>>>>>> [00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
When any HHH emulates DD according to the finite
string transformation rules specified by the x86
language (the line of demarcation between correct
and incorrect emulation) no emulated DD can possibly
reach its final halt state and halt.
There is a type error above. First DD is introduced as a proper name. >>>>>> But later it is used in the phrase "no emulated DD" where the rules >>>>>> of the language require a generic name.
*This of this as an axiom schema*
No DD correctly emulated by any HHH can possibly
reach its final halt state. This conclusively
proves that every HHH is correct to reject its
input DD as non-halting.
That cannot be used as a schema before you specify what symbols in
it are
placeholders and what replacements can be used for the placeholders.
I have gone over this many hundreds of times
do you not remember anything that I already said?
int DD()
{
int Halt_Status = EEE(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
When each element of the set of x86 emulators
named EEE
Changing the input is not allowed.
Hypothetical possibilities numbskull.
On 4/28/2025 3:23 PM, Fred. Zwarts wrote:
Op 28.apr.2025 om 22:10 schreef olcott:
On 4/28/2025 3:02 PM, dbush wrote:
On 4/28/2025 3:53 PM, olcott wrote:
On 4/28/2025 2:10 PM, dbush wrote:
On 4/28/2025 3:03 PM, olcott wrote:
On 4/28/2025 1:37 PM, dbush wrote:
On 4/28/2025 2:32 PM, olcott wrote:Examining the infinite set of HHH/DD pairs simultaneously
On 4/28/2025 11:11 AM, dbush wrote:
On 4/28/2025 12:10 PM, olcott wrote:
On 4/28/2025 4:05 AM, Mikko wrote:
On 2025-04-27 18:23:03 +0000, olcott said:
On 4/27/2025 4:51 AM, Mikko wrote:
On 2025-04-26 16:15:44 +0000, olcott said:
_DD()
[00002133] 55 push ebp ; housekeeping >>>>>>>>>>>>>>> [00002134] 8bec mov ebp,esp ; housekeeping >>>>>>>>>>>>>>> [00002136] 51 push ecx ; make space for local
[00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD) >>>>>>>>>>>>>>> [00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
When any HHH emulates DD according to the finite >>>>>>>>>>>>>>> string transformation rules specified by the x86 >>>>>>>>>>>>>>> language (the line of demarcation between correct >>>>>>>>>>>>>>> and incorrect emulation) no emulated DD can possibly >>>>>>>>>>>>>>> reach its final halt state and halt.
There is a type error above. First DD is introduced as a >>>>>>>>>>>>>> proper name.
But later it is used in the phrase "no emulated DD" where >>>>>>>>>>>>>> the rules
of the language require a generic name.
*This of this as an axiom schema*
No DD correctly emulated by any HHH can possibly
reach its final halt state. This conclusively
proves that every HHH is correct to reject its
input DD as non-halting.
That cannot be used as a schema before you specify what >>>>>>>>>>>> symbols in it are
placeholders and what replacements can be used for the >>>>>>>>>>>> placeholders.
I have gone over this many hundreds of times
do you not remember anything that I already said?
int DD()
{
int Halt_Status = EEE(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
When each element of the set of x86 emulators
named EEE
Changing the input is not allowed.
Hypothetical possibilities numbskull.
So you're hypothesizing changing the input.
Changing the input, hypothetically or otherwise, is not allowed. >>>>>>>
IS NOT CHANGING THE INPUT DUMBO.
When DD runs, HHH runs. So HHH is part of the input. So when you >>>>>> hypothesize changing HHH, you're hypothesizing changing the input. >>>>>>
Changing the input, hypothetically or otherwise, is not allowed.
HHH[0] emulates zero instructions of DD
HHH[1] emulates one instructions of DD
HHH[n] emulates n instructions of DD
HHH[∞] emulates ∞ instructions of DD
FALSE:
HHH[0] emulates zero instructions of DD[0]
HHH[1] emulates one instructions of DD[1]
HHH[n] emulates n instructions of DD[n]
HHH[∞] emulates ∞ instructions of DD[∞]
Each DD has the exactly same machine code
False, because the algorithm DD consists of the machine code of the
function DD, the function HHH, and the machine code of everything
that HHH calls down to the OS level.
You can look at it that way.
So when you hypothesize changing the code of the function HHH,
you're hypothesizing changing the input algorithm DD.
Changing the input is not allowed.
Of the freaking infinite set of every damn HHH/DD
pair that can possibly exist where DD is emulated
by HHH according to the finite string transformation
rules of the x86 language NOT A DAMN ONE OF THE EMULATED DD HALTS.
Because they all were prevented to halt by HHH, which aborts the
simulation prematurely.
Factually incorrect and apparently way over your head.
On 4/29/2025 5:06 AM, joes wrote:
Am Mon, 28 Apr 2025 16:49:05 -0500 schrieb olcott:
On 4/28/2025 3:23 PM, Fred. Zwarts wrote:Does HHH not abort?
Op 28.apr.2025 om 22:10 schreef olcott:
On 4/28/2025 3:02 PM, dbush wrote:
Factually incorrect and apparently way over your head.Because they all were prevented to halt by HHH, which aborts theSo when you hypothesize changing the code of the function HHH, you're >>>>>> hypothesizing changing the input algorithm DD.Of the freaking infinite set of every damn HHH/DD pair that can
Changing the input is not allowed.
possibly exist where DD is emulated by HHH according to the finite
string transformation rules of the x86 language NOT A DAMN ONE OF THE >>>>> EMULATED DD HALTS.
simulation prematurely.
The abort is the effect, not the cause.
The cause is that DD specifies recursive
emulation.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 01:28:05 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,057 |
| Messages: | 6,416,578 |