On 7/30/2025 1:50 AM, Mikko wrote:
On 2025-07-29 20:53:54 +0000, olcott said:
On 7/29/2025 1:37 AM, Mikko wrote:
On 2025-07-28 12:42:24 +0000, olcott said:
On 7/28/2025 2:50 AM, Mikko wrote:
On 2025-07-27 14:39:45 +0000, olcott said:
On 7/27/2025 2:36 AM, Mikko wrote:
On 2025-07-26 16:21:19 +0000, olcott said:
On 7/26/2025 2:28 AM, Mikko wrote:
On 2025-07-25 15:54:06 +0000, olcott said:
On 7/25/2025 2:43 AM, Mikko wrote:
On 2025-07-24 21:18:32 +0000, olcott said:
On 7/24/2025 4:02 PM, joes wrote:
Am Thu, 24 Jul 2025 09:11:44 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 7/24/2025 5:07 AM, joes wrote:
Yes, it is. And that can obviously be computed by a processor, a UTMAm Wed, 23 Jul 2025 16:08:51 -0500 schrieb olcott: >>>>>>>>>>>>>>>>> On 7/23/2025 3:56 PM, joes wrote:
int Simulate(ptr x)If HHH (which aborts) was given to a UTM/pure simulator, it would stopOf course, and then it incorrectly assumes that an unaborted >>>>>>>>>>>>>>>>>> simulation *of this HHH*, which does in fact abort, wouldn't abort.If HHH(DDD) never aborts its simulation then this HHH never stops
running.
running.
{
x(); return 1;
}
It is the behavior of the input to HHH(DDD) that HHH is supposed to
measure.
It is not the behavior of the input to Simulate(DDD) that HHH is
supposed to measure.
It is also not the behavior of the directly executed DDD() that HHH is
supposed to measure.
or any simulator that doesn't abort before the HHH called by DDD does -
which HHH logically cannot do.
HHH(DDD) is only supposed to measure the behavior of its own input.Do you understand that it trivially produces the same result as the
value that it returns?
It has been three years and still not one person has understood that theIt is well understood that HHH does not simulate DDD the same way as the
behavior of an input that calls its own simulator is not the same as the
behavior of an input that does not call its own simulator. >>>>>>>>>>>>>
direct execution. DDD doesn't even have an "own simulator", it is just
a program that you want to simulate using the simulator it happens to
call.
What has never been understood (even now) is that
Simulate(DDD) is presented with a different sequence >>>>>>>>>>>>> of x86 instructions than HHH(DDD) is presented with.
That you don't understand something does not mean that it is not >>>>>>>>>>>> understood. Everyone other than you understand that if DDD in >>>>>>>>>>>> Simulate(DDD) is not the same as DDD in HHH(DDD) then one of them >>>>>>>>>>>> was given a false name (and perhaps the other, too).
*Correctly emulated is defined as*
Emulated according to the rules of the x86 language.
This includes DDD emulated by HHH and HHH emulating
itself emulating DDD one or more times.
Irrelevant. The meaning of "DDD" in a C expresssion does not depend on its
immediate context.
The meaning of a C function translated into x86
machine code is the meaning of this x86 machine code.
Only because the C compiler attempts to preserve the meaning. The >>>>>>>> definitions of the meanings are distinct (except for assembly code >>>>>>>> insertinos that the compiler permits as a lnaguage extension). >>>>>>>>
But the meaning of DDD in the C expression does not depend on its >>>>>>>> immediate context. The x86 codes pointed to in the two calls are >>>>>>>> identical or at least semantically equivalent so they specify the >>>>>>>> same behaviour.
Independently of above considerations the meaning of DDD is the same >>>>>>>> in Simulate(DDD) and HHH(DDD).
This ChatGPT analysis of its input below
correctly derives both of our views.
Whatever ChatGPT says is irrelevant. If you can't defend your claims >>>>>> then your claims are undefencible.
I can and have proven my claims are verified facts:
https://github.com/plolcott/x86utm/blob/master/Halt7.c
and people disagreed anyway.
No, you have not. You have claimed that you have prooven but that is
not the same. Perhaps you don't know what a proof is but it certainly
is very different from anything you have ever presented.
*A proof is any sequence of steps deriving a necessary result*
https://github.com/plolcott/x86utm/blob/master/Halt7.c
No, it is not. There are additional requirements for each step. The
sequence is a proof only if those additional requirements are satisfied.
From a practical point of view, the purpose of a proof is to convince,
so what does not convince is not a proof.
Proves that HHH does correctly emulate DDD then correctly
emulates itself emulating DDD.
No, it does not. The presentation is not convincing about anything
and does not satisfy the requirements ot a proof.
The actual execution trace of DDD emulated by HHH
and DDD emulated by an emulated HHH does prove that
DDD has been correctly emulated by an emulated HHH.
On 7/31/2025 3:34 AM, Mikko wrote:
On 2025-07-30 15:32:39 +0000, olcott said:
On 7/30/2025 1:50 AM, Mikko wrote:
On 2025-07-29 20:53:54 +0000, olcott said:
On 7/29/2025 1:37 AM, Mikko wrote:
On 2025-07-28 12:42:24 +0000, olcott said:
On 7/28/2025 2:50 AM, Mikko wrote:
On 2025-07-27 14:39:45 +0000, olcott said:
On 7/27/2025 2:36 AM, Mikko wrote:
On 2025-07-26 16:21:19 +0000, olcott said:
On 7/26/2025 2:28 AM, Mikko wrote:
On 2025-07-25 15:54:06 +0000, olcott said:
On 7/25/2025 2:43 AM, Mikko wrote:
On 2025-07-24 21:18:32 +0000, olcott said:*Correctly emulated is defined as*
On 7/24/2025 4:02 PM, joes wrote:That you don't understand something does not mean that it >>>>>>>>>>>>>> is not
Am Thu, 24 Jul 2025 09:11:44 -0500 schrieb olcott: >>>>>>>>>>>>>>>>> On 7/24/2025 5:07 AM, joes wrote:
Yes, it is. And that can obviously be computed by a >>>>>>>>>>>>>>>> processor, a UTMAm Wed, 23 Jul 2025 16:08:51 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>>> On 7/23/2025 3:56 PM, joes wrote:
int Simulate(ptr x)If HHH (which aborts) was given to a UTM/pure >>>>>>>>>>>>>>>>>> simulator, it would stopOf course, and then it incorrectly assumes that an >>>>>>>>>>>>>>>>>>>> unabortedIf HHH(DDD) never aborts its simulation then this HHH >>>>>>>>>>>>>>>>>>> never stops
simulation *of this HHH*, which does in fact abort, >>>>>>>>>>>>>>>>>>>> wouldn't abort.
running.
running.
{
x(); return 1;
}
It is the behavior of the input to HHH(DDD) that HHH is >>>>>>>>>>>>>>>>> supposed to
measure.
It is not the behavior of the input to Simulate(DDD) >>>>>>>>>>>>>>>>> that HHH is
supposed to measure.
It is also not the behavior of the directly executed >>>>>>>>>>>>>>>>> DDD() that HHH is
supposed to measure.
or any simulator that doesn't abort before the HHH >>>>>>>>>>>>>>>> called by DDD does -
which HHH logically cannot do.
HHH(DDD) is only supposed to measure the behavior of >>>>>>>>>>>>>>>>> its own input.Do you understand that it trivially produces the same >>>>>>>>>>>>>>>> result as the
value that it returns?
It has been three years and still not one person has >>>>>>>>>>>>>>>>> understood that theIt is well understood that HHH does not simulate DDD the >>>>>>>>>>>>>>>> same way as the
behavior of an input that calls its own simulator is >>>>>>>>>>>>>>>>> not the same as the
behavior of an input that does not call its own simulator. >>>>>>>>>>>>>>>
direct execution. DDD doesn't even have an "own >>>>>>>>>>>>>>>> simulator", it is just
a program that you want to simulate using the simulator >>>>>>>>>>>>>>>> it happens to
call.
What has never been understood (even now) is that >>>>>>>>>>>>>>> Simulate(DDD) is presented with a different sequence >>>>>>>>>>>>>>> of x86 instructions than HHH(DDD) is presented with. >>>>>>>>>>>>>>
understood. Everyone other than you understand that if DDD in >>>>>>>>>>>>>> Simulate(DDD) is not the same as DDD in HHH(DDD) then one >>>>>>>>>>>>>> of them
was given a false name (and perhaps the other, too). >>>>>>>>>>>>>
Emulated according to the rules of the x86 language. >>>>>>>>>>>>> This includes DDD emulated by HHH and HHH emulating
itself emulating DDD one or more times.
Irrelevant. The meaning of "DDD" in a C expresssion does not >>>>>>>>>>>> depend on its
immediate context.
The meaning of a C function translated into x86
machine code is the meaning of this x86 machine code.
Only because the C compiler attempts to preserve the meaning. The >>>>>>>>>> definitions of the meanings are distinct (except for assembly >>>>>>>>>> code
insertinos that the compiler permits as a lnaguage extension). >>>>>>>>>>
But the meaning of DDD in the C expression does not depend on its >>>>>>>>>> immediate context. The x86 codes pointed to in the two calls are >>>>>>>>>> identical or at least semantically equivalent so they specify the >>>>>>>>>> same behaviour.
Independently of above considerations the meaning of DDD is >>>>>>>>>> the same
in Simulate(DDD) and HHH(DDD).
This ChatGPT analysis of its input below
correctly derives both of our views.
Whatever ChatGPT says is irrelevant. If you can't defend your
claims
then your claims are undefencible.
I can and have proven my claims are verified facts:
https://github.com/plolcott/x86utm/blob/master/Halt7.c
and people disagreed anyway.
No, you have not. You have claimed that you have prooven but that is >>>>>> not the same. Perhaps you don't know what a proof is but it certainly >>>>>> is very different from anything you have ever presented.
*A proof is any sequence of steps deriving a necessary result*
https://github.com/plolcott/x86utm/blob/master/Halt7.c
No, it is not. There are additional requirements for each step. The
sequence is a proof only if those additional requirements are
satisfied.
From a practical point of view, the purpose of a proof is to convince, >>>> so what does not convince is not a proof.
Proves that HHH does correctly emulate DDD then correctly
emulates itself emulating DDD.
No, it does not. The presentation is not convincing about anything
and does not satisfy the requirements ot a proof.
The actual execution trace of DDD emulated by HHH
and DDD emulated by an emulated HHH does prove that
DDD has been correctly emulated by an emulated HHH.
No, it only provides materila for a proof that a part of DDD has been
correctly emulated. The emulation is not continied to the point where
it is obvious that HHH is not a decider. From inspection of the code
of DDD we can see that if DDD does not halt then HHH is not a decider.
void DDD()
{
HHH(DDD);
return;
}
When HHH(DDD) simulates ten instructions of DDD is 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)
On 7/31/2025 6:16 PM, Richard Damon wrote:
On 7/31/25 11:55 AM, olcott wrote:
On 7/31/2025 3:34 AM, Mikko wrote:
On 2025-07-30 15:32:39 +0000, olcott said:
On 7/30/2025 1:50 AM, Mikko wrote:
On 2025-07-29 20:53:54 +0000, olcott said:
On 7/29/2025 1:37 AM, Mikko wrote:
On 2025-07-28 12:42:24 +0000, olcott said:
On 7/28/2025 2:50 AM, Mikko wrote:
On 2025-07-27 14:39:45 +0000, olcott said:
On 7/27/2025 2:36 AM, Mikko wrote:
On 2025-07-26 16:21:19 +0000, olcott said:
On 7/26/2025 2:28 AM, Mikko wrote:Only because the C compiler attempts to preserve the
On 2025-07-25 15:54:06 +0000, olcott said:
On 7/25/2025 2:43 AM, Mikko wrote:
On 2025-07-24 21:18:32 +0000, olcott said:*Correctly emulated is defined as*
On 7/24/2025 4:02 PM, joes wrote:That you don't understand something does not mean that >>>>>>>>>>>>>>>> it is not
Am Thu, 24 Jul 2025 09:11:44 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>>> On 7/24/2025 5:07 AM, joes wrote:
Yes, it is. And that can obviously be computed by a >>>>>>>>>>>>>>>>>> processor, a UTMAm Wed, 23 Jul 2025 16:08:51 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>>>>> On 7/23/2025 3:56 PM, joes wrote:
int Simulate(ptr x)If HHH (which aborts) was given to a UTM/pure >>>>>>>>>>>>>>>>>>>> simulator, it would stopOf course, and then it incorrectly assumes that an >>>>>>>>>>>>>>>>>>>>>> unabortedIf HHH(DDD) never aborts its simulation then this >>>>>>>>>>>>>>>>>>>>> HHH never stops
simulation *of this HHH*, which does in fact >>>>>>>>>>>>>>>>>>>>>> abort, wouldn't abort.
running.
running.
{
x(); return 1;
}
It is the behavior of the input to HHH(DDD) that HHH >>>>>>>>>>>>>>>>>>> is supposed to
measure.
It is not the behavior of the input to Simulate(DDD) >>>>>>>>>>>>>>>>>>> that HHH is
supposed to measure.
It is also not the behavior of the directly executed >>>>>>>>>>>>>>>>>>> DDD() that HHH is
supposed to measure.
or any simulator that doesn't abort before the HHH >>>>>>>>>>>>>>>>>> called by DDD does -
which HHH logically cannot do.
HHH(DDD) is only supposed to measure the behavior of >>>>>>>>>>>>>>>>>>> its own input.Do you understand that it trivially produces the same >>>>>>>>>>>>>>>>>> result as the
value that it returns?
It has been three years and still not one person has >>>>>>>>>>>>>>>>>>> understood that the
behavior of an input that calls its own simulator is >>>>>>>>>>>>>>>>>>> not the same as the
behavior of an input that does not call its own >>>>>>>>>>>>>>>>>>> simulator.
It is well understood that HHH does not simulate DDD >>>>>>>>>>>>>>>>>> the same way as the
direct execution. DDD doesn't even have an "own >>>>>>>>>>>>>>>>>> simulator", it is just
a program that you want to simulate using the >>>>>>>>>>>>>>>>>> simulator it happens to
call.
What has never been understood (even now) is that >>>>>>>>>>>>>>>>> Simulate(DDD) is presented with a different sequence >>>>>>>>>>>>>>>>> of x86 instructions than HHH(DDD) is presented with. >>>>>>>>>>>>>>>>
understood. Everyone other than you understand that if >>>>>>>>>>>>>>>> DDD in
Simulate(DDD) is not the same as DDD in HHH(DDD) then >>>>>>>>>>>>>>>> one of them
was given a false name (and perhaps the other, too). >>>>>>>>>>>>>>>
Emulated according to the rules of the x86 language. >>>>>>>>>>>>>>> This includes DDD emulated by HHH and HHH emulating >>>>>>>>>>>>>>> itself emulating DDD one or more times.
Irrelevant. The meaning of "DDD" in a C expresssion does >>>>>>>>>>>>>> not depend on its
immediate context.
The meaning of a C function translated into x86
machine code is the meaning of this x86 machine code. >>>>>>>>>>>>
meaning. The
definitions of the meanings are distinct (except for
assembly code
insertinos that the compiler permits as a lnaguage extension). >>>>>>>>>>>>
But the meaning of DDD in the C expression does not depend >>>>>>>>>>>> on its
immediate context. The x86 codes pointed to in the two calls >>>>>>>>>>>> are
identical or at least semantically equivalent so they
specify the
same behaviour.
Independently of above considerations the meaning of DDD is >>>>>>>>>>>> the same
in Simulate(DDD) and HHH(DDD).
This ChatGPT analysis of its input below
correctly derives both of our views.
Whatever ChatGPT says is irrelevant. If you can't defend your >>>>>>>>>> claims
then your claims are undefencible.
I can and have proven my claims are verified facts:
https://github.com/plolcott/x86utm/blob/master/Halt7.c
and people disagreed anyway.
No, you have not. You have claimed that you have prooven but
that is
not the same. Perhaps you don't know what a proof is but it
certainly
is very different from anything you have ever presented.
*A proof is any sequence of steps deriving a necessary result*
https://github.com/plolcott/x86utm/blob/master/Halt7.c
No, it is not. There are additional requirements for each step. The >>>>>> sequence is a proof only if those additional requirements are
satisfied.
From a practical point of view, the purpose of a proof is to
convince,
so what does not convince is not a proof.
Proves that HHH does correctly emulate DDD then correctly
emulates itself emulating DDD.
No, it does not. The presentation is not convincing about anything >>>>>> and does not satisfy the requirements ot a proof.
The actual execution trace of DDD emulated by HHH
and DDD emulated by an emulated HHH does prove that
DDD has been correctly emulated by an emulated HHH.
No, it only provides materila for a proof that a part of DDD has been
correctly emulated. The emulation is not continied to the point where
it is obvious that HHH is not a decider. From inspection of the code
of DDD we can see that if DDD does not halt then HHH is not a decider. >>>>
void DDD()
{
HHH(DDD);
return;
}
When HHH(DDD) simulates ten instructions of DDD is 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)
Nope, Just your lie.
Because if that WAS true, it would never answer.
Yes that is correct because everyone knows that counting to
ten takes an infinite amount of time.
On 7/31/2025 3:34 AM, Mikko wrote:
On 2025-07-30 15:32:39 +0000, olcott said:
On 7/30/2025 1:50 AM, Mikko wrote:
On 2025-07-29 20:53:54 +0000, olcott said:
On 7/29/2025 1:37 AM, Mikko wrote:
On 2025-07-28 12:42:24 +0000, olcott said:
On 7/28/2025 2:50 AM, Mikko wrote:
On 2025-07-27 14:39:45 +0000, olcott said:
On 7/27/2025 2:36 AM, Mikko wrote:
On 2025-07-26 16:21:19 +0000, olcott said:
On 7/26/2025 2:28 AM, Mikko wrote:
On 2025-07-25 15:54:06 +0000, olcott said:
On 7/25/2025 2:43 AM, Mikko wrote:
On 2025-07-24 21:18:32 +0000, olcott said:*Correctly emulated is defined as*
On 7/24/2025 4:02 PM, joes wrote:That you don't understand something does not mean that it is not >>>>>>>>>>>>>> understood. Everyone other than you understand that if DDD in >>>>>>>>>>>>>> Simulate(DDD) is not the same as DDD in HHH(DDD) then one of them
Am Thu, 24 Jul 2025 09:11:44 -0500 schrieb olcott: >>>>>>>>>>>>>>>>> On 7/24/2025 5:07 AM, joes wrote:
Yes, it is. And that can obviously be computed by a processor, a UTMAm Wed, 23 Jul 2025 16:08:51 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>>> On 7/23/2025 3:56 PM, joes wrote:
int Simulate(ptr x)If HHH (which aborts) was given to a UTM/pure simulator, it would stopOf course, and then it incorrectly assumes that an unabortedIf HHH(DDD) never aborts its simulation then this HHH never stops
simulation *of this HHH*, which does in fact abort, wouldn't abort.
running.
running.
{
x(); return 1;
}
It is the behavior of the input to HHH(DDD) that HHH is supposed to
measure.
It is not the behavior of the input to Simulate(DDD) that HHH is
supposed to measure.
It is also not the behavior of the directly executed DDD() that HHH is
supposed to measure.
or any simulator that doesn't abort before the HHH called by DDD does -
which HHH logically cannot do.
HHH(DDD) is only supposed to measure the behavior of its own input.Do you understand that it trivially produces the same result as the
value that it returns?
It has been three years and still not one person has understood that theIt is well understood that HHH does not simulate DDD the same way as the
behavior of an input that calls its own simulator is not the same as the
behavior of an input that does not call its own simulator. >>>>>>>>>>>>>>>
direct execution. DDD doesn't even have an "own simulator", it is just
a program that you want to simulate using the simulator it happens to
call.
What has never been understood (even now) is that >>>>>>>>>>>>>>> Simulate(DDD) is presented with a different sequence >>>>>>>>>>>>>>> of x86 instructions than HHH(DDD) is presented with. >>>>>>>>>>>>>>
was given a false name (and perhaps the other, too). >>>>>>>>>>>>>
Emulated according to the rules of the x86 language. >>>>>>>>>>>>> This includes DDD emulated by HHH and HHH emulating
itself emulating DDD one or more times.
Irrelevant. The meaning of "DDD" in a C expresssion does not depend on its
immediate context.
The meaning of a C function translated into x86
machine code is the meaning of this x86 machine code.
Only because the C compiler attempts to preserve the meaning. The >>>>>>>>>> definitions of the meanings are distinct (except for assembly code >>>>>>>>>> insertinos that the compiler permits as a lnaguage extension). >>>>>>>>>>
But the meaning of DDD in the C expression does not depend on its >>>>>>>>>> immediate context. The x86 codes pointed to in the two calls are >>>>>>>>>> identical or at least semantically equivalent so they specify the >>>>>>>>>> same behaviour.
Independently of above considerations the meaning of DDD is the same >>>>>>>>>> in Simulate(DDD) and HHH(DDD).
This ChatGPT analysis of its input below
correctly derives both of our views.
Whatever ChatGPT says is irrelevant. If you can't defend your claims >>>>>>>> then your claims are undefencible.
I can and have proven my claims are verified facts:
https://github.com/plolcott/x86utm/blob/master/Halt7.c
and people disagreed anyway.
No, you have not. You have claimed that you have prooven but that is >>>>>> not the same. Perhaps you don't know what a proof is but it certainly >>>>>> is very different from anything you have ever presented.
*A proof is any sequence of steps deriving a necessary result*
https://github.com/plolcott/x86utm/blob/master/Halt7.c
No, it is not. There are additional requirements for each step. The
sequence is a proof only if those additional requirements are satisfied. >>>> From a practical point of view, the purpose of a proof is to convince, >>>> so what does not convince is not a proof.
Proves that HHH does correctly emulate DDD then correctly
emulates itself emulating DDD.
No, it does not. The presentation is not convincing about anything
and does not satisfy the requirements ot a proof.
The actual execution trace of DDD emulated by HHH
and DDD emulated by an emulated HHH does prove that
DDD has been correctly emulated by an emulated HHH.
No, it only provides materila for a proof that a part of DDD has been
correctly emulated. The emulation is not continied to the point where
it is obvious that HHH is not a decider. From inspection of the code
of DDD we can see that if DDD does not halt then HHH is not a decider.
void DDD()
{
HHH(DDD);
return;
}
When HHH(DDD) simulates ten instructions of DDD is 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)
On 7/31/2025 7:38 PM, Richard Damon wrote:
On 7/31/25 7:38 PM, olcott wrote:
On 7/31/2025 6:16 PM, Richard Damon wrote:
On 7/31/25 11:55 AM, olcott wrote:
On 7/31/2025 3:34 AM, Mikko wrote:
On 2025-07-30 15:32:39 +0000, olcott said:
On 7/30/2025 1:50 AM, Mikko wrote:
On 2025-07-29 20:53:54 +0000, olcott said:
On 7/29/2025 1:37 AM, Mikko wrote:
On 2025-07-28 12:42:24 +0000, olcott said:
On 7/28/2025 2:50 AM, Mikko wrote:
On 2025-07-27 14:39:45 +0000, olcott said:
On 7/27/2025 2:36 AM, Mikko wrote:
On 2025-07-26 16:21:19 +0000, olcott said:
On 7/26/2025 2:28 AM, Mikko wrote:Only because the C compiler attempts to preserve the >>>>>>>>>>>>>> meaning. The
On 2025-07-25 15:54:06 +0000, olcott said:
On 7/25/2025 2:43 AM, Mikko wrote:
On 2025-07-24 21:18:32 +0000, olcott said: >>>>>>>>>>>>>>>>>>*Correctly emulated is defined as*
On 7/24/2025 4:02 PM, joes wrote:That you don't understand something does not mean that >>>>>>>>>>>>>>>>>> it is not
Am Thu, 24 Jul 2025 09:11:44 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>>>>> On 7/24/2025 5:07 AM, joes wrote:
Yes, it is. And that can obviously be computed by a >>>>>>>>>>>>>>>>>>>> processor, a UTMAm Wed, 23 Jul 2025 16:08:51 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>>>>>>> On 7/23/2025 3:56 PM, joes wrote:
int Simulate(ptr x)If HHH (which aborts) was given to a UTM/pure >>>>>>>>>>>>>>>>>>>>>> simulator, it would stopOf course, and then it incorrectly assumes that >>>>>>>>>>>>>>>>>>>>>>>> an unabortedIf HHH(DDD) never aborts its simulation then this >>>>>>>>>>>>>>>>>>>>>>> HHH never stops
simulation *of this HHH*, which does in fact >>>>>>>>>>>>>>>>>>>>>>>> abort, wouldn't abort.
running.
running.
{
x(); return 1;
}
It is the behavior of the input to HHH(DDD) that >>>>>>>>>>>>>>>>>>>>> HHH is supposed to
measure.
It is not the behavior of the input to >>>>>>>>>>>>>>>>>>>>> Simulate(DDD) that HHH is
supposed to measure.
It is also not the behavior of the directly >>>>>>>>>>>>>>>>>>>>> executed DDD() that HHH is
supposed to measure.
or any simulator that doesn't abort before the HHH >>>>>>>>>>>>>>>>>>>> called by DDD does -
which HHH logically cannot do.
HHH(DDD) is only supposed to measure the behavior >>>>>>>>>>>>>>>>>>>>> of its own input.Do you understand that it trivially produces the >>>>>>>>>>>>>>>>>>>> same result as the
value that it returns?
It has been three years and still not one person >>>>>>>>>>>>>>>>>>>>> has understood that the
behavior of an input that calls its own simulator >>>>>>>>>>>>>>>>>>>>> is not the same as the
behavior of an input that does not call its own >>>>>>>>>>>>>>>>>>>>> simulator.
It is well understood that HHH does not simulate DDD >>>>>>>>>>>>>>>>>>>> the same way as the
direct execution. DDD doesn't even have an "own >>>>>>>>>>>>>>>>>>>> simulator", it is just
a program that you want to simulate using the >>>>>>>>>>>>>>>>>>>> simulator it happens to
call.
What has never been understood (even now) is that >>>>>>>>>>>>>>>>>>> Simulate(DDD) is presented with a different sequence >>>>>>>>>>>>>>>>>>> of x86 instructions than HHH(DDD) is presented with. >>>>>>>>>>>>>>>>>>
understood. Everyone other than you understand that if >>>>>>>>>>>>>>>>>> DDD in
Simulate(DDD) is not the same as DDD in HHH(DDD) then >>>>>>>>>>>>>>>>>> one of them
was given a false name (and perhaps the other, too). >>>>>>>>>>>>>>>>>
Emulated according to the rules of the x86 language. >>>>>>>>>>>>>>>>> This includes DDD emulated by HHH and HHH emulating >>>>>>>>>>>>>>>>> itself emulating DDD one or more times.
Irrelevant. The meaning of "DDD" in a C expresssion does >>>>>>>>>>>>>>>> not depend on its
immediate context.
The meaning of a C function translated into x86
machine code is the meaning of this x86 machine code. >>>>>>>>>>>>>>
definitions of the meanings are distinct (except for >>>>>>>>>>>>>> assembly code
insertinos that the compiler permits as a lnaguage >>>>>>>>>>>>>> extension).
But the meaning of DDD in the C expression does not depend >>>>>>>>>>>>>> on its
immediate context. The x86 codes pointed to in the two >>>>>>>>>>>>>> calls are
identical or at least semantically equivalent so they >>>>>>>>>>>>>> specify the
same behaviour.
Independently of above considerations the meaning of DDD >>>>>>>>>>>>>> is the same
in Simulate(DDD) and HHH(DDD).
This ChatGPT analysis of its input below
correctly derives both of our views.
Whatever ChatGPT says is irrelevant. If you can't defend >>>>>>>>>>>> your claims
then your claims are undefencible.
I can and have proven my claims are verified facts:
https://github.com/plolcott/x86utm/blob/master/Halt7.c
and people disagreed anyway.
No, you have not. You have claimed that you have prooven but >>>>>>>>>> that is
not the same. Perhaps you don't know what a proof is but it >>>>>>>>>> certainly
is very different from anything you have ever presented.
*A proof is any sequence of steps deriving a necessary result* >>>>>>>>> https://github.com/plolcott/x86utm/blob/master/Halt7.c
No, it is not. There are additional requirements for each step. The >>>>>>>> sequence is a proof only if those additional requirements are
satisfied.
From a practical point of view, the purpose of a proof is to
convince,
so what does not convince is not a proof.
Proves that HHH does correctly emulate DDD then correctly
emulates itself emulating DDD.
No, it does not. The presentation is not convincing about anything >>>>>>>> and does not satisfy the requirements ot a proof.
The actual execution trace of DDD emulated by HHH
and DDD emulated by an emulated HHH does prove that
DDD has been correctly emulated by an emulated HHH.
No, it only provides materila for a proof that a part of DDD has been >>>>>> correctly emulated. The emulation is not continied to the point where >>>>>> it is obvious that HHH is not a decider. From inspection of the code >>>>>> of DDD we can see that if DDD does not halt then HHH is not a
decider.
void DDD()
{
HHH(DDD);
return;
}
When HHH(DDD) simulates ten instructions of DDD is 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)
Nope, Just your lie.
Because if that WAS true, it would never answer.
Yes that is correct because everyone knows that counting to
ten takes an infinite amount of time.
Nope, but counting to the end requires you to count to the end.
So no one has any idea that they can't count to infinity
until after they have counted to infinity and failed.
void DDD()
{
HHH(DDD);
return;
}
When DDD is correctly emulated by HHH up until
10 recursive simulations
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)
and then HHH kills the whole simulation process
Not one person on the face of the Earth can possibly
determine whether or not DDD would have reaches its
own "return" statement final halt state with more than
10 recursive simulations?
On 7/31/2025 7:38 PM, Richard Damon wrote:
On 7/31/25 7:38 PM, olcott wrote:
On 7/31/2025 6:16 PM, Richard Damon wrote:
On 7/31/25 11:55 AM, olcott wrote:
On 7/31/2025 3:34 AM, Mikko wrote:
On 2025-07-30 15:32:39 +0000, olcott said:
On 7/30/2025 1:50 AM, Mikko wrote:
On 2025-07-29 20:53:54 +0000, olcott said:
On 7/29/2025 1:37 AM, Mikko wrote:
On 2025-07-28 12:42:24 +0000, olcott said:
On 7/28/2025 2:50 AM, Mikko wrote:
On 2025-07-27 14:39:45 +0000, olcott said:
On 7/27/2025 2:36 AM, Mikko wrote:
On 2025-07-26 16:21:19 +0000, olcott said:
On 7/26/2025 2:28 AM, Mikko wrote:Only because the C compiler attempts to preserve the >>>>>>>>>>>>>> meaning. The
On 2025-07-25 15:54:06 +0000, olcott said:
On 7/25/2025 2:43 AM, Mikko wrote:
On 2025-07-24 21:18:32 +0000, olcott said: >>>>>>>>>>>>>>>>>>*Correctly emulated is defined as*
On 7/24/2025 4:02 PM, joes wrote:That you don't understand something does not mean that >>>>>>>>>>>>>>>>>> it is not
Am Thu, 24 Jul 2025 09:11:44 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>>>>> On 7/24/2025 5:07 AM, joes wrote:
Yes, it is. And that can obviously be computed by a >>>>>>>>>>>>>>>>>>>> processor, a UTMAm Wed, 23 Jul 2025 16:08:51 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>>>>>>> On 7/23/2025 3:56 PM, joes wrote:
int Simulate(ptr x)If HHH (which aborts) was given to a UTM/pure >>>>>>>>>>>>>>>>>>>>>> simulator, it would stopOf course, and then it incorrectly assumes that >>>>>>>>>>>>>>>>>>>>>>>> an unabortedIf HHH(DDD) never aborts its simulation then this >>>>>>>>>>>>>>>>>>>>>>> HHH never stops
simulation *of this HHH*, which does in fact >>>>>>>>>>>>>>>>>>>>>>>> abort, wouldn't abort.
running.
running.
{
x(); return 1;
}
It is the behavior of the input to HHH(DDD) that >>>>>>>>>>>>>>>>>>>>> HHH is supposed to
measure.
It is not the behavior of the input to >>>>>>>>>>>>>>>>>>>>> Simulate(DDD) that HHH is
supposed to measure.
It is also not the behavior of the directly >>>>>>>>>>>>>>>>>>>>> executed DDD() that HHH is
supposed to measure.
or any simulator that doesn't abort before the HHH >>>>>>>>>>>>>>>>>>>> called by DDD does -
which HHH logically cannot do.
HHH(DDD) is only supposed to measure the behavior >>>>>>>>>>>>>>>>>>>>> of its own input.Do you understand that it trivially produces the >>>>>>>>>>>>>>>>>>>> same result as the
value that it returns?
It has been three years and still not one person >>>>>>>>>>>>>>>>>>>>> has understood that the
behavior of an input that calls its own simulator >>>>>>>>>>>>>>>>>>>>> is not the same as the
behavior of an input that does not call its own >>>>>>>>>>>>>>>>>>>>> simulator.
It is well understood that HHH does not simulate DDD >>>>>>>>>>>>>>>>>>>> the same way as the
direct execution. DDD doesn't even have an "own >>>>>>>>>>>>>>>>>>>> simulator", it is just
a program that you want to simulate using the >>>>>>>>>>>>>>>>>>>> simulator it happens to
call.
What has never been understood (even now) is that >>>>>>>>>>>>>>>>>>> Simulate(DDD) is presented with a different sequence >>>>>>>>>>>>>>>>>>> of x86 instructions than HHH(DDD) is presented with. >>>>>>>>>>>>>>>>>>
understood. Everyone other than you understand that if >>>>>>>>>>>>>>>>>> DDD in
Simulate(DDD) is not the same as DDD in HHH(DDD) then >>>>>>>>>>>>>>>>>> one of them
was given a false name (and perhaps the other, too). >>>>>>>>>>>>>>>>>
Emulated according to the rules of the x86 language. >>>>>>>>>>>>>>>>> This includes DDD emulated by HHH and HHH emulating >>>>>>>>>>>>>>>>> itself emulating DDD one or more times.
Irrelevant. The meaning of "DDD" in a C expresssion does >>>>>>>>>>>>>>>> not depend on its
immediate context.
The meaning of a C function translated into x86
machine code is the meaning of this x86 machine code. >>>>>>>>>>>>>>
definitions of the meanings are distinct (except for >>>>>>>>>>>>>> assembly code
insertinos that the compiler permits as a lnaguage >>>>>>>>>>>>>> extension).
But the meaning of DDD in the C expression does not depend >>>>>>>>>>>>>> on its
immediate context. The x86 codes pointed to in the two >>>>>>>>>>>>>> calls are
identical or at least semantically equivalent so they >>>>>>>>>>>>>> specify the
same behaviour.
Independently of above considerations the meaning of DDD >>>>>>>>>>>>>> is the same
in Simulate(DDD) and HHH(DDD).
This ChatGPT analysis of its input below
correctly derives both of our views.
Whatever ChatGPT says is irrelevant. If you can't defend >>>>>>>>>>>> your claims
then your claims are undefencible.
I can and have proven my claims are verified facts:
https://github.com/plolcott/x86utm/blob/master/Halt7.c
and people disagreed anyway.
No, you have not. You have claimed that you have prooven but >>>>>>>>>> that is
not the same. Perhaps you don't know what a proof is but it >>>>>>>>>> certainly
is very different from anything you have ever presented.
*A proof is any sequence of steps deriving a necessary result* >>>>>>>>> https://github.com/plolcott/x86utm/blob/master/Halt7.c
No, it is not. There are additional requirements for each step. The >>>>>>>> sequence is a proof only if those additional requirements are
satisfied.
From a practical point of view, the purpose of a proof is to
convince,
so what does not convince is not a proof.
Proves that HHH does correctly emulate DDD then correctly
emulates itself emulating DDD.
No, it does not. The presentation is not convincing about anything >>>>>>>> and does not satisfy the requirements ot a proof.
The actual execution trace of DDD emulated by HHH
and DDD emulated by an emulated HHH does prove that
DDD has been correctly emulated by an emulated HHH.
No, it only provides materila for a proof that a part of DDD has been >>>>>> correctly emulated. The emulation is not continied to the point where >>>>>> it is obvious that HHH is not a decider. From inspection of the code >>>>>> of DDD we can see that if DDD does not halt then HHH is not a
decider.
void DDD()
{
HHH(DDD);
return;
}
When HHH(DDD) simulates ten instructions of DDD is 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)
Nope, Just your lie.
Because if that WAS true, it would never answer.
Yes that is correct because everyone knows that counting to
ten takes an infinite amount of time.
Nope, but counting to the end requires you to count to the end.
So no one has any idea that they can't count to infinity
until after they have counted to infinity and failed.
void DDD()
{
HHH(DDD);
return;
}
When DDD is correctly emulated by HHH up until
10 recursive simulations
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)
and then HHH kills the whole simulation process
Not one person on the face of the Earth can possibly
determine whether or not DDD would have reaches its
own "return" statement final halt state with more than
10 recursive simulations?
On 8/1/2025 1:55 AM, Mikko wrote:
On 2025-07-31 15:55:25 +0000, olcott said:
On 7/31/2025 3:34 AM, Mikko wrote:
On 2025-07-30 15:32:39 +0000, olcott said:
On 7/30/2025 1:50 AM, Mikko wrote:
On 2025-07-29 20:53:54 +0000, olcott said:
On 7/29/2025 1:37 AM, Mikko wrote:
On 2025-07-28 12:42:24 +0000, olcott said:
On 7/28/2025 2:50 AM, Mikko wrote:
On 2025-07-27 14:39:45 +0000, olcott said:
On 7/27/2025 2:36 AM, Mikko wrote:
On 2025-07-26 16:21:19 +0000, olcott said:
On 7/26/2025 2:28 AM, Mikko wrote:Only because the C compiler attempts to preserve the
On 2025-07-25 15:54:06 +0000, olcott said:
On 7/25/2025 2:43 AM, Mikko wrote:
On 2025-07-24 21:18:32 +0000, olcott said:*Correctly emulated is defined as*
On 7/24/2025 4:02 PM, joes wrote:That you don't understand something does not mean that >>>>>>>>>>>>>>>> it is not
Am Thu, 24 Jul 2025 09:11:44 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>>> On 7/24/2025 5:07 AM, joes wrote:
Yes, it is. And that can obviously be computed by a >>>>>>>>>>>>>>>>>> processor, a UTMAm Wed, 23 Jul 2025 16:08:51 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>>>>> On 7/23/2025 3:56 PM, joes wrote:
int Simulate(ptr x)If HHH (which aborts) was given to a UTM/pure >>>>>>>>>>>>>>>>>>>> simulator, it would stopOf course, and then it incorrectly assumes that an >>>>>>>>>>>>>>>>>>>>>> unabortedIf HHH(DDD) never aborts its simulation then this >>>>>>>>>>>>>>>>>>>>> HHH never stops
simulation *of this HHH*, which does in fact >>>>>>>>>>>>>>>>>>>>>> abort, wouldn't abort.
running.
running.
{
x(); return 1;
}
It is the behavior of the input to HHH(DDD) that HHH >>>>>>>>>>>>>>>>>>> is supposed to
measure.
It is not the behavior of the input to Simulate(DDD) >>>>>>>>>>>>>>>>>>> that HHH is
supposed to measure.
It is also not the behavior of the directly executed >>>>>>>>>>>>>>>>>>> DDD() that HHH is
supposed to measure.
or any simulator that doesn't abort before the HHH >>>>>>>>>>>>>>>>>> called by DDD does -
which HHH logically cannot do.
HHH(DDD) is only supposed to measure the behavior of >>>>>>>>>>>>>>>>>>> its own input.Do you understand that it trivially produces the same >>>>>>>>>>>>>>>>>> result as the
value that it returns?
It has been three years and still not one person has >>>>>>>>>>>>>>>>>>> understood that the
behavior of an input that calls its own simulator is >>>>>>>>>>>>>>>>>>> not the same as the
behavior of an input that does not call its own >>>>>>>>>>>>>>>>>>> simulator.
It is well understood that HHH does not simulate DDD >>>>>>>>>>>>>>>>>> the same way as the
direct execution. DDD doesn't even have an "own >>>>>>>>>>>>>>>>>> simulator", it is just
a program that you want to simulate using the >>>>>>>>>>>>>>>>>> simulator it happens to
call.
What has never been understood (even now) is that >>>>>>>>>>>>>>>>> Simulate(DDD) is presented with a different sequence >>>>>>>>>>>>>>>>> of x86 instructions than HHH(DDD) is presented with. >>>>>>>>>>>>>>>>
understood. Everyone other than you understand that if >>>>>>>>>>>>>>>> DDD in
Simulate(DDD) is not the same as DDD in HHH(DDD) then >>>>>>>>>>>>>>>> one of them
was given a false name (and perhaps the other, too). >>>>>>>>>>>>>>>
Emulated according to the rules of the x86 language. >>>>>>>>>>>>>>> This includes DDD emulated by HHH and HHH emulating >>>>>>>>>>>>>>> itself emulating DDD one or more times.
Irrelevant. The meaning of "DDD" in a C expresssion does >>>>>>>>>>>>>> not depend on its
immediate context.
The meaning of a C function translated into x86
machine code is the meaning of this x86 machine code. >>>>>>>>>>>>
meaning. The
definitions of the meanings are distinct (except for
assembly code
insertinos that the compiler permits as a lnaguage extension). >>>>>>>>>>>>
But the meaning of DDD in the C expression does not depend >>>>>>>>>>>> on its
immediate context. The x86 codes pointed to in the two calls >>>>>>>>>>>> are
identical or at least semantically equivalent so they
specify the
same behaviour.
Independently of above considerations the meaning of DDD is >>>>>>>>>>>> the same
in Simulate(DDD) and HHH(DDD).
This ChatGPT analysis of its input below
correctly derives both of our views.
Whatever ChatGPT says is irrelevant. If you can't defend your >>>>>>>>>> claims
then your claims are undefencible.
I can and have proven my claims are verified facts:
https://github.com/plolcott/x86utm/blob/master/Halt7.c
and people disagreed anyway.
No, you have not. You have claimed that you have prooven but
that is
not the same. Perhaps you don't know what a proof is but it
certainly
is very different from anything you have ever presented.
*A proof is any sequence of steps deriving a necessary result*
https://github.com/plolcott/x86utm/blob/master/Halt7.c
No, it is not. There are additional requirements for each step. The >>>>>> sequence is a proof only if those additional requirements are
satisfied.
From a practical point of view, the purpose of a proof is to
convince,
so what does not convince is not a proof.
Proves that HHH does correctly emulate DDD then correctly
emulates itself emulating DDD.
No, it does not. The presentation is not convincing about anything >>>>>> and does not satisfy the requirements ot a proof.
The actual execution trace of DDD emulated by HHH
and DDD emulated by an emulated HHH does prove that
DDD has been correctly emulated by an emulated HHH.
No, it only provides materila for a proof that a part of DDD has been
correctly emulated. The emulation is not continied to the point where
it is obvious that HHH is not a decider. From inspection of the code
of DDD we can see that if DDD does not halt then HHH is not a decider. >>>>
void DDD()
{
HHH(DDD);
return;
}
When HHH(DDD) simulates ten instructions of DDD is 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)
Are you trying to say that HHH is stuck in a loop and therefore
never returns?
I repeated the pattern ten times so that people can
notice that there really is a non-terminating pattern.
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.
*ChatGPT totally understands* https://chatgpt.com/share/688521d8-e5fc-8011-9d7c-0d77ac83706c
https://www.researchgate.net/publication/394042683_ChatGPT_analyzes_HHHDDD
On 8/1/2025 3:34 AM, Fred. Zwarts wrote:
Op 01.aug.2025 om 04:49 schreef olcott:is totally beyond your capacity to understand.
When DDD is correctly emulated by HHH up until
10 recursive simulations
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)
and then HHH kills the whole simulation process
Proving that it is not needed to count to infinity, but only to the
moment that HHH aborts and halts.
Not one person on the face of the Earth can possibly
determine whether or not DDD would have reaches its
own "return" statement final halt state with more than
10 recursive simulations?
Counter factual. World-class simulators show that the final halt state
can be reached with simulating only a few cycles. In other words the
whole notion of recursive simulation
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 8/1/2025 10:10 AM, Richard Damon wrote:Also known as spamming.
On 8/1/25 11:01 AM, olcott wrote:
On 8/1/2025 1:55 AM, Mikko wrote:
On 2025-07-31 15:55:25 +0000, olcott said:
When HHH(DDD) simulates ten instructions of DDD is goes like this:
executed HHH(DDD) simulates DDD that calls HHH(DDD)
simulated HHH(DDD) simulates DDD that calls HHH(DDD)
Are you trying to say that HHH is stuck in a loop and therefore neverI repeated the pattern ten times so that people can notice that there
returns?
really is a non-terminating pattern.
Then don't imply that the name "HHH" refers to a single program.And thus show that you think lying is ok.Under the false assumption that my fully encoded HHH is the only one
that can possibly exist you would be correct.
It is libelous for you to call me a liar on the basis of your own false assumption. It is libelous for you to call me a liar when you meanSame.
mistaken and not willfully deceptive.
On 8/1/2025 10:10 AM, Richard Damon wrote:
On 8/1/25 11:01 AM, olcott wrote:
On 8/1/2025 1:55 AM, Mikko wrote:
On 2025-07-31 15:55:25 +0000, olcott said:
void DDD()
{
HHH(DDD);
return;
}
When HHH(DDD) simulates ten instructions of DDD is 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)
Are you trying to say that HHH is stuck in a loop and therefore
never returns?
I repeated the pattern ten times so that people can
notice that there really is a non-terminating pattern.
And thus show that you think lying is ok.
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.
Under the false assumption that my fully encoded HHH is
the only one that can possibly exist you would be correct.
It is libelous for you to call me a liar on the basis
of your own false assumption. It is libelous for you to
call me a liar when you mean mistaken and not willfully
deceptive.
On 8/1/2025 10:32 AM, joes wrote:That's not how it works. I skim over repetitions.
Am Fri, 01 Aug 2025 10:19:11 -0500 schrieb olcott:When people make sure to fail to notice the key elements of my key
On 8/1/2025 10:10 AM, Richard Damon wrote:Also known as spamming.
On 8/1/25 11:01 AM, olcott wrote:
On 8/1/2025 1:55 AM, Mikko wrote:
On 2025-07-31 15:55:25 +0000, olcott said:
When HHH(DDD) simulates ten instructions of DDD is goes like this: >>>>>>> executed HHH(DDD) simulates DDD that calls HHH(DDD)
simulated HHH(DDD) simulates DDD that calls HHH(DDD)
Are you trying to say that HHH is stuck in a loop and thereforeI repeated the pattern ten times so that people can notice that
never returns?
there really is a non-terminating pattern.
points it has been proven that these key elements must be repeated until someone bothers to pay attention.
Ok. The program that aborts after 10 simulation levels is then not HHH.*This is the official definition of HHH*Then don't imply that the name "HHH" refers to a single program.And thus show that you think lying is ok.Under the false assumption that my fully encoded HHH is the only one
that can possibly exist you would be correct.
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.
On 8/1/2025 10:32 AM, joes wrote:
Am Fri, 01 Aug 2025 10:19:11 -0500 schrieb olcott:
On 8/1/2025 10:10 AM, Richard Damon wrote:Also known as spamming.
On 8/1/25 11:01 AM, olcott wrote:
On 8/1/2025 1:55 AM, Mikko wrote:
On 2025-07-31 15:55:25 +0000, olcott said:
When HHH(DDD) simulates ten instructions of DDD is goes like this: >>>>>>> executed HHH(DDD) simulates DDD that calls HHH(DDD)
simulated HHH(DDD) simulates DDD that calls HHH(DDD)
Are you trying to say that HHH is stuck in a loop and therefore never >>>>>> returns?I repeated the pattern ten times so that people can notice that there >>>>> really is a non-terminating pattern.
When people make sure to fail to notice the key
elements of my key points it has been proven that
these key elements must be repeated until someone
bothers to pay attention.
And thus show that you think lying is ok.Under the false assumption that my fully encoded HHH is the only one
that can possibly exist you would be correct.
Then don't imply that the name "HHH" refers to a single program.
*This is the official definition of HHH*
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.
It is libelous for you to call me a liar on the basis of your own falseSame.
assumption. It is libelous for you to call me a liar when you mean
mistaken and not willfully deceptive.
On 8/1/2025 11:03 AM, joes wrote:
Am Fri, 01 Aug 2025 10:54:52 -0500 schrieb olcott>> When people make
sure to fail to notice the key elements of my key
points it has been proven that these key elements must be repeated
until someone bothers to pay attention.
That's not how it works. I skim over repetitions.When I tell Richard the exact same thing 500 times he continues to
respond as it I never said it.
I kept telling Richard the HHH does simulate an instance itself
emulating an instance of DDD and can do this because HHH and DDD are in
the same global memory space of Halt7.obj.
Richard keeps saying That HHH cannot simulate an instance of itself
because it does not have access to this memory. I corrected him 20 times
on this and he still does not get it.
On 8/1/2025 11:29 AM, Mr Flibble wrote:
On Fri, 01 Aug 2025 11:22:45 -0500, olcott wrote:
On 8/1/2025 11:03 AM, joes wrote:
Am Fri, 01 Aug 2025 10:54:52 -0500 schrieb olcott>> When people makeWhen I tell Richard the exact same thing 500 times he continues to
sure to fail to notice the key elements of my key
points it has been proven that these key elements must be repeated
until someone bothers to pay attention.
That's not how it works. I skim over repetitions.
respond as it I never said it.
I kept telling Richard the HHH does simulate an instance itself
emulating an instance of DDD and can do this because HHH and DDD are
in the same global memory space of Halt7.obj.
Richard keeps saying That HHH cannot simulate an instance of itself
because it does not have access to this memory. I corrected him 20
times on this and he still does not get it.
DDD can analyse a COPY of HHH, lets call it HHH', and through
simulation or some other means do the opposite of what HHH' decides
(given HHH' must halt with a decision because HHH must halt with a
decision).
/Flibble
Yet that makes the details more difficult to understand.
We must do that in the Linz proof. Whereas with my DDD/HHH proof any C programmer knowing what recursion is can see the repeating pattern.
On 8/1/2025 11:03 AM, joes wrote:
Am Fri, 01 Aug 2025 10:54:52 -0500 schrieb olcott>> When people make
sure to fail to notice the key elements of my key
points it has been proven that these key elements must be repeated until >>> someone bothers to pay attention.
That's not how it works. I skim over repetitions.
When I tell Richard the exact same thing 500 times
he continues to respond as it I never said it.
I kept telling Richard the HHH does simulate an
instance itself emulating an instance of DDD and
can do this because HHH and DDD are in the same
global memory space of Halt7.obj.
Richard keeps saying That HHH cannot simulate an
instance of itself because it does not have access
to this memory. I corrected him 20 times on this
and he still does not get it.
Ok. The program that aborts after 10 simulation levels is then not HHH.*This is the official definition of HHH*Then don't imply that the name "HHH" refers to a single program.And thus show that you think lying is ok.Under the false assumption that my fully encoded HHH is the only one >>>>> that can possibly exist you would be correct.
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.
On Fri, 01 Aug 2025 11:22:45 -0500, olcott wrote:
On 8/1/2025 11:03 AM, joes wrote:
Am Fri, 01 Aug 2025 10:54:52 -0500 schrieb olcott>> When people makeWhen I tell Richard the exact same thing 500 times he continues to
sure to fail to notice the key elements of my key
points it has been proven that these key elements must be repeated
until someone bothers to pay attention.
That's not how it works. I skim over repetitions.
respond as it I never said it.
I kept telling Richard the HHH does simulate an instance itself
emulating an instance of DDD and can do this because HHH and DDD are in
the same global memory space of Halt7.obj.
Richard keeps saying That HHH cannot simulate an instance of itself
because it does not have access to this memory. I corrected him 20 times
on this and he still does not get it.
DDD can analyse a COPY of HHH, lets call it HHH', and through simulation
or some other means do the opposite of what HHH' decides (given HHH' must halt with a decision because HHH must halt with a decision).
/Flibble
On 8/1/2025 11:29 AM, Mr Flibble wrote:
On Fri, 01 Aug 2025 11:22:45 -0500, olcott wrote:
On 8/1/2025 11:03 AM, joes wrote:
Am Fri, 01 Aug 2025 10:54:52 -0500 schrieb olcott>> When people makeWhen I tell Richard the exact same thing 500 times he continues to
sure to fail to notice the key elements of my key
points it has been proven that these key elements must be repeated
until someone bothers to pay attention.
That's not how it works. I skim over repetitions.
respond as it I never said it.
I kept telling Richard the HHH does simulate an instance itself
emulating an instance of DDD and can do this because HHH and DDD are in
the same global memory space of Halt7.obj.
Richard keeps saying That HHH cannot simulate an instance of itself
because it does not have access to this memory. I corrected him 20 times >>> on this and he still does not get it.
DDD can analyse a COPY of HHH, lets call it HHH', and through simulation
or some other means do the opposite of what HHH' decides (given HHH' must
halt with a decision because HHH must halt with a decision).
/Flibble
Yet that makes the details more difficult to understand.
We must do that in the Linz proof. Whereas with my DDD/HHH
proof any C programmer knowing what recursion is can
see the repeating pattern.
*From the bottom of page 319 has been adapted to this* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Ĥ.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⟩.
On 8/1/2025 11:51 AM, Mr Flibble wrote:
On Fri, 01 Aug 2025 11:33:51 -0500, olcott wrote:
On 8/1/2025 11:29 AM, Mr Flibble wrote:
On Fri, 01 Aug 2025 11:22:45 -0500, olcott wrote:
On 8/1/2025 11:03 AM, joes wrote:
Am Fri, 01 Aug 2025 10:54:52 -0500 schrieb olcott>> When people make >>>>>> sure to fail to notice the key elements of my keyWhen I tell Richard the exact same thing 500 times he continues to
points it has been proven that these key elements must be repeated >>>>>>> until someone bothers to pay attention.
That's not how it works. I skim over repetitions.
respond as it I never said it.
I kept telling Richard the HHH does simulate an instance itself
emulating an instance of DDD and can do this because HHH and DDD are >>>>> in the same global memory space of Halt7.obj.
Richard keeps saying That HHH cannot simulate an instance of itself
because it does not have access to this memory. I corrected him 20
times on this and he still does not get it.
DDD can analyse a COPY of HHH, lets call it HHH', and through
simulation or some other means do the opposite of what HHH' decides
(given HHH' must halt with a decision because HHH must halt with a
decision).
/Flibble
Yet that makes the details more difficult to understand.
We must do that in the Linz proof. Whereas with my DDD/HHH proof any C
programmer knowing what recursion is can see the repeating pattern.
There isn't a repeated pattern because there isn't any recursion: DDD can
*analyse* HHH without *executing* HHH because it can use a COPY of HHH
using whatever representation it deems appropriate.
/Flibble
One of the problems with static analysis of code
is that it may not ignore unreachable code.
Analysis by a simulating halt decider never even
sees this unreachable code. It only pays attention
to the code in its actual execution trace.
On 8/1/2025 12:19 PM, Richard Damon wrote:
On 8/1/25 12:58 PM, olcott wrote:
On 8/1/2025 11:51 AM, Mr Flibble wrote:
On Fri, 01 Aug 2025 11:33:51 -0500, olcott wrote:
On 8/1/2025 11:29 AM, Mr Flibble wrote:
On Fri, 01 Aug 2025 11:22:45 -0500, olcott wrote:
On 8/1/2025 11:03 AM, joes wrote:
Am Fri, 01 Aug 2025 10:54:52 -0500 schrieb olcott>> When people >>>>>>>> makeWhen I tell Richard the exact same thing 500 times he continues to >>>>>>> respond as it I never said it.
sure to fail to notice the key elements of my key
points it has been proven that these key elements must be repeated >>>>>>>>> until someone bothers to pay attention.
That's not how it works. I skim over repetitions.
I kept telling Richard the HHH does simulate an instance itself
emulating an instance of DDD and can do this because HHH and DDD are >>>>>>> in the same global memory space of Halt7.obj.
Richard keeps saying That HHH cannot simulate an instance of itself >>>>>>> because it does not have access to this memory. I corrected him 20 >>>>>>> times on this and he still does not get it.
DDD can analyse a COPY of HHH, lets call it HHH', and through
simulation or some other means do the opposite of what HHH' decides >>>>>> (given HHH' must halt with a decision because HHH must halt with a >>>>>> decision).
/Flibble
Yet that makes the details more difficult to understand.
We must do that in the Linz proof. Whereas with my DDD/HHH proof any C >>>>> programmer knowing what recursion is can see the repeating pattern.
There isn't a repeated pattern because there isn't any recursion:
DDD can
*analyse* HHH without *executing* HHH because it can use a COPY of HHH >>>> using whatever representation it deems appropriate.
/Flibble
One of the problems with static analysis of code
is that it may not ignore unreachable code.
Analysis by a simulating halt decider never even
sees this unreachable code. It only pays attention
to the code in its actual execution trace.
But the code isn't "unreachable", only not reached by the partial
simulation that the decider did.
Anyone with slight C programming experience can see
the repeating pattern that cannot possibly reach its
own simulated final halt state.
On 8/1/2025 1:36 PM, Richard Damon wrote:
On 8/1/25 1:28 PM, olcott wrote:
On 8/1/2025 12:19 PM, Richard Damon wrote:
On 8/1/25 12:58 PM, olcott wrote:
On 8/1/2025 11:51 AM, Mr Flibble wrote:
On Fri, 01 Aug 2025 11:33:51 -0500, olcott wrote:
On 8/1/2025 11:29 AM, Mr Flibble wrote:There isn't a repeated pattern because there isn't any recursion:
On Fri, 01 Aug 2025 11:22:45 -0500, olcott wrote:
On 8/1/2025 11:03 AM, joes wrote:
Am Fri, 01 Aug 2025 10:54:52 -0500 schrieb olcott>> WhenWhen I tell Richard the exact same thing 500 times he continues to >>>>>>>>> respond as it I never said it.
people make
sure to fail to notice the key elements of my key
points it has been proven that these key elements must be >>>>>>>>>>> repeated
until someone bothers to pay attention.
That's not how it works. I skim over repetitions.
I kept telling Richard the HHH does simulate an instance itself >>>>>>>>> emulating an instance of DDD and can do this because HHH and >>>>>>>>> DDD are
in the same global memory space of Halt7.obj.
Richard keeps saying That HHH cannot simulate an instance of >>>>>>>>> itself
because it does not have access to this memory. I corrected him 20 >>>>>>>>> times on this and he still does not get it.
DDD can analyse a COPY of HHH, lets call it HHH', and through
simulation or some other means do the opposite of what HHH' decides >>>>>>>> (given HHH' must halt with a decision because HHH must halt with a >>>>>>>> decision).
/Flibble
Yet that makes the details more difficult to understand.
We must do that in the Linz proof. Whereas with my DDD/HHH proof >>>>>>> any C
programmer knowing what recursion is can see the repeating pattern. >>>>>>
DDD can
*analyse* HHH without *executing* HHH because it can use a COPY of >>>>>> HHH
using whatever representation it deems appropriate.
/Flibble
One of the problems with static analysis of code
is that it may not ignore unreachable code.
Analysis by a simulating halt decider never even
sees this unreachable code. It only pays attention
to the code in its actual execution trace.
But the code isn't "unreachable", only not reached by the partial
simulation that the decider did.
Anyone with slight C programming experience can see
the repeating pattern that cannot possibly reach its
own simulated final halt state.
The problem is that "its own" isn't the requirement.
Sicne your HHH doesn't do that, and any otehr HHH won't be given this
input, you are just proving you don't understand how logic works,
because you just think in LIES.
All you are doing is proving you are just a stupid pathological liar.
And the fact that you just repeat the lies shows how unrepentant that
sin is.
No you are proving that you are libelous.
You glance at a couple of my words without even
understanding what I said and then immediately
call me a liar.
Also you are libelous in another way when you call
someone a liar you include unintentional mistakes
as deliberate lies.
On Fri, 01 Aug 2025 13:14:09 -0400, Richard Damon wrote:
On 8/1/25 12:29 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 11:22:45 -0500, olcott wrote:
On 8/1/2025 11:03 AM, joes wrote:
Am Fri, 01 Aug 2025 10:54:52 -0500 schrieb olcott>> When people make >>>>> sure to fail to notice the key elements of my keyWhen I tell Richard the exact same thing 500 times he continues to
points it has been proven that these key elements must be repeated >>>>>> until someone bothers to pay attention.
That's not how it works. I skim over repetitions.
respond as it I never said it.
I kept telling Richard the HHH does simulate an instance itself
emulating an instance of DDD and can do this because HHH and DDD are
in the same global memory space of Halt7.obj.
Richard keeps saying That HHH cannot simulate an instance of itself
because it does not have access to this memory. I corrected him 20
times on this and he still does not get it.
DDD can analyse a COPY of HHH, lets call it HHH', and through
simulation or some other means do the opposite of what HHH' decides
(given HHH' must halt with a decision because HHH must halt with a
decision).
/Flibble
It doesn't need to "analyse" HHH, it just needs to include in itself a
copy of the code of HHH.
It seems you don't understand how programs work.
Of course I understand how fucking programs work, do you?
If it is including in itself a copy of the code of HHH then it will use
that to *analyse* HHH in order to do the opposite, you demented fuckwit.
/Flibble
On 8/1/25 12:29 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 11:22:45 -0500, olcott wrote:
On 8/1/2025 11:03 AM, joes wrote:
Am Fri, 01 Aug 2025 10:54:52 -0500 schrieb olcott>> When people makeWhen I tell Richard the exact same thing 500 times he continues to
sure to fail to notice the key elements of my key
points it has been proven that these key elements must be repeated
until someone bothers to pay attention.
That's not how it works. I skim over repetitions.
respond as it I never said it.
I kept telling Richard the HHH does simulate an instance itself
emulating an instance of DDD and can do this because HHH and DDD are
in the same global memory space of Halt7.obj.
Richard keeps saying That HHH cannot simulate an instance of itself
because it does not have access to this memory. I corrected him 20
times on this and he still does not get it.
DDD can analyse a COPY of HHH, lets call it HHH', and through
simulation or some other means do the opposite of what HHH' decides
(given HHH' must halt with a decision because HHH must halt with a
decision).
/Flibble
It doesn't need to "analyse" HHH, it just needs to include in itself a
copy of the code of HHH.
It seems you don't understand how programs work.
On Fri, 01 Aug 2025 13:14:09 -0400, Richard Damon wrote:
On 8/1/25 12:29 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 11:22:45 -0500, olcott wrote:
On 8/1/2025 11:03 AM, joes wrote:
Am Fri, 01 Aug 2025 10:54:52 -0500 schrieb olcott>> When people make >>>>> sure to fail to notice the key elements of my keyWhen I tell Richard the exact same thing 500 times he continues to
points it has been proven that these key elements must be repeated >>>>>> until someone bothers to pay attention.
That's not how it works. I skim over repetitions.
respond as it I never said it.
I kept telling Richard the HHH does simulate an instance itself
emulating an instance of DDD and can do this because HHH and DDD are
in the same global memory space of Halt7.obj.
Richard keeps saying That HHH cannot simulate an instance of itself
because it does not have access to this memory. I corrected him 20
times on this and he still does not get it.
DDD can analyse a COPY of HHH, lets call it HHH', and through
simulation or some other means do the opposite of what HHH' decides
(given HHH' must halt with a decision because HHH must halt with a
decision).
/Flibble
It doesn't need to "analyse" HHH, it just needs to include in itself a
copy of the code of HHH.
It seems you don't understand how programs work.
Of course I understand how fucking programs work, do you?
If it is including in itself a copy of the code of HHH then it will use
that to *analyse* HHH in order to do the opposite, you demented fuckwit.
/Flibble
On Fri, 01 Aug 2025 21:17:49 +0000, Mr Flibble wrote:
On Fri, 01 Aug 2025 13:14:09 -0400, Richard Damon wrote:
On 8/1/25 12:29 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 11:22:45 -0500, olcott wrote:
On 8/1/2025 11:03 AM, joes wrote:
Am Fri, 01 Aug 2025 10:54:52 -0500 schrieb olcott>> When people make >>>>>> sure to fail to notice the key elements of my keyWhen I tell Richard the exact same thing 500 times he continues to
points it has been proven that these key elements must be repeated >>>>>>> until someone bothers to pay attention.
That's not how it works. I skim over repetitions.
respond as it I never said it.
I kept telling Richard the HHH does simulate an instance itself
emulating an instance of DDD and can do this because HHH and DDD are >>>>> in the same global memory space of Halt7.obj.
Richard keeps saying That HHH cannot simulate an instance of itself
because it does not have access to this memory. I corrected him 20
times on this and he still does not get it.
DDD can analyse a COPY of HHH, lets call it HHH', and through
simulation or some other means do the opposite of what HHH' decides
(given HHH' must halt with a decision because HHH must halt with a
decision).
/Flibble
It doesn't need to "analyse" HHH, it just needs to include in itself a
copy of the code of HHH.
It seems you don't understand how programs work.
Of course I understand how fucking programs work, do you?
If it is including in itself a copy of the code of HHH then it will use
that to *analyse* HHH in order to do the opposite, you demented fuckwit.
/Flibble
Oh. I have seen the light, my apologies Damon. Of course DDD doesn't need
to *analyse* HHH', just execute it with itself as an input and THEN do the opposite.
/Flibble
On 8/1/25 5:17 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 13:14:09 -0400, Richard Damon wrote:
On 8/1/25 12:29 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 11:22:45 -0500, olcott wrote:
On 8/1/2025 11:03 AM, joes wrote:
Am Fri, 01 Aug 2025 10:54:52 -0500 schrieb olcott>> When peopleWhen I tell Richard the exact same thing 500 times he continues to
make sure to fail to notice the key elements of my key
points it has been proven that these key elements must be repeated >>>>>>> until someone bothers to pay attention.
That's not how it works. I skim over repetitions.
respond as it I never said it.
I kept telling Richard the HHH does simulate an instance itself
emulating an instance of DDD and can do this because HHH and DDD are >>>>> in the same global memory space of Halt7.obj.
Richard keeps saying That HHH cannot simulate an instance of itself
because it does not have access to this memory. I corrected him 20
times on this and he still does not get it.
DDD can analyse a COPY of HHH, lets call it HHH', and through
simulation or some other means do the opposite of what HHH' decides
(given HHH' must halt with a decision because HHH must halt with a
decision).
/Flibble
It doesn't need to "analyse" HHH, it just needs to include in itself a
copy of the code of HHH.
It seems you don't understand how programs work.
Of course I understand how fucking programs work, do you?
If it is including in itself a copy of the code of HHH then it will use
that to *analyse* HHH in order to do the opposite, you demented
fuckwit.
/Flibble
Code doesn't "analyze" itself, it just does it.
When you call the sin function, does your program analyze the code of
the function you called to figure out how it works and figure out what
answer it will give? No. It just uses the basic instruction in that
functiosn and executes them like any onther instruciton in the program.
It is clear you really don't know what you are talking about.
Maybe you need to go to someone to analyze you self to see why you have
the problems you are having.
On Fri, 01 Aug 2025 17:33:41 -0400, Richard Damon wrote:
On 8/1/25 5:17 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 13:14:09 -0400, Richard Damon wrote:
On 8/1/25 12:29 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 11:22:45 -0500, olcott wrote:
On 8/1/2025 11:03 AM, joes wrote:
Am Fri, 01 Aug 2025 10:54:52 -0500 schrieb olcott>> When peopleWhen I tell Richard the exact same thing 500 times he continues to >>>>>> respond as it I never said it.
make sure to fail to notice the key elements of my key
points it has been proven that these key elements must be repeated >>>>>>>> until someone bothers to pay attention.
That's not how it works. I skim over repetitions.
I kept telling Richard the HHH does simulate an instance itself
emulating an instance of DDD and can do this because HHH and DDD are >>>>>> in the same global memory space of Halt7.obj.
Richard keeps saying That HHH cannot simulate an instance of itself >>>>>> because it does not have access to this memory. I corrected him 20 >>>>>> times on this and he still does not get it.
DDD can analyse a COPY of HHH, lets call it HHH', and through
simulation or some other means do the opposite of what HHH' decides
(given HHH' must halt with a decision because HHH must halt with a
decision).
/Flibble
It doesn't need to "analyse" HHH, it just needs to include in itself a >>>> copy of the code of HHH.
It seems you don't understand how programs work.
Of course I understand how fucking programs work, do you?
If it is including in itself a copy of the code of HHH then it will use
that to *analyse* HHH in order to do the opposite, you demented
fuckwit.
/Flibble
Code doesn't "analyze" itself, it just does it.
When you call the sin function, does your program analyze the code of
the function you called to figure out how it works and figure out what
answer it will give? No. It just uses the basic instruction in that
functiosn and executes them like any onther instruciton in the program.
It is clear you really don't know what you are talking about.
Maybe you need to go to someone to analyze you self to see why you have
the problems you are having.
I do know what I am talking about, I just made a mistake in my wording, we all make mistakes, Damon. By "analyse HHH" I actually meant actually
meant DDD *interpret* HHH' *analysing* DDD.
/Flibble
On Fri, 01 Aug 2025 18:03:01 -0400, Richard Damon wrote:
On 8/1/25 5:50 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 17:33:41 -0400, Richard Damon wrote:
On 8/1/25 5:17 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 13:14:09 -0400, Richard Damon wrote:
On 8/1/25 12:29 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 11:22:45 -0500, olcott wrote:
On 8/1/2025 11:03 AM, joes wrote:
Am Fri, 01 Aug 2025 10:54:52 -0500 schrieb olcott>> When people >>>>>>>>> make sure to fail to notice the key elements of my keyWhen I tell Richard the exact same thing 500 times he continues to >>>>>>>> respond as it I never said it.
points it has been proven that these key elements must be
repeated until someone bothers to pay attention.
That's not how it works. I skim over repetitions.
I kept telling Richard the HHH does simulate an instance itself >>>>>>>> emulating an instance of DDD and can do this because HHH and DDD >>>>>>>> are in the same global memory space of Halt7.obj.
Richard keeps saying That HHH cannot simulate an instance of
itself because it does not have access to this memory. I corrected >>>>>>>> him 20 times on this and he still does not get it.
DDD can analyse a COPY of HHH, lets call it HHH', and through
simulation or some other means do the opposite of what HHH' decides >>>>>>> (given HHH' must halt with a decision because HHH must halt with a >>>>>>> decision).
/Flibble
It doesn't need to "analyse" HHH, it just needs to include in itself >>>>>> a copy of the code of HHH.
It seems you don't understand how programs work.
Of course I understand how fucking programs work, do you?
If it is including in itself a copy of the code of HHH then it will
use that to *analyse* HHH in order to do the opposite, you demented
fuckwit.
/Flibble
Code doesn't "analyze" itself, it just does it.
When you call the sin function, does your program analyze the code of
the function you called to figure out how it works and figure out what >>>> answer it will give? No. It just uses the basic instruction in that
functiosn and executes them like any onther instruciton in the
program.
It is clear you really don't know what you are talking about.
Maybe you need to go to someone to analyze you self to see why you
have the problems you are having.
I do know what I am talking about, I just made a mistake in my wording,
we all make mistakes, Damon. By "analyse HHH" I actually meant
actually meant DDD *interpret* HHH' *analysing* DDD.
/Flibble
but it doesn't even do that, it just runs the algorithm of HHH as part
of itself, so it arrives that the same answer.
Well it certainly can do it that way but I would argue that that is an optimisation; it could also do it in the way I describe.
/Flibble
On 8/1/25 5:50 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 17:33:41 -0400, Richard Damon wrote:
On 8/1/25 5:17 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 13:14:09 -0400, Richard Damon wrote:
On 8/1/25 12:29 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 11:22:45 -0500, olcott wrote:
On 8/1/2025 11:03 AM, joes wrote:
Am Fri, 01 Aug 2025 10:54:52 -0500 schrieb olcott>> When people >>>>>>>> make sure to fail to notice the key elements of my keyWhen I tell Richard the exact same thing 500 times he continues to >>>>>>> respond as it I never said it.
points it has been proven that these key elements must be
repeated until someone bothers to pay attention.
That's not how it works. I skim over repetitions.
I kept telling Richard the HHH does simulate an instance itself
emulating an instance of DDD and can do this because HHH and DDD >>>>>>> are in the same global memory space of Halt7.obj.
Richard keeps saying That HHH cannot simulate an instance of
itself because it does not have access to this memory. I corrected >>>>>>> him 20 times on this and he still does not get it.
DDD can analyse a COPY of HHH, lets call it HHH', and through
simulation or some other means do the opposite of what HHH' decides >>>>>> (given HHH' must halt with a decision because HHH must halt with a >>>>>> decision).
/Flibble
It doesn't need to "analyse" HHH, it just needs to include in itself >>>>> a copy of the code of HHH.
It seems you don't understand how programs work.
Of course I understand how fucking programs work, do you?
If it is including in itself a copy of the code of HHH then it will
use that to *analyse* HHH in order to do the opposite, you demented
fuckwit.
/Flibble
Code doesn't "analyze" itself, it just does it.
When you call the sin function, does your program analyze the code of
the function you called to figure out how it works and figure out what
answer it will give? No. It just uses the basic instruction in that
functiosn and executes them like any onther instruciton in the
program.
It is clear you really don't know what you are talking about.
Maybe you need to go to someone to analyze you self to see why you
have the problems you are having.
I do know what I am talking about, I just made a mistake in my wording,
we all make mistakes, Damon. By "analyse HHH" I actually meant
actually meant DDD *interpret* HHH' *analysing* DDD.
/Flibble
but it doesn't even do that, it just runs the algorithm of HHH as part
of itself, so it arrives that the same answer.
On 8/1/25 6:20 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 18:03:01 -0400, Richard Damon wrote:
On 8/1/25 5:50 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 17:33:41 -0400, Richard Damon wrote:
On 8/1/25 5:17 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 13:14:09 -0400, Richard Damon wrote:
On 8/1/25 12:29 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 11:22:45 -0500, olcott wrote:
On 8/1/2025 11:03 AM, joes wrote:
Am Fri, 01 Aug 2025 10:54:52 -0500 schrieb olcott>> When people >>>>>>>>>> make sure to fail to notice the key elements of my keyWhen I tell Richard the exact same thing 500 times he continues >>>>>>>>> to respond as it I never said it.
points it has been proven that these key elements must be >>>>>>>>>>> repeated until someone bothers to pay attention.
That's not how it works. I skim over repetitions.
I kept telling Richard the HHH does simulate an instance itself >>>>>>>>> emulating an instance of DDD and can do this because HHH and DDD >>>>>>>>> are in the same global memory space of Halt7.obj.
Richard keeps saying That HHH cannot simulate an instance of >>>>>>>>> itself because it does not have access to this memory. I
corrected him 20 times on this and he still does not get it.
DDD can analyse a COPY of HHH, lets call it HHH', and through
simulation or some other means do the opposite of what HHH'
decides (given HHH' must halt with a decision because HHH must >>>>>>>> halt with a decision).
/Flibble
It doesn't need to "analyse" HHH, it just needs to include in
itself a copy of the code of HHH.
It seems you don't understand how programs work.
Of course I understand how fucking programs work, do you?
If it is including in itself a copy of the code of HHH then it will >>>>>> use that to *analyse* HHH in order to do the opposite, you demented >>>>>> fuckwit.
/Flibble
Code doesn't "analyze" itself, it just does it.
When you call the sin function, does your program analyze the code
of the function you called to figure out how it works and figure out >>>>> what answer it will give? No. It just uses the basic instruction in
that functiosn and executes them like any onther instruciton in the
program.
It is clear you really don't know what you are talking about.
Maybe you need to go to someone to analyze you self to see why you
have the problems you are having.
I do know what I am talking about, I just made a mistake in my
wording,
we all make mistakes, Damon. By "analyse HHH" I actually meant
actually meant DDD *interpret* HHH' *analysing* DDD.
/Flibble
but it doesn't even do that, it just runs the algorithm of HHH as part
of itself, so it arrives that the same answer.
Well it certainly can do it that way but I would argue that that is an
optimisation; it could also do it in the way I describe.
/Flibble
You could, but that isn't the way it is normally described. Yours is
more of a obfuscation method.
On Fri, 01 Aug 2025 18:46:12 -0400, Richard Damon wrote:
On 8/1/25 6:20 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 18:03:01 -0400, Richard Damon wrote:
On 8/1/25 5:50 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 17:33:41 -0400, Richard Damon wrote:
On 8/1/25 5:17 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 13:14:09 -0400, Richard Damon wrote:
On 8/1/25 12:29 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 11:22:45 -0500, olcott wrote:
On 8/1/2025 11:03 AM, joes wrote:DDD can analyse a COPY of HHH, lets call it HHH', and through >>>>>>>>> simulation or some other means do the opposite of what HHH'
Am Fri, 01 Aug 2025 10:54:52 -0500 schrieb olcott>> When people >>>>>>>>>>> make sure to fail to notice the key elements of my keyWhen I tell Richard the exact same thing 500 times he continues >>>>>>>>>> to respond as it I never said it.
points it has been proven that these key elements must be >>>>>>>>>>>> repeated until someone bothers to pay attention.
That's not how it works. I skim over repetitions.
I kept telling Richard the HHH does simulate an instance itself >>>>>>>>>> emulating an instance of DDD and can do this because HHH and DDD >>>>>>>>>> are in the same global memory space of Halt7.obj.
Richard keeps saying That HHH cannot simulate an instance of >>>>>>>>>> itself because it does not have access to this memory. I
corrected him 20 times on this and he still does not get it. >>>>>>>>>
decides (given HHH' must halt with a decision because HHH must >>>>>>>>> halt with a decision).
/Flibble
It doesn't need to "analyse" HHH, it just needs to include in
itself a copy of the code of HHH.
It seems you don't understand how programs work.
Of course I understand how fucking programs work, do you?
If it is including in itself a copy of the code of HHH then it will >>>>>>> use that to *analyse* HHH in order to do the opposite, you demented >>>>>>> fuckwit.
/Flibble
Code doesn't "analyze" itself, it just does it.
When you call the sin function, does your program analyze the code >>>>>> of the function you called to figure out how it works and figure out >>>>>> what answer it will give? No. It just uses the basic instruction in >>>>>> that functiosn and executes them like any onther instruciton in the >>>>>> program.
It is clear you really don't know what you are talking about.
Maybe you need to go to someone to analyze you self to see why you >>>>>> have the problems you are having.
I do know what I am talking about, I just made a mistake in my
wording,
we all make mistakes, Damon. By "analyse HHH" I actually meant
actually meant DDD *interpret* HHH' *analysing* DDD.
/Flibble
but it doesn't even do that, it just runs the algorithm of HHH as part >>>> of itself, so it arrives that the same answer.
Well it certainly can do it that way but I would argue that that is an
optimisation; it could also do it in the way I describe.
/Flibble
You could, but that isn't the way it is normally described. Yours is
more of a obfuscation method.
My method is closer to how it would work using idealised Turing machines (reading a tape).
/Flibble
On 8/1/25 6:54 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 18:46:12 -0400, Richard Damon wrote:
On 8/1/25 6:20 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 18:03:01 -0400, Richard Damon wrote:
On 8/1/25 5:50 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 17:33:41 -0400, Richard Damon wrote:
On 8/1/25 5:17 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 13:14:09 -0400, Richard Damon wrote:
On 8/1/25 12:29 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 11:22:45 -0500, olcott wrote:
On 8/1/2025 11:03 AM, joes wrote:DDD can analyse a COPY of HHH, lets call it HHH', and through >>>>>>>>>> simulation or some other means do the opposite of what HHH' >>>>>>>>>> decides (given HHH' must halt with a decision because HHH must >>>>>>>>>> halt with a decision).
Am Fri, 01 Aug 2025 10:54:52 -0500 schrieb olcott>> When >>>>>>>>>>>> people make sure to fail to notice the key elements of my key >>>>>>>>>>>>> points it has been proven that these key elements must be >>>>>>>>>>>>> repeated until someone bothers to pay attention.When I tell Richard the exact same thing 500 times he
That's not how it works. I skim over repetitions.
continues to respond as it I never said it.
I kept telling Richard the HHH does simulate an instance >>>>>>>>>>> itself emulating an instance of DDD and can do this because >>>>>>>>>>> HHH and DDD are in the same global memory space of Halt7.obj. >>>>>>>>>>>
Richard keeps saying That HHH cannot simulate an instance of >>>>>>>>>>> itself because it does not have access to this memory. I >>>>>>>>>>> corrected him 20 times on this and he still does not get it. >>>>>>>>>>
/Flibble
It doesn't need to "analyse" HHH, it just needs to include in >>>>>>>>> itself a copy of the code of HHH.
It seems you don't understand how programs work.
Of course I understand how fucking programs work, do you?
If it is including in itself a copy of the code of HHH then it >>>>>>>> will use that to *analyse* HHH in order to do the opposite, you >>>>>>>> demented fuckwit.
/Flibble
Code doesn't "analyze" itself, it just does it.
When you call the sin function, does your program analyze the code >>>>>>> of the function you called to figure out how it works and figure >>>>>>> out what answer it will give? No. It just uses the basic
instruction in that functiosn and executes them like any onther
instruciton in the program.
It is clear you really don't know what you are talking about.
Maybe you need to go to someone to analyze you self to see why you >>>>>>> have the problems you are having.
I do know what I am talking about, I just made a mistake in my
wording,
we all make mistakes, Damon. By "analyse HHH" I actually meant
actually meant DDD *interpret* HHH' *analysing* DDD.
/Flibble
but it doesn't even do that, it just runs the algorithm of HHH as
part of itself, so it arrives that the same answer.
Well it certainly can do it that way but I would argue that that is
an optimisation; it could also do it in the way I describe.
/Flibble
You could, but that isn't the way it is normally described. Yours is
more of a obfuscation method.
My method is closer to how it would work using idealised Turing
machines (reading a tape).
/Flibble
No, as when you build the machine D you just incorporate the code. To
put it on the tape would require the decider to be part of the input, so
it would be DDD(HHH) where the input specifies what machine is to be
made wrong, but that isn't how the problem has been defined.
Turing Machine have a VERY sharp line between the program and the input.
THe concept of a UTM allows making parts of the algorith to be in the
input, but that becomes a deliberate decision.
On Fri, 01 Aug 2025 19:20:28 -0400, Richard Damon wrote:
On 8/1/25 6:54 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 18:46:12 -0400, Richard Damon wrote:
On 8/1/25 6:20 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 18:03:01 -0400, Richard Damon wrote:
On 8/1/25 5:50 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 17:33:41 -0400, Richard Damon wrote:
On 8/1/25 5:17 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 13:14:09 -0400, Richard Damon wrote:
On 8/1/25 12:29 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 11:22:45 -0500, olcott wrote:
On 8/1/2025 11:03 AM, joes wrote:DDD can analyse a COPY of HHH, lets call it HHH', and through >>>>>>>>>>> simulation or some other means do the opposite of what HHH' >>>>>>>>>>> decides (given HHH' must halt with a decision because HHH must >>>>>>>>>>> halt with a decision).
Am Fri, 01 Aug 2025 10:54:52 -0500 schrieb olcott>> When >>>>>>>>>>>>> people make sure to fail to notice the key elements of my key >>>>>>>>>>>>>> points it has been proven that these key elements must be >>>>>>>>>>>>>> repeated until someone bothers to pay attention.When I tell Richard the exact same thing 500 times he
That's not how it works. I skim over repetitions.
continues to respond as it I never said it.
I kept telling Richard the HHH does simulate an instance >>>>>>>>>>>> itself emulating an instance of DDD and can do this because >>>>>>>>>>>> HHH and DDD are in the same global memory space of Halt7.obj. >>>>>>>>>>>>
Richard keeps saying That HHH cannot simulate an instance of >>>>>>>>>>>> itself because it does not have access to this memory. I >>>>>>>>>>>> corrected him 20 times on this and he still does not get it. >>>>>>>>>>>
/Flibble
It doesn't need to "analyse" HHH, it just needs to include in >>>>>>>>>> itself a copy of the code of HHH.
It seems you don't understand how programs work.
Of course I understand how fucking programs work, do you?
If it is including in itself a copy of the code of HHH then it >>>>>>>>> will use that to *analyse* HHH in order to do the opposite, you >>>>>>>>> demented fuckwit.
/Flibble
Code doesn't "analyze" itself, it just does it.
When you call the sin function, does your program analyze the code >>>>>>>> of the function you called to figure out how it works and figure >>>>>>>> out what answer it will give? No. It just uses the basic
instruction in that functiosn and executes them like any onther >>>>>>>> instruciton in the program.
It is clear you really don't know what you are talking about.
Maybe you need to go to someone to analyze you self to see why you >>>>>>>> have the problems you are having.
I do know what I am talking about, I just made a mistake in my
wording,
we all make mistakes, Damon. By "analyse HHH" I actually meant
actually meant DDD *interpret* HHH' *analysing* DDD.
/Flibble
but it doesn't even do that, it just runs the algorithm of HHH as
part of itself, so it arrives that the same answer.
Well it certainly can do it that way but I would argue that that is
an optimisation; it could also do it in the way I describe.
/Flibble
You could, but that isn't the way it is normally described. Yours is
more of a obfuscation method.
My method is closer to how it would work using idealised Turing
machines (reading a tape).
/Flibble
No, as when you build the machine D you just incorporate the code. To
put it on the tape would require the decider to be part of the input, so
it would be DDD(HHH) where the input specifies what machine is to be
made wrong, but that isn't how the problem has been defined.
Turing Machine have a VERY sharp line between the program and the input.
THe concept of a UTM allows making parts of the algorith to be in the
input, but that becomes a deliberate decision.
In the context of Turing's original 1936 proof of the undecidability of
the halting problem, the halt decider (let's denote it as TM **H**) is
indeed a Turing machine that takes as input the *description* (or
encoding, often denoted as ⟨M⟩) of another TM **M** and an input
string **w** for **M**, both provided on the tape. **H** must then decide whether **M** halts on **w**. This setup relies on the concept of a
universal Turing machine (UTM), which can simulate any other TM given its description on the tape. Without this, self-reference and the diagonal argument wouldn't work, as TMs don't "call" each other like subroutines in modern programming—they operate solely on tape contents.
Damon's point about the "sharp line" between program (the finite
transition table defining the TM) and input (the tape) is accurate for
basic TMs. However, the halting problem is specifically formulated in
terms of computable functions over encodings, which necessitates treating machine descriptions as data on the tape. This is not an "obfuscation" or deviation; it's the core of how undecidability is proven. To clarify:
- When constructing the counterexample TM **D** (your DDD), its transition table is designed to:
1. Read the encoding ⟨M⟩ from the tape (the input).
2. Prepare the pair (⟨M⟩, ⟨M⟩) on a working section of the tape.
3. Simulate **H** on that pair (effectively asking if **M** halts on its own description).
4. If **H** accepts (predicts halting), **D** enters an infinite loop.
5. If **H** rejects (predicts non-halting), **D** halts.
- The paradox arises when we provide **D** with its own encoding ⟨D⟩
as input: **H**(⟨D⟩, ⟨D⟩) can't consistently decide, because **D**
is built to contradict whatever **H** says.
This doesn't require **D** to "incorporate the code" of **H** in the sense
of merging transition tables statically. Instead, **D**'s transition table includes logic to simulate **H** (via a UTM subroutine encoded in **D**'s
own table). The input to **D** is always an encoding on the tape, not a direct reference to **H**. If we tried to hardwire **H** without
encodings, we'd lose the ability to diagonalize over all possible
machines, which is essential to the proof.
To illustrate the distinction between TM and programming-language views, here's a comparison:
| Aspect | Turing Machine Model (Idealized, Tape-Based) | Modern Programming Model (e.g., C/Python) | |-------------------------|---------------------------------------------|-------------------------------------------|
| **Halt Decider (H)** | TM that reads ⟨M⟩ and w from tape,
simulates M(w) via UTM. Must halt with accept/reject. | Function `h(code, input)` that analyzes or simulates the code string on input. |
| **Counterexample (D)** | TM whose transition table simulates H on
(⟨M⟩, ⟨M⟩) from tape, then inverts. Paradox via H(⟨D⟩, ⟨D⟩). | Function `d(code)` that calls `h(code, code)` and inverts (e.g., loop if
h says halt). Paradox via h("d_source", "d_source"). |
| **Self-Reference** | Achieved via encodings on tape (Quine-like construction for ⟨D⟩). No shared memory. | Often via source code
strings or function pointers; simulation avoids direct recursion. |
| **"Incorporating Code"**| D simulates H dynamically based on its own
table; input is always data (encodings). | D can embed H's code statically
as a subroutine for efficiency. |
| **Sharp Program/Input Line** | Yes, but UTMs deliberately treat programs
as input data to enable simulation. | Blurred by interpreters/compilers;
code is data (e.g., eval() in Python). |
Flibble's emphasis on "reading a tape" aligns precisely with this TM formulation—it's not an optimization or alternative; it's the canonical
way the problem is defined in computability texts. Damon's suggestion of DDD(HHH) mischaracterizes it: the input isn't "specifying what machine to make wrong"; it's the encoding that allows universal computation and the diagonal contradiction. If we restricted to non-universal TMs without tape encodings, the halting problem wouldn't even be poseable in its general
form.
For a concrete example, consider Sipser's textbook pseudocode for the
proof (adapted to TM style):
- Assume H exists: On input ⟨M, w⟩, run UTM simulation of M on w; if
it halts, accept; else reject. (But this begs the question, as detecting infinite simulation is the hard part.)
- D: On input ⟨M⟩, run H on ⟨M, ⟨M⟩⟩; if H accepts, loop; else halt.The big problem with olcotts' model is he tries to make the input not
- Feed ⟨D⟩ to H as both machine and input → contradiction.
This has been substantiated unchanged since 1936, across sources from Turing's paper to modern references like Arora/Barak's "Computational Complexity." If we're discussing a specific implementation (e.g., Olcott's x86 simulator), the TM model still holds as the theoretical benchmark, and shared memory doesn't resolve the undecidability—it just approximates for subsets of programs.
/Grok
On 8/1/2025 1:55 AM, Mikko wrote:
On 2025-07-31 15:55:25 +0000, olcott said:
On 7/31/2025 3:34 AM, Mikko wrote:
On 2025-07-30 15:32:39 +0000, olcott said:
On 7/30/2025 1:50 AM, Mikko wrote:
On 2025-07-29 20:53:54 +0000, olcott said:
On 7/29/2025 1:37 AM, Mikko wrote:
On 2025-07-28 12:42:24 +0000, olcott said:
On 7/28/2025 2:50 AM, Mikko wrote:
On 2025-07-27 14:39:45 +0000, olcott said:
On 7/27/2025 2:36 AM, Mikko wrote:
On 2025-07-26 16:21:19 +0000, olcott said:
On 7/26/2025 2:28 AM, Mikko wrote:Only because the C compiler attempts to preserve the meaning. The >>>>>>>>>>>> definitions of the meanings are distinct (except for assembly code >>>>>>>>>>>> insertinos that the compiler permits as a lnaguage extension). >>>>>>>>>>>>
On 2025-07-25 15:54:06 +0000, olcott said:
On 7/25/2025 2:43 AM, Mikko wrote:
On 2025-07-24 21:18:32 +0000, olcott said:*Correctly emulated is defined as*
On 7/24/2025 4:02 PM, joes wrote:That you don't understand something does not mean that it is not
Am Thu, 24 Jul 2025 09:11:44 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>>> On 7/24/2025 5:07 AM, joes wrote:
Yes, it is. And that can obviously be computed by a processor, a UTMAm Wed, 23 Jul 2025 16:08:51 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>>>>> On 7/23/2025 3:56 PM, joes wrote:
int Simulate(ptr x)If HHH (which aborts) was given to a UTM/pure simulator, it would stopOf course, and then it incorrectly assumes that an unabortedIf HHH(DDD) never aborts its simulation then this HHH never stops
simulation *of this HHH*, which does in fact abort, wouldn't abort.
running.
running.
{
x(); return 1;
}
It is the behavior of the input to HHH(DDD) that HHH is supposed to
measure.
It is not the behavior of the input to Simulate(DDD) that HHH is
supposed to measure.
It is also not the behavior of the directly executed DDD() that HHH is
supposed to measure.
or any simulator that doesn't abort before the HHH called by DDD does -
which HHH logically cannot do.
HHH(DDD) is only supposed to measure the behavior of its own input.Do you understand that it trivially produces the same result as the
value that it returns?
It has been three years and still not one person has understood that theIt is well understood that HHH does not simulate DDD the same way as the
behavior of an input that calls its own simulator is not the same as the
behavior of an input that does not call its own simulator. >>>>>>>>>>>>>>>>>
direct execution. DDD doesn't even have an "own simulator", it is just
a program that you want to simulate using the simulator it happens to
call.
What has never been understood (even now) is that >>>>>>>>>>>>>>>>> Simulate(DDD) is presented with a different sequence >>>>>>>>>>>>>>>>> of x86 instructions than HHH(DDD) is presented with. >>>>>>>>>>>>>>>>
understood. Everyone other than you understand that if DDD in >>>>>>>>>>>>>>>> Simulate(DDD) is not the same as DDD in HHH(DDD) then one of them
was given a false name (and perhaps the other, too). >>>>>>>>>>>>>>>
Emulated according to the rules of the x86 language. >>>>>>>>>>>>>>> This includes DDD emulated by HHH and HHH emulating >>>>>>>>>>>>>>> itself emulating DDD one or more times.
Irrelevant. The meaning of "DDD" in a C expresssion does not depend on its
immediate context.
The meaning of a C function translated into x86
machine code is the meaning of this x86 machine code. >>>>>>>>>>>>
But the meaning of DDD in the C expression does not depend on its >>>>>>>>>>>> immediate context. The x86 codes pointed to in the two calls are >>>>>>>>>>>> identical or at least semantically equivalent so they specify the >>>>>>>>>>>> same behaviour.
Independently of above considerations the meaning of DDD is the same
in Simulate(DDD) and HHH(DDD).
This ChatGPT analysis of its input below
correctly derives both of our views.
Whatever ChatGPT says is irrelevant. If you can't defend your claims >>>>>>>>>> then your claims are undefencible.
I can and have proven my claims are verified facts:
https://github.com/plolcott/x86utm/blob/master/Halt7.c
and people disagreed anyway.
No, you have not. You have claimed that you have prooven but that is >>>>>>>> not the same. Perhaps you don't know what a proof is but it certainly >>>>>>>> is very different from anything you have ever presented.
*A proof is any sequence of steps deriving a necessary result*
https://github.com/plolcott/x86utm/blob/master/Halt7.c
No, it is not. There are additional requirements for each step. The >>>>>> sequence is a proof only if those additional requirements are satisfied. >>>>>> From a practical point of view, the purpose of a proof is to convince, >>>>>> so what does not convince is not a proof.
Proves that HHH does correctly emulate DDD then correctly
emulates itself emulating DDD.
No, it does not. The presentation is not convincing about anything >>>>>> and does not satisfy the requirements ot a proof.
The actual execution trace of DDD emulated by HHH
and DDD emulated by an emulated HHH does prove that
DDD has been correctly emulated by an emulated HHH.
No, it only provides materila for a proof that a part of DDD has been
correctly emulated. The emulation is not continied to the point where
it is obvious that HHH is not a decider. From inspection of the code
of DDD we can see that if DDD does not halt then HHH is not a decider. >>>>
void DDD()
{
HHH(DDD);
return;
}
When HHH(DDD) simulates ten instructions of DDD is 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)
Are you trying to say that HHH is stuck in a loop and therefore
never returns?
I repeated the pattern ten times so that people can
notice that there really is a non-terminating pattern.
On 8/1/2025 12:19 PM, Richard Damon wrote:
On 8/1/25 12:58 PM, olcott wrote:
On 8/1/2025 11:51 AM, Mr Flibble wrote:
On Fri, 01 Aug 2025 11:33:51 -0500, olcott wrote:
On 8/1/2025 11:29 AM, Mr Flibble wrote:
On Fri, 01 Aug 2025 11:22:45 -0500, olcott wrote:
On 8/1/2025 11:03 AM, joes wrote:
Am Fri, 01 Aug 2025 10:54:52 -0500 schrieb olcott>> When people >>>>>>>> makeWhen I tell Richard the exact same thing 500 times he continues to >>>>>>> respond as it I never said it.
sure to fail to notice the key elements of my key
points it has been proven that these key elements must be repeated >>>>>>>>> until someone bothers to pay attention.
That's not how it works. I skim over repetitions.
I kept telling Richard the HHH does simulate an instance itself
emulating an instance of DDD and can do this because HHH and DDD are >>>>>>> in the same global memory space of Halt7.obj.
Richard keeps saying That HHH cannot simulate an instance of itself >>>>>>> because it does not have access to this memory. I corrected him 20 >>>>>>> times on this and he still does not get it.
DDD can analyse a COPY of HHH, lets call it HHH', and through
simulation or some other means do the opposite of what HHH' decides >>>>>> (given HHH' must halt with a decision because HHH must halt with a >>>>>> decision).
/Flibble
Yet that makes the details more difficult to understand.
We must do that in the Linz proof. Whereas with my DDD/HHH proof any C >>>>> programmer knowing what recursion is can see the repeating pattern.
There isn't a repeated pattern because there isn't any recursion:
DDD can
*analyse* HHH without *executing* HHH because it can use a COPY of HHH >>>> using whatever representation it deems appropriate.
/Flibble
One of the problems with static analysis of code
is that it may not ignore unreachable code.
Analysis by a simulating halt decider never even
sees this unreachable code. It only pays attention
to the code in its actual execution trace.
But the code isn't "unreachable", only not reached by the partial
simulation that the decider did.
Anyone with slight C programming experience can see
the repeating pattern that cannot possibly reach its
own simulated final halt state.
On 8/2/2025 4:09 AM, Mikko wrote:
On 2025-08-01 15:01:54 +0000, olcott said:
On 8/1/2025 1:55 AM, Mikko wrote:
On 2025-07-31 15:55:25 +0000, olcott said:
On 7/31/2025 3:34 AM, Mikko wrote:
On 2025-07-30 15:32:39 +0000, olcott said:
On 7/30/2025 1:50 AM, Mikko wrote:
On 2025-07-29 20:53:54 +0000, olcott said:
On 7/29/2025 1:37 AM, Mikko wrote:
On 2025-07-28 12:42:24 +0000, olcott said:
On 7/28/2025 2:50 AM, Mikko wrote:
On 2025-07-27 14:39:45 +0000, olcott said:
On 7/27/2025 2:36 AM, Mikko wrote:
On 2025-07-26 16:21:19 +0000, olcott said:
On 7/26/2025 2:28 AM, Mikko wrote:Only because the C compiler attempts to preserve the >>>>>>>>>>>>>> meaning. The
On 2025-07-25 15:54:06 +0000, olcott said:
On 7/25/2025 2:43 AM, Mikko wrote:
On 2025-07-24 21:18:32 +0000, olcott said: >>>>>>>>>>>>>>>>>>*Correctly emulated is defined as*
On 7/24/2025 4:02 PM, joes wrote:That you don't understand something does not mean that >>>>>>>>>>>>>>>>>> it is not
Am Thu, 24 Jul 2025 09:11:44 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>>>>> On 7/24/2025 5:07 AM, joes wrote:
Yes, it is. And that can obviously be computed by a >>>>>>>>>>>>>>>>>>>> processor, a UTMAm Wed, 23 Jul 2025 16:08:51 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>>>>>>> On 7/23/2025 3:56 PM, joes wrote:
int Simulate(ptr x)If HHH (which aborts) was given to a UTM/pure >>>>>>>>>>>>>>>>>>>>>> simulator, it would stopOf course, and then it incorrectly assumes that >>>>>>>>>>>>>>>>>>>>>>>> an unabortedIf HHH(DDD) never aborts its simulation then this >>>>>>>>>>>>>>>>>>>>>>> HHH never stops
simulation *of this HHH*, which does in fact >>>>>>>>>>>>>>>>>>>>>>>> abort, wouldn't abort.
running.
running.
{
x(); return 1;
}
It is the behavior of the input to HHH(DDD) that >>>>>>>>>>>>>>>>>>>>> HHH is supposed to
measure.
It is not the behavior of the input to >>>>>>>>>>>>>>>>>>>>> Simulate(DDD) that HHH is
supposed to measure.
It is also not the behavior of the directly >>>>>>>>>>>>>>>>>>>>> executed DDD() that HHH is
supposed to measure.
or any simulator that doesn't abort before the HHH >>>>>>>>>>>>>>>>>>>> called by DDD does -
which HHH logically cannot do.
HHH(DDD) is only supposed to measure the behavior >>>>>>>>>>>>>>>>>>>>> of its own input.Do you understand that it trivially produces the >>>>>>>>>>>>>>>>>>>> same result as the
value that it returns?
It has been three years and still not one person >>>>>>>>>>>>>>>>>>>>> has understood that the
behavior of an input that calls its own simulator >>>>>>>>>>>>>>>>>>>>> is not the same as the
behavior of an input that does not call its own >>>>>>>>>>>>>>>>>>>>> simulator.
It is well understood that HHH does not simulate DDD >>>>>>>>>>>>>>>>>>>> the same way as the
direct execution. DDD doesn't even have an "own >>>>>>>>>>>>>>>>>>>> simulator", it is just
a program that you want to simulate using the >>>>>>>>>>>>>>>>>>>> simulator it happens to
call.
What has never been understood (even now) is that >>>>>>>>>>>>>>>>>>> Simulate(DDD) is presented with a different sequence >>>>>>>>>>>>>>>>>>> of x86 instructions than HHH(DDD) is presented with. >>>>>>>>>>>>>>>>>>
understood. Everyone other than you understand that if >>>>>>>>>>>>>>>>>> DDD in
Simulate(DDD) is not the same as DDD in HHH(DDD) then >>>>>>>>>>>>>>>>>> one of them
was given a false name (and perhaps the other, too). >>>>>>>>>>>>>>>>>
Emulated according to the rules of the x86 language. >>>>>>>>>>>>>>>>> This includes DDD emulated by HHH and HHH emulating >>>>>>>>>>>>>>>>> itself emulating DDD one or more times.
Irrelevant. The meaning of "DDD" in a C expresssion does >>>>>>>>>>>>>>>> not depend on its
immediate context.
The meaning of a C function translated into x86
machine code is the meaning of this x86 machine code. >>>>>>>>>>>>>>
definitions of the meanings are distinct (except for >>>>>>>>>>>>>> assembly code
insertinos that the compiler permits as a lnaguage >>>>>>>>>>>>>> extension).
But the meaning of DDD in the C expression does not depend >>>>>>>>>>>>>> on its
immediate context. The x86 codes pointed to in the two >>>>>>>>>>>>>> calls are
identical or at least semantically equivalent so they >>>>>>>>>>>>>> specify the
same behaviour.
Independently of above considerations the meaning of DDD >>>>>>>>>>>>>> is the same
in Simulate(DDD) and HHH(DDD).
This ChatGPT analysis of its input below
correctly derives both of our views.
Whatever ChatGPT says is irrelevant. If you can't defend >>>>>>>>>>>> your claims
then your claims are undefencible.
I can and have proven my claims are verified facts:
https://github.com/plolcott/x86utm/blob/master/Halt7.c
and people disagreed anyway.
No, you have not. You have claimed that you have prooven but >>>>>>>>>> that is
not the same. Perhaps you don't know what a proof is but it >>>>>>>>>> certainly
is very different from anything you have ever presented.
*A proof is any sequence of steps deriving a necessary result* >>>>>>>>> https://github.com/plolcott/x86utm/blob/master/Halt7.c
No, it is not. There are additional requirements for each step. The >>>>>>>> sequence is a proof only if those additional requirements are
satisfied.
From a practical point of view, the purpose of a proof is to
convince,
so what does not convince is not a proof.
Proves that HHH does correctly emulate DDD then correctly
emulates itself emulating DDD.
No, it does not. The presentation is not convincing about anything >>>>>>>> and does not satisfy the requirements ot a proof.
The actual execution trace of DDD emulated by HHH
and DDD emulated by an emulated HHH does prove that
DDD has been correctly emulated by an emulated HHH.
No, it only provides materila for a proof that a part of DDD has been >>>>>> correctly emulated. The emulation is not continied to the point where >>>>>> it is obvious that HHH is not a decider. From inspection of the code >>>>>> of DDD we can see that if DDD does not halt then HHH is not a
decider.
void DDD()
{
HHH(DDD);
return;
}
When HHH(DDD) simulates ten instructions of DDD is 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)
Are you trying to say that HHH is stuck in a loop and therefore
never returns?
I repeated the pattern ten times so that people can
notice that there really is a non-terminating pattern.
Your HHH does not repeat that pattern ten times. But that is not
relevant. Any finite number is finite. HHH returns and so does
DDD.
I have never been taking about directly executed DDD.
I have only been talking about DDD correctly simulated by HHH.
Because Turing machines can only report on behavior specified
by finite string inputs and cannot report on directly executed
non-inputs we can ignore the behavior of the direct execution
as outside of the domain of HHH.
On 8/2/2025 4:09 AM, Mikko wrote:
On 2025-08-01 15:01:54 +0000, olcott said:
On 8/1/2025 1:55 AM, Mikko wrote:
On 2025-07-31 15:55:25 +0000, olcott said:
On 7/31/2025 3:34 AM, Mikko wrote:
On 2025-07-30 15:32:39 +0000, olcott said:
On 7/30/2025 1:50 AM, Mikko wrote:
On 2025-07-29 20:53:54 +0000, olcott said:
On 7/29/2025 1:37 AM, Mikko wrote:
On 2025-07-28 12:42:24 +0000, olcott said:
On 7/28/2025 2:50 AM, Mikko wrote:
On 2025-07-27 14:39:45 +0000, olcott said:
On 7/27/2025 2:36 AM, Mikko wrote:
On 2025-07-26 16:21:19 +0000, olcott said:
On 7/26/2025 2:28 AM, Mikko wrote:Only because the C compiler attempts to preserve the meaning. The
On 2025-07-25 15:54:06 +0000, olcott said:
On 7/25/2025 2:43 AM, Mikko wrote:
On 2025-07-24 21:18:32 +0000, olcott said: >>>>>>>>>>>>>>>>>>*Correctly emulated is defined as*
On 7/24/2025 4:02 PM, joes wrote:That you don't understand something does not mean that it is not
Am Thu, 24 Jul 2025 09:11:44 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>>>>> On 7/24/2025 5:07 AM, joes wrote:
Yes, it is. And that can obviously be computed by a processor, a UTMAm Wed, 23 Jul 2025 16:08:51 -0500 schrieb olcott: >>>>>>>>>>>>>>>>>>>>>>> On 7/23/2025 3:56 PM, joes wrote:
int Simulate(ptr x)If HHH (which aborts) was given to a UTM/pure simulator, it would stopOf course, and then it incorrectly assumes that an unabortedIf HHH(DDD) never aborts its simulation then this HHH never stops
simulation *of this HHH*, which does in fact abort, wouldn't abort.
running.
running.
{
x(); return 1;
}
It is the behavior of the input to HHH(DDD) that HHH is supposed to
measure.
It is not the behavior of the input to Simulate(DDD) that HHH is
supposed to measure.
It is also not the behavior of the directly executed DDD() that HHH is
supposed to measure.
or any simulator that doesn't abort before the HHH called by DDD does -
which HHH logically cannot do.
HHH(DDD) is only supposed to measure the behavior of its own input.Do you understand that it trivially produces the same result as the
value that it returns?
It has been three years and still not one person has understood that the
behavior of an input that calls its own simulator is not the same as the
behavior of an input that does not call its own simulator.
It is well understood that HHH does not simulate DDD the same way as the
direct execution. DDD doesn't even have an "own simulator", it is just
a program that you want to simulate using the simulator it happens to
call.
What has never been understood (even now) is that >>>>>>>>>>>>>>>>>>> Simulate(DDD) is presented with a different sequence >>>>>>>>>>>>>>>>>>> of x86 instructions than HHH(DDD) is presented with. >>>>>>>>>>>>>>>>>>
understood. Everyone other than you understand that if DDD in
Simulate(DDD) is not the same as DDD in HHH(DDD) then one of them
was given a false name (and perhaps the other, too). >>>>>>>>>>>>>>>>>
Emulated according to the rules of the x86 language. >>>>>>>>>>>>>>>>> This includes DDD emulated by HHH and HHH emulating >>>>>>>>>>>>>>>>> itself emulating DDD one or more times.
Irrelevant. The meaning of "DDD" in a C expresssion does not depend on its
immediate context.
The meaning of a C function translated into x86
machine code is the meaning of this x86 machine code. >>>>>>>>>>>>>>
definitions of the meanings are distinct (except for assembly code
insertinos that the compiler permits as a lnaguage extension). >>>>>>>>>>>>>>
But the meaning of DDD in the C expression does not depend on its
immediate context. The x86 codes pointed to in the two calls are >>>>>>>>>>>>>> identical or at least semantically equivalent so they specify the
same behaviour.
Independently of above considerations the meaning of DDD is the same
in Simulate(DDD) and HHH(DDD).
This ChatGPT analysis of its input below
correctly derives both of our views.
Whatever ChatGPT says is irrelevant. If you can't defend your claims
then your claims are undefencible.
I can and have proven my claims are verified facts:
https://github.com/plolcott/x86utm/blob/master/Halt7.c
and people disagreed anyway.
No, you have not. You have claimed that you have prooven but that is >>>>>>>>>> not the same. Perhaps you don't know what a proof is but it certainly
is very different from anything you have ever presented.
*A proof is any sequence of steps deriving a necessary result* >>>>>>>>> https://github.com/plolcott/x86utm/blob/master/Halt7.c
No, it is not. There are additional requirements for each step. The >>>>>>>> sequence is a proof only if those additional requirements are satisfied.
From a practical point of view, the purpose of a proof is to convince, >>>>>>>> so what does not convince is not a proof.
Proves that HHH does correctly emulate DDD then correctly
emulates itself emulating DDD.
No, it does not. The presentation is not convincing about anything >>>>>>>> and does not satisfy the requirements ot a proof.
The actual execution trace of DDD emulated by HHH
and DDD emulated by an emulated HHH does prove that
DDD has been correctly emulated by an emulated HHH.
No, it only provides materila for a proof that a part of DDD has been >>>>>> correctly emulated. The emulation is not continied to the point where >>>>>> it is obvious that HHH is not a decider. From inspection of the code >>>>>> of DDD we can see that if DDD does not halt then HHH is not a decider. >>>>>>
void DDD()
{
HHH(DDD);
return;
}
When HHH(DDD) simulates ten instructions of DDD is 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)
Are you trying to say that HHH is stuck in a loop and therefore
never returns?
I repeated the pattern ten times so that people can
notice that there really is a non-terminating pattern.
Your HHH does not repeat that pattern ten times. But that is not
relevant. Any finite number is finite. HHH returns and so does
DDD.
I have never been taking about directly executed DDD.
I have only been talking about DDD correctly simulated by HHH.
Because Turing machines can only report on behavior specified
by finite string inputs and cannot report on directly executed
non-inputs we can ignore the behavior of the direct execution
as outside of the domain of HHH.
On 8/6/2025 6:32 AM, Richard Damon wrote:
On 8/6/25 7:17 AM, olcott wrote:
On 8/6/2025 2:05 AM, Mikko wrote:
On 2025-08-05 14:08:27 +0000, olcott said:
On 8/5/2025 1:58 AM, Mikko wrote:
On 2025-08-04 13:26:48 +0000, olcott said:I made no mistake.
On 8/4/2025 2:44 AM, Mikko wrote:
On 2025-08-03 13:46:50 +0000, olcott said:
On 8/3/2025 2:41 AM, Mikko wrote:
On 2025-08-02 13:59:35 +0000, olcott said:
On 8/2/2025 4:09 AM, Mikko wrote:
Your HHH does not repeat that pattern ten times. But that is >>>>>>>>>>>> not
relevant. Any finite number is finite. HHH returns and so does >>>>>>>>>>>> DDD.
I have never been taking about directly executed DDD.
True, but everything you said about DDD simulated by HHH is >>>>>>>>>> equally
false or true about the directly executed DDD because DDD
simulated
by HHH is the same DDD as the directly executed DDD.
It only seems that way when you make sure to hardly pay
any attention at all. (see my other reply).
Wrong. What is obvious from the meaning of the words does not
become
false when paying more attention.
_D4()
[000021c3] 55 push ebp
[000021c4] 8bec mov ebp,esp
[000021c6] 68c3210000 push 000021c3 // push D4
[000021cb] e8f3f3ffff call 000015c3 // call HHH
[000021d0] 83c404 add esp,+04
[000021d3] 5d pop ebp
[000021d4] c3 ret
Size in bytes:(0018) [000021d4]
D4 correctly emulated by HHH cannot possibly get
past its own machine address [000021cb] thus the
input to HHH(D4) does specify non-halting behavior
no matter what the D4() that is not an input does.
Nice to see that you don't disagree with my comment about your error. >>>>>
The input to HHH(DDD) specifies the non halting behavior
of recursive emulation and DDD() halts.
I didn't say "mistake", I said "error". Your error was a mistake
only if you later think it was.
HHH(DDD)==0 is correct.
Nope, becuase DDD() returns,
When we report on the basis of the behavior that the
input to HHH(DDD) specifies then HHH(DDD)==0 is correct.
A partial simulation of DDD by HHH proves that DDD
simulated by HHH cannot possibly halt.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt.
It has always been incorrect to require
Ĥ.embedded_H to report on its own behavior.
On 8/6/2025 2:05 AM, Mikko wrote:
On 2025-08-05 14:08:27 +0000, olcott said:
On 8/5/2025 1:58 AM, Mikko wrote:
On 2025-08-04 13:26:48 +0000, olcott said:
On 8/4/2025 2:44 AM, Mikko wrote:
On 2025-08-03 13:46:50 +0000, olcott said:
On 8/3/2025 2:41 AM, Mikko wrote:
On 2025-08-02 13:59:35 +0000, olcott said:
On 8/2/2025 4:09 AM, Mikko wrote:
Your HHH does not repeat that pattern ten times. But that is not >>>>>>>>>> relevant. Any finite number is finite. HHH returns and so does >>>>>>>>>> DDD.
I have never been taking about directly executed DDD.
True, but everything you said about DDD simulated by HHH is equally >>>>>>>> false or true about the directly executed DDD because DDD simulated >>>>>>>> by HHH is the same DDD as the directly executed DDD.
It only seems that way when you make sure to hardly pay
any attention at all. (see my other reply).
Wrong. What is obvious from the meaning of the words does not become >>>>>> false when paying more attention.
_D4()
[000021c3] 55 push ebp
[000021c4] 8bec mov ebp,esp
[000021c6] 68c3210000 push 000021c3 // push D4
[000021cb] e8f3f3ffff call 000015c3 // call HHH
[000021d0] 83c404 add esp,+04
[000021d3] 5d pop ebp
[000021d4] c3 ret
Size in bytes:(0018) [000021d4]
D4 correctly emulated by HHH cannot possibly get
past its own machine address [000021cb] thus the
input to HHH(D4) does specify non-halting behavior
no matter what the D4() that is not an input does.
Nice to see that you don't disagree with my comment about your error.
I made no mistake.
The input to HHH(DDD) specifies the non halting behavior
of recursive emulation and DDD() halts.
I didn't say "mistake", I said "error". Your error was a mistake
only if you later think it was.
HHH(DDD)==0 is correct.
On 8/7/2025 2:30 AM, Mikko wrote:
On 2025-08-06 11:17:40 +0000, olcott said:
On 8/6/2025 2:05 AM, Mikko wrote:
On 2025-08-05 14:08:27 +0000, olcott said:
On 8/5/2025 1:58 AM, Mikko wrote:
On 2025-08-04 13:26:48 +0000, olcott said:I made no mistake.
On 8/4/2025 2:44 AM, Mikko wrote:
On 2025-08-03 13:46:50 +0000, olcott said:
On 8/3/2025 2:41 AM, Mikko wrote:
On 2025-08-02 13:59:35 +0000, olcott said:
On 8/2/2025 4:09 AM, Mikko wrote:
Your HHH does not repeat that pattern ten times. But that is >>>>>>>>>>>> not
relevant. Any finite number is finite. HHH returns and so does >>>>>>>>>>>> DDD.
I have never been taking about directly executed DDD.
True, but everything you said about DDD simulated by HHH is >>>>>>>>>> equally
false or true about the directly executed DDD because DDD
simulated
by HHH is the same DDD as the directly executed DDD.
It only seems that way when you make sure to hardly pay
any attention at all. (see my other reply).
Wrong. What is obvious from the meaning of the words does not
become
false when paying more attention.
_D4()
[000021c3] 55 push ebp
[000021c4] 8bec mov ebp,esp
[000021c6] 68c3210000 push 000021c3 // push D4
[000021cb] e8f3f3ffff call 000015c3 // call HHH
[000021d0] 83c404 add esp,+04
[000021d3] 5d pop ebp
[000021d4] c3 ret
Size in bytes:(0018) [000021d4]
D4 correctly emulated by HHH cannot possibly get
past its own machine address [000021cb] thus the
input to HHH(D4) does specify non-halting behavior
no matter what the D4() that is not an input does.
Nice to see that you don't disagree with my comment about your error. >>>>>
The input to HHH(DDD) specifies the non halting behavior
of recursive emulation and DDD() halts.
I didn't say "mistake", I said "error". Your error was a mistake
only if you later think it was.
HHH(DDD)==0 is correct.
Maybe for some purposes but not as an answer to the question
"does DDD() halt".
OK we are finally getting somewhere.
The question really never has been does DDD() halt.
The question has always been: Does the input to HHH(DDD)
specify a halting sequence of configurations?
On 8/7/25 8:54 AM, olcott wrote:
OK we are finally getting somewhere.
The question really never has been does DDD() halt.
The question has always been: Does the input to HHH(DDD)
specify a halting sequence of configurations?
No, the Halting Problem has ALWAYS been about does DDD halt.
On 8/7/2025 2:30 AM, Mikko wrote:
On 2025-08-06 11:17:40 +0000, olcott said:
On 8/6/2025 2:05 AM, Mikko wrote:
On 2025-08-05 14:08:27 +0000, olcott said:
On 8/5/2025 1:58 AM, Mikko wrote:
On 2025-08-04 13:26:48 +0000, olcott said:I made no mistake.
On 8/4/2025 2:44 AM, Mikko wrote:
On 2025-08-03 13:46:50 +0000, olcott said:
On 8/3/2025 2:41 AM, Mikko wrote:
On 2025-08-02 13:59:35 +0000, olcott said:
On 8/2/2025 4:09 AM, Mikko wrote:
Your HHH does not repeat that pattern ten times. But that is not >>>>>>>>>>>> relevant. Any finite number is finite. HHH returns and so does >>>>>>>>>>>> DDD.
I have never been taking about directly executed DDD.
True, but everything you said about DDD simulated by HHH is equally >>>>>>>>>> false or true about the directly executed DDD because DDD simulated >>>>>>>>>> by HHH is the same DDD as the directly executed DDD.
It only seems that way when you make sure to hardly pay
any attention at all. (see my other reply).
Wrong. What is obvious from the meaning of the words does not become >>>>>>>> false when paying more attention.
_D4()
[000021c3] 55 push ebp
[000021c4] 8bec mov ebp,esp
[000021c6] 68c3210000 push 000021c3 // push D4
[000021cb] e8f3f3ffff call 000015c3 // call HHH
[000021d0] 83c404 add esp,+04
[000021d3] 5d pop ebp
[000021d4] c3 ret
Size in bytes:(0018) [000021d4]
D4 correctly emulated by HHH cannot possibly get
past its own machine address [000021cb] thus the
input to HHH(D4) does specify non-halting behavior
no matter what the D4() that is not an input does.
Nice to see that you don't disagree with my comment about your error. >>>>>
The input to HHH(DDD) specifies the non halting behavior
of recursive emulation and DDD() halts.
I didn't say "mistake", I said "error". Your error was a mistake
only if you later think it was.
HHH(DDD)==0 is correct.
Maybe for some purposes but not as an answer to the question
"does DDD() halt".
OK we are finally getting somewhere.
The question really never has been does DDD() halt.
On 8/10/2025 3:00 AM, Mikko wrote:
On 2025-08-07 12:54:09 +0000, olcott said:Claude AI proved why HHH(DD)==0 is correct in terms that any expert C programmer can understand. https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
On 8/7/2025 2:30 AM, Mikko wrote:
On 2025-08-06 11:17:40 +0000, olcott said:
On 8/6/2025 2:05 AM, Mikko wrote:
On 2025-08-05 14:08:27 +0000, olcott said:
On 8/5/2025 1:58 AM, Mikko wrote:
On 2025-08-04 13:26:48 +0000, olcott said:
On 8/4/2025 2:44 AM, Mikko wrote:
On 2025-08-03 13:46:50 +0000, olcott said:
On 8/3/2025 2:41 AM, Mikko wrote:
On 2025-08-02 13:59:35 +0000, olcott said:
On 8/2/2025 4:09 AM, Mikko wrote:True, but everything you said about DDD simulated by HHH is >>>>>>>>>>>> equally false or true about the directly executed DDD because >>>>>>>>>>>> DDD simulated by HHH is the same DDD as the directly executed >>>>>>>>>>>> DDD.
Your HHH does not repeat that pattern ten times. But that >>>>>>>>>>>>>> is not relevant. Any finite number is finite. HHH returns >>>>>>>>>>>>>> and so does DDD.
I have never been taking about directly executed DDD. >>>>>>>>>>>>
It only seems that way when you make sure to hardly pay any >>>>>>>>>>> attention at all. (see my other reply).
Wrong. What is obvious from the meaning of the words does not >>>>>>>>>> become false when paying more attention.
_D4()
[000021c3] 55 push ebp [000021c4] 8bec mov
ebp,esp [000021c6] 68c3210000 push 000021c3 // push D4 >>>>>>>>> [000021cb] e8f3f3ffff call 000015c3 // call HHH [000021d0] >>>>>>>>> 83c404 add esp,+04 [000021d3] 5d pop ebp
[000021d4] c3 ret Size in bytes:(0018) [000021d4]
D4 correctly emulated by HHH cannot possibly get past its own >>>>>>>>> machine address [000021cb] thus the input to HHH(D4) does
specify non-halting behavior no matter what the D4() that is not >>>>>>>>> an input does.
Nice to see that you don't disagree with my comment about your >>>>>>>> error.
I made no mistake.
The input to HHH(DDD) specifies the non halting behavior of
recursive emulation and DDD() halts.
I didn't say "mistake", I said "error". Your error was a mistake
only if you later think it was.
HHH(DDD)==0 is correct.
Maybe for some purposes but not as an answer to the question "does
DDD() halt".
OK we are finally getting somewhere.
The question really never has been does DDD() halt.
Of course not, that question would only be relevant if you would want
to do something related to the halting problem.
As soon as you understand that the above page is totally correct we can
move on to the next step of my proof.
On 8/10/2025 3:00 AM, Mikko wrote:
On 2025-08-07 12:54:09 +0000, olcott said:
On 8/7/2025 2:30 AM, Mikko wrote:
On 2025-08-06 11:17:40 +0000, olcott said:
On 8/6/2025 2:05 AM, Mikko wrote:
On 2025-08-05 14:08:27 +0000, olcott said:
On 8/5/2025 1:58 AM, Mikko wrote:
On 2025-08-04 13:26:48 +0000, olcott said:I made no mistake.
On 8/4/2025 2:44 AM, Mikko wrote:
On 2025-08-03 13:46:50 +0000, olcott said:
On 8/3/2025 2:41 AM, Mikko wrote:
On 2025-08-02 13:59:35 +0000, olcott said:
On 8/2/2025 4:09 AM, Mikko wrote:True, but everything you said about DDD simulated by HHH is equally
Your HHH does not repeat that pattern ten times. But that is not >>>>>>>>>>>>>> relevant. Any finite number is finite. HHH returns and so does >>>>>>>>>>>>>> DDD.
I have never been taking about directly executed DDD. >>>>>>>>>>>>
false or true about the directly executed DDD because DDD simulated
by HHH is the same DDD as the directly executed DDD.
It only seems that way when you make sure to hardly pay
any attention at all. (see my other reply).
Wrong. What is obvious from the meaning of the words does not become >>>>>>>>>> false when paying more attention.
_D4()
[000021c3] 55 push ebp
[000021c4] 8bec mov ebp,esp
[000021c6] 68c3210000 push 000021c3 // push D4
[000021cb] e8f3f3ffff call 000015c3 // call HHH
[000021d0] 83c404 add esp,+04
[000021d3] 5d pop ebp
[000021d4] c3 ret
Size in bytes:(0018) [000021d4]
D4 correctly emulated by HHH cannot possibly get
past its own machine address [000021cb] thus the
input to HHH(D4) does specify non-halting behavior
no matter what the D4() that is not an input does.
Nice to see that you don't disagree with my comment about your error. >>>>>>>
The input to HHH(DDD) specifies the non halting behavior
of recursive emulation and DDD() halts.
I didn't say "mistake", I said "error". Your error was a mistake
only if you later think it was.
HHH(DDD)==0 is correct.
Maybe for some purposes but not as an answer to the question
"does DDD() halt".
OK we are finally getting somewhere.
The question really never has been does DDD() halt.
Of course not, that question would only be relevant if you would
want to do something related to the halting problem.
Claude AI proved why HHH(DD)==0 is correct in terms that
any expert C programmer can understand. https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
On 8/11/2025 1:27 AM, Mikko wrote:
On 2025-08-10 15:26:59 +0000, olcott said:
Claude AI proved why HHH(DD)==0 is correct in terms that
any expert C programmer can understand.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
Hardly relevant as long as you keep reminding that what you are doing
has no connection to the haltning problem.
HHH(DD)==0 is correct proving that the behavior of DD()
doesn't count.
You won't be able to understand why the behavior of DD()
doesn't count until after you understand that HHH(DD)==0
is correct.
On 8/11/2025 1:27 AM, Mikko wrote:
On 2025-08-10 15:26:59 +0000, olcott said:
Claude AI proved why HHH(DD)==0 is correct in terms that
any expert C programmer can understand.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
Hardly relevant as long as you keep reminding that what you are doing
has no connection to the haltning problem.
HHH(DD)==0 is correct proving that the behavior of DD()
doesn't count.
You won't be able to understand why the behavior of DD()
doesn't count until after you understand that HHH(DD)==0
is correct.
On 8/12/2025 3:58 AM, Mikko wrote:
On 2025-08-11 14:27:35 +0000, olcott said:
On 8/11/2025 1:27 AM, Mikko wrote:
On 2025-08-10 15:26:59 +0000, olcott said:
Claude AI proved why HHH(DD)==0 is correct in terms that
any expert C programmer can understand.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
Hardly relevant as long as you keep reminding that what you are doing
has no connection to the haltning problem.
HHH(DD)==0 is correct proving that the behavior of DD()
doesn't count.
Hardly relevant as long as you keep reminding that what you are doing
has co connection to the halting problem.
You won't be able to understand why the behavior of DD()
doesn't count until after you understand that HHH(DD)==0
is correct.
I don't care about is counting or non-counting to something
uninteresting.
The behaviour of DD() matters in the context of the halting problem,
which
is not relevant to this discussion.
DD correctly simulated by HHH cannot possibly halt
because DD calls HHH(DD) in recursive simulation.
On 8/12/2025 3:58 AM, Mikko wrote:
On 2025-08-11 14:27:35 +0000, olcott said:
On 8/11/2025 1:27 AM, Mikko wrote:
On 2025-08-10 15:26:59 +0000, olcott said:
Claude AI proved why HHH(DD)==0 is correct in terms that
any expert C programmer can understand.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
Hardly relevant as long as you keep reminding that what you are doing
has no connection to the haltning problem.
HHH(DD)==0 is correct proving that the behavior of DD()
doesn't count.
Hardly relevant as long as you keep reminding that what you are doing
has co connection to the halting problem.
You won't be able to understand why the behavior of DD()
doesn't count until after you understand that HHH(DD)==0
is correct.
I don't care about is counting or non-counting to something uninteresting. >> The behaviour of DD() matters in the context of the halting problem, which >> is not relevant to this discussion.
DD correctly simulated by HHH cannot possibly halt
because DD calls HHH(DD) in recursive simulation.
On 8/13/2025 3:05 AM, Mikko wrote:
On 2025-08-12 16:37:02 +0000, olcott said:
On 8/12/2025 3:58 AM, Mikko wrote:
On 2025-08-11 14:27:35 +0000, olcott said:
On 8/11/2025 1:27 AM, Mikko wrote:
On 2025-08-10 15:26:59 +0000, olcott said:
Claude AI proved why HHH(DD)==0 is correct in terms that
any expert C programmer can understand.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
Hardly relevant as long as you keep reminding that what you are doing >>>>>> has no connection to the haltning problem.
HHH(DD)==0 is correct proving that the behavior of DD()
doesn't count.
Hardly relevant as long as you keep reminding that what you are doing
has co connection to the halting problem.
You won't be able to understand why the behavior of DD()
doesn't count until after you understand that HHH(DD)==0
is correct.
I don't care about is counting or non-counting to something
uninteresting.
The behaviour of DD() matters in the context of the halting problem,
which
is not relevant to this discussion.
DD correctly simulated by HHH cannot possibly halt
because DD calls HHH(DD) in recursive simulation.
Which is another example of uninteresting and unrelated to the halting
problem.
It proves that the halting problem proof is wrong.
It proves that the halting problem proof does not
prove is undecidability result.
The halting problem may still be undecidable yet
needs a new proof. Every variation of this conventional
proof also fails. Rice's theorem fails.
The halting problem is about all of the behaviour of DD (or some other
computation), not merely about the part correctly simulated by HHH.
DD keeps calling HHH(DD) in recursive simulation
such that no matter what HHH does this simulated
DD cannot possibly reach its own final halt state.
On 8/13/2025 3:05 AM, Mikko wrote:
On 2025-08-12 16:37:02 +0000, olcott said:
On 8/12/2025 3:58 AM, Mikko wrote:
On 2025-08-11 14:27:35 +0000, olcott said:
On 8/11/2025 1:27 AM, Mikko wrote:
On 2025-08-10 15:26:59 +0000, olcott said:
Claude AI proved why HHH(DD)==0 is correct in terms that
any expert C programmer can understand.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
Hardly relevant as long as you keep reminding that what you are doing >>>>>> has no connection to the haltning problem.
HHH(DD)==0 is correct proving that the behavior of DD()
doesn't count.
Hardly relevant as long as you keep reminding that what you are doing
has co connection to the halting problem.
You won't be able to understand why the behavior of DD()
doesn't count until after you understand that HHH(DD)==0
is correct.
I don't care about is counting or non-counting to something uninteresting. >>>> The behaviour of DD() matters in the context of the halting problem, which >>>> is not relevant to this discussion.
DD correctly simulated by HHH cannot possibly halt
because DD calls HHH(DD) in recursive simulation.
Which is another example of uninteresting and unrelated to the halting
problem.
It proves that the halting problem proof is wrong.
It proves that the halting problem proof does not
prove is undecidability result.
The halting problem may still be undecidable yet
needs a new proof.
Every variation of this conventional
proof also fails. Rice's theorem fails.
DD keeps calling HHH(DD) in recursive simulation
such that no matter what HHH does this simulated
DD cannot possibly reach its own final halt state.
On 8/14/2025 4:20 AM, Mikko wrote:
On 2025-08-13 15:27:39 +0000, olcott said:I am correcting an erroneous aspect of the theory of computation. All deciders must only compute the mapping from their finite string input. Anything that is not a finite string input is outside of the scope of
On 8/13/2025 3:05 AM, Mikko wrote:
On 2025-08-12 16:37:02 +0000, olcott said:
On 8/12/2025 3:58 AM, Mikko wrote:
On 2025-08-11 14:27:35 +0000, olcott said:
On 8/11/2025 1:27 AM, Mikko wrote:
On 2025-08-10 15:26:59 +0000, olcott said:
Claude AI proved why HHH(DD)==0 is correct in terms that any >>>>>>>>> expert C programmer can understand.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
Hardly relevant as long as you keep reminding that what you are >>>>>>>> doing has no connection to the haltning problem.
HHH(DD)==0 is correct proving that the behavior of DD() doesn't
count.
Hardly relevant as long as you keep reminding that what you are
doing has co connection to the halting problem.
You won't be able to understand why the behavior of DD()
doesn't count until after you understand that HHH(DD)==0 is
correct.
I don't care about is counting or non-counting to something
uninteresting.
The behaviour of DD() matters in the context of the halting
problem, which is not relevant to this discussion.
DD correctly simulated by HHH cannot possibly halt because DD calls
HHH(DD) in recursive simulation.
Which is another example of uninteresting and unrelated to the
halting problem.
It proves that the halting problem proof is wrong.
No, it does not. The answer returned by HHH(DD) is not the answer
reauired by the halting problem.
It proves that the halting problem proof does not prove is
undecidability result.
No, it does not. And the undecidability of halting is anyway proven by
different proofs.
The halting problem may still be undecidable yet needs a new proof.
A new proof is not needed. There are already proofs that you haven't
even pretended to have refuted.
Every variation of this conventional proof also fails. Rice's theorem
fails.
No, they don't. You have not pointed any error in any of the proofs,
let alone all of them.
DD keeps calling HHH(DD) in recursive simulation such that no matter
what HHH does this simulated DD cannot possibly reach its own final
halt state.
A consequene of which is that HHH fails to be a counter-example to amy
halting problem proof.
any decider.
M.H applied to ⟨M⟩ ⟨M⟩ does correctly report on the behavior ofits
actual input: M applied to ⟨M⟩ is not an actual input to M.H.halt
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.∞
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn
*Repeats until aborted proving non-halting*
(a) M copies its input ⟨M⟩
(b) M invokes M.H ⟨M⟩ ⟨M⟩
(c) M.H simulates ⟨M⟩ ⟨M⟩
then M.H ⟨M⟩ ⟨M⟩ transitions to M.qn causing M applied to ⟨M⟩
On 8/14/2025 1:00 PM, Mr Flibble wrote:
On Thu, 14 Aug 2025 12:24:18 -0500, olcott wrote:
On 8/14/2025 4:20 AM, Mikko wrote:
On 2025-08-13 15:27:39 +0000, olcott said:I am correcting an erroneous aspect of the theory of computation. All
On 8/13/2025 3:05 AM, Mikko wrote:
On 2025-08-12 16:37:02 +0000, olcott said:
On 8/12/2025 3:58 AM, Mikko wrote:
On 2025-08-11 14:27:35 +0000, olcott said:
On 8/11/2025 1:27 AM, Mikko wrote:
On 2025-08-10 15:26:59 +0000, olcott said:
Claude AI proved why HHH(DD)==0 is correct in terms that any >>>>>>>>>>> expert C programmer can understand.Hardly relevant as long as you keep reminding that what you are >>>>>>>>>> doing has no connection to the haltning problem.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c >>>>>>>>>>
HHH(DD)==0 is correct proving that the behavior of DD() doesn't >>>>>>>>> count.
Hardly relevant as long as you keep reminding that what you are >>>>>>>> doing has co connection to the halting problem.
You won't be able to understand why the behavior of DD() doesn't >>>>>>>>> count until after you understand that HHH(DD)==0 is correct.
I don't care about is counting or non-counting to something
uninteresting.
The behaviour of DD() matters in the context of the halting
problem, which is not relevant to this discussion.
DD correctly simulated by HHH cannot possibly halt because DD
calls HHH(DD) in recursive simulation.
Which is another example of uninteresting and unrelated to the
halting problem.
It proves that the halting problem proof is wrong.
No, it does not. The answer returned by HHH(DD) is not the answer
reauired by the halting problem.
It proves that the halting problem proof does not prove is
undecidability result.
No, it does not. And the undecidability of halting is anyway proven
by different proofs.
The halting problem may still be undecidable yet needs a new proof.
A new proof is not needed. There are already proofs that you haven't
even pretended to have refuted.
Every variation of this conventional proof also fails. Rice's
theorem fails.
No, they don't. You have not pointed any error in any of the proofs,
let alone all of them.
DD keeps calling HHH(DD) in recursive simulation such that no matter >>>>> what HHH does this simulated DD cannot possibly reach its own final
halt state.
A consequene of which is that HHH fails to be a counter-example to
amy halting problem proof.
deciders must only compute the mapping from their finite string input.
Anything that is not a finite string input is outside of the scope of
any decider.
But a *description* of DD *is* a finite string.
M.H applied to ⟨M⟩ ⟨M⟩ does correctly report on the behavior ofits
actual input: M applied to ⟨M⟩ is not an actual input to M.H.
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.∞
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn
*Repeats until aborted proving non-halting*
(a) M copies its input ⟨M⟩
(b) M invokes M.H ⟨M⟩ ⟨M⟩
(c) M.H simulates ⟨M⟩ ⟨M⟩
then M.H ⟨M⟩ ⟨M⟩ transitions to M.qn causing M applied to ⟨M⟩ >> halt
But you abort that infinite recursion returning non-halting to its
caller which is DD() and DD() does the opposite thus proving HHH is not
a decider as per the diagonalization proofs.
/Flibble
Yes when you make sure to ignore what I said you will form the "received view" as the default.
DD() is none of the damn business of HHH(DD) because DD() is not a
freaking finite string input to HHH(DD).
On 8/14/2025 4:20 AM, Mikko wrote:
On 2025-08-13 15:27:39 +0000, olcott said:
On 8/13/2025 3:05 AM, Mikko wrote:
On 2025-08-12 16:37:02 +0000, olcott said:
On 8/12/2025 3:58 AM, Mikko wrote:
On 2025-08-11 14:27:35 +0000, olcott said:
On 8/11/2025 1:27 AM, Mikko wrote:
On 2025-08-10 15:26:59 +0000, olcott said:
Claude AI proved why HHH(DD)==0 is correct in terms that
any expert C programmer can understand.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
Hardly relevant as long as you keep reminding that what you are doing >>>>>>>> has no connection to the haltning problem.
HHH(DD)==0 is correct proving that the behavior of DD()
doesn't count.
Hardly relevant as long as you keep reminding that what you are doing >>>>>> has co connection to the halting problem.
You won't be able to understand why the behavior of DD()
doesn't count until after you understand that HHH(DD)==0
is correct.
I don't care about is counting or non-counting to something uninteresting.
The behaviour of DD() matters in the context of the halting problem, which
is not relevant to this discussion.
DD correctly simulated by HHH cannot possibly halt
because DD calls HHH(DD) in recursive simulation.
Which is another example of uninteresting and unrelated to the halting >>>> problem.
It proves that the halting problem proof is wrong.
No, it does not. The answer returned by HHH(DD) is not the answer
reauired by the halting problem.
It proves that the halting problem proof does not
prove is undecidability result.
No, it does not. And the undecidability of halting is anyway proven
by different proofs.
The halting problem may still be undecidable yet
needs a new proof.
A new proof is not needed. There are already proofs that you
haven't even pretended to have refuted.
Every variation of this conventional
proof also fails. Rice's theorem fails.
No, they don't. You have not pointed any error in any of the proofs,
let alone all of them.
DD keeps calling HHH(DD) in recursive simulation
such that no matter what HHH does this simulated
DD cannot possibly reach its own final halt state.
A consequene of which is that HHH fails to be a counter-example to
amy halting problem proof.
I am correcting an erroneous aspect of the theory
of computation.
All deciders must only compute the mapping from their finite string
input. Anything that is not a finite string input is outside of the
scope of any decider.
M.H applied to ⟨M⟩ ⟨M⟩ does correctly report on
the behavior of its actual input: M applied to ⟨M⟩
is not an actual input to M.H.
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.∞
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn
On 8/14/2025 1:00 PM, Mr Flibble wrote:
On Thu, 14 Aug 2025 12:24:18 -0500, olcott wrote:
On 8/14/2025 4:20 AM, Mikko wrote:
On 2025-08-13 15:27:39 +0000, olcott said:I am correcting an erroneous aspect of the theory of computation. All
On 8/13/2025 3:05 AM, Mikko wrote:
On 2025-08-12 16:37:02 +0000, olcott said:
On 8/12/2025 3:58 AM, Mikko wrote:
On 2025-08-11 14:27:35 +0000, olcott said:
On 8/11/2025 1:27 AM, Mikko wrote:
On 2025-08-10 15:26:59 +0000, olcott said:
Claude AI proved why HHH(DD)==0 is correct in terms that any >>>>>>>>>>> expert C programmer can understand.Hardly relevant as long as you keep reminding that what you are >>>>>>>>>> doing has no connection to the haltning problem.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c >>>>>>>>>>
HHH(DD)==0 is correct proving that the behavior of DD() doesn't >>>>>>>>> count.
Hardly relevant as long as you keep reminding that what you are >>>>>>>> doing has co connection to the halting problem.
You won't be able to understand why the behavior of DD()
doesn't count until after you understand that HHH(DD)==0 is
correct.
I don't care about is counting or non-counting to something
uninteresting.
The behaviour of DD() matters in the context of the halting
problem, which is not relevant to this discussion.
DD correctly simulated by HHH cannot possibly halt because DD calls >>>>>>> HHH(DD) in recursive simulation.
Which is another example of uninteresting and unrelated to the
halting problem.
It proves that the halting problem proof is wrong.
No, it does not. The answer returned by HHH(DD) is not the answer
reauired by the halting problem.
It proves that the halting problem proof does not prove is
undecidability result.
No, it does not. And the undecidability of halting is anyway proven by >>>> different proofs.
The halting problem may still be undecidable yet needs a new proof.
A new proof is not needed. There are already proofs that you haven't
even pretended to have refuted.
Every variation of this conventional proof also fails. Rice's theorem >>>>> fails.
No, they don't. You have not pointed any error in any of the proofs,
let alone all of them.
DD keeps calling HHH(DD) in recursive simulation such that no matter >>>>> what HHH does this simulated DD cannot possibly reach its own final
halt state.
A consequene of which is that HHH fails to be a counter-example to amy >>>> halting problem proof.
deciders must only compute the mapping from their finite string input.
Anything that is not a finite string input is outside of the scope of
any decider.
But a *description* of DD *is* a finite string.
its
M.H applied to ⟨M⟩ ⟨M⟩ does correctly report on the behavior of
actual input: M applied to ⟨M⟩ is not an actual input to M.H.
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.∞
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn
*Repeats until aborted proving non-halting*
(a) M copies its input ⟨M⟩
(b) M invokes M.H ⟨M⟩ ⟨M⟩
(c) M.H simulates ⟨M⟩ ⟨M⟩
then M.H ⟨M⟩ ⟨M⟩ transitions to M.qn causing M applied to ⟨M⟩ >> halt
But you abort that infinite recursion returning non-halting to its caller
which is DD() and DD() does the opposite thus proving HHH is not a
decider
as per the diagonalization proofs.
/Flibble
Yes when you make sure to ignore what I said
you will form the "received view" as the default.
DD() is none of the damn business of HHH(DD) because
DD() is not a freaking finite string input to HHH(DD).
On 8/14/2025 1:27 PM, Mr Flibble wrote:
On Thu, 14 Aug 2025 13:23:26 -0500, olcott wrote:
On 8/14/2025 1:00 PM, Mr Flibble wrote:
On Thu, 14 Aug 2025 12:24:18 -0500, olcott wrote:
On 8/14/2025 4:20 AM, Mikko wrote:
On 2025-08-13 15:27:39 +0000, olcott said:I am correcting an erroneous aspect of the theory of computation. All >>>>> deciders must only compute the mapping from their finite string input. >>>>> Anything that is not a finite string input is outside of the scope of >>>>> any decider.
On 8/13/2025 3:05 AM, Mikko wrote:
On 2025-08-12 16:37:02 +0000, olcott said:
On 8/12/2025 3:58 AM, Mikko wrote:
On 2025-08-11 14:27:35 +0000, olcott said:
On 8/11/2025 1:27 AM, Mikko wrote:
On 2025-08-10 15:26:59 +0000, olcott said:
Claude AI proved why HHH(DD)==0 is correct in terms that any >>>>>>>>>>>>> expert C programmer can understand.Hardly relevant as long as you keep reminding that what you are >>>>>>>>>>>> doing has no connection to the haltning problem.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c >>>>>>>>>>>>
HHH(DD)==0 is correct proving that the behavior of DD() doesn't >>>>>>>>>>> count.
Hardly relevant as long as you keep reminding that what you are >>>>>>>>>> doing has co connection to the halting problem.
You won't be able to understand why the behavior of DD() doesn't >>>>>>>>>>> count until after you understand that HHH(DD)==0 is correct. >>>>>>>>>>I don't care about is counting or non-counting to something >>>>>>>>>> uninteresting.
The behaviour of DD() matters in the context of the halting >>>>>>>>>> problem, which is not relevant to this discussion.
DD correctly simulated by HHH cannot possibly halt because DD >>>>>>>>> calls HHH(DD) in recursive simulation.
Which is another example of uninteresting and unrelated to the >>>>>>>> halting problem.
It proves that the halting problem proof is wrong.
No, it does not. The answer returned by HHH(DD) is not the answer
reauired by the halting problem.
It proves that the halting problem proof does not prove is
undecidability result.
No, it does not. And the undecidability of halting is anyway proven >>>>>> by different proofs.
The halting problem may still be undecidable yet needs a new proof. >>>>>>A new proof is not needed. There are already proofs that you haven't >>>>>> even pretended to have refuted.
Every variation of this conventional proof also fails. Rice's
theorem fails.
No, they don't. You have not pointed any error in any of the proofs, >>>>>> let alone all of them.
DD keeps calling HHH(DD) in recursive simulation such that no matter >>>>>>> what HHH does this simulated DD cannot possibly reach its own final >>>>>>> halt state.
A consequene of which is that HHH fails to be a counter-example to >>>>>> amy halting problem proof.
But a *description* of DD *is* a finite string.
M.H applied to ⟨M⟩ ⟨M⟩ does correctly report on the behavior of >>>> its
actual input: M applied to ⟨M⟩ is not an actual input to M.H.
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.∞
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn
*Repeats until aborted proving non-halting*
(a) M copies its input ⟨M⟩
(b) M invokes M.H ⟨M⟩ ⟨M⟩
(c) M.H simulates ⟨M⟩ ⟨M⟩
then M.H ⟨M⟩ ⟨M⟩ transitions to M.qn causing M applied to ⟨M⟩ >>>> halt
But you abort that infinite recursion returning non-halting to its
caller which is DD() and DD() does the opposite thus proving HHH is not >>>> a decider as per the diagonalization proofs.
/Flibble
Yes when you make sure to ignore what I said you will form the "received >>> view" as the default.
DD() is none of the damn business of HHH(DD) because DD() is not a
freaking finite string input to HHH(DD).
If DD passed to HHH is not a *description* of DD then your entire
approach
is wrong.
/Flibble
It is a verified fact that everyone very diligently
makes sure to ignore or contradicts the verified
fact that DD correctly simulated by HHH cannot
possibly reach its own final halt state.
This is the behavior that HHH must report on and the
directly executed DD() is behavior that HHH must not
report on.
On 8/15/2025 3:41 AM, Mikko wrote:
On 2025-08-14 17:24:18 +0000, olcott said:
On 8/14/2025 4:20 AM, Mikko wrote:
On 2025-08-13 15:27:39 +0000, olcott said:
On 8/13/2025 3:05 AM, Mikko wrote:
On 2025-08-12 16:37:02 +0000, olcott said:
On 8/12/2025 3:58 AM, Mikko wrote:
On 2025-08-11 14:27:35 +0000, olcott said:
On 8/11/2025 1:27 AM, Mikko wrote:
On 2025-08-10 15:26:59 +0000, olcott said:
Hardly relevant as long as you keep reminding that what you >>>>>>>>>> are doing
Claude AI proved why HHH(DD)==0 is correct in terms that >>>>>>>>>>> any expert C programmer can understand.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c >>>>>>>>>>
has no connection to the haltning problem.
HHH(DD)==0 is correct proving that the behavior of DD()
doesn't count.
Hardly relevant as long as you keep reminding that what you are >>>>>>>> doing
has co connection to the halting problem.
You won't be able to understand why the behavior of DD()
doesn't count until after you understand that HHH(DD)==0
is correct.
I don't care about is counting or non-counting to something
uninteresting.
The behaviour of DD() matters in the context of the halting
problem, which
is not relevant to this discussion.
DD correctly simulated by HHH cannot possibly halt
because DD calls HHH(DD) in recursive simulation.
Which is another example of uninteresting and unrelated to the
halting
problem.
It proves that the halting problem proof is wrong.
No, it does not. The answer returned by HHH(DD) is not the answer
reauired by the halting problem.
It proves that the halting problem proof does not
prove is undecidability result.
No, it does not. And the undecidability of halting is anyway proven
by different proofs.
The halting problem may still be undecidable yet
needs a new proof.
A new proof is not needed. There are already proofs that you
haven't even pretended to have refuted.
Every variation of this conventional
proof also fails. Rice's theorem fails.
No, they don't. You have not pointed any error in any of the proofs,
let alone all of them.
DD keeps calling HHH(DD) in recursive simulation
such that no matter what HHH does this simulated
DD cannot possibly reach its own final halt state.
A consequene of which is that HHH fails to be a counter-example to
amy halting problem proof.
I am correcting an erroneous aspect of the theory
of computation.
To change something correct to something erroneous is not correcting.
All deciders must only compute the mapping from their finite string
input. Anything that is not a finite string input is outside of the
scope of any decider.
Wrong. All deciders must only do what their requirements require.
Sometimes that is expressed as the requirement to solve some
problem.
M.H applied to ⟨M⟩ ⟨M⟩ does correctly report on
the behavior of its actual input: M applied to ⟨M⟩
is not an actual input to M.H.
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.∞
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn
Which means that H is required to be something other than a
halting decider.
Requiring a decider to report on something
that it cannot see has always been incorrect.
On 8/15/2025 3:41 AM, Mikko wrote:
On 2025-08-14 17:24:18 +0000, olcott said:
On 8/14/2025 4:20 AM, Mikko wrote:
On 2025-08-13 15:27:39 +0000, olcott said:
On 8/13/2025 3:05 AM, Mikko wrote:
On 2025-08-12 16:37:02 +0000, olcott said:
On 8/12/2025 3:58 AM, Mikko wrote:
On 2025-08-11 14:27:35 +0000, olcott said:
On 8/11/2025 1:27 AM, Mikko wrote:
On 2025-08-10 15:26:59 +0000, olcott said:
Hardly relevant as long as you keep reminding that what you are doing
Claude AI proved why HHH(DD)==0 is correct in terms that >>>>>>>>>>> any expert C programmer can understand.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c >>>>>>>>>>
has no connection to the haltning problem.
HHH(DD)==0 is correct proving that the behavior of DD()
doesn't count.
Hardly relevant as long as you keep reminding that what you are doing >>>>>>>> has co connection to the halting problem.
You won't be able to understand why the behavior of DD()
doesn't count until after you understand that HHH(DD)==0
is correct.
I don't care about is counting or non-counting to something uninteresting.
The behaviour of DD() matters in the context of the halting problem, which
is not relevant to this discussion.
DD correctly simulated by HHH cannot possibly halt
because DD calls HHH(DD) in recursive simulation.
Which is another example of uninteresting and unrelated to the halting >>>>>> problem.
It proves that the halting problem proof is wrong.
No, it does not. The answer returned by HHH(DD) is not the answer
reauired by the halting problem.
It proves that the halting problem proof does not
prove is undecidability result.
No, it does not. And the undecidability of halting is anyway proven
by different proofs.
The halting problem may still be undecidable yet
needs a new proof.
A new proof is not needed. There are already proofs that you
haven't even pretended to have refuted.
Every variation of this conventional
proof also fails. Rice's theorem fails.
No, they don't. You have not pointed any error in any of the proofs,
let alone all of them.
DD keeps calling HHH(DD) in recursive simulation
such that no matter what HHH does this simulated
DD cannot possibly reach its own final halt state.
A consequene of which is that HHH fails to be a counter-example to
amy halting problem proof.
I am correcting an erroneous aspect of the theory
of computation.
To change something correct to something erroneous is not correcting.
All deciders must only compute the mapping from their finite string
input. Anything that is not a finite string input is outside of the
scope of any decider.
Wrong. All deciders must only do what their requirements require.
Sometimes that is expressed as the requirement to solve some
problem.
M.H applied to ⟨M⟩ ⟨M⟩ does correctly report on
the behavior of its actual input: M applied to ⟨M⟩
is not an actual input to M.H.
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.∞
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn
Which means that H is required to be something other than a
halting decider.
Requiring a decider to report on something
that it cannot see has always been incorrect.
On 8/16/2025 2:37 AM, Mikko wrote:
On 2025-08-15 12:20:05 +0000, olcott said:
On 8/15/2025 3:41 AM, Mikko wrote:
On 2025-08-14 17:24:18 +0000, olcott said:
On 8/14/2025 4:20 AM, Mikko wrote:
On 2025-08-13 15:27:39 +0000, olcott said:
On 8/13/2025 3:05 AM, Mikko wrote:
On 2025-08-12 16:37:02 +0000, olcott said:
On 8/12/2025 3:58 AM, Mikko wrote:
On 2025-08-11 14:27:35 +0000, olcott said:
On 8/11/2025 1:27 AM, Mikko wrote:
On 2025-08-10 15:26:59 +0000, olcott said:
Hardly relevant as long as you keep reminding that what you >>>>>>>>>>>> are doing
Claude AI proved why HHH(DD)==0 is correct in terms that >>>>>>>>>>>>> any expert C programmer can understand.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c >>>>>>>>>>>>
has no connection to the haltning problem.
HHH(DD)==0 is correct proving that the behavior of DD()
doesn't count.
Hardly relevant as long as you keep reminding that what you >>>>>>>>>> are doing
has co connection to the halting problem.
You won't be able to understand why the behavior of DD() >>>>>>>>>>> doesn't count until after you understand that HHH(DD)==0 >>>>>>>>>>> is correct.
I don't care about is counting or non-counting to something >>>>>>>>>> uninteresting.
The behaviour of DD() matters in the context of the halting >>>>>>>>>> problem, which
is not relevant to this discussion.
DD correctly simulated by HHH cannot possibly halt
because DD calls HHH(DD) in recursive simulation.
Which is another example of uninteresting and unrelated to the >>>>>>>> halting
problem.
It proves that the halting problem proof is wrong.
No, it does not. The answer returned by HHH(DD) is not the answer
reauired by the halting problem.
It proves that the halting problem proof does not
prove is undecidability result.
No, it does not. And the undecidability of halting is anyway proven >>>>>> by different proofs.
The halting problem may still be undecidable yet
needs a new proof.
A new proof is not needed. There are already proofs that you
haven't even pretended to have refuted.
Every variation of this conventional
proof also fails. Rice's theorem fails.
No, they don't. You have not pointed any error in any of the proofs, >>>>>> let alone all of them.
DD keeps calling HHH(DD) in recursive simulation
such that no matter what HHH does this simulated
DD cannot possibly reach its own final halt state.
A consequene of which is that HHH fails to be a counter-example to >>>>>> amy halting problem proof.
I am correcting an erroneous aspect of the theory
of computation.
To change something correct to something erroneous is not correcting.
All deciders must only compute the mapping from their finite string
input. Anything that is not a finite string input is outside of the
scope of any decider.
Wrong. All deciders must only do what their requirements require.
Sometimes that is expressed as the requirement to solve some
problem.
M.H applied to ⟨M⟩ ⟨M⟩ does correctly report on
the behavior of its actual input: M applied to ⟨M⟩
is not an actual input to M.H.
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.∞
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn
Which means that H is required to be something other than a
halting decider.
Requiring a decider to report on something
that it cannot see has always been incorrect.
It is not an error to require what would be useful.
HHH(DD)==0 is very useful.
HHH1(DD)==1 is very useful.
HHH(DD)== "no one knows" is not useful.
The only case where the correct simulation of an input
is not the same as its direct execution is when the
input calls its own halt decider. The prior answer
to this is "no one knows"
On 8/16/2025 2:37 AM, Mikko wrote:
On 2025-08-15 12:20:05 +0000, olcott said:
On 8/15/2025 3:41 AM, Mikko wrote:
On 2025-08-14 17:24:18 +0000, olcott said:
On 8/14/2025 4:20 AM, Mikko wrote:
On 2025-08-13 15:27:39 +0000, olcott said:
On 8/13/2025 3:05 AM, Mikko wrote:
On 2025-08-12 16:37:02 +0000, olcott said:
On 8/12/2025 3:58 AM, Mikko wrote:
On 2025-08-11 14:27:35 +0000, olcott said:
On 8/11/2025 1:27 AM, Mikko wrote:
On 2025-08-10 15:26:59 +0000, olcott said:
Hardly relevant as long as you keep reminding that what you are doing
Claude AI proved why HHH(DD)==0 is correct in terms that >>>>>>>>>>>>> any expert C programmer can understand.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c >>>>>>>>>>>>
has no connection to the haltning problem.
HHH(DD)==0 is correct proving that the behavior of DD()
doesn't count.
Hardly relevant as long as you keep reminding that what you are doing
has co connection to the halting problem.
You won't be able to understand why the behavior of DD() >>>>>>>>>>> doesn't count until after you understand that HHH(DD)==0 >>>>>>>>>>> is correct.
I don't care about is counting or non-counting to something uninteresting.
The behaviour of DD() matters in the context of the halting problem, which
is not relevant to this discussion.
DD correctly simulated by HHH cannot possibly halt
because DD calls HHH(DD) in recursive simulation.
Which is another example of uninteresting and unrelated to the halting >>>>>>>> problem.
It proves that the halting problem proof is wrong.
No, it does not. The answer returned by HHH(DD) is not the answer
reauired by the halting problem.
It proves that the halting problem proof does not
prove is undecidability result.
No, it does not. And the undecidability of halting is anyway proven >>>>>> by different proofs.
The halting problem may still be undecidable yet
needs a new proof.
A new proof is not needed. There are already proofs that you
haven't even pretended to have refuted.
Every variation of this conventional
proof also fails. Rice's theorem fails.
No, they don't. You have not pointed any error in any of the proofs, >>>>>> let alone all of them.
DD keeps calling HHH(DD) in recursive simulation
such that no matter what HHH does this simulated
DD cannot possibly reach its own final halt state.
A consequene of which is that HHH fails to be a counter-example to >>>>>> amy halting problem proof.
I am correcting an erroneous aspect of the theory
of computation.
To change something correct to something erroneous is not correcting.
All deciders must only compute the mapping from their finite string
input. Anything that is not a finite string input is outside of the
scope of any decider.
Wrong. All deciders must only do what their requirements require.
Sometimes that is expressed as the requirement to solve some
problem.
M.H applied to ⟨M⟩ ⟨M⟩ does correctly report on
the behavior of its actual input: M applied to ⟨M⟩
is not an actual input to M.H.
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.∞
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn
Which means that H is required to be something other than a
halting decider.
Requiring a decider to report on something
that it cannot see has always been incorrect.
It is not an error to require what would be useful.
HHH(DD)==0 is very useful.
HHH1(DD)==1 is very useful.
HHH(DD)== "no one knows" is not useful.
The only case where the correct simulation of an input
is not the same as its direct execution is when the
input calls its own halt decider. The prior answer
to this is "no one knows"
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 162:25:48 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,057 |
| Messages: | 6,416,501 |