On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
In comp.theory olcott <[email protected]> wrote:
void DDD()
{
HHH(DDD);
return;
}
It is not any lack of technical ability that determines
whether or not DDD correctly simulated by HHH can or
cannot reach its own "return" instruction final halt state.
It is a lack of technical ability on your part which is unable to judge
whether such a correct simulation is possible. Everybody else sees that
it is not, so further questions about it are non-sensical.
The notion of cooperative multi-tasking should be fully
understood by anyone with a computer science degree. If
most people here have much less than that then this may
be very difficult to understand.
https://en.wikipedia.org/wiki/Cooperative_multitasking
I wrote a time slicing x86 function for the original
MSDOS 3.0. This required intercepting the clock interrupt.
I did a lot of interrupt intercept programming back in
the 1980's.
I used this to create the Software Master program that
enabled one program to control another through the command
line interface. Much more powerful than a DOS batch file
because it could see the text on the display screen at
the B800:0000H fixed address. Then MS Windows came out making
Software Master Obsolete.
The x86utm operating system that I wrote uses cooperative
multi-tasking. It enables any C function to emulate the
x86 machine language of another other C function in debug
step mode.
Before it does this it creates a separate simulation
context having its own set of 16 virtual registers and
its own virtual stack.
_DDD()
[0000219e] 55 push ebp
[0000219f] 8bec mov ebp,esp
[000021a1] 689e210000 push 0000219e // push DDD
[000021a6] e843f4ffff call 000015ee // call HHH
[000021ab] 83c404 add esp,+04
[000021ae] 5d pop ebp
[000021af] c3 ret
Size in bytes:(0018) [000021af]
HHH emulates DDD in a separate process context. When
this DDD calls HHH(DDD) the original HHH emulates this
HHH in the DDD process context.
This emulated HHH creates yet another process context
to emulate its own DDD. When this DDD calls yet another
HHH(DDD) this provides enough execution trace that the
repeating pattern can be seen.
*The above is proven right here* https://github.com/plolcott/x86utm/blob/master/Halt7.c
Directly executed HHH emulates DDD that calls an emulated HHH(DDD)
that emulates another DDD instance that calls another HHH(DDD).
machine stack stack machine assembly
address address data code language
======== ======== ======== ========== ============= [000021be][00103872][00000000] 55 push ebp [000021bf][00103872][00000000] 8bec mov ebp,esp [000021c1][0010386e][0000219e] 689e210000 push 0000219e // push DDD [000021c6][0010386a][000021cb] e823f4ffff call 000015ee // call HHH
New slave_stack at:103916
Begin Local Halt Decider Simulation Execution Trace Stored at:11391e [0000219e][0011390e][00113912] 55 push ebp [0000219f][0011390e][00113912] 8bec mov ebp,esp [000021a1][0011390a][0000219e] 689e210000 push 0000219e // push DDD [000021a6][00113906][000021ab] e843f4ffff call 000015ee // call HHH
New slave_stack at:14e33e
[0000219e][0015e336][0015e33a] 55 push ebp [0000219f][0015e336][0015e33a] 8bec mov ebp,esp [000021a1][0015e332][0000219e] 689e210000 push 0000219e // push DDD [000021a6][0015e32e][000021ab] e843f4ffff call 000015ee // call HHH
176 pages of the full execution trace are shown here. https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
On 7/30/2025 9:26 PM, Richard Damon wrote:
On 7/30/25 10:08 PM, olcott wrote:
On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
In comp.theory olcott <[email protected]> wrote:
void DDD()
{
HHH(DDD);
return;
}
It is not any lack of technical ability that determines
whether or not DDD correctly simulated by HHH can or
cannot reach its own "return" instruction final halt state.
It is a lack of technical ability on your part which is unable to judge >>>> whether such a correct simulation is possible. Everybody else sees
that
it is not, so further questions about it are non-sensical.
The notion of cooperative multi-tasking should be fully
understood by anyone with a computer science degree. If
most people here have much less than that then this may
be very difficult to understand.
Sure, but you don't "trace" a program by going cross process.
DDD and HHH retain the exact same machine addresses
thus can be traced across processes.
https://en.wikipedia.org/wiki/Cooperative_multitasking
<snip>
The x86utm operating system that I wrote uses cooperative
multi-tasking. It enables any C function to emulate the
x86 machine language of another other C function in debug
step mode.
So? What does that have to do with the correct simulation of one
specific program?
If people here have much less than a computer science
degree and have never heard of any kind of multi-tasking
that may lead them to believe that HHH cannot emulate
itself emulating DDD.
People cold honestly believe that this is impossible
entirely on the basis of their lack of sufficient
technical competence.
When simulating DDD, we need to look at each instruciton executed in
the context of THAT PROCESS. That will watch every instruction of the
HHH that it calls and is thus part of that process.
We watch HHH doing the simulation, not the results of that simulation
Right if you want to see the actual behavior of DDD
you must make sure to not look at this behavior because
that might mislead you into telling the truth.
Before it does this it creates a separate simulation
context having its own set of 16 virtual registers and
its own virtual stack.
Right, which isn't part of the program being simulated,
HHH is the master process of all processes.
DDD is the immediate slave process.
_DDD()
[0000219e] 55 push ebp
[0000219f] 8bec mov ebp,esp
[000021a1] 689e210000 push 0000219e // push DDD
[000021a6] e843f4ffff call 000015ee // call HHH
[000021ab] 83c404 add esp,+04
[000021ae] 5d pop ebp
[000021af] c3 ret
Size in bytes:(0018) [000021af]
Which isn't a program, and can't be simulated past the call instruction.
The recursive structure of DDD cannot be easily seen
when buried in hundreds of pages of extraneous detail.
So far not one person here could ever understand
one half of one page of text when given three years
to understand it.
HHH emulates DDD in a separate process context. When
this DDD calls HHH(DDD) the original HHH emulates this
HHH in the DDD process context.
When it call HHH, that HHH is PART OF THE PROCESS OF DDD.
Not something "new"
When HHH emulates DDD it creates a new process context
allocating memory for this process context. The first
simulated HHH uses this same new process context.
You don't understand what you are talking about, but just add fluff
and smoke to hide your lies.
It that was true you could point to an actual mistake.
That ignorant people think that your own misconceptions
are my mistake is their mistake.
This emulated HHH creates yet another process context
to emulate its own DDD. When this DDD calls yet another
HHH(DDD) this provides enough execution trace that the
repeating pattern can be seen.
Which we don't actually care about, what we care abput it the original
process of DDD, which includes the HHH that it calls.
We only care about whether the original input to
HHH(DDD) can possibly reach its own simulated final
halt state.
We cannot possibly get there while some people
(through their ignorance) honestly believe that HHH
cannot possibly emulate itself emulating DDD.
When this *is* understood then we understand why
DDD correctly simulated by HHH cannot possibly halt.
*The above is proven right here*
https://github.com/plolcott/x86utm/blob/master/Halt7.c
Directly executed HHH emulates DDD that calls an emulated HHH(DDD)
that emulates another DDD instance that calls another HHH(DDD).
And the only emulation that is the emulation of the input is that
first emulation, NOT any of the other levels of emulation.
*Counter-factual*
The executed HHH(DDD) emulates DDD and also emulates
another HHH in the same process context as this DDD.
This emulated HHH creates another process context and
emulates another DDD. This DDD calls another HHH(DDD)
in its same process context.
All of the above actually occurs in the fully operational code.
Sorry, you are just proving you don't understand the basics of what a
program is.
The notion of a program in C with global variables and such
is not what I am going for. That diverges from the Turing
model of computation.
If we merely examine all of the behavior that the input to
HHH(DDD) specifies it does specify exactly what I said above
in *Counter-factual*
The rest is merely you proving that you did not
understand the half page of text that you have
had three years to understand.
On 7/30/25 11:38 PM, olcott wrote:
On 7/30/2025 9:26 PM, Richard Damon wrote:
On 7/30/25 10:08 PM, olcott wrote:DDD and HHH retain the exact same machine addresses thus can be traced
On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
In comp.theory olcott <[email protected]> wrote:
void DDD()
{
HHH(DDD);
return;
}
The notion of cooperative multi-tasking should be fully understood byIt is not any lack of technical ability that determines whether or >>>>>> not DDD correctly simulated by HHH can or cannot reach its own
"return" instruction final halt state.
It is a lack of technical ability on your part which is unable to
judge whether such a correct simulation is possible. Everybody else >>>>> sees that it is not, so further questions about it are non-sensical. >>>>>
anyone with a computer science degree. If most people here have much
less than that then this may be very difficult to understand.
Sure, but you don't "trace" a program by going cross process.
across processes.
Doesn't mean that is what you are to do.
HHH is supposed to simulate DDD, and all of DDD which include HHH, to determine what that program will do.
Since HHH does a CONDINTIONAL simulation of its input, it is important
to keep track of that conditionality. Something you forget when you stop looking at the trace of it, and only at the trace of what it is doing, something that has no bearing on the behavior of the simulated HHH.
<snip>https://en.wikipedia.org/wiki/Cooperative_multitasking
So, you admit that you talking about multi-tasking was irrelevent.
If people here have much less than a computer science degree and have
The x86utm operating system that I wrote uses cooperative
multi-tasking. It enables any C function to emulate the x86 machine
language of another other C function in debug step mode.
So? What does that have to do with the correct simulation of one
specific program?
never heard of any kind of multi-tasking that may lead them to believe
that HHH cannot emulate itself emulating DDD.
Who said that?
The problem is the question is what the first level DDD does, which has
code, from HHH, to CONDITIONALLY simulate a copy of itself.
Since that code will abort the simulation if it thinks it will not be halting,
People cold honestly believe that this is impossible entirely on the
basis of their lack of sufficient technical competence.
No, people see that *YOUR* implementation gets the wrong answer, because
you assume a wrong criteria\.
Oh, and this multi-tasling system wzs very badly done, as it forces all
the code to use the same memory space. Maybe that is because your
experience was with older processors that couldn't handle themselves the seperate memory spacee. Note, the code of x86utm that you started with
didn't require that the code being simulated be at the physical memory address that it represents, That limitation is something you added to
the system because you apparently don't understand the abstraction of
virtual addresses.
When simulating DDD, we need to look at each instruciton executed inRight if you want to see the actual behavior of DDD you must make sure
the context of THAT PROCESS. That will watch every instruction of the
HHH that it calls and is thus part of that process.
We watch HHH doing the simulation, not the results of that simulation
to not look at this behavior because that might mislead you into
telling the truth.
And that behavior is DEFINED to be what it does when RUN, or COMPLETELY simulted.
SInce that WILL HALT, DDD is HALTING, and saying anything else is just a
lie.
That HHH doesn't simulate it to that point, is an error in HHH, not a
problem with DDD.
HHH is the master process of all processes.Before it does this it creates a separate simulation context having
its own set of 16 virtual registers and its own virtual stack.
Right, which isn't part of the program being simulated,
DDD is the immediate slave process.
No it isn't.
You may be trying to implement it that way, but DDD is DEFINED as a
totally independent process, which HHH is trying to determine what it
will do by looking at its code.
The recursive structure of DDD cannot be easily seen when buried in_DDD()
[0000219e] 55 push ebp [0000219f] 8bec mov
ebp,esp [000021a1] 689e210000 push 0000219e // push DDD
[000021a6] e843f4ffff call 000015ee // call HHH [000021ab]
83c404 add esp,+04 [000021ae] 5d pop ebp
[000021af] c3 ret Size in bytes:(0018) [000021af] >>>
Which isn't a program, and can't be simulated past the call
instruction.
hundreds of pages of extraneous detail.
Thats YOUR problem.
LYING about what happens, just shows that you are a liar.
So far not one person here could ever understand one half of one page
of text when given three years to understand it.
No, the one person here that doesn't understand that trace is YOU.
Because you keep on lying to yourself about what you are doing.
*We are only addressing this one point in this thread*
On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
It is a lack of technical ability on your
part which is unable to judge whether such
a correct simulation is possible. Everybody
else sees that it is not, so further questions
about it are non-sensical.
HHH emulates DDD in a separate process context. When
this DDD calls HHH(DDD) the original HHH emulates this
HHH in the DDD process context.
This emulated HHH creates yet another process context
to emulate its own DDD. When this DDD calls yet another
HHH(DDD) this provides enough execution trace that the
repeating pattern can be seen.
void DDD()
{
HHH(DDD);
return;
}
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
On 7/31/2025 6:32 AM, Richard Damon wrote:
On 7/30/25 11:38 PM, olcott wrote:
If people here have much less than a computer science
degree and have never heard of any kind of multi-tasking
that may lead them to believe that HHH cannot emulate
itself emulating DDD.
Who said that?
On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
It is a lack of technical ability on your
part which is unable to judge whether such
a correct simulation is possible. Everybody
else sees that it is not, so further questions
about it are non-sensical.
Oh, and this multi-tasling system wzs very badly done, as it forces
all the code to use the same memory space. Maybe that is because your
experience was with older processors that couldn't handle themselves
the seperate memory spacee. Note, the code of x86utm that you started
with didn't require that the code being simulated be at the physical
memory address that it represents, That limitation is something you
added to the system because you apparently don't understand the
abstraction of virtual addresses.
The whole point is to show that HHH does emulate itself
emulating DDD because so many people believe this is
impossible. *All of the above critique is off-topic*
*It merely distracts attention away from the point*
When simulating DDD, we need to look at each instruciton executed in
the context of THAT PROCESS. That will watch every instruction of
the HHH that it calls and is thus part of that process.
We watch HHH doing the simulation, not the results of that simulation
Right if you want to see the actual behavior of DDD
you must make sure to not look at this behavior because
that might mislead you into telling the truth.
And that behavior is DEFINED to be what it does when RUN, or
COMPLETELY simulted.
*Not at all you never get this correctly even*
*when you have been corrected hundreds of times*
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) It detects a non-terminating behavior pattern then it aborts its simulation and returns 0,
(b) Its simulated input reaches its simulated "return" statement then it returns 1.
SInce that WILL HALT, DDD is HALTING, and saying anything else is just
a lie.
*Not at all you never get this correctly even*
*when you have been corrected hundreds of times*
We are only measuring whether or not DDD correctly
simulated by HHH can possibly reach its own simulated
final halt state.
That HHH doesn't simulate it to that point, is an error in HHH, not a
problem with DDD.
That merely shows that you do not understand what
is actually occurring.
void DDD()
{
HHH(DDD);
return;
}
*When HHH simulates ten instructions of DDD it goes like this*
Executed HHH(DDD) simulates DDD that calls HHH(DDD)
Simulated HHH(DDD) simulates DDD that calls HHH(DDD)
Simulated HHH(DDD) simulates DDD that calls HHH(DDD)
Simulated HHH(DDD) simulates DDD that calls HHH(DDD)
Simulated HHH(DDD) simulates DDD that calls HHH(DDD)
Simulated HHH(DDD) simulates DDD that calls HHH(DDD)
Simulated HHH(DDD) simulates DDD that calls HHH(DDD)
Simulated HHH(DDD) simulates DDD that calls HHH(DDD)
Simulated HHH(DDD) simulates DDD that calls HHH(DDD)
Simulated HHH(DDD) simulates DDD that calls HHH(DDD)
Before it does this it creates a separate simulation
context having its own set of 16 virtual registers and
its own virtual stack.
Right, which isn't part of the program being simulated,
HHH is the master process of all processes.
DDD is the immediate slave process.
No it isn't.
You may be trying to implement it that way, but DDD is DEFINED as a
totally independent process, which HHH is trying to determine what it
will do by looking at its code.
HHH(DDD) the slave DDD is not a totally independent process
it requires HHH to pump its process at each of its instructions.
_DDD()
[0000219e] 55 push ebp
[0000219f] 8bec mov ebp,esp
[000021a1] 689e210000 push 0000219e // push DDD
[000021a6] e843f4ffff call 000015ee // call HHH
[000021ab] 83c404 add esp,+04
[000021ae] 5d pop ebp
[000021af] c3 ret
Size in bytes:(0018) [000021af]
Which isn't a program, and can't be simulated past the call
instruction.
The recursive structure of DDD cannot be easily seen
when buried in hundreds of pages of extraneous detail.
Thats YOUR problem.
It has always been your mistake that I have corrected
many many times that you believe that HHH and DDD are
not in the same global block of memory of Halt7.obj.
LYING about what happens, just shows that you are a liar.
No this is actually a case of your own dementia.
When I correct your false assumptions hundreds of
times at some point you should remember that I
corrected you at least once.
*Its either dementia or persistent dishonesty*
So far not one person here could ever understand
one half of one page of text when given three years
to understand it.
No, the one person here that doesn't understand that trace is YOU.
Because you keep on lying to yourself about what you are doing.
That your dementia causes you to always forget my corrections
to your false assumptions is not any mistake on my part.
People that fully understand cooperative multi-taking will
understand that I am correct.
*It is comprehension of this that is the point of this thread*
HHH emulates DDD in a separate process context. When
this DDD calls HHH(DDD) the original HHH emulates this
HHH in the DDD process context.
This emulated HHH creates yet another process context
to emulate its own DDD. When this DDD calls yet another
HHH(DDD) this provides enough execution trace that the
repeating pattern can be seen.
On 7/31/2025 6:32 AM, Richard Damon wrote:
On 7/30/25 11:38 PM, olcott wrote:
So far not one person here could ever understand
one half of one page of text when given three years
to understand it.
No, the one person here that doesn't understand that trace is YOU.
*That you keep disagreeing with this verified fact*
*does not count as any rebuttal at all*
HHH emulates DDD in a separate process context. When
this DDD calls HHH(DDD) the original HHH emulates this
HHH in the DDD process context.
This emulated HHH creates yet another process context
to emulate its own DDD. When this DDD calls yet another
HHH(DDD) this provides enough execution trace that the
repeating pattern can be seen.
On 7/31/2025 7:07 PM, Richard Damon wrote:
On 7/31/25 11:50 AM, olcott wrote:
*We are only addressing this one point in this thread*
On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
It is a lack of technical ability on your
part which is unable to judge whether such
a correct simulation is possible. Everybody
else sees that it is not, so further questions
about it are non-sensical.
HHH emulates DDD in a separate process context. When
this DDD calls HHH(DDD) the original HHH emulates this
HHH in the DDD process context.
And that separate proccess, if left unaborted, would halt. But HHH
gives up and aborts it, so the process is Halting, not non-halting.
This emulated HHH creates yet another process context
to emulate its own DDD. When this DDD calls yet another
HHH(DDD) this provides enough execution trace that the
repeating pattern can be seen.
But the pattern isn't non-halting by the fact that DDD is shown to be
halting.
*No not at all. Not in the least little bit*
Recursive simulation is only a little more difficult
than self recursion. Do you understand self-recursion?
What is the classic example of self-recursion?
When N instructions of DDD are correctly emulated by
every HHH that can possibly exist
(technically this is an infinite set of HHH/DDD pairs)
no emulated DDD can possibly halt and every directly
executed DDD() halts.
On 7/31/2025 7:37 PM, Richard Damon wrote:
On 7/31/25 8:18 PM, olcott wrote:It is an infinite set with every HHH/DDD pair having
On 7/31/2025 7:07 PM, Richard Damon wrote:
On 7/31/25 11:50 AM, olcott wrote:
*We are only addressing this one point in this thread*
On 7/29/2025 11:22 PM, Alan Mackenzie wrote:
It is a lack of technical ability on your
part which is unable to judge whether such
a correct simulation is possible. Everybody
else sees that it is not, so further questions
about it are non-sensical.
HHH emulates DDD in a separate process context. When
this DDD calls HHH(DDD) the original HHH emulates this
HHH in the DDD process context.
And that separate proccess, if left unaborted, would halt. But HHH
gives up and aborts it, so the process is Halting, not non-halting.
This emulated HHH creates yet another process context
to emulate its own DDD. When this DDD calls yet another
HHH(DDD) this provides enough execution trace that the
repeating pattern can be seen.
But the pattern isn't non-halting by the fact that DDD is shown to
be halting.
*No not at all. Not in the least little bit*
Of course it is,
The pattern can't be non-halting if it occurs in a halting program.
Recursive simulation is only a little more difficult
than self recursion. Do you understand self-recursion?
What is the classic example of self-recursion?
but since it is only finite recursion of partial simulation, since the
first level WILL abort the process and end the recursion.
When N instructions of DDD are correctly emulated by
every HHH that can possibly exist
(technically this is an infinite set of HHH/DDD pairs)
no emulated DDD can possibly halt and every directly
executed DDD() halts.
Wrong, your problem is you forget that all those DDD are different,
the same property that each DDD cannot possibly halt.
On 8/1/2025 2:11 AM, joes wrote:
Am Thu, 31 Jul 2025 20:03:15 -0500 schrieb olcott:
On 7/31/2025 7:37 PM, Richard Damon wrote:
On 7/31/25 8:18 PM, olcott wrote:
On 7/31/2025 7:07 PM, Richard Damon wrote:
On 7/31/25 11:50 AM, olcott wrote:
And that separate proccess, if left unaborted, would halt. But HHH >>>>>> gives up and aborts it, so the process is Halting, not non-halting.
But the pattern isn't non-halting by the fact that DDD is shown to be >>>>>> halting.
but since it is only finite recursion of partial simulation, since the >>>> first level WILL abort the process and end the recursion.
It is an infinite set with every HHH/DDD pair having the same propertyWhen N instructions of DDD are correctly emulated by every HHH thatWrong, your problem is you forget that all those DDD are different,
can possibly exist (technically this is an infinite set of HHH/DDD
pairs) no emulated DDD can possibly halt and every directly executed >>>>> DDD() halts.
that each DDD cannot possibly halt.
Sure, but what about different HHH_n's simulating the same DDD?
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Each element of the infinite set of HHH/DDD pairs
that emulates a natural number N number of instructions
of DDD never halts. The machine code bytes of DDD remain
that same. The only thing that changes is the code of
HHH at machine address 000015d2.
On 8/1/2025 1:53 AM, joes wrote:
Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott:
On 7/31/2025 7:07 PM, Richard Damon wrote:
On 7/31/25 11:50 AM, olcott wrote:
On 7/29/2025 11:22 PM, Alan Mackenzie wrote:And that separate proccess, if left unaborted, would halt. But HHH
> It is a lack of technical ability on your part which is unable to >>>>> > judge whether such a correct simulation is possible. Everybody >>>>> > else sees that it is not, so further questions about it are
> non-sensical.
HHH emulates DDD in a separate process context. When this DDD calls
HHH(DDD) the original HHH emulates this HHH in the DDD process
context.
gives up and aborts it, so the process is Halting, not non-halting.
And HHH cannot simulate itself to its undeniable halting state.
*No not at all. Not in the least little bit* Recursive simulation isThis emulated HHH creates yet another process context to emulate its >>>>> own DDD. When this DDD calls yet another HHH(DDD) this provides enough >>>>> execution trace that the repeating pattern can be seen.But the pattern isn't non-halting by the fact that DDD is shown to be
halting.
only a little more difficult than self recursion.
DDD halts if it weren't aborted.
(1) That is counter-factual. Neither HHH() nor DDD() nor DDD
simulated by HHH ever stops running unless HHH(DDD) aborts
its input.
(2) I have never been taking about DDD() the behavior of a non-input.
Turing machines are only accountable for the behavior that their
inputs specify, they are never accountable for any non-inputs.
(3) When I make a claim about DDD simulated by HHH and this is
changed to the behavior of the directly executed DDD this is
a dishonest tactic known as the strawman error.
void DDD()
{
HHH(DDD);
return;
}
Executed HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
Then HHH kills the whole simulation process and returns 0
When N instructions of DDD are correctly emulated by every HHH that can
possibly exist (technically this is an infinite set of HHH/DDD pairs)
no emulated DDD can possibly halt and every directly executed DDD()
halts.
See, and I thought DDD was a concrete program filled in with HHH,
which aborts after two levels of simulation, not something that
calls "HHH" symbolically, producing many different programs.
I had to turn it into an infinite set of HHH/DDD
pairs so that it could be more easily understood
that DDD simulated by HHH cannot possibly halt.
When HHH detects the above non-halting behavior
pattern it kills the whole simulation process so
there is no stack unwinding.
On 8/1/2025 2:11 AM, joes wrote:
Am Thu, 31 Jul 2025 20:03:15 -0500 schrieb olcott:
On 7/31/2025 7:37 PM, Richard Damon wrote:
On 7/31/25 8:18 PM, olcott wrote:
On 7/31/2025 7:07 PM, Richard Damon wrote:
On 7/31/25 11:50 AM, olcott wrote:
And that separate proccess, if left unaborted, would halt. But HHH >>>>>> gives up and aborts it, so the process is Halting, not non-halting.
But the pattern isn't non-halting by the fact that DDD is shown to be >>>>>> halting.
but since it is only finite recursion of partial simulation, since the >>>> first level WILL abort the process and end the recursion.
It is an infinite set with every HHH/DDD pair having the same propertyWhen N instructions of DDD are correctly emulated by every HHH thatWrong, your problem is you forget that all those DDD are different,
can possibly exist (technically this is an infinite set of HHH/DDD
pairs) no emulated DDD can possibly halt and every directly executed >>>>> DDD() halts.
that each DDD cannot possibly halt.
Sure, but what about different HHH_n's simulating the same DDD?
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Each element of the infinite set of HHH/DDD pairs
that emulates a natural number N number of instructions
of DDD never halts.
The machine code bytes of DDD remain
that same.
The only thing that changes is the code of
HHH at machine address 000015d2.
On 8/1/2025 1:53 AM, joes wrote:
Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott:
On 7/31/2025 7:07 PM, Richard Damon wrote:
On 7/31/25 11:50 AM, olcott wrote:
On 7/29/2025 11:22 PM, Alan Mackenzie wrote:And that separate proccess, if left unaborted, would halt. But HHH
> It is a lack of technical ability on your part which is unable to >>>>> > judge whether such a correct simulation is possible. Everybody >>>>> > else sees that it is not, so further questions about it are
> non-sensical.
HHH emulates DDD in a separate process context. When this DDD calls
HHH(DDD) the original HHH emulates this HHH in the DDD process
context.
gives up and aborts it, so the process is Halting, not non-halting.
And HHH cannot simulate itself to its undeniable halting state.
*No not at all. Not in the least little bit* Recursive simulation isThis emulated HHH creates yet another process context to emulate its >>>>> own DDD. When this DDD calls yet another HHH(DDD) this provides enough >>>>> execution trace that the repeating pattern can be seen.But the pattern isn't non-halting by the fact that DDD is shown to be
halting.
only a little more difficult than self recursion.
DDD halts if it weren't aborted.
(1) That is counter-factual. Neither HHH() nor DDD() nor DDD
simulated by HHH ever stops running unless HHH(DDD) aborts
its input.
(2) I have never been taking about DDD() the behavior of a non-input.
Turing machines are only accountable for the behavior that their
inputs specify, they are never accountable for any non-inputs.
(3) When I make a claim about DDD simulated by HHH and this is
changed to the behavior of the directly executed DDD this is
a dishonest tactic known as the strawman error.
void DDD()
{
HHH(DDD);
return;
}
Executed HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
Then HHH kills the whole simulation process and returns 0
When N instructions of DDD are correctly emulated by every HHH that can
possibly exist (technically this is an infinite set of HHH/DDD pairs)
no emulated DDD can possibly halt and every directly executed DDD()
halts.
See, and I thought DDD was a concrete program filled in with HHH,
which aborts after two levels of simulation, not something that
calls "HHH" symbolically, producing many different programs.
I had to turn it into an infinite set of HHH/DDD
pairs so that it could be more easily understood
that DDD simulated by HHH cannot possibly halt.
When HHH detects the above non-halting behavior
pattern it kills the whole simulation process so
there is no stack unwinding.
On 8/4/2025 7:47 AM, Fred. Zwarts wrote:
Op 02.aug.2025 om 16:16 schreef olcott:
On 8/2/2025 4:18 AM, Fred. Zwarts wrote:
Op 01.aug.2025 om 16:46 schreef olcott:
On 8/1/2025 1:53 AM, joes wrote:
Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott:
On 7/31/2025 7:07 PM, Richard Damon wrote:And HHH cannot simulate itself to its undeniable halting state.
On 7/31/25 11:50 AM, olcott wrote:
On 7/29/2025 11:22 PM, Alan Mackenzie wrote:And that separate proccess, if left unaborted, would halt. But HHH >>>>>>>> gives up and aborts it, so the process is Halting, not non-halting. >>>>>
> It is a lack of technical ability on your part which is >>>>>>>>> unable to
> judge whether such a correct simulation is possible.
Everybody
> else sees that it is not, so further questions about it are >>>>>>>>> > non-sensical.
HHH emulates DDD in a separate process context. When this DDD >>>>>>>>> calls
HHH(DDD) the original HHH emulates this HHH in the DDD process >>>>>>>>> context.
*No not at all. Not in the least little bit* Recursive simulation is >>>>>>> only a little more difficult than self recursion.This emulated HHH creates yet another process context toBut the pattern isn't non-halting by the fact that DDD is shown >>>>>>>> to be
emulate its
own DDD. When this DDD calls yet another HHH(DDD) this provides >>>>>>>>> enough
execution trace that the repeating pattern can be seen.
halting.
DDD halts if it weren't aborted.
(1) That is counter-factual. Neither HHH() nor DDD() nor DDD
simulated by HHH ever stops running unless HHH(DDD) aborts
its input.
It is irrelevant what a hypothetical non-input would do. HHH aborts,
so DDD and HHH, both the directly executing and the simulated
versions halt.
DDD correctly simulated by HHH cannot possibly reach
its own simulated "return" instruction final halt state
in 1 to infinity steps of correct simulation. When the
simulation is aborted the entire process is killed so
there is no stack unwinding.
(2) I have never been taking about DDD() the behavior of a non-input. >>>>> Turing machines are only accountable for the behavior that their
inputs specify, they are never accountable for any non-inputs.
And this input specifies a program with code to abort, so it
specifies a halting program. When HHH does not see that, it fails.
I discovered a case where the correct simulation
and the direct execution have different halting
behaviors.
No, you dreamed, but could not prove it. Only by twisting the meaning
of the words, you could make yourself believing it.
(3) When I make a claim about DDD simulated by HHH and this is
changed to the behavior of the directly executed DDD this is
a dishonest tactic known as the strawman error.
When the input specifies a halting behaviour, it is an error to
close your eyes and pretend that it does not exist.
void DDD()
{
HHH(DDD);
return;
}
Executed HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
Then HHH kills the whole simulation process and returns 0
Counterfactual. HHH abors after a few cycles, when only one more
cycle is needed to complete the simulation, as proven by simulators
that do not abort the exact same input.
The above HHH aborts after ten recursive simulations
because people here did not understand that there were
any recursive simulation when I only show one or two.
That does not make any difference. We also see that you are cheating,
by not only changing the simulator, but also the simulated input.
World class simulators show that the original input, when correctly
simulated, reaches its final halt state after tree recursion.
The HHH that simulates 10 recursions would also reach the final halt
state for this same input.
But, because your are cheating, you changed the input, which now needs
eleven recursion to halt.
We see in this way, the, no matter how many recursions you simulate,
this method is unable to reach the final halt state that is specified
in the input when we construct a new DDD with this new HHH.
There is no non-halting behaviour pattern, only a finite number more
When N instructions of DDD are correctly emulated by every HHH
that can
possibly exist (technically this is an infinite set of HHH/DDD
pairs)
no emulated DDD can possibly halt and every directly executed DDD() >>>>>>> halts.
See, and I thought DDD was a concrete program filled in with HHH,
which aborts after two levels of simulation, not something that
calls "HHH" symbolically, producing many different programs.
I had to turn it into an infinite set of HHH/DDD
pairs so that it could be more easily understood
that DDD simulated by HHH cannot possibly halt.
When HHH detects the above non-halting behavior
pattern it kills the whole simulation process so
there is no stack unwinding.
than N instructions are needed to reach the final input *for this
input*.
counter-factual
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
WE have told you many times that it is incorrect to suggest that these
18 bytes describe the whole input for the simulator.
All functions called by DDD, directly or indirectly, also belong to
the input under test.
Every 5 instructions of DDD that are correctly emulated
end up in HHH at line one. One more instruction of
DDD emulates line two, one more emulates line three,
one more ends up at line four, one more ends up back
at line one.
Incorrect, the call ends up inside HHH. When you would correctly
follow the code of HHH in your simulator, keeping track of the
internal state of HHH and its conditional branch instruction, you
would see that after a few cycles, HHH is specified to abort and
return to DDD at line 5.
Then lines 6 and 7 would be simulated and the final halt state is
reached.
But HHH fails to do this correct simulation, because it prematurely
aborts before it can see that.
Then HHH uses your attitude: close its eyes and pretend that what is
not seen does not exist.
Each pair has a different input for the simulator. Each simulator
Proving that for all N the program specifies a halting behaviour,
but we can construct *another* input for which HHH fails again.
But you cheat by changing the input, which then needs more steps.
I do not cheat. I define the infinite set of HHH/DDD pairs
where HHH emulates N instructions of DDD and N is one element
of the natural numbers.
fails for the input constructed with its own version. But many of them
prove that the input constructed with other HHH versions, which have
less steps before the premature abort, have a final halt state that
can be reached.
Because HHH correctly predicts that DDD emulated by
HHH cannot possibly reach its own final state each HHH that
aborts after N instructions have been emulated is correct
to reject its input as non halting.
This shows that the infinite set is irrelevant.
One example if already enough to prove the failure of this method.
So, don't change the subject and lets stay at the HHH that aborts
after two cycles, which need a simulator that simulates at least three
cycles.
On 8/4/2025 8:25 PM, Richard Damon wrote:
On 8/4/25 9:42 AM, olcott wrote:
On 8/4/2025 7:47 AM, Fred. Zwarts wrote:
Op 02.aug.2025 om 16:16 schreef olcott:
On 8/2/2025 4:18 AM, Fred. Zwarts wrote:
Op 01.aug.2025 om 16:46 schreef olcott:
On 8/1/2025 1:53 AM, joes wrote:
Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott:
On 7/31/2025 7:07 PM, Richard Damon wrote:
On 7/31/25 11:50 AM, olcott wrote:
On 7/29/2025 11:22 PM, Alan Mackenzie wrote:And that separate proccess, if left unaborted, would halt. But >>>>>>>>>> HHH
> It is a lack of technical ability on your part which is >>>>>>>>>>> unable to
> judge whether such a correct simulation is possible. >>>>>>>>>>> Everybody
> else sees that it is not, so further questions about it are >>>>>>>>>>> > non-sensical.
HHH emulates DDD in a separate process context. When this DDD >>>>>>>>>>> calls
HHH(DDD) the original HHH emulates this HHH in the DDD process >>>>>>>>>>> context.
gives up and aborts it, so the process is Halting, not non- >>>>>>>>>> halting.
And HHH cannot simulate itself to its undeniable halting state. >>>>>>>>
*No not at all. Not in the least little bit* RecursiveThis emulated HHH creates yet another process context to >>>>>>>>>>> emulate itsBut the pattern isn't non-halting by the fact that DDD is
own DDD. When this DDD calls yet another HHH(DDD) this
provides enough
execution trace that the repeating pattern can be seen.
shown to be
halting.
simulation is
only a little more difficult than self recursion.
DDD halts if it weren't aborted.
(1) That is counter-factual. Neither HHH() nor DDD() nor DDD
simulated by HHH ever stops running unless HHH(DDD) aborts
its input.
It is irrelevant what a hypothetical non-input would do. HHH
aborts, so DDD and HHH, both the directly executing and the
simulated versions halt.
DDD correctly simulated by HHH cannot possibly reach
its own simulated "return" instruction final halt state
in 1 to infinity steps of correct simulation. When the
simulation is aborted the entire process is killed so
there is no stack unwinding.
(2) I have never been taking about DDD() the behavior of a non-
input.
Turing machines are only accountable for the behavior that their >>>>>>> inputs specify, they are never accountable for any non-inputs.
And this input specifies a program with code to abort, so it
specifies a halting program. When HHH does not see that, it fails. >>>>>>
I discovered a case where the correct simulation
and the direct execution have different halting
behaviors.
No, you dreamed, but could not prove it. Only by twisting the
meaning of the words, you could make yourself believing it.
(3) When I make a claim about DDD simulated by HHH and this is
changed to the behavior of the directly executed DDD this is
a dishonest tactic known as the strawman error.
When the input specifies a halting behaviour, it is an error to
close your eyes and pretend that it does not exist.
void DDD()
{
HHH(DDD);
return;
}
Executed HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
Then HHH kills the whole simulation process and returns 0
Counterfactual. HHH abors after a few cycles, when only one more
cycle is needed to complete the simulation, as proven by
simulators that do not abort the exact same input.
The above HHH aborts after ten recursive simulations
because people here did not understand that there were
any recursive simulation when I only show one or two.
That does not make any difference. We also see that you are
cheating, by not only changing the simulator, but also the simulated
input. World class simulators show that the original input, when
correctly simulated, reaches its final halt state after tree recursion. >>>> The HHH that simulates 10 recursions would also reach the final halt
state for this same input.
But, because your are cheating, you changed the input, which now
needs eleven recursion to halt.
We see in this way, the, no matter how many recursions you simulate,
this method is unable to reach the final halt state that is
specified in the input when we construct a new DDD with this new HHH.
There is no non-halting behaviour pattern, only a finite number
When N instructions of DDD are correctly emulated by every HHH >>>>>>>>> that can
possibly exist (technically this is an infinite set of HHH/DDD >>>>>>>>> pairs)
no emulated DDD can possibly halt and every directly executed >>>>>>>>> DDD()
halts.
See, and I thought DDD was a concrete program filled in with HHH, >>>>>>>> which aborts after two levels of simulation, not something that >>>>>>>> calls "HHH" symbolically, producing many different programs.
I had to turn it into an infinite set of HHH/DDD
pairs so that it could be more easily understood
that DDD simulated by HHH cannot possibly halt.
When HHH detects the above non-halting behavior
pattern it kills the whole simulation process so
there is no stack unwinding.
more than N instructions are needed to reach the final input *for
this input*.
counter-factual
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
WE have told you many times that it is incorrect to suggest that
these 18 bytes describe the whole input for the simulator.
All functions called by DDD, directly or indirectly, also belong to
the input under test.
Every 5 instructions of DDD that are correctly emulated
end up in HHH at line one. One more instruction of
DDD emulates line two, one more emulates line three,
one more ends up at line four, one more ends up back
at line one.
Incorrect, the call ends up inside HHH. When you would correctly
follow the code of HHH in your simulator, keeping track of the
internal state of HHH and its conditional branch instruction, you
would see that after a few cycles, HHH is specified to abort and
return to DDD at line 5.
Then lines 6 and 7 would be simulated and the final halt state is
reached.
But HHH fails to do this correct simulation, because it prematurely
aborts before it can see that.
Then HHH uses your attitude: close its eyes and pretend that what is
not seen does not exist.
Each pair has a different input for the simulator. Each simulator
Proving that for all N the program specifies a halting behaviour,
but we can construct *another* input for which HHH fails again.
But you cheat by changing the input, which then needs more steps.
I do not cheat. I define the infinite set of HHH/DDD pairs
where HHH emulates N instructions of DDD and N is one element
of the natural numbers.
fails for the input constructed with its own version. But many of
them prove that the input constructed with other HHH versions, which
have less steps before the premature abort, have a final halt state
that can be reached.
Because HHH correctly predicts that DDD emulated by
HHH cannot possibly reach its own final state each HHH that
aborts after N instructions have been emulated is correct
to reject its input as non halting.
But it can't do that, as that HHH doesn't correct emulate this DDD.
HHH correctly emulates DDD until this emulated DDD
proves that it cannot possibly reach its own emulated
final halt state.
On 8/4/2025 8:41 PM, Richard Damon wrote:
On 8/4/25 9:31 PM, olcott wrote:
On 8/4/2025 8:25 PM, Richard Damon wrote:
On 8/4/25 9:42 AM, olcott wrote:
On 8/4/2025 7:47 AM, Fred. Zwarts wrote:
Op 02.aug.2025 om 16:16 schreef olcott:
On 8/2/2025 4:18 AM, Fred. Zwarts wrote:
Op 01.aug.2025 om 16:46 schreef olcott:
On 8/1/2025 1:53 AM, joes wrote:
Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott:
On 7/31/2025 7:07 PM, Richard Damon wrote:
On 7/31/25 11:50 AM, olcott wrote:
On 7/29/2025 11:22 PM, Alan Mackenzie wrote:And that separate proccess, if left unaborted, would halt. >>>>>>>>>>>> But HHH
> It is a lack of technical ability on your part which is >>>>>>>>>>>>> unable to
> judge whether such a correct simulation is possible. >>>>>>>>>>>>> Everybody
> else sees that it is not, so further questions about it >>>>>>>>>>>>> are
> non-sensical.
HHH emulates DDD in a separate process context. When this >>>>>>>>>>>>> DDD calls
HHH(DDD) the original HHH emulates this HHH in the DDD process >>>>>>>>>>>>> context.
gives up and aborts it, so the process is Halting, not non- >>>>>>>>>>>> halting.
And HHH cannot simulate itself to its undeniable halting state. >>>>>>>>>>
*No not at all. Not in the least little bit* RecursiveThis emulated HHH creates yet another process context to >>>>>>>>>>>>> emulate itshalting.
own DDD. When this DDD calls yet another HHH(DDD) this >>>>>>>>>>>>> provides enough
execution trace that the repeating pattern can be seen. >>>>>>>>>>>> But the pattern isn't non-halting by the fact that DDD is >>>>>>>>>>>> shown to be
simulation is
only a little more difficult than self recursion.
DDD halts if it weren't aborted.
(1) That is counter-factual. Neither HHH() nor DDD() nor DDD >>>>>>>>> simulated by HHH ever stops running unless HHH(DDD) aborts
its input.
It is irrelevant what a hypothetical non-input would do. HHH
aborts, so DDD and HHH, both the directly executing and the
simulated versions halt.
DDD correctly simulated by HHH cannot possibly reach
its own simulated "return" instruction final halt state
in 1 to infinity steps of correct simulation. When the
simulation is aborted the entire process is killed so
there is no stack unwinding.
(2) I have never been taking about DDD() the behavior of a non- >>>>>>>>> input.
Turing machines are only accountable for the behavior that their >>>>>>>>> inputs specify, they are never accountable for any non-inputs. >>>>>>>>
And this input specifies a program with code to abort, so it
specifies a halting program. When HHH does not see that, it fails. >>>>>>>>
I discovered a case where the correct simulation
and the direct execution have different halting
behaviors.
No, you dreamed, but could not prove it. Only by twisting the
meaning of the words, you could make yourself believing it.
(3) When I make a claim about DDD simulated by HHH and this is >>>>>>>>> changed to the behavior of the directly executed DDD this is >>>>>>>>> a dishonest tactic known as the strawman error.
When the input specifies a halting behaviour, it is an error to >>>>>>>> close your eyes and pretend that it does not exist.
void DDD()
{
HHH(DDD);
return;
}
Executed HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
Then HHH kills the whole simulation process and returns 0
Counterfactual. HHH abors after a few cycles, when only one more >>>>>>>> cycle is needed to complete the simulation, as proven by
simulators that do not abort the exact same input.
The above HHH aborts after ten recursive simulations
because people here did not understand that there were
any recursive simulation when I only show one or two.
That does not make any difference. We also see that you are
cheating, by not only changing the simulator, but also the
simulated input. World class simulators show that the original
input, when correctly simulated, reaches its final halt state
after tree recursion.
The HHH that simulates 10 recursions would also reach the final
halt state for this same input.
But, because your are cheating, you changed the input, which now
needs eleven recursion to halt.
We see in this way, the, no matter how many recursions you
simulate, this method is unable to reach the final halt state that >>>>>> is specified in the input when we construct a new DDD with this
new HHH.
There is no non-halting behaviour pattern, only a finite number >>>>>>>> more than N instructions are needed to reach the final input
When N instructions of DDD are correctly emulated by every >>>>>>>>>>> HHH that can
possibly exist (technically this is an infinite set of HHH/ >>>>>>>>>>> DDD pairs)
no emulated DDD can possibly halt and every directly executed >>>>>>>>>>> DDD()
halts.
See, and I thought DDD was a concrete program filled in with HHH, >>>>>>>>>> which aborts after two levels of simulation, not something that >>>>>>>>>> calls "HHH" symbolically, producing many different programs. >>>>>>>>>>
I had to turn it into an infinite set of HHH/DDD
pairs so that it could be more easily understood
that DDD simulated by HHH cannot possibly halt.
When HHH detects the above non-halting behavior
pattern it kills the whole simulation process so
there is no stack unwinding.
*for this input*.
counter-factual
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
WE have told you many times that it is incorrect to suggest that
these 18 bytes describe the whole input for the simulator.
All functions called by DDD, directly or indirectly, also belong
to the input under test.
Every 5 instructions of DDD that are correctly emulated
end up in HHH at line one. One more instruction of
DDD emulates line two, one more emulates line three,
one more ends up at line four, one more ends up back
at line one.
Incorrect, the call ends up inside HHH. When you would correctly
follow the code of HHH in your simulator, keeping track of the
internal state of HHH and its conditional branch instruction, you
would see that after a few cycles, HHH is specified to abort and
return to DDD at line 5.
Then lines 6 and 7 would be simulated and the final halt state is
reached.
But HHH fails to do this correct simulation, because it
prematurely aborts before it can see that.
Then HHH uses your attitude: close its eyes and pretend that what
is not seen does not exist.
Each pair has a different input for the simulator. Each simulator
Proving that for all N the program specifies a haltingI do not cheat. I define the infinite set of HHH/DDD pairs
behaviour, but we can construct *another* input for which HHH
fails again.
But you cheat by changing the input, which then needs more steps. >>>>>>>
where HHH emulates N instructions of DDD and N is one element
of the natural numbers.
fails for the input constructed with its own version. But many of
them prove that the input constructed with other HHH versions,
which have less steps before the premature abort, have a final
halt state that can be reached.
Because HHH correctly predicts that DDD emulated by
HHH cannot possibly reach its own final state each HHH that
aborts after N instructions have been emulated is correct
to reject its input as non halting.
But it can't do that, as that HHH doesn't correct emulate this DDD.
HHH correctly emulates DDD until this emulated DDD
proves that it cannot possibly reach its own emulated
final halt state.
And Correctly until ... isn't correct.
In other words when HHH correctly emulates N instructions
of DDD you are claiming that HHH did not correctly emulate
N instructions of DDD and likewise 1 does not equal itself.
On 8/4/2025 7:47 AM, Fred. Zwarts wrote:
Op 02.aug.2025 om 16:16 schreef olcott:
On 8/2/2025 4:18 AM, Fred. Zwarts wrote:
Op 01.aug.2025 om 16:46 schreef olcott:
On 8/1/2025 1:53 AM, joes wrote:
Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott:
On 7/31/2025 7:07 PM, Richard Damon wrote:And HHH cannot simulate itself to its undeniable halting state.
On 7/31/25 11:50 AM, olcott wrote:
On 7/29/2025 11:22 PM, Alan Mackenzie wrote:And that separate proccess, if left unaborted, would halt. But HHH >>>>>>>> gives up and aborts it, so the process is Halting, not non-halting. >>>>>
> It is a lack of technical ability on your part which is >>>>>>>>> unable to
> judge whether such a correct simulation is possible.
Everybody
> else sees that it is not, so further questions about it are >>>>>>>>> > non-sensical.
HHH emulates DDD in a separate process context. When this DDD >>>>>>>>> calls
HHH(DDD) the original HHH emulates this HHH in the DDD process >>>>>>>>> context.
*No not at all. Not in the least little bit* Recursive simulation is >>>>>>> only a little more difficult than self recursion.This emulated HHH creates yet another process context toBut the pattern isn't non-halting by the fact that DDD is shown >>>>>>>> to be
emulate its
own DDD. When this DDD calls yet another HHH(DDD) this provides >>>>>>>>> enough
execution trace that the repeating pattern can be seen.
halting.
DDD halts if it weren't aborted.
(1) That is counter-factual. Neither HHH() nor DDD() nor DDD
simulated by HHH ever stops running unless HHH(DDD) aborts
its input.
It is irrelevant what a hypothetical non-input would do. HHH aborts,
so DDD and HHH, both the directly executing and the simulated
versions halt.
DDD correctly simulated by HHH cannot possibly reach
its own simulated "return" instruction final halt state
in 1 to infinity steps of correct simulation. When the
simulation is aborted the entire process is killed so
there is no stack unwinding.
(2) I have never been taking about DDD() the behavior of a non-input. >>>>> Turing machines are only accountable for the behavior that their
inputs specify, they are never accountable for any non-inputs.
And this input specifies a program with code to abort, so it
specifies a halting program. When HHH does not see that, it fails.
I discovered a case where the correct simulation
and the direct execution have different halting
behaviors.
No, you dreamed, but could not prove it. Only by twisting the meaning
of the words, you could make yourself believing it.
(3) When I make a claim about DDD simulated by HHH and this is
changed to the behavior of the directly executed DDD this is
a dishonest tactic known as the strawman error.
When the input specifies a halting behaviour, it is an error to
close your eyes and pretend that it does not exist.
void DDD()
{
HHH(DDD);
return;
}
Executed HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
Then HHH kills the whole simulation process and returns 0
Counterfactual. HHH abors after a few cycles, when only one more
cycle is needed to complete the simulation, as proven by simulators
that do not abort the exact same input.
The above HHH aborts after ten recursive simulations
because people here did not understand that there were
any recursive simulation when I only show one or two.
That does not make any difference. We also see that you are cheating,
by not only changing the simulator, but also the simulated input.
World class simulators show that the original input, when correctly
simulated, reaches its final halt state after tree recursion.
The HHH that simulates 10 recursions would also reach the final halt
state for this same input.
But, because your are cheating, you changed the input, which now needs
eleven recursion to halt.
We see in this way, the, no matter how many recursions you simulate,
this method is unable to reach the final halt state that is specified
in the input when we construct a new DDD with this new HHH.
There is no non-halting behaviour pattern, only a finite number more
When N instructions of DDD are correctly emulated by every HHH
that can
possibly exist (technically this is an infinite set of HHH/DDD
pairs)
no emulated DDD can possibly halt and every directly executed DDD() >>>>>>> halts.
See, and I thought DDD was a concrete program filled in with HHH,
which aborts after two levels of simulation, not something that
calls "HHH" symbolically, producing many different programs.
I had to turn it into an infinite set of HHH/DDD
pairs so that it could be more easily understood
that DDD simulated by HHH cannot possibly halt.
When HHH detects the above non-halting behavior
pattern it kills the whole simulation process so
there is no stack unwinding.
than N instructions are needed to reach the final input *for this
input*.
counter-factual
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
WE have told you many times that it is incorrect to suggest that these
18 bytes describe the whole input for the simulator.
All functions called by DDD, directly or indirectly, also belong to
the input under test.
Every 5 instructions of DDD that are correctly emulated
end up in HHH at line one. One more instruction of
DDD emulates line two, one more emulates line three,
one more ends up at line four, one more ends up back
at line one.
Incorrect, the call ends up inside HHH. When you would correctly
follow the code of HHH in your simulator, keeping track of the
internal state of HHH and its conditional branch instruction, you
would see that after a few cycles, HHH is specified to abort and
return to DDD at line 5.
Then lines 6 and 7 would be simulated and the final halt state is
reached.
But HHH fails to do this correct simulation, because it prematurely
aborts before it can see that.
Then HHH uses your attitude: close its eyes and pretend that what is
not seen does not exist.
Each pair has a different input for the simulator. Each simulator
Proving that for all N the program specifies a halting behaviour,
but we can construct *another* input for which HHH fails again.
But you cheat by changing the input, which then needs more steps.
I do not cheat. I define the infinite set of HHH/DDD pairs
where HHH emulates N instructions of DDD and N is one element
of the natural numbers.
fails for the input constructed with its own version. But many of them
prove that the input constructed with other HHH versions, which have
less steps before the premature abort, have a final halt state that
can be reached.
Because HHH correctly predicts that DDD emulated by
HHH cannot possibly reach its own final state each HHH that
aborts after N instructions have been emulated is correct
to reject its input as non halting.
This shows that the infinite set is irrelevant.
One example if already enough to prove the failure of this method.
So, don't change the subject and lets stay at the HHH that aborts
after two cycles, which need a simulator that simulates at least three
cycles.
On 8/4/2025 7:33 AM, Fred. Zwarts wrote:
Op 02.aug.2025 om 16:17 schreef olcott:
On 8/2/2025 4:22 AM, Fred. Zwarts wrote:That has been proven multiple times, but you close your eyes for it.
Op 01.aug.2025 om 16:54 schreef olcott:Try to prove that and you will find that
On 8/1/2025 2:11 AM, joes wrote:
Am Thu, 31 Jul 2025 20:03:15 -0500 schrieb olcott:
On 7/31/2025 7:37 PM, Richard Damon wrote:
On 7/31/25 8:18 PM, olcott wrote:
On 7/31/2025 7:07 PM, Richard Damon wrote:
On 7/31/25 11:50 AM, olcott wrote:
And that separate proccess, if left unaborted, would halt. But >>>>>>>>>> HHH
gives up and aborts it, so the process is Halting, not non- >>>>>>>>>> halting.
But the pattern isn't non-halting by the fact that DDD is
shown to be
halting.
but since it is only finite recursion of partial simulation,
since the
first level WILL abort the process and end the recursion.
propertyWhen N instructions of DDD are correctly emulated by every HHH >>>>>>>>> thatWrong, your problem is you forget that all those DDD are different, >>>>>>> It is an infinite set with every HHH/DDD pair having the same
can possibly exist (technically this is an infinite set of HHH/DDD >>>>>>>>> pairs) no emulated DDD can possibly halt and every directly
executed
DDD() halts.
that each DDD cannot possibly halt.
Sure, but what about different HHH_n's simulating the same DDD?
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Each element of the infinite set of HHH/DDD pairs
that emulates a natural number N number of instructions
of DDD never halts.
Because HHH aborts prematurely,
your proof is incoherent or has glaring gaps.
Show every single step of the execution trace of DDD
such that DDD simulated by HHH that never aborts reaches
its own machine address of [000021a3].
On 8/4/2025 8:58 PM, Richard Damon wrote:
On 8/4/25 9:45 PM, olcott wrote:
On 8/4/2025 8:41 PM, Richard Damon wrote:
On 8/4/25 9:31 PM, olcott wrote:
On 8/4/2025 8:25 PM, Richard Damon wrote:
On 8/4/25 9:42 AM, olcott wrote:
On 8/4/2025 7:47 AM, Fred. Zwarts wrote:
Op 02.aug.2025 om 16:16 schreef olcott:
On 8/2/2025 4:18 AM, Fred. Zwarts wrote:
Op 01.aug.2025 om 16:46 schreef olcott:
On 8/1/2025 1:53 AM, joes wrote:
Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott:
On 7/31/2025 7:07 PM, Richard Damon wrote:
On 7/31/25 11:50 AM, olcott wrote:
On 7/29/2025 11:22 PM, Alan Mackenzie wrote:And that separate proccess, if left unaborted, would halt. >>>>>>>>>>>>>> But HHH
> It is a lack of technical ability on your part which >>>>>>>>>>>>>>> is unable to
> judge whether such a correct simulation is possible. >>>>>>>>>>>>>>> Everybody
> else sees that it is not, so further questions about >>>>>>>>>>>>>>> it are
> non-sensical.
HHH emulates DDD in a separate process context. When this >>>>>>>>>>>>>>> DDD calls
HHH(DDD) the original HHH emulates this HHH in the DDD >>>>>>>>>>>>>>> process
context.
gives up and aborts it, so the process is Halting, not >>>>>>>>>>>>>> non- halting.
And HHH cannot simulate itself to its undeniable halting state. >>>>>>>>>>>>
*No not at all. Not in the least little bit* Recursive >>>>>>>>>>>>> simulation isThis emulated HHH creates yet another process context to >>>>>>>>>>>>>>> emulate itshalting.
own DDD. When this DDD calls yet another HHH(DDD) this >>>>>>>>>>>>>>> provides enough
execution trace that the repeating pattern can be seen. >>>>>>>>>>>>>> But the pattern isn't non-halting by the fact that DDD is >>>>>>>>>>>>>> shown to be
only a little more difficult than self recursion.
DDD halts if it weren't aborted.
(1) That is counter-factual. Neither HHH() nor DDD() nor DDD >>>>>>>>>>> simulated by HHH ever stops running unless HHH(DDD) aborts >>>>>>>>>>> its input.
It is irrelevant what a hypothetical non-input would do. HHH >>>>>>>>>> aborts, so DDD and HHH, both the directly executing and the >>>>>>>>>> simulated versions halt.
DDD correctly simulated by HHH cannot possibly reach
its own simulated "return" instruction final halt state
in 1 to infinity steps of correct simulation. When the
simulation is aborted the entire process is killed so
there is no stack unwinding.
(2) I have never been taking about DDD() the behavior of a >>>>>>>>>>> non- input.
Turing machines are only accountable for the behavior that their >>>>>>>>>>> inputs specify, they are never accountable for any non-inputs. >>>>>>>>>>
And this input specifies a program with code to abort, so it >>>>>>>>>> specifies a halting program. When HHH does not see that, it >>>>>>>>>> fails.
I discovered a case where the correct simulation
and the direct execution have different halting
behaviors.
No, you dreamed, but could not prove it. Only by twisting the
meaning of the words, you could make yourself believing it.
(3) When I make a claim about DDD simulated by HHH and this is >>>>>>>>>>> changed to the behavior of the directly executed DDD this is >>>>>>>>>>> a dishonest tactic known as the strawman error.
When the input specifies a halting behaviour, it is an error >>>>>>>>>> to close your eyes and pretend that it does not exist.
Counterfactual. HHH abors after a few cycles, when only one >>>>>>>>>> more cycle is needed to complete the simulation, as proven by >>>>>>>>>> simulators that do not abort the exact same input.
void DDD()
{
HHH(DDD);
return;
}
Executed HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
Then HHH kills the whole simulation process and returns 0 >>>>>>>>>>
The above HHH aborts after ten recursive simulations
because people here did not understand that there were
any recursive simulation when I only show one or two.
That does not make any difference. We also see that you are
cheating, by not only changing the simulator, but also the
simulated input. World class simulators show that the original >>>>>>>> input, when correctly simulated, reaches its final halt state
after tree recursion.
The HHH that simulates 10 recursions would also reach the final >>>>>>>> halt state for this same input.
But, because your are cheating, you changed the input, which now >>>>>>>> needs eleven recursion to halt.
We see in this way, the, no matter how many recursions you
simulate, this method is unable to reach the final halt state
that is specified in the input when we construct a new DDD with >>>>>>>> this new HHH.
There is no non-halting behaviour pattern, only a finite
When N instructions of DDD are correctly emulated by every >>>>>>>>>>>>> HHH that can
possibly exist (technically this is an infinite set of HHH/ >>>>>>>>>>>>> DDD pairs)
no emulated DDD can possibly halt and every directly >>>>>>>>>>>>> executed DDD()
halts.
See, and I thought DDD was a concrete program filled in with >>>>>>>>>>>> HHH,
which aborts after two levels of simulation, not something that >>>>>>>>>>>> calls "HHH" symbolically, producing many different programs. >>>>>>>>>>>>
I had to turn it into an infinite set of HHH/DDD
pairs so that it could be more easily understood
that DDD simulated by HHH cannot possibly halt.
When HHH detects the above non-halting behavior
pattern it kills the whole simulation process so
there is no stack unwinding.
number more than N instructions are needed to reach the final >>>>>>>>>> input *for this input*.
counter-factual
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
WE have told you many times that it is incorrect to suggest that >>>>>>>> these 18 bytes describe the whole input for the simulator.
All functions called by DDD, directly or indirectly, also belong >>>>>>>> to the input under test.
Every 5 instructions of DDD that are correctly emulated
end up in HHH at line one. One more instruction of
DDD emulates line two, one more emulates line three,
one more ends up at line four, one more ends up back
at line one.
Incorrect, the call ends up inside HHH. When you would correctly >>>>>>>> follow the code of HHH in your simulator, keeping track of the >>>>>>>> internal state of HHH and its conditional branch instruction,
you would see that after a few cycles, HHH is specified to abort >>>>>>>> and return to DDD at line 5.
Then lines 6 and 7 would be simulated and the final halt state >>>>>>>> is reached.
But HHH fails to do this correct simulation, because it
prematurely aborts before it can see that.
Then HHH uses your attitude: close its eyes and pretend that
what is not seen does not exist.
Each pair has a different input for the simulator. Each
Proving that for all N the program specifies a haltingI do not cheat. I define the infinite set of HHH/DDD pairs
behaviour, but we can construct *another* input for which HHH >>>>>>>>>> fails again.
But you cheat by changing the input, which then needs more steps. >>>>>>>>>
where HHH emulates N instructions of DDD and N is one element >>>>>>>>> of the natural numbers.
simulator fails for the input constructed with its own version. >>>>>>>> But many of them prove that the input constructed with other HHH >>>>>>>> versions, which have less steps before the premature abort, have >>>>>>>> a final halt state that can be reached.
Because HHH correctly predicts that DDD emulated by
HHH cannot possibly reach its own final state each HHH that
aborts after N instructions have been emulated is correct
to reject its input as non halting.
But it can't do that, as that HHH doesn't correct emulate this DDD. >>>>>>
HHH correctly emulates DDD until this emulated DDD
proves that it cannot possibly reach its own emulated
final halt state.
And Correctly until ... isn't correct.
In other words when HHH correctly emulates N instructions
of DDD you are claiming that HHH did not correctly emulate
N instructions of DDD and likewise 1 does not equal itself.
No, and you are just lying by changing my words.
I am paraphrasing so that we can get a mutual understanding.
I said that H didn't CORRCTLY EMULATE H, which means to have finished
the job.
When HHH correctly emulates N instructions of DDD
then HHH has correctly finished its job of correctly
emulating N instructions of DDD.
On 8/5/2025 5:53 AM, Richard Damon wrote:
On 8/4/25 10:05 PM, olcott wrote:
On 8/4/2025 8:58 PM, Richard Damon wrote:
On 8/4/25 9:45 PM, olcott wrote:
In other words when HHH correctly emulates N instructions
of DDD you are claiming that HHH did not correctly emulate
N instructions of DDD and likewise 1 does not equal itself.
No, and you are just lying by changing my words.
I am paraphrasing so that we can get a mutual understanding.
You mean you are LYING by changing the meaning of them, just like you
falsely accuse everyone else.
Sorry, all you are doing is proving you are a Hypocritical
Pathological Liar that doesn't care about what it true.
I said that H didn't CORRCTLY EMULATE H, which means to have
finished the job.
When HHH correctly emulates N instructions of DDD
then HHH has correctly finished its job of correctly
emulating N instructions of DDD.
But its job wasn't to emulate N instructions of DDD, its job was to
predict if DDD will halt when run.
*From the bottom of page 319 has been adapted to this* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Definition of Turing Machine Ĥ applied
to its own machine description ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt.
*Lines 2 and 4 above*
*Does insist that Ĥ.embedded_H report on its own behavior*
"The contradiction in Linz's (or Turing's) self-referential
halting construction only appears if one insists that the
machine can and must decide on its own behavior, which is
neither possible nor required."
https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8
The definition of Turing Machines proves that none of
them can directly report on their own behavior on the
basis that Turing machines do not take other Turing
machines as inputs and no actual Machine can be an
actual input to itself.
In those cases where the behavior specified by the
input does not agree with the behavior of the direct
execution the behavior of the input overrules.
The fact that this disagrees with what your learned
by rote is not an actual rebuttal. Learning by rote
is not the ultimate measure of truth.
On 8/5/2025 5:53 AM, Richard Damon wrote:
On 8/4/25 10:05 PM, olcott wrote:
On 8/4/2025 8:58 PM, Richard Damon wrote:
On 8/4/25 9:45 PM, olcott wrote:
On 8/4/2025 8:41 PM, Richard Damon wrote:
On 8/4/25 9:31 PM, olcott wrote:
On 8/4/2025 8:25 PM, Richard Damon wrote:
On 8/4/25 9:42 AM, olcott wrote:
On 8/4/2025 7:47 AM, Fred. Zwarts wrote:
Op 02.aug.2025 om 16:16 schreef olcott:Because HHH correctly predicts that DDD emulated by
On 8/2/2025 4:18 AM, Fred. Zwarts wrote:
Op 01.aug.2025 om 16:46 schreef olcott:
On 8/1/2025 1:53 AM, joes wrote:
Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 7/31/2025 7:07 PM, Richard Damon wrote:
On 7/31/25 11:50 AM, olcott wrote:
On 7/29/2025 11:22 PM, Alan Mackenzie wrote: >>>>>>>>>>>>>>>>> > It is a lack of technical ability on your part >>>>>>>>>>>>>>>>> which is unable toAnd that separate proccess, if left unaborted, would >>>>>>>>>>>>>>>> halt. But HHH
> judge whether such a correct simulation is >>>>>>>>>>>>>>>>> possible. Everybody
> else sees that it is not, so further questions >>>>>>>>>>>>>>>>> about it are
> non-sensical.
HHH emulates DDD in a separate process context. When >>>>>>>>>>>>>>>>> this DDD calls
HHH(DDD) the original HHH emulates this HHH in the DDD >>>>>>>>>>>>>>>>> process
context.
gives up and aborts it, so the process is Halting, not >>>>>>>>>>>>>>>> non- halting.
And HHH cannot simulate itself to its undeniable halting >>>>>>>>>>>>>> state.
*No not at all. Not in the least little bit* Recursive >>>>>>>>>>>>>>> simulation isThis emulated HHH creates yet another process context >>>>>>>>>>>>>>>>> to emulate itshalting.
own DDD. When this DDD calls yet another HHH(DDD) this >>>>>>>>>>>>>>>>> provides enough
execution trace that the repeating pattern can be seen. >>>>>>>>>>>>>>>> But the pattern isn't non-halting by the fact that DDD >>>>>>>>>>>>>>>> is shown to be
only a little more difficult than self recursion.
DDD halts if it weren't aborted.
(1) That is counter-factual. Neither HHH() nor DDD() nor DDD >>>>>>>>>>>>> simulated by HHH ever stops running unless HHH(DDD) aborts >>>>>>>>>>>>> its input.
It is irrelevant what a hypothetical non-input would do. HHH >>>>>>>>>>>> aborts, so DDD and HHH, both the directly executing and the >>>>>>>>>>>> simulated versions halt.
DDD correctly simulated by HHH cannot possibly reach
its own simulated "return" instruction final halt state
in 1 to infinity steps of correct simulation. When the
simulation is aborted the entire process is killed so
there is no stack unwinding.
(2) I have never been taking about DDD() the behavior of a >>>>>>>>>>>>> non- input.
Turing machines are only accountable for the behavior that >>>>>>>>>>>>> their
inputs specify, they are never accountable for any non-inputs. >>>>>>>>>>>>
And this input specifies a program with code to abort, so it >>>>>>>>>>>> specifies a halting program. When HHH does not see that, it >>>>>>>>>>>> fails.
I discovered a case where the correct simulation
and the direct execution have different halting
behaviors.
No, you dreamed, but could not prove it. Only by twisting the >>>>>>>>>> meaning of the words, you could make yourself believing it. >>>>>>>>>>
(3) When I make a claim about DDD simulated by HHH and this is >>>>>>>>>>>>> changed to the behavior of the directly executed DDD this is >>>>>>>>>>>>> a dishonest tactic known as the strawman error.
When the input specifies a halting behaviour, it is an error >>>>>>>>>>>> to close your eyes and pretend that it does not exist. >>>>>>>>>>>>
Counterfactual. HHH abors after a few cycles, when only one >>>>>>>>>>>> more cycle is needed to complete the simulation, as proven >>>>>>>>>>>> by simulators that do not abort the exact same input.
void DDD()
{
HHH(DDD);
return;
}
Executed HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
Then HHH kills the whole simulation process and returns 0 >>>>>>>>>>>>
The above HHH aborts after ten recursive simulations
because people here did not understand that there were
any recursive simulation when I only show one or two.
That does not make any difference. We also see that you are >>>>>>>>>> cheating, by not only changing the simulator, but also the >>>>>>>>>> simulated input. World class simulators show that the original >>>>>>>>>> input, when correctly simulated, reaches its final halt state >>>>>>>>>> after tree recursion.
The HHH that simulates 10 recursions would also reach the
final halt state for this same input.
But, because your are cheating, you changed the input, which >>>>>>>>>> now needs eleven recursion to halt.
We see in this way, the, no matter how many recursions you >>>>>>>>>> simulate, this method is unable to reach the final halt state >>>>>>>>>> that is specified in the input when we construct a new DDD >>>>>>>>>> with this new HHH.
There is no non-halting behaviour pattern, only a finite >>>>>>>>>>>> number more than N instructions are needed to reach the >>>>>>>>>>>> final input *for this input*.
When N instructions of DDD are correctly emulated by >>>>>>>>>>>>>>> every HHH that can
possibly exist (technically this is an infinite set of >>>>>>>>>>>>>>> HHH/ DDD pairs)
no emulated DDD can possibly halt and every directly >>>>>>>>>>>>>>> executed DDD()
halts.
See, and I thought DDD was a concrete program filled in >>>>>>>>>>>>>> with HHH,
which aborts after two levels of simulation, not something >>>>>>>>>>>>>> that
calls "HHH" symbolically, producing many different programs. >>>>>>>>>>>>>>
I had to turn it into an infinite set of HHH/DDD
pairs so that it could be more easily understood
that DDD simulated by HHH cannot possibly halt.
When HHH detects the above non-halting behavior
pattern it kills the whole simulation process so
there is no stack unwinding.
counter-factual
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
WE have told you many times that it is incorrect to suggest >>>>>>>>>> that these 18 bytes describe the whole input for the simulator. >>>>>>>>>> All functions called by DDD, directly or indirectly, also
belong to the input under test.
Every 5 instructions of DDD that are correctly emulated
end up in HHH at line one. One more instruction of
DDD emulates line two, one more emulates line three,
one more ends up at line four, one more ends up back
at line one.
Incorrect, the call ends up inside HHH. When you would
correctly follow the code of HHH in your simulator, keeping >>>>>>>>>> track of the internal state of HHH and its conditional branch >>>>>>>>>> instruction, you would see that after a few cycles, HHH is >>>>>>>>>> specified to abort and return to DDD at line 5.
Then lines 6 and 7 would be simulated and the final halt state >>>>>>>>>> is reached.
But HHH fails to do this correct simulation, because it
prematurely aborts before it can see that.
Then HHH uses your attitude: close its eyes and pretend that >>>>>>>>>> what is not seen does not exist.
Each pair has a different input for the simulator. Each
Proving that for all N the program specifies a halting >>>>>>>>>>>> behaviour, but we can construct *another* input for which >>>>>>>>>>>> HHH fails again.
But you cheat by changing the input, which then needs more >>>>>>>>>>>> steps.
I do not cheat. I define the infinite set of HHH/DDD pairs >>>>>>>>>>> where HHH emulates N instructions of DDD and N is one element >>>>>>>>>>> of the natural numbers.
simulator fails for the input constructed with its own
version. But many of them prove that the input constructed >>>>>>>>>> with other HHH versions, which have less steps before the
premature abort, have a final halt state that can be reached. >>>>>>>>>
HHH cannot possibly reach its own final state each HHH that
aborts after N instructions have been emulated is correct
to reject its input as non halting.
But it can't do that, as that HHH doesn't correct emulate this DDD. >>>>>>>>
HHH correctly emulates DDD until this emulated DDD
proves that it cannot possibly reach its own emulated
final halt state.
And Correctly until ... isn't correct.
In other words when HHH correctly emulates N instructions
of DDD you are claiming that HHH did not correctly emulate
N instructions of DDD and likewise 1 does not equal itself.
No, and you are just lying by changing my words.
I am paraphrasing so that we can get a mutual understanding.
You mean you are LYING by changing the meaning of them, just like you
falsely accuse everyone else.
Sorry, all you are doing is proving you are a Hypocritical
Pathological Liar that doesn't care about what it true.
I said that H didn't CORRCTLY EMULATE H, which means to have
finished the job.
When HHH correctly emulates N instructions of DDD
then HHH has correctly finished its job of correctly
emulating N instructions of DDD.
But its job wasn't to emulate N instructions of DDD, its job was to
predict if DDD will halt when run.
The definition of a simulating halt decider stipulates otherwise.
On 8/5/2025 9:48 PM, Richard Damon wrote:
On 8/5/25 9:10 PM, olcott wrote:
On 8/5/2025 5:53 AM, Richard Damon wrote:
On 8/4/25 10:05 PM, olcott wrote:
On 8/4/2025 8:58 PM, Richard Damon wrote:
On 8/4/25 9:45 PM, olcott wrote:
On 8/4/2025 8:41 PM, Richard Damon wrote:
On 8/4/25 9:31 PM, olcott wrote:
On 8/4/2025 8:25 PM, Richard Damon wrote:
On 8/4/25 9:42 AM, olcott wrote:
On 8/4/2025 7:47 AM, Fred. Zwarts wrote:
Op 02.aug.2025 om 16:16 schreef olcott:Because HHH correctly predicts that DDD emulated by
On 8/2/2025 4:18 AM, Fred. Zwarts wrote:
Op 01.aug.2025 om 16:46 schreef olcott:
On 8/1/2025 1:53 AM, joes wrote:
Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott: >>>>>>>>>>>>>>>>> On 7/31/2025 7:07 PM, Richard Damon wrote:
On 7/31/25 11:50 AM, olcott wrote:
On 7/29/2025 11:22 PM, Alan Mackenzie wrote: >>>>>>>>>>>>>>>>>>> > It is a lack of technical ability on your part >>>>>>>>>>>>>>>>>>> which is unable toAnd that separate proccess, if left unaborted, would >>>>>>>>>>>>>>>>>> halt. But HHH
> judge whether such a correct simulation is >>>>>>>>>>>>>>>>>>> possible. Everybody
> else sees that it is not, so further questions >>>>>>>>>>>>>>>>>>> about it are
> non-sensical.
HHH emulates DDD in a separate process context. When >>>>>>>>>>>>>>>>>>> this DDD calls
HHH(DDD) the original HHH emulates this HHH in the >>>>>>>>>>>>>>>>>>> DDD process
context.
gives up and aborts it, so the process is Halting, not >>>>>>>>>>>>>>>>>> non- halting.
And HHH cannot simulate itself to its undeniable halting >>>>>>>>>>>>>>>> state.
DDD halts if it weren't aborted.*No not at all. Not in the least little bit* Recursive >>>>>>>>>>>>>>>>> simulation isThis emulated HHH creates yet another process context >>>>>>>>>>>>>>>>>>> to emulate itshalting.
own DDD. When this DDD calls yet another HHH(DDD) >>>>>>>>>>>>>>>>>>> this provides enough
execution trace that the repeating pattern can be seen. >>>>>>>>>>>>>>>>>> But the pattern isn't non-halting by the fact that DDD >>>>>>>>>>>>>>>>>> is shown to be
only a little more difficult than self recursion. >>>>>>>>>>>>>>>
(1) That is counter-factual. Neither HHH() nor DDD() nor DDD >>>>>>>>>>>>>>> simulated by HHH ever stops running unless HHH(DDD) aborts >>>>>>>>>>>>>>> its input.
It is irrelevant what a hypothetical non-input would do. >>>>>>>>>>>>>> HHH aborts, so DDD and HHH, both the directly executing >>>>>>>>>>>>>> and the simulated versions halt.
DDD correctly simulated by HHH cannot possibly reach >>>>>>>>>>>>> its own simulated "return" instruction final halt state >>>>>>>>>>>>> in 1 to infinity steps of correct simulation. When the >>>>>>>>>>>>> simulation is aborted the entire process is killed so >>>>>>>>>>>>> there is no stack unwinding.
(2) I have never been taking about DDD() the behavior of >>>>>>>>>>>>>>> a non- input.
Turing machines are only accountable for the behavior >>>>>>>>>>>>>>> that their
inputs specify, they are never accountable for any non- >>>>>>>>>>>>>>> inputs.
And this input specifies a program with code to abort, so >>>>>>>>>>>>>> it specifies a halting program. When HHH does not see >>>>>>>>>>>>>> that, it fails.
I discovered a case where the correct simulation
and the direct execution have different halting
behaviors.
No, you dreamed, but could not prove it. Only by twisting >>>>>>>>>>>> the meaning of the words, you could make yourself believing it. >>>>>>>>>>>>
That does not make any difference. We also see that you are >>>>>>>>>>>> cheating, by not only changing the simulator, but also the >>>>>>>>>>>> simulated input. World class simulators show that the
(3) When I make a claim about DDD simulated by HHH and >>>>>>>>>>>>>>> this is
changed to the behavior of the directly executed DDD this is >>>>>>>>>>>>>>> a dishonest tactic known as the strawman error.
When the input specifies a halting behaviour, it is an >>>>>>>>>>>>>> error to close your eyes and pretend that it does not exist. >>>>>>>>>>>>>>
Counterfactual. HHH abors after a few cycles, when only >>>>>>>>>>>>>> one more cycle is needed to complete the simulation, as >>>>>>>>>>>>>> proven by simulators that do not abort the exact same input. >>>>>>>>>>>>>>
void DDD()
{
HHH(DDD);
return;
}
Executed HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
Then HHH kills the whole simulation process and returns 0 >>>>>>>>>>>>>>
The above HHH aborts after ten recursive simulations >>>>>>>>>>>>> because people here did not understand that there were >>>>>>>>>>>>> any recursive simulation when I only show one or two. >>>>>>>>>>>>
original input, when correctly simulated, reaches its final >>>>>>>>>>>> halt state after tree recursion.
The HHH that simulates 10 recursions would also reach the >>>>>>>>>>>> final halt state for this same input.
But, because your are cheating, you changed the input, which >>>>>>>>>>>> now needs eleven recursion to halt.
We see in this way, the, no matter how many recursions you >>>>>>>>>>>> simulate, this method is unable to reach the final halt >>>>>>>>>>>> state that is specified in the input when we construct a new >>>>>>>>>>>> DDD with this new HHH.
There is no non-halting behaviour pattern, only a finite >>>>>>>>>>>>>> number more than N instructions are needed to reach the >>>>>>>>>>>>>> final input *for this input*.
When N instructions of DDD are correctly emulated by >>>>>>>>>>>>>>>>> every HHH that can
possibly exist (technically this is an infinite set of >>>>>>>>>>>>>>>>> HHH/ DDD pairs)
no emulated DDD can possibly halt and every directly >>>>>>>>>>>>>>>>> executed DDD()
halts.
See, and I thought DDD was a concrete program filled in >>>>>>>>>>>>>>>> with HHH,
which aborts after two levels of simulation, not >>>>>>>>>>>>>>>> something that
calls "HHH" symbolically, producing many different >>>>>>>>>>>>>>>> programs.
I had to turn it into an infinite set of HHH/DDD >>>>>>>>>>>>>>> pairs so that it could be more easily understood >>>>>>>>>>>>>>> that DDD simulated by HHH cannot possibly halt.
When HHH detects the above non-halting behavior
pattern it kills the whole simulation process so >>>>>>>>>>>>>>> there is no stack unwinding.
counter-factual
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
WE have told you many times that it is incorrect to suggest >>>>>>>>>>>> that these 18 bytes describe the whole input for the simulator. >>>>>>>>>>>> All functions called by DDD, directly or indirectly, also >>>>>>>>>>>> belong to the input under test.
Every 5 instructions of DDD that are correctly emulated >>>>>>>>>>>>> end up in HHH at line one. One more instruction of
DDD emulates line two, one more emulates line three, >>>>>>>>>>>>> one more ends up at line four, one more ends up back >>>>>>>>>>>>> at line one.
Incorrect, the call ends up inside HHH. When you would >>>>>>>>>>>> correctly follow the code of HHH in your simulator, keeping >>>>>>>>>>>> track of the internal state of HHH and its conditional >>>>>>>>>>>> branch instruction, you would see that after a few cycles, >>>>>>>>>>>> HHH is specified to abort and return to DDD at line 5. >>>>>>>>>>>> Then lines 6 and 7 would be simulated and the final halt >>>>>>>>>>>> state is reached.
But HHH fails to do this correct simulation, because it >>>>>>>>>>>> prematurely aborts before it can see that.
Then HHH uses your attitude: close its eyes and pretend that >>>>>>>>>>>> what is not seen does not exist.
Each pair has a different input for the simulator. Each >>>>>>>>>>>> simulator fails for the input constructed with its own >>>>>>>>>>>> version. But many of them prove that the input constructed >>>>>>>>>>>> with other HHH versions, which have less steps before the >>>>>>>>>>>> premature abort, have a final halt state that can be reached. >>>>>>>>>>>
Proving that for all N the program specifies a halting >>>>>>>>>>>>>> behaviour, but we can construct *another* input for which >>>>>>>>>>>>>> HHH fails again.
But you cheat by changing the input, which then needs more >>>>>>>>>>>>>> steps.
I do not cheat. I define the infinite set of HHH/DDD pairs >>>>>>>>>>>>> where HHH emulates N instructions of DDD and N is one element >>>>>>>>>>>>> of the natural numbers.
HHH cannot possibly reach its own final state each HHH that >>>>>>>>>>> aborts after N instructions have been emulated is correct >>>>>>>>>>> to reject its input as non halting.
But it can't do that, as that HHH doesn't correct emulate this >>>>>>>>>> DDD.
HHH correctly emulates DDD until this emulated DDD
proves that it cannot possibly reach its own emulated
final halt state.
And Correctly until ... isn't correct.
In other words when HHH correctly emulates N instructions
of DDD you are claiming that HHH did not correctly emulate
N instructions of DDD and likewise 1 does not equal itself.
No, and you are just lying by changing my words.
I am paraphrasing so that we can get a mutual understanding.
You mean you are LYING by changing the meaning of them, just like
you falsely accuse everyone else.
Sorry, all you are doing is proving you are a Hypocritical
Pathological Liar that doesn't care about what it true.
I said that H didn't CORRCTLY EMULATE H, which means to have
finished the job.
When HHH correctly emulates N instructions of DDD
then HHH has correctly finished its job of correctly
emulating N instructions of DDD.
But its job wasn't to emulate N instructions of DDD, its job was to
predict if DDD will halt when run.
The definition of a simulating halt decider stipulates otherwise.
Then they aren't Halt Decider, and you whole proof when up in a big
puff of smoke and lies.
It corrects the error of the requirement that
a halt decider reports on its own behavior.
"The contradiction in Linz's (or Turing's) self-referential
halting construction only appears if one insists that the
machine can and must decide on its own behavior, which is
neither possible nor required."
https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8
On 8/5/2025 9:48 PM, Richard Damon wrote:
On 8/5/25 9:10 PM, olcott wrote:
On 8/5/2025 5:53 AM, Richard Damon wrote:
On 8/4/25 10:05 PM, olcott wrote:
On 8/4/2025 8:58 PM, Richard Damon wrote:
On 8/4/25 9:45 PM, olcott wrote:
On 8/4/2025 8:41 PM, Richard Damon wrote:
On 8/4/25 9:31 PM, olcott wrote:
On 8/4/2025 8:25 PM, Richard Damon wrote:
On 8/4/25 9:42 AM, olcott wrote:
On 8/4/2025 7:47 AM, Fred. Zwarts wrote:
Op 02.aug.2025 om 16:16 schreef olcott:Because HHH correctly predicts that DDD emulated by
On 8/2/2025 4:18 AM, Fred. Zwarts wrote:
Op 01.aug.2025 om 16:46 schreef olcott:
On 8/1/2025 1:53 AM, joes wrote:
Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott: >>>>>>>>>>>>>>>>> On 7/31/2025 7:07 PM, Richard Damon wrote:
On 7/31/25 11:50 AM, olcott wrote:
On 7/29/2025 11:22 PM, Alan Mackenzie wrote: >>>>>>>>>>>>>>>>>>> > It is a lack of technical ability on your part >>>>>>>>>>>>>>>>>>> which is unable toAnd that separate proccess, if left unaborted, would >>>>>>>>>>>>>>>>>> halt. But HHH
> judge whether such a correct simulation is >>>>>>>>>>>>>>>>>>> possible. Everybody
> else sees that it is not, so further questions >>>>>>>>>>>>>>>>>>> about it are
> non-sensical.
HHH emulates DDD in a separate process context. When >>>>>>>>>>>>>>>>>>> this DDD calls
HHH(DDD) the original HHH emulates this HHH in the >>>>>>>>>>>>>>>>>>> DDD process
context.
gives up and aborts it, so the process is Halting, not >>>>>>>>>>>>>>>>>> non- halting.
And HHH cannot simulate itself to its undeniable halting >>>>>>>>>>>>>>>> state.
DDD halts if it weren't aborted.*No not at all. Not in the least little bit* Recursive >>>>>>>>>>>>>>>>> simulation isThis emulated HHH creates yet another process context >>>>>>>>>>>>>>>>>>> to emulate itshalting.
own DDD. When this DDD calls yet another HHH(DDD) >>>>>>>>>>>>>>>>>>> this provides enough
execution trace that the repeating pattern can be seen. >>>>>>>>>>>>>>>>>> But the pattern isn't non-halting by the fact that DDD >>>>>>>>>>>>>>>>>> is shown to be
only a little more difficult than self recursion. >>>>>>>>>>>>>>>
(1) That is counter-factual. Neither HHH() nor DDD() nor DDD >>>>>>>>>>>>>>> simulated by HHH ever stops running unless HHH(DDD) aborts >>>>>>>>>>>>>>> its input.
It is irrelevant what a hypothetical non-input would do. >>>>>>>>>>>>>> HHH aborts, so DDD and HHH, both the directly executing >>>>>>>>>>>>>> and the simulated versions halt.
DDD correctly simulated by HHH cannot possibly reach >>>>>>>>>>>>> its own simulated "return" instruction final halt state >>>>>>>>>>>>> in 1 to infinity steps of correct simulation. When the >>>>>>>>>>>>> simulation is aborted the entire process is killed so >>>>>>>>>>>>> there is no stack unwinding.
(2) I have never been taking about DDD() the behavior of >>>>>>>>>>>>>>> a non- input.
Turing machines are only accountable for the behavior >>>>>>>>>>>>>>> that their
inputs specify, they are never accountable for any non- >>>>>>>>>>>>>>> inputs.
And this input specifies a program with code to abort, so >>>>>>>>>>>>>> it specifies a halting program. When HHH does not see >>>>>>>>>>>>>> that, it fails.
I discovered a case where the correct simulation
and the direct execution have different halting
behaviors.
No, you dreamed, but could not prove it. Only by twisting >>>>>>>>>>>> the meaning of the words, you could make yourself believing it. >>>>>>>>>>>>
That does not make any difference. We also see that you are >>>>>>>>>>>> cheating, by not only changing the simulator, but also the >>>>>>>>>>>> simulated input. World class simulators show that the
(3) When I make a claim about DDD simulated by HHH and >>>>>>>>>>>>>>> this is
changed to the behavior of the directly executed DDD this is >>>>>>>>>>>>>>> a dishonest tactic known as the strawman error.
When the input specifies a halting behaviour, it is an >>>>>>>>>>>>>> error to close your eyes and pretend that it does not exist. >>>>>>>>>>>>>>
Counterfactual. HHH abors after a few cycles, when only >>>>>>>>>>>>>> one more cycle is needed to complete the simulation, as >>>>>>>>>>>>>> proven by simulators that do not abort the exact same input. >>>>>>>>>>>>>>
void DDD()
{
HHH(DDD);
return;
}
Executed HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
Then HHH kills the whole simulation process and returns 0 >>>>>>>>>>>>>>
The above HHH aborts after ten recursive simulations >>>>>>>>>>>>> because people here did not understand that there were >>>>>>>>>>>>> any recursive simulation when I only show one or two. >>>>>>>>>>>>
original input, when correctly simulated, reaches its final >>>>>>>>>>>> halt state after tree recursion.
The HHH that simulates 10 recursions would also reach the >>>>>>>>>>>> final halt state for this same input.
But, because your are cheating, you changed the input, which >>>>>>>>>>>> now needs eleven recursion to halt.
We see in this way, the, no matter how many recursions you >>>>>>>>>>>> simulate, this method is unable to reach the final halt >>>>>>>>>>>> state that is specified in the input when we construct a new >>>>>>>>>>>> DDD with this new HHH.
There is no non-halting behaviour pattern, only a finite >>>>>>>>>>>>>> number more than N instructions are needed to reach the >>>>>>>>>>>>>> final input *for this input*.
When N instructions of DDD are correctly emulated by >>>>>>>>>>>>>>>>> every HHH that can
possibly exist (technically this is an infinite set of >>>>>>>>>>>>>>>>> HHH/ DDD pairs)
no emulated DDD can possibly halt and every directly >>>>>>>>>>>>>>>>> executed DDD()
halts.
See, and I thought DDD was a concrete program filled in >>>>>>>>>>>>>>>> with HHH,
which aborts after two levels of simulation, not >>>>>>>>>>>>>>>> something that
calls "HHH" symbolically, producing many different >>>>>>>>>>>>>>>> programs.
I had to turn it into an infinite set of HHH/DDD >>>>>>>>>>>>>>> pairs so that it could be more easily understood >>>>>>>>>>>>>>> that DDD simulated by HHH cannot possibly halt.
When HHH detects the above non-halting behavior
pattern it kills the whole simulation process so >>>>>>>>>>>>>>> there is no stack unwinding.
counter-factual
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
WE have told you many times that it is incorrect to suggest >>>>>>>>>>>> that these 18 bytes describe the whole input for the simulator. >>>>>>>>>>>> All functions called by DDD, directly or indirectly, also >>>>>>>>>>>> belong to the input under test.
Every 5 instructions of DDD that are correctly emulated >>>>>>>>>>>>> end up in HHH at line one. One more instruction of
DDD emulates line two, one more emulates line three, >>>>>>>>>>>>> one more ends up at line four, one more ends up back >>>>>>>>>>>>> at line one.
Incorrect, the call ends up inside HHH. When you would >>>>>>>>>>>> correctly follow the code of HHH in your simulator, keeping >>>>>>>>>>>> track of the internal state of HHH and its conditional >>>>>>>>>>>> branch instruction, you would see that after a few cycles, >>>>>>>>>>>> HHH is specified to abort and return to DDD at line 5. >>>>>>>>>>>> Then lines 6 and 7 would be simulated and the final halt >>>>>>>>>>>> state is reached.
But HHH fails to do this correct simulation, because it >>>>>>>>>>>> prematurely aborts before it can see that.
Then HHH uses your attitude: close its eyes and pretend that >>>>>>>>>>>> what is not seen does not exist.
Each pair has a different input for the simulator. Each >>>>>>>>>>>> simulator fails for the input constructed with its own >>>>>>>>>>>> version. But many of them prove that the input constructed >>>>>>>>>>>> with other HHH versions, which have less steps before the >>>>>>>>>>>> premature abort, have a final halt state that can be reached. >>>>>>>>>>>
Proving that for all N the program specifies a halting >>>>>>>>>>>>>> behaviour, but we can construct *another* input for which >>>>>>>>>>>>>> HHH fails again.
But you cheat by changing the input, which then needs more >>>>>>>>>>>>>> steps.
I do not cheat. I define the infinite set of HHH/DDD pairs >>>>>>>>>>>>> where HHH emulates N instructions of DDD and N is one element >>>>>>>>>>>>> of the natural numbers.
HHH cannot possibly reach its own final state each HHH that >>>>>>>>>>> aborts after N instructions have been emulated is correct >>>>>>>>>>> to reject its input as non halting.
But it can't do that, as that HHH doesn't correct emulate this >>>>>>>>>> DDD.
HHH correctly emulates DDD until this emulated DDD
proves that it cannot possibly reach its own emulated
final halt state.
And Correctly until ... isn't correct.
In other words when HHH correctly emulates N instructions
of DDD you are claiming that HHH did not correctly emulate
N instructions of DDD and likewise 1 does not equal itself.
No, and you are just lying by changing my words.
I am paraphrasing so that we can get a mutual understanding.
You mean you are LYING by changing the meaning of them, just like
you falsely accuse everyone else.
Sorry, all you are doing is proving you are a Hypocritical
Pathological Liar that doesn't care about what it true.
I said that H didn't CORRCTLY EMULATE H, which means to have
finished the job.
When HHH correctly emulates N instructions of DDD
then HHH has correctly finished its job of correctly
emulating N instructions of DDD.
But its job wasn't to emulate N instructions of DDD, its job was to
predict if DDD will halt when run.
The definition of a simulating halt decider stipulates otherwise.
Then they aren't Halt Decider, and you whole proof when up in a big
puff of smoke and lies.
It corrects the error of the requirement that
a halt decider reports on its own behavior.
"The contradiction in Linz's (or Turing's) self-referential
halting construction only appears if one insists that the
machine can and must decide on its own behavior, which is
neither possible nor required."
https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8
On 8/5/2025 9:48 PM, Richard Damon wrote:
On 8/5/25 9:10 PM, olcott wrote:
On 8/5/2025 5:53 AM, Richard Damon wrote:
On 8/4/25 10:05 PM, olcott wrote:
On 8/4/2025 8:58 PM, Richard Damon wrote:
On 8/4/25 9:45 PM, olcott wrote:
On 8/4/2025 8:41 PM, Richard Damon wrote:
On 8/4/25 9:31 PM, olcott wrote:
On 8/4/2025 8:25 PM, Richard Damon wrote:
On 8/4/25 9:42 AM, olcott wrote:
On 8/4/2025 7:47 AM, Fred. Zwarts wrote:
Op 02.aug.2025 om 16:16 schreef olcott:Because HHH correctly predicts that DDD emulated by
On 8/2/2025 4:18 AM, Fred. Zwarts wrote:
Op 01.aug.2025 om 16:46 schreef olcott:
On 8/1/2025 1:53 AM, joes wrote:
Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott: >>>>>>>>>>>>>>>>> On 7/31/2025 7:07 PM, Richard Damon wrote:
On 7/31/25 11:50 AM, olcott wrote:
On 7/29/2025 11:22 PM, Alan Mackenzie wrote: >>>>>>>>>>>>>>>>>>> > It is a lack of technical ability on your part >>>>>>>>>>>>>>>>>>> which is unable toAnd that separate proccess, if left unaborted, would >>>>>>>>>>>>>>>>>> halt. But HHH
> judge whether such a correct simulation is >>>>>>>>>>>>>>>>>>> possible. Everybody
> else sees that it is not, so further questions >>>>>>>>>>>>>>>>>>> about it are
> non-sensical.
HHH emulates DDD in a separate process context. When >>>>>>>>>>>>>>>>>>> this DDD calls
HHH(DDD) the original HHH emulates this HHH in the >>>>>>>>>>>>>>>>>>> DDD process
context.
gives up and aborts it, so the process is Halting, not >>>>>>>>>>>>>>>>>> non- halting.
And HHH cannot simulate itself to its undeniable halting >>>>>>>>>>>>>>>> state.
DDD halts if it weren't aborted.*No not at all. Not in the least little bit* Recursive >>>>>>>>>>>>>>>>> simulation isThis emulated HHH creates yet another process context >>>>>>>>>>>>>>>>>>> to emulate itshalting.
own DDD. When this DDD calls yet another HHH(DDD) >>>>>>>>>>>>>>>>>>> this provides enough
execution trace that the repeating pattern can be seen. >>>>>>>>>>>>>>>>>> But the pattern isn't non-halting by the fact that DDD >>>>>>>>>>>>>>>>>> is shown to be
only a little more difficult than self recursion. >>>>>>>>>>>>>>>
(1) That is counter-factual. Neither HHH() nor DDD() nor DDD >>>>>>>>>>>>>>> simulated by HHH ever stops running unless HHH(DDD) aborts >>>>>>>>>>>>>>> its input.
It is irrelevant what a hypothetical non-input would do. >>>>>>>>>>>>>> HHH aborts, so DDD and HHH, both the directly executing >>>>>>>>>>>>>> and the simulated versions halt.
DDD correctly simulated by HHH cannot possibly reach >>>>>>>>>>>>> its own simulated "return" instruction final halt state >>>>>>>>>>>>> in 1 to infinity steps of correct simulation. When the >>>>>>>>>>>>> simulation is aborted the entire process is killed so >>>>>>>>>>>>> there is no stack unwinding.
(2) I have never been taking about DDD() the behavior of >>>>>>>>>>>>>>> a non- input.
Turing machines are only accountable for the behavior >>>>>>>>>>>>>>> that their
inputs specify, they are never accountable for any non- >>>>>>>>>>>>>>> inputs.
And this input specifies a program with code to abort, so >>>>>>>>>>>>>> it specifies a halting program. When HHH does not see >>>>>>>>>>>>>> that, it fails.
I discovered a case where the correct simulation
and the direct execution have different halting
behaviors.
No, you dreamed, but could not prove it. Only by twisting >>>>>>>>>>>> the meaning of the words, you could make yourself believing it. >>>>>>>>>>>>
That does not make any difference. We also see that you are >>>>>>>>>>>> cheating, by not only changing the simulator, but also the >>>>>>>>>>>> simulated input. World class simulators show that the
(3) When I make a claim about DDD simulated by HHH and >>>>>>>>>>>>>>> this is
changed to the behavior of the directly executed DDD this is >>>>>>>>>>>>>>> a dishonest tactic known as the strawman error.
When the input specifies a halting behaviour, it is an >>>>>>>>>>>>>> error to close your eyes and pretend that it does not exist. >>>>>>>>>>>>>>
Counterfactual. HHH abors after a few cycles, when only >>>>>>>>>>>>>> one more cycle is needed to complete the simulation, as >>>>>>>>>>>>>> proven by simulators that do not abort the exact same input. >>>>>>>>>>>>>>
void DDD()
{
HHH(DDD);
return;
}
Executed HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
Then HHH kills the whole simulation process and returns 0 >>>>>>>>>>>>>>
The above HHH aborts after ten recursive simulations >>>>>>>>>>>>> because people here did not understand that there were >>>>>>>>>>>>> any recursive simulation when I only show one or two. >>>>>>>>>>>>
original input, when correctly simulated, reaches its final >>>>>>>>>>>> halt state after tree recursion.
The HHH that simulates 10 recursions would also reach the >>>>>>>>>>>> final halt state for this same input.
But, because your are cheating, you changed the input, which >>>>>>>>>>>> now needs eleven recursion to halt.
We see in this way, the, no matter how many recursions you >>>>>>>>>>>> simulate, this method is unable to reach the final halt >>>>>>>>>>>> state that is specified in the input when we construct a new >>>>>>>>>>>> DDD with this new HHH.
There is no non-halting behaviour pattern, only a finite >>>>>>>>>>>>>> number more than N instructions are needed to reach the >>>>>>>>>>>>>> final input *for this input*.
When N instructions of DDD are correctly emulated by >>>>>>>>>>>>>>>>> every HHH that can
possibly exist (technically this is an infinite set of >>>>>>>>>>>>>>>>> HHH/ DDD pairs)
no emulated DDD can possibly halt and every directly >>>>>>>>>>>>>>>>> executed DDD()
halts.
See, and I thought DDD was a concrete program filled in >>>>>>>>>>>>>>>> with HHH,
which aborts after two levels of simulation, not >>>>>>>>>>>>>>>> something that
calls "HHH" symbolically, producing many different >>>>>>>>>>>>>>>> programs.
I had to turn it into an infinite set of HHH/DDD >>>>>>>>>>>>>>> pairs so that it could be more easily understood >>>>>>>>>>>>>>> that DDD simulated by HHH cannot possibly halt.
When HHH detects the above non-halting behavior
pattern it kills the whole simulation process so >>>>>>>>>>>>>>> there is no stack unwinding.
counter-factual
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
WE have told you many times that it is incorrect to suggest >>>>>>>>>>>> that these 18 bytes describe the whole input for the simulator. >>>>>>>>>>>> All functions called by DDD, directly or indirectly, also >>>>>>>>>>>> belong to the input under test.
Every 5 instructions of DDD that are correctly emulated >>>>>>>>>>>>> end up in HHH at line one. One more instruction of
DDD emulates line two, one more emulates line three, >>>>>>>>>>>>> one more ends up at line four, one more ends up back >>>>>>>>>>>>> at line one.
Incorrect, the call ends up inside HHH. When you would >>>>>>>>>>>> correctly follow the code of HHH in your simulator, keeping >>>>>>>>>>>> track of the internal state of HHH and its conditional >>>>>>>>>>>> branch instruction, you would see that after a few cycles, >>>>>>>>>>>> HHH is specified to abort and return to DDD at line 5. >>>>>>>>>>>> Then lines 6 and 7 would be simulated and the final halt >>>>>>>>>>>> state is reached.
But HHH fails to do this correct simulation, because it >>>>>>>>>>>> prematurely aborts before it can see that.
Then HHH uses your attitude: close its eyes and pretend that >>>>>>>>>>>> what is not seen does not exist.
Each pair has a different input for the simulator. Each >>>>>>>>>>>> simulator fails for the input constructed with its own >>>>>>>>>>>> version. But many of them prove that the input constructed >>>>>>>>>>>> with other HHH versions, which have less steps before the >>>>>>>>>>>> premature abort, have a final halt state that can be reached. >>>>>>>>>>>
Proving that for all N the program specifies a halting >>>>>>>>>>>>>> behaviour, but we can construct *another* input for which >>>>>>>>>>>>>> HHH fails again.
But you cheat by changing the input, which then needs more >>>>>>>>>>>>>> steps.
I do not cheat. I define the infinite set of HHH/DDD pairs >>>>>>>>>>>>> where HHH emulates N instructions of DDD and N is one element >>>>>>>>>>>>> of the natural numbers.
HHH cannot possibly reach its own final state each HHH that >>>>>>>>>>> aborts after N instructions have been emulated is correct >>>>>>>>>>> to reject its input as non halting.
But it can't do that, as that HHH doesn't correct emulate this >>>>>>>>>> DDD.
HHH correctly emulates DDD until this emulated DDD
proves that it cannot possibly reach its own emulated
final halt state.
And Correctly until ... isn't correct.
In other words when HHH correctly emulates N instructions
of DDD you are claiming that HHH did not correctly emulate
N instructions of DDD and likewise 1 does not equal itself.
No, and you are just lying by changing my words.
I am paraphrasing so that we can get a mutual understanding.
You mean you are LYING by changing the meaning of them, just like
you falsely accuse everyone else.
Sorry, all you are doing is proving you are a Hypocritical
Pathological Liar that doesn't care about what it true.
I said that H didn't CORRCTLY EMULATE H, which means to have
finished the job.
When HHH correctly emulates N instructions of DDD
then HHH has correctly finished its job of correctly
emulating N instructions of DDD.
But its job wasn't to emulate N instructions of DDD, its job was to
predict if DDD will halt when run.
The definition of a simulating halt decider stipulates otherwise.
Then they aren't Halt Decider, and you whole proof when up in a big
puff of smoke and lies.
It corrects the error of the requirement that
a halt decider reports on its own behavior.
"The contradiction in Linz's (or Turing's) self-referential
halting construction only appears if one insists that the
machine can and must decide on its own behavior, which is
neither possible nor required."
https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8
On 8/6/2025 4:00 AM, Fred. Zwarts wrote:
Op 06.aug.2025 om 05:47 schreef olcott:*This is my correction*
It corrects the error of the requirement that
a halt decider reports on its own behavior.
"The contradiction in Linz's (or Turing's) self-referential
halting construction only appears if one insists that the
machine can and must decide on its own behavior, which is
neither possible nor required."
https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8
That seems to be one of your misunderstanding. A decider must report
on the behaviour of its input, even if this behaviour resembles its
own behaviour. That is very different from 'deciding on its own
behaviour'.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
its simulated final halt state of ⟨Ĥ.qn⟩, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly
reach its simulated final halt state of ⟨Ĥ.qn⟩.
*This is the original erroneous one*
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt.
*Lines two and four requires Ĥ.embedded_H to report on its own behavior*
On 8/6/2025 6:41 AM, Richard Damon wrote:
On 8/6/25 7:39 AM, olcott wrote:
On 8/6/2025 4:00 AM, Fred. Zwarts wrote:
Op 06.aug.2025 om 05:47 schreef olcott:*This is my correction*
It corrects the error of the requirement that
a halt decider reports on its own behavior.
"The contradiction in Linz's (or Turing's) self-referential
halting construction only appears if one insists that the
machine can and must decide on its own behavior, which is
neither possible nor required."
https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8
That seems to be one of your misunderstanding. A decider must report
on the behaviour of its input, even if this behaviour resembles its
own behaviour. That is very different from 'deciding on its own
behaviour'.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
its simulated final halt state of ⟨Ĥ.qn⟩, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly
reach its simulated final halt state of ⟨Ĥ.qn⟩.
*This is the original erroneous one*
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt.
*Lines two and four requires Ĥ.embedded_H to report on its own behavior* >>>
Which is valid.
And you are just stupid to think otherwise.
It is only valid when Turing machine deciders can
take themselves as inputs.
On 8/6/2025 6:41 AM, Richard Damon wrote:
On 8/6/25 7:39 AM, olcott wrote:
On 8/6/2025 4:00 AM, Fred. Zwarts wrote:
Op 06.aug.2025 om 05:47 schreef olcott:*This is my correction*
It corrects the error of the requirement that
a halt decider reports on its own behavior.
"The contradiction in Linz's (or Turing's) self-referential
halting construction only appears if one insists that the
machine can and must decide on its own behavior, which is
neither possible nor required."
https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8
That seems to be one of your misunderstanding. A decider must report
on the behaviour of its input, even if this behaviour resembles its
own behaviour. That is very different from 'deciding on its own
behaviour'.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
its simulated final halt state of ⟨Ĥ.qn⟩, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly
reach its simulated final halt state of ⟨Ĥ.qn⟩.
*This is the original erroneous one*
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt.
*Lines two and four requires Ĥ.embedded_H to report on its own behavior* >>>
Which is valid.
typedef void (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
A halt decider is required to report on the actual behavior
that its input actually specifies.
After N steps of DD correctly emulated by HHH the
non-terminating pattern of recursive emulation emerges
on the basis of the structure of the relationship
between HHH and DD. There never has been any actual
need for an infinite emulation to see this pattern.
And you are just stupid to think otherwise.
Things people say when they have no actual reasoning
to back up their position.
On 8/6/2025 5:54 AM, Richard Damon wrote:
On 8/5/25 11:47 PM, olcott wrote:
It corrects the error of the requirement that
a halt decider reports on its own behavior.
But it isn't an error.
Halt Deciders need to answer about *ANY* program, and they are programs.
"The contradiction in Linz's (or Turing's) self-referential
halting construction only appears if one insists that the
machine can and must decide on its own behavior, which is
neither possible nor required."
https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8
Because you lied to it and said it was an error.
The above paragraph is proved true by the meaning of its words.
When we ask a Turing machine to report on its own behavior we
are assuming that its Turing Machine description is an accurate
proxy for this behavior. When there are exceptions to this rule
then we cannot possibly ask a Turing machine about its own behavior.
This is easily corrected:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
its simulated final halt state of ⟨Ĥ.qn⟩, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly
reach its simulated final halt state of ⟨Ĥ.qn⟩.
When we use the above standard then a halt decider
will always report on the actual behavior that its
input actually specifies.
On 8/6/2025 6:07 AM, Richard Damon wrote:
On 8/5/25 11:47 PM, olcott wrote:
On 8/5/2025 9:48 PM, Richard Damon wrote:
On 8/5/25 9:10 PM, olcott wrote:
On 8/5/2025 5:53 AM, Richard Damon wrote:
On 8/4/25 10:05 PM, olcott wrote:
On 8/4/2025 8:58 PM, Richard Damon wrote:
On 8/4/25 9:45 PM, olcott wrote:
On 8/4/2025 8:41 PM, Richard Damon wrote:
On 8/4/25 9:31 PM, olcott wrote:
On 8/4/2025 8:25 PM, Richard Damon wrote:
On 8/4/25 9:42 AM, olcott wrote:
On 8/4/2025 7:47 AM, Fred. Zwarts wrote:
Op 02.aug.2025 om 16:16 schreef olcott:Because HHH correctly predicts that DDD emulated by
On 8/2/2025 4:18 AM, Fred. Zwarts wrote:
Op 01.aug.2025 om 16:46 schreef olcott:
On 8/1/2025 1:53 AM, joes wrote:
Am Thu, 31 Jul 2025 19:18:36 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>>> On 7/31/2025 7:07 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 7/31/25 11:50 AM, olcott wrote:
On 7/29/2025 11:22 PM, Alan Mackenzie wrote: >>>>>>>>>>>>>>>>>>>>> > It is a lack of technical ability on your part >>>>>>>>>>>>>>>>>>>>> which is unable toAnd that separate proccess, if left unaborted, would >>>>>>>>>>>>>>>>>>>> halt. But HHH
> judge whether such a correct simulation is >>>>>>>>>>>>>>>>>>>>> possible. Everybody
> else sees that it is not, so further questions >>>>>>>>>>>>>>>>>>>>> about it are
> non-sensical.
HHH emulates DDD in a separate process context. >>>>>>>>>>>>>>>>>>>>> When this DDD calls
HHH(DDD) the original HHH emulates this HHH in the >>>>>>>>>>>>>>>>>>>>> DDD process
context.
gives up and aborts it, so the process is Halting, >>>>>>>>>>>>>>>>>>>> not non- halting.
And HHH cannot simulate itself to its undeniable >>>>>>>>>>>>>>>>>> halting state.
DDD halts if it weren't aborted.*No not at all. Not in the least little bit* >>>>>>>>>>>>>>>>>>> Recursive simulation isThis emulated HHH creates yet another process >>>>>>>>>>>>>>>>>>>>> context to emulate itsBut the pattern isn't non-halting by the fact that >>>>>>>>>>>>>>>>>>>> DDD is shown to be
own DDD. When this DDD calls yet another HHH(DDD) >>>>>>>>>>>>>>>>>>>>> this provides enough
execution trace that the repeating pattern can be >>>>>>>>>>>>>>>>>>>>> seen.
halting.
only a little more difficult than self recursion. >>>>>>>>>>>>>>>>>
(1) That is counter-factual. Neither HHH() nor DDD() >>>>>>>>>>>>>>>>> nor DDD
simulated by HHH ever stops running unless HHH(DDD) aborts >>>>>>>>>>>>>>>>> its input.
It is irrelevant what a hypothetical non-input would do. >>>>>>>>>>>>>>>> HHH aborts, so DDD and HHH, both the directly executing >>>>>>>>>>>>>>>> and the simulated versions halt.
DDD correctly simulated by HHH cannot possibly reach >>>>>>>>>>>>>>> its own simulated "return" instruction final halt state >>>>>>>>>>>>>>> in 1 to infinity steps of correct simulation. When the >>>>>>>>>>>>>>> simulation is aborted the entire process is killed so >>>>>>>>>>>>>>> there is no stack unwinding.
(2) I have never been taking about DDD() the behavior >>>>>>>>>>>>>>>>> of a non- input.
Turing machines are only accountable for the behavior >>>>>>>>>>>>>>>>> that their
inputs specify, they are never accountable for any non- >>>>>>>>>>>>>>>>> inputs.
And this input specifies a program with code to abort, >>>>>>>>>>>>>>>> so it specifies a halting program. When HHH does not see >>>>>>>>>>>>>>>> that, it fails.
I discovered a case where the correct simulation >>>>>>>>>>>>>>> and the direct execution have different halting
behaviors.
No, you dreamed, but could not prove it. Only by twisting >>>>>>>>>>>>>> the meaning of the words, you could make yourself
believing it.
That does not make any difference. We also see that you >>>>>>>>>>>>>> are cheating, by not only changing the simulator, but also >>>>>>>>>>>>>> the simulated input. World class simulators show that the >>>>>>>>>>>>>> original input, when correctly simulated, reaches its >>>>>>>>>>>>>> final halt state after tree recursion.
When the input specifies a halting behaviour, it is an >>>>>>>>>>>>>>>> error to close your eyes and pretend that it does not >>>>>>>>>>>>>>>> exist.
(3) When I make a claim about DDD simulated by HHH and >>>>>>>>>>>>>>>>> this is
changed to the behavior of the directly executed DDD >>>>>>>>>>>>>>>>> this is
a dishonest tactic known as the strawman error. >>>>>>>>>>>>>>>>
Counterfactual. HHH abors after a few cycles, when only >>>>>>>>>>>>>>>> one more cycle is needed to complete the simulation, as >>>>>>>>>>>>>>>> proven by simulators that do not abort the exact same >>>>>>>>>>>>>>>> input.
void DDD()
{
HHH(DDD);
return;
}
Executed HHH simulates DDD that calls HHH(DDD) >>>>>>>>>>>>>>>>> that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
Then HHH kills the whole simulation process and returns 0 >>>>>>>>>>>>>>>>
The above HHH aborts after ten recursive simulations >>>>>>>>>>>>>>> because people here did not understand that there were >>>>>>>>>>>>>>> any recursive simulation when I only show one or two. >>>>>>>>>>>>>>
The HHH that simulates 10 recursions would also reach the >>>>>>>>>>>>>> final halt state for this same input.
But, because your are cheating, you changed the input, >>>>>>>>>>>>>> which now needs eleven recursion to halt.
We see in this way, the, no matter how many recursions you >>>>>>>>>>>>>> simulate, this method is unable to reach the final halt >>>>>>>>>>>>>> state that is specified in the input when we construct a >>>>>>>>>>>>>> new DDD with this new HHH.
There is no non-halting behaviour pattern, only a finite >>>>>>>>>>>>>>>> number more than N instructions are needed to reach the >>>>>>>>>>>>>>>> final input *for this input*.
When N instructions of DDD are correctly emulated by >>>>>>>>>>>>>>>>>>> every HHH that can
possibly exist (technically this is an infinite set >>>>>>>>>>>>>>>>>>> of HHH/ DDD pairs)
no emulated DDD can possibly halt and every directly >>>>>>>>>>>>>>>>>>> executed DDD()
halts.
See, and I thought DDD was a concrete program filled >>>>>>>>>>>>>>>>>> in with HHH,
which aborts after two levels of simulation, not >>>>>>>>>>>>>>>>>> something that
calls "HHH" symbolically, producing many different >>>>>>>>>>>>>>>>>> programs.
I had to turn it into an infinite set of HHH/DDD >>>>>>>>>>>>>>>>> pairs so that it could be more easily understood >>>>>>>>>>>>>>>>> that DDD simulated by HHH cannot possibly halt. >>>>>>>>>>>>>>>>>
When HHH detects the above non-halting behavior >>>>>>>>>>>>>>>>> pattern it kills the whole simulation process so >>>>>>>>>>>>>>>>> there is no stack unwinding.
counter-factual
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD >>>>>>>>>>>>>>> [0000219a] e833f4ffff call 000015d2 // call HHH >>>>>>>>>>>>>>> [0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
WE have told you many times that it is incorrect to >>>>>>>>>>>>>> suggest that these 18 bytes describe the whole input for >>>>>>>>>>>>>> the simulator.
All functions called by DDD, directly or indirectly, also >>>>>>>>>>>>>> belong to the input under test.
Every 5 instructions of DDD that are correctly emulated >>>>>>>>>>>>>>> end up in HHH at line one. One more instruction of >>>>>>>>>>>>>>> DDD emulates line two, one more emulates line three, >>>>>>>>>>>>>>> one more ends up at line four, one more ends up back >>>>>>>>>>>>>>> at line one.
Incorrect, the call ends up inside HHH. When you would >>>>>>>>>>>>>> correctly follow the code of HHH in your simulator, >>>>>>>>>>>>>> keeping track of the internal state of HHH and its >>>>>>>>>>>>>> conditional branch instruction, you would see that after a >>>>>>>>>>>>>> few cycles, HHH is specified to abort and return to DDD at >>>>>>>>>>>>>> line 5.
Then lines 6 and 7 would be simulated and the final halt >>>>>>>>>>>>>> state is reached.
But HHH fails to do this correct simulation, because it >>>>>>>>>>>>>> prematurely aborts before it can see that.
Then HHH uses your attitude: close its eyes and pretend >>>>>>>>>>>>>> that what is not seen does not exist.
Each pair has a different input for the simulator. Each >>>>>>>>>>>>>> simulator fails for the input constructed with its own >>>>>>>>>>>>>> version. But many of them prove that the input constructed >>>>>>>>>>>>>> with other HHH versions, which have less steps before the >>>>>>>>>>>>>> premature abort, have a final halt state that can be reached. >>>>>>>>>>>>>
Proving that for all N the program specifies a halting >>>>>>>>>>>>>>>> behaviour, but we can construct *another* input for >>>>>>>>>>>>>>>> which HHH fails again.
But you cheat by changing the input, which then needs >>>>>>>>>>>>>>>> more steps.
I do not cheat. I define the infinite set of HHH/DDD pairs >>>>>>>>>>>>>>> where HHH emulates N instructions of DDD and N is one >>>>>>>>>>>>>>> element
of the natural numbers.
HHH cannot possibly reach its own final state each HHH that >>>>>>>>>>>>> aborts after N instructions have been emulated is correct >>>>>>>>>>>>> to reject its input as non halting.
But it can't do that, as that HHH doesn't correct emulate >>>>>>>>>>>> this DDD.
HHH correctly emulates DDD until this emulated DDD
proves that it cannot possibly reach its own emulated
final halt state.
And Correctly until ... isn't correct.
In other words when HHH correctly emulates N instructions
of DDD you are claiming that HHH did not correctly emulate
N instructions of DDD and likewise 1 does not equal itself.
No, and you are just lying by changing my words.
I am paraphrasing so that we can get a mutual understanding.
You mean you are LYING by changing the meaning of them, just like
you falsely accuse everyone else.
Sorry, all you are doing is proving you are a Hypocritical
Pathological Liar that doesn't care about what it true.
I said that H didn't CORRCTLY EMULATE H, which means to have
finished the job.
When HHH correctly emulates N instructions of DDD
then HHH has correctly finished its job of correctly
emulating N instructions of DDD.
But its job wasn't to emulate N instructions of DDD, its job was
to predict if DDD will halt when run.
The definition of a simulating halt decider stipulates otherwise.
Then they aren't Halt Decider, and you whole proof when up in a big
puff of smoke and lies.
It corrects the error of the requirement that
a halt decider reports on its own behavior.
Which isn't an error, but is a valid part of the requirments.
"The contradiction in Linz's (or Turing's) self-referential
halting construction only appears if one insists that the
machine can and must decide on its own behavior, which is
neither possible nor required."
https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8
Since you LIED to it by saying that Halt Deciders aren't responsible
for an input that is itself, the answer it gives is invalid.
Truth has no lie.
The above paragraph is proved true by the meaning of its words.
When we ask a Turing machine to report on its own behavior we
are assuming that its Turing Machine description is an accurate
proxy for this behavior. When there are exceptions to this rule
then we cannot possibly ask a Turing machine about its own behavior.
This is easily corrected:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
its simulated final halt state of ⟨Ĥ.qn⟩, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly
reach its simulated final halt state of ⟨Ĥ.qn⟩.
When we use the above standard then a halt decider
will always report on the actual behavior that its
input actually specifies.
On 8/6/2025 9:27 PM, Richard Damon wrote:
On 8/6/25 7:53 AM, olcott wrote:
On 8/6/2025 5:54 AM, Richard Damon wrote:
On 8/5/25 11:47 PM, olcott wrote:
It corrects the error of the requirement that
a halt decider reports on its own behavior.
But it isn't an error.
Halt Deciders need to answer about *ANY* program, and they are
programs.
"The contradiction in Linz's (or Turing's) self-referential
halting construction only appears if one insists that the
machine can and must decide on its own behavior, which is
neither possible nor required."
https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8
Because you lied to it and said it was an error.
The above paragraph is proved true by the meaning of its words.
When we ask a Turing machine to report on its own behavior we
are assuming that its Turing Machine description is an accurate
proxy for this behavior. When there are exceptions to this rule
then we cannot possibly ask a Turing machine about its own behavior.
This is easily corrected:
But the existance of UTMs means that it IS possible to make a perfect
proxy, as the UTM can completely recreate the behavior of ANY machine
from its Turing Machine Description.
All you are doing is admitting that you think errors and lies are ok.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy,
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
After a finite number of correct simulations the UTM
will reach its final state yet no simulated UTM ever
reaches its own final state.
On 8/6/2025 9:13 PM, Richard Damon wrote:That is your mistake. It does not require to report on its own
On 8/6/25 8:18 AM, olcott wrote:
On 8/6/2025 6:41 AM, Richard Damon wrote:
On 8/6/25 7:39 AM, olcott wrote:
On 8/6/2025 4:00 AM, Fred. Zwarts wrote:
Op 06.aug.2025 om 05:47 schreef olcott:*This is my correction*
It corrects the error of the requirement that
a halt decider reports on its own behavior.
"The contradiction in Linz's (or Turing's) self-referential >>>>>>> halting construction only appears if one insists that the >>>>>>> machine can and must decide on its own behavior, which is >>>>>>> neither possible nor required."
https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8
That seems to be one of your misunderstanding. A decider must
report on the behaviour of its input, even if this behaviour
resembles its own behaviour. That is very different from 'deciding >>>>>> on its own behaviour'.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
its simulated final halt state of ⟨Ĥ.qn⟩, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly >>>>> reach its simulated final halt state of ⟨Ĥ.qn⟩.
*This is the original erroneous one*
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt.
*Lines two and four requires Ĥ.embedded_H to report on its own
behavior*
Which is valid.
And you are just stupid to think otherwise.
It is only valid when Turing machine deciders can
take themselves as inputs.
They only need to take representation of themselves as input.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt.
The Linz proof has Ĥ take its own machine description
as input (this is fine) yet requires Ĥ.embedded_H to
directly report on its own behavior. No TM can ever
do that.
On 8/6/2025 9:13 PM, Richard Damon wrote:
On 8/6/25 8:18 AM, olcott wrote:
On 8/6/2025 6:41 AM, Richard Damon wrote:
On 8/6/25 7:39 AM, olcott wrote:
On 8/6/2025 4:00 AM, Fred. Zwarts wrote:
Op 06.aug.2025 om 05:47 schreef olcott:*This is my correction*
It corrects the error of the requirement that
a halt decider reports on its own behavior.
"The contradiction in Linz's (or Turing's) self-referential >>>>>>> halting construction only appears if one insists that the >>>>>>> machine can and must decide on its own behavior, which is >>>>>>> neither possible nor required."
https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8
That seems to be one of your misunderstanding. A decider must
report on the behaviour of its input, even if this behaviour
resembles its own behaviour. That is very different from 'deciding >>>>>> on its own behaviour'.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
its simulated final halt state of ⟨Ĥ.qn⟩, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly >>>>> reach its simulated final halt state of ⟨Ĥ.qn⟩.
*This is the original erroneous one*
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt.
*Lines two and four requires Ĥ.embedded_H to report on its own
behavior*
Which is valid.
And you are just stupid to think otherwise.
It is only valid when Turing machine deciders can
take themselves as inputs.
They only need to take representation of themselves as input.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt.
The Linz proof has Ĥ take its own machine description
as input (this is fine) yet requires Ĥ.embedded_H to
directly report on its own behavior. No TM can ever
do that.
On 8/6/2025 9:27 PM, Richard Damon wrote:
On 8/6/25 7:53 AM, olcott wrote:
On 8/6/2025 5:54 AM, Richard Damon wrote:
On 8/5/25 11:47 PM, olcott wrote:
It corrects the error of the requirement that
a halt decider reports on its own behavior.
But it isn't an error.
Halt Deciders need to answer about *ANY* program, and they are
programs.
"The contradiction in Linz's (or Turing's) self-referential
halting construction only appears if one insists that the
machine can and must decide on its own behavior, which is
neither possible nor required."
https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8
Because you lied to it and said it was an error.
The above paragraph is proved true by the meaning of its words.
When we ask a Turing machine to report on its own behavior we
are assuming that its Turing Machine description is an accurate
proxy for this behavior. When there are exceptions to this rule
then we cannot possibly ask a Turing machine about its own behavior.
This is easily corrected:
But the existance of UTMs means that it IS possible to make a perfect
proxy, as the UTM can completely recreate the behavior of ANY machine
from its Turing Machine Description.
All you are doing is admitting that you think errors and lies are ok.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy,
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
After a finite number of correct simulations the UTM
will reach its final state yet no simulated UTM ever
reaches its own final state.
On 8/7/2025 4:14 AM, Fred. Zwarts wrote:
Op 07.aug.2025 om 05:24 schreef olcott:
On 8/6/2025 9:27 PM, Richard Damon wrote:
On 8/6/25 7:53 AM, olcott wrote:
On 8/6/2025 5:54 AM, Richard Damon wrote:
On 8/5/25 11:47 PM, olcott wrote:
It corrects the error of the requirement that
a halt decider reports on its own behavior.
But it isn't an error.
Halt Deciders need to answer about *ANY* program, and they are
programs.
"The contradiction in Linz's (or Turing's) self-referential >>>>>>> halting construction only appears if one insists that the >>>>>>> machine can and must decide on its own behavior, which is >>>>>>> neither possible nor required."
https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8
Because you lied to it and said it was an error.
The above paragraph is proved true by the meaning of its words.
When we ask a Turing machine to report on its own behavior we
are assuming that its Turing Machine description is an accurate
proxy for this behavior. When there are exceptions to this rule
then we cannot possibly ask a Turing machine about its own behavior. >>>>> This is easily corrected:
But the existance of UTMs means that it IS possible to make a
perfect proxy, as the UTM can completely recreate the behavior of
ANY machine from its Turing Machine Description.
All you are doing is admitting that you think errors and lies are ok.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy,
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
After a finite number of correct simulations the UTM
will reach its final state yet no simulated UTM ever
reaches its own final state.
Indeed, that is the proof that such a simulation fails.
No simulator exists that is able to simulate correctly all halting
programs up to the end,because it fails to simulate correctly code
that resembles its own code.
*You are confusing two distinctly different notions*
No simulator can correctly simulate an input that has a
pathological relationship to itself until this simulated
input reaches its simulated final halt state because this
simulated final halt state is unreachable by this correctly
simulated input.
On 8/7/2025 4:11 AM, Fred. Zwarts wrote:
Op 07.aug.2025 om 05:15 schreef olcott:
That is your mistake. It does not require to report on its own
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt.
The Linz proof has Ĥ take its own machine description
as input (this is fine) yet requires Ĥ.embedded_H to
directly report on its own behavior. No TM can ever
do that.
behaviour, but on the behaviour of Ĥ.
That *is* its own behavior.
Ĥ.embedded_H *is* an aspect of Ĥ.
Ĥ.embedded_H does correctly report on the behavior
specified by its input ⟨Ĥ⟩ ⟨Ĥ⟩ as measured by its
correct simulation of this input.
It is irrelevant whether the behaviour of Ĥ resembles that of embedded_H.
On 8/7/2025 4:11 AM, Fred. Zwarts wrote:
Op 07.aug.2025 om 05:15 schreef olcott:
That is your mistake. It does not require to report on its own
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt.
The Linz proof has Ĥ take its own machine description
as input (this is fine) yet requires Ĥ.embedded_H to
directly report on its own behavior. No TM can ever
do that.
behaviour, but on the behaviour of Ĥ.
That *is* its own behavior.
Ĥ.embedded_H *is* an aspect of Ĥ.
Ĥ.embedded_H does correctly report on the behavior
specified by its input ⟨Ĥ⟩ ⟨Ĥ⟩ as measured by its
correct simulation of this input.
It is irrelevant whether the behaviour of Ĥ resembles that of embedded_H.
On 8/7/2025 4:14 AM, Fred. Zwarts wrote:
Op 07.aug.2025 om 05:24 schreef olcott:
On 8/6/2025 9:27 PM, Richard Damon wrote:
On 8/6/25 7:53 AM, olcott wrote:
On 8/6/2025 5:54 AM, Richard Damon wrote:
On 8/5/25 11:47 PM, olcott wrote:
It corrects the error of the requirement that
a halt decider reports on its own behavior.
But it isn't an error.
Halt Deciders need to answer about *ANY* program, and they are
programs.
"The contradiction in Linz's (or Turing's) self-referential >>>>>>> halting construction only appears if one insists that the >>>>>>> machine can and must decide on its own behavior, which is >>>>>>> neither possible nor required."
https://chatgpt.com/share/6890ee5a-52bc-8011-852e-3d9f97bcfbd8
Because you lied to it and said it was an error.
The above paragraph is proved true by the meaning of its words.
When we ask a Turing machine to report on its own behavior we
are assuming that its Turing Machine description is an accurate
proxy for this behavior. When there are exceptions to this rule
then we cannot possibly ask a Turing machine about its own behavior. >>>>> This is easily corrected:
But the existance of UTMs means that it IS possible to make a
perfect proxy, as the UTM can completely recreate the behavior of
ANY machine from its Turing Machine Description.
All you are doing is admitting that you think errors and lies are ok.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy,
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
After a finite number of correct simulations the UTM
will reach its final state yet no simulated UTM ever
reaches its own final state.
Indeed, that is the proof that such a simulation fails.
No simulator exists that is able to simulate correctly all halting
programs up to the end,because it fails to simulate correctly code
that resembles its own code.
*You are confusing two distinctly different notions*
No simulator can correctly simulate an input that has a
pathological relationship to itself until this simulated
input reaches its simulated final halt state because this
simulated final halt state is unreachable by this correctly
simulated input.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 716 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 59:04:57 |
| Calls: | 12,117 |
| Files: | 15,010 |
| Messages: | 6,518,720 |