When we disable the abort code so that HHH(DD) is a
pure function of its inputs DD() never stops running.
On 8/27/2025 9:56 PM, Richard Heathfield wrote:
On 28/08/2025 03:24, olcott wrote:
When we disable the abort code so that HHH(DD) is a
pure function of its inputs DD() never stops running.
Taking that at face value, clearly HHH can't report that such
code halts, so it must report that it doesn't halt,
Done! Everything else in the universe has nothing
to do with the behavior that the input to HHH(DD) SPECIFIED!
thus totally irrelevant.
On 8/27/2025 10:33 PM, Richard Heathfield wrote:
On 28/08/2025 04:06, olcott wrote:Everyone with sufficient understanding of Turing
On 8/27/2025 9:56 PM, Richard Heathfield wrote:
On 28/08/2025 03:24, olcott wrote:
When we disable the abort code so that HHH(DD) is a
pure function of its inputs DD() never stops running.
Taking that at face value, clearly HHH can't report that such
code halts, so it must report that it doesn't halt,
Done! Everything else in the universe has nothing
to do with the behavior that the input to HHH(DD) SPECIFIED!
thus totally irrelevant.
Not so.
All that matters is whether DD halts,
machine deciders already knows that they only
compute the mapping from their inputs.
When we disable the abort code so that HHH(DD) is a
pure function of its inputs DD() never stops running.
When we disable the abort code so that HHH(DD) is a
pure function of its inputs DD() never stops running.
Because this change has no effect on the sequence of
steps of DD correctly simulated by HHH it has no
consequence and can be generalized to every HHH/DD pair.
*Best selling author of theory of computation textbooks*
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
would never stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern:
abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
return 1.
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
What value should HHH(DD) correctly return?
<Input to LLM systems>
Five different LLM systems formed a consensus on
the basis of the verified fact that DD correctly
simulated by HHH cannot possibly reach its own
"return" statement final halt state in any finite
number of steps.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
https://chatgpt.com/share/68939ee5-e2f8-8011-837d-438fe8e98b9c
https://grok.com/share/c2hhcmQtMg%3D%3D_810120bb-5ab5-4bf8-af21-
eedd0f09e141
Gemini had to be forced into do not guess mode https://g.co/gemini/share/4f44c883b348
ChatGPT 5.0 had to be forced into do not guess mode https://chatgpt.com/share/68abcbd5-cee4-8011-80d7-93e8385d90d8
When we disable the abort code so that HHH(DD) is a
pure function of its inputs DD() never stops running.
Because this change has no effect on the sequence of
steps of DD correctly simulated by HHH it has no
consequence and can be generalized to every HHH/DD pair.
*Best selling author of theory of computation textbooks*
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
would never stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern:
abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
return 1.
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
What value should HHH(DD) correctly return?
<Input to LLM systems>
Five different LLM systems formed a consensus on
the basis of the verified fact that DD correctly
simulated by HHH cannot possibly reach its own
"return" statement final halt state in any finite
number of steps.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
https://chatgpt.com/share/68939ee5-e2f8-8011-837d-438fe8e98b9c
https://grok.com/share/c2hhcmQtMg%3D%3D_810120bb-5ab5-4bf8-af21-
eedd0f09e141
Gemini had to be forced into do not guess mode https://g.co/gemini/share/4f44c883b348
ChatGPT 5.0 had to be forced into do not guess mode https://chatgpt.com/share/68abcbd5-cee4-8011-80d7-93e8385d90d8
On 8/27/2025 11:29 PM, Richard Heathfield wrote:
On 28/08/2025 04:49, olcott wrote:
On 8/27/2025 10:33 PM, Richard Heathfield wrote:
On 28/08/2025 04:06, olcott wrote:Everyone with sufficient understanding of Turing
On 8/27/2025 9:56 PM, Richard Heathfield wrote:
On 28/08/2025 03:24, olcott wrote:
When we disable the abort code so that HHH(DD) is a
pure function of its inputs DD() never stops running.
Taking that at face value, clearly HHH can't report that
such code halts, so it must report that it doesn't halt,
Done! Everything else in the universe has nothing
to do with the behavior that the input to HHH(DD) SPECIFIED!
thus totally irrelevant.
Not so.
All that matters is whether DD halts,
machine deciders already knows that they only
compute the mapping from their inputs.
Input:
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
*Incorrect the machine code bytes are the input*
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
The first five instructions are as
far as DD simulated by HHH can get.
Whether or not HHH(DD) aborts the
simulation of its input its input specifies non-halting
behavior either way.
On 8/28/2025 9:27 AM, Richard Heathfield wrote:
On 28/08/2025 14:56, olcott wrote:
On 8/27/2025 11:29 PM, Richard Heathfield wrote:
On 28/08/2025 04:49, olcott wrote:
On 8/27/2025 10:33 PM, Richard Heathfield wrote:
On 28/08/2025 04:06, olcott wrote:Everyone with sufficient understanding of Turing
On 8/27/2025 9:56 PM, Richard Heathfield wrote:
On 28/08/2025 03:24, olcott wrote:
When we disable the abort code so that HHH(DD) is a
pure function of its inputs DD() never stops running.
Taking that at face value, clearly HHH can't report that
such code halts, so it must report that it doesn't halt,
Done! Everything else in the universe has nothing
to do with the behavior that the input to HHH(DD) SPECIFIED!
thus totally irrelevant.
Not so.
All that matters is whether DD halts,
machine deciders already knows that they only
compute the mapping from their inputs.
Input:
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
*Incorrect the machine code bytes are the input*
The input is the C function.
Counter-factual
The x86 code gives me a ready made directed graph
of all control flow.
On 8/28/2025 9:59 AM, Richard Heathfield wrote:
On 28/08/2025 15:46, olcott wrote:
<snip>
Whether or not HHH(DD) aborts the
simulation of its input its input specifies non-halting
behavior either way.
On the contrary, by the mere act of calling HHH(DD), DD
*requires* that the simulation must halt.
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
void Infinite_Loop()
{
HERE: goto HERE;
OutputString("I never get here you dumb bunny!\n");
return;
}
These simulations halt too you dumb bunny!
On 8/28/2025 10:07 AM, Richard Heathfield wrote:
On 28/08/2025 16:01, olcott wrote:
On 8/28/2025 9:59 AM, Richard Heathfield wrote:
On 28/08/2025 15:46, olcott wrote:
<snip>
Whether or not HHH(DD) aborts the
simulation of its input its input specifies non-halting
behavior either way.
On the contrary, by the mere act of calling HHH(DD), DD
*requires* that the simulation must halt.
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
Doesn't call HHH(DD).
void Infinite_Loop()
{
HERE: goto HERE;
OutputString("I never get here you dumb bunny!\n");
return;
}
Doesn't call HHH(DD).
These simulations halt too you dumb bunny!
So you cannot reasonably claim that they don't.
Those are examples whether the simulation stops
and the input is non-halting.
HHH correctly determines that its input
does not halt then HHH halts.
On 8/28/2025 10:40 AM, Richard Heathfield wrote:
On 28/08/2025 16:32, olcott wrote:
<snip>
HHH correctly determines that its input
does not halt then HHH halts.
To be clear, then, HHH determines that the *simulation* doesn't
halt, and then *it* stops the simulation.
Not clear enough.
DD correctly simulated by HHH correctly determines
On 8/27/2025 11:29 PM, Richard Heathfield wrote:
On 28/08/2025 04:49, olcott wrote:
On 8/27/2025 10:33 PM, Richard Heathfield wrote:
On 28/08/2025 04:06, olcott wrote:Everyone with sufficient understanding of Turing
On 8/27/2025 9:56 PM, Richard Heathfield wrote:
On 28/08/2025 03:24, olcott wrote:
When we disable the abort code so that HHH(DD) is a
pure function of its inputs DD() never stops running.
Taking that at face value, clearly HHH can't report that such code >>>>>> halts, so it must report that it doesn't halt,
Done! Everything else in the universe has nothing
to do with the behavior that the input to HHH(DD) SPECIFIED!
thus totally irrelevant.
Not so.
All that matters is whether DD halts,
machine deciders already knows that they only
compute the mapping from their inputs.
Input:
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
*Incorrect the machine code bytes are the input*
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
The first five instructions are as
far as DD simulated by HHH can get.
On 8/28/2025 2:41 AM, Mikko wrote:
On 2025-08-28 02:24:06 +0000, olcott said:
When we disable the abort code so that HHH(DD) is a
pure function of its inputs DD() never stops running.
If the abort code is disbled then HHH is no longer HHH.
The change is of no consequence because the behavior of
DD correctly simulated by HHH remains the exact same
sequence of steps. Whether or not HHH(DD) aborts the
simulation of its input its input specifies non-halting
behavior either way.
If DD
calls the original HHH then the new HHH correctly determines
that DD halts. If the DD calls the new HHH then it is no
longfer the DD that the question was asked about, and the
new HHH does not answer at all, so it is not a decider.
It has never been the case that any Turing machine based
halt decider was ever supposed to report on the behavior
of its caller.
On 8/29/2025 2:35 AM, Mikko wrote:
On 2025-08-28 14:46:10 +0000, olcott said:
On 8/28/2025 2:41 AM, Mikko wrote:
On 2025-08-28 02:24:06 +0000, olcott said:
When we disable the abort code so that HHH(DD) is a
pure function of its inputs DD() never stops running.
If the abort code is disbled then HHH is no longer HHH.
The change is of no consequence because the behavior of
DD correctly simulated by HHH remains the exact same
sequence of steps. Whether or not HHH(DD) aborts the
simulation of its input its input specifies non-halting
behavior either way.
No, DD with the real HHH specifies a halting behaviour
as can be verified with a direct execution.
That ignores the fact that DD calls HHH(DD) in
recursive simulation.
On 8/29/2025 2:35 AM, Mikko wrote:
On 2025-08-28 14:46:10 +0000, olcott said:
On 8/28/2025 2:41 AM, Mikko wrote:
On 2025-08-28 02:24:06 +0000, olcott said:
When we disable the abort code so that HHH(DD) is a
pure function of its inputs DD() never stops running.
If the abort code is disbled then HHH is no longer HHH.
The change is of no consequence because the behavior of
DD correctly simulated by HHH remains the exact same
sequence of steps. Whether or not HHH(DD) aborts the
simulation of its input its input specifies non-halting
behavior either way.
No, DD with the real HHH specifies a halting behaviour
as can be verified with a direct execution.
That ignores the fact that DD calls HHH(DD) in
recursive simulation.
On 8/27/2025 11:29 PM, Richard Heathfield wrote:
On 28/08/2025 04:49, olcott wrote:
On 8/27/2025 10:33 PM, Richard Heathfield wrote:
On 28/08/2025 04:06, olcott wrote:Everyone with sufficient understanding of Turing
On 8/27/2025 9:56 PM, Richard Heathfield wrote:
On 28/08/2025 03:24, olcott wrote:
When we disable the abort code so that HHH(DD) is a
pure function of its inputs DD() never stops running.
Taking that at face value, clearly HHH can't report that such code >>>>>> halts, so it must report that it doesn't halt,
Done! Everything else in the universe has nothing
to do with the behavior that the input to HHH(DD) SPECIFIED!
thus totally irrelevant.
Not so.
All that matters is whether DD halts,
machine deciders already knows that they only
compute the mapping from their inputs.
Input:
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
*Incorrect the machine code bytes are the input*
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
The first five instructions are as
far as DD simulated by HHH can get.
On 8/30/2025 5:04 AM, Mikko wrote:
On 2025-08-29 18:11:07 +0000, olcott said:Using the notion of naming conventions proposed by Kaz
On 8/29/2025 2:35 AM, Mikko wrote:
On 2025-08-28 14:46:10 +0000, olcott said:
On 8/28/2025 2:41 AM, Mikko wrote:
On 2025-08-28 02:24:06 +0000, olcott said:
When we disable the abort code so that HHH(DD) is a pure function >>>>>>> of its inputs DD() never stops running.
If the abort code is disbled then HHH is no longer HHH.
The change is of no consequence because the behavior of DD correctly >>>>> simulated by HHH remains the exact same sequence of steps. Whether
or not HHH(DD) aborts the simulation of its input its input
specifies non-halting behavior either way.
No, DD with the real HHH specifies a halting behaviour as can be
verified with a direct execution.
That ignores the fact that DD calls HHH(DD) in recursive simulation.
The real execution of HHH(DD) does not ignore any relevant fact.
DD.exe is executed.
DD.exe calls HHH(DD).exe HHH.exe simulates DD.sim1 DD.sim1 calls
HHH(DD).sim1 HHH.sim1 simulates DD.sim2 DD.sim2 calls HHH(DD).sim2 ...
This would repeat unless aborted if aborted then DD.exe halts
HHH(DD).exe is only being asked about DD.sim1.
HHH cannot be asked about DD.exe
On 8/30/2025 5:04 AM, Mikko wrote:
On 2025-08-29 18:11:07 +0000, olcott said:
On 8/29/2025 2:35 AM, Mikko wrote:
On 2025-08-28 14:46:10 +0000, olcott said:
On 8/28/2025 2:41 AM, Mikko wrote:
On 2025-08-28 02:24:06 +0000, olcott said:
When we disable the abort code so that HHH(DD) is a
pure function of its inputs DD() never stops running.
If the abort code is disbled then HHH is no longer HHH.
The change is of no consequence because the behavior of
DD correctly simulated by HHH remains the exact same
sequence of steps. Whether or not HHH(DD) aborts the
simulation of its input its input specifies non-halting
behavior either way.
No, DD with the real HHH specifies a halting behaviour
as can be verified with a direct execution.
That ignores the fact that DD calls HHH(DD) in
recursive simulation.
The real execution of HHH(DD) does not ignore any relevant fact.
Using the notion of naming conventions proposed by Kaz
DD.exe is executed.
DD.exe calls HHH(DD).exe
HHH.exe simulates DD.sim1
DD.sim1 calls HHH(DD).sim1
HHH.sim1 simulates DD.sim2
DD.sim2 calls HHH(DD).sim2 ... This would repeat unless aborted
if aborted then DD.exe halts
HHH(DD).exe is only being asked about DD.sim1.
HHH cannot be asked about DD.exe
On 8/30/2025 4:13 PM, olcott wrote:
HHH has always been asked about the behavior
specified by its input finite string of x86 code.
Which includes static data.
WE ARE ASSUMING NO STATIC DATA
WE ARE ASSUMING NO STATIC DATA
WE ARE ASSUMING NO STATIC DATA
You just contradicted yourself.
On 8/30/2025 2:49 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <[email protected]> wrote:>>
Using the notion of naming conventions proposed by Kaz
HHH(DD).exe is only being asked about DD.sim1.
HHH cannot be asked about DD.exe
If you move the distinguishing suffixes outside of the expression,
it becomes ambiguous. Does A(B).sim mean that B is simulated
or A and B are both simulated?
I think you want:
// with static fuses being used:
DD_exe is executed
DD_exe calls HHH_exe(DD_exe)
That has always been impossible
HHH has never ever been asked about
the executing process of its caller.
HHH has always been asked about the behavior
specified by its input finite string of x86 code.
WE ARE ASSUMING NO STATIC DATA
WE ARE ASSUMING NO STATIC DATA
WE ARE ASSUMING NO STATIC DATA
HHH(DD) either must recognize the repeating
state by some other means or HHH(DD) never halts.
On 8/30/2025 2:49 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <[email protected]> wrote:>>
Using the notion of naming conventions proposed by Kaz
HHH(DD).exe is only being asked about DD.sim1.
HHH cannot be asked about DD.exe
If you move the distinguishing suffixes outside of the expression,
it becomes ambiguous. Does A(B).sim mean that B is simulated
or A and B are both simulated?
I think you want:
// with static fuses being used:
DD_exe is executed
DD_exe calls HHH_exe(DD_exe)
That has always been impossible
HHH has never ever been asked about
the executing process of its caller.
HHH has always been asked about the behavior
specified by its input finite string of x86 code.
WE ARE ASSUMING NO STATIC DATA
WE ARE ASSUMING NO STATIC DATA
WE ARE ASSUMING NO STATIC DATA
HHH(DD) either must recognize the repeating
state by some other means or HHH(DD) never halts.
On 8/30/2025 2:49 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <[email protected]> wrote:>>
Using the notion of naming conventions proposed by Kaz
HHH(DD).exe is only being asked about DD.sim1.
HHH cannot be asked about DD.exe
If you move the distinguishing suffixes outside of the expression,
it becomes ambiguous. Does A(B).sim mean that B is simulated
or A and B are both simulated?
I think you want:
// with static fuses being used:
DD_exe is executed
DD_exe calls HHH_exe(DD_exe)
That has always been impossible
HHH has never ever been asked about
the executing process of its caller.
HHH has always been asked about the behavior
specified by its input finite string of x86 code.
WE ARE ASSUMING NO STATIC DATA
WE ARE ASSUMING NO STATIC DATA
WE ARE ASSUMING NO STATIC DATA
On 8/30/2025 10:24 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <[email protected]> wrote:
On 8/30/2025 2:49 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <[email protected]> wrote:>>
Using the notion of naming conventions proposed by Kaz
HHH(DD).exe is only being asked about DD.sim1.
HHH cannot be asked about DD.exe
If you move the distinguishing suffixes outside of the expression,
it becomes ambiguous. Does A(B).sim mean that B is simulated
or A and B are both simulated?
I think you want:
// with static fuses being used:
DD_exe is executed
DD_exe calls HHH_exe(DD_exe)
That has always been impossible
HHH has never ever been asked about
the executing process of its caller.
HHH does not have a caller. HHH is a halting decider that someone
proposed.
DD was developed after HHH to show that it's broken;
but HHH was already broken before that.
DD may be developed using a clean-room implementation of the HHH
algorithm; it doesn't call back into the decider that is operating on it
or anything like that.
That's just unnecessary embellishments that you have added.
HHH has always been asked about the behavior
specified by its input finite string of x86 code.
Sure; any string whatsoever.
WE ARE ASSUMING NO STATIC DATA
WE ARE ASSUMING NO STATIC DATA
WE ARE ASSUMING NO STATIC DATA
Then we have only one HHH and one DD in the system; it is not possible
to claim that HHH decides some DD other than that one DD.
An infinite number of HHH/DD pairs is decided this way.
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern:
abort simulation and return 0.
Five LLM systems were smart enough to see this
and return the correct value for HHH so we
On 8/30/2025 11:25 PM, Kaz Kylheku wrote:
But DD does not literally call HHH. That's just a feature in your
appartus; an embellishment that amounts to nothing, and only serves as a
mechanism for perpetrating distracting cheats.
I keep bringing this up that has the same form
and you keep ignoring it.
*From the bottom of page 319 has been adapted to this* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Machine M contains simulating halt decider H *based on a UTM*
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.∞ // accept state
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn // reject state
*Repeats until aborted proving non-halting*
(a) M copies its input ⟨M⟩
On 8/30/2025 10:56 PM, Kaz Kylheku wrote:
On 2025-08-31, olcott <[email protected]> wrote:
On 8/30/2025 10:24 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <[email protected]> wrote:
On 8/30/2025 2:49 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <[email protected]> wrote:>>
Using the notion of naming conventions proposed by Kaz
HHH(DD).exe is only being asked about DD.sim1.
HHH cannot be asked about DD.exe
If you move the distinguishing suffixes outside of the expression, >>>>>> it becomes ambiguous. Does A(B).sim mean that B is simulated
or A and B are both simulated?
I think you want:
// with static fuses being used:
DD_exe is executed
DD_exe calls HHH_exe(DD_exe)
That has always been impossible
HHH has never ever been asked about
the executing process of its caller.
HHH does not have a caller. HHH is a halting decider that someone
proposed.
DD was developed after HHH to show that it's broken;
but HHH was already broken before that.
DD may be developed using a clean-room implementation of the HHH
algorithm; it doesn't call back into the decider that is operating on it >>>> or anything like that.
That's just unnecessary embellishments that you have added.
HHH has always been asked about the behavior
specified by its input finite string of x86 code.
Sure; any string whatsoever.
WE ARE ASSUMING NO STATIC DATA
WE ARE ASSUMING NO STATIC DATA
WE ARE ASSUMING NO STATIC DATA
Then we have only one HHH and one DD in the system; it is not possible >>>> to claim that HHH decides some DD other than that one DD.
An infinite number of HHH/DD pairs is decided this way.
There is only one HHH/DD pair, because HHH and DD must refer to specific
algorithms.
Other pairs must use at least one name that is different, like
HHH1/DD or HHH/DD1 or HH1/DD1, HH2/DD7, ...
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input until: >>> (a) Detects a non-terminating behavior pattern:
abort simulation and return 0.
That's readily contradicted by the diagonal program which
integrates a clean-room implementation of the HHH algorthm,
calls it on itself, obtains the zero, and promptly terminates.
Five LLM systems were smart enough to see this
and return the correct value for HHH so we
Everyone you've discussed with here is also smart enough
to see that a given DD will terminate or not, and identify
the correct halting status.
You still don't get it that HHH is only supposed to
report in the infinitely recursive behavior that its
input specifies and it not supposed to report on the
behavior of its caller: DD called from main().
On 8/30/2025 11:53 PM, Kaz Kylheku wrote:
On 2025-08-31, olcott <[email protected]> wrote:
On 8/30/2025 11:25 PM, Kaz Kylheku wrote:
But DD does not literally call HHH. That's just a feature in
your
appartus; an embellishment that amounts to nothing, and only
serves as a
mechanism for perpetrating distracting cheats.
I keep bringing this up that has the same form
and you keep ignoring it.
I find the Linz approach tedious to follow; it's simply too
much work to
get into it and work out an explanation of how you are
misunderstanding
it and how it has nothing to do with the approach in your x86_utm.
You argued that HHH(DD) is not the same as a
TM and then I show you how it is just like a TM.
On 8/30/2025 5:04 AM, Mikko wrote:
On 2025-08-29 18:11:07 +0000, olcott said:
On 8/29/2025 2:35 AM, Mikko wrote:
On 2025-08-28 14:46:10 +0000, olcott said:
On 8/28/2025 2:41 AM, Mikko wrote:
On 2025-08-28 02:24:06 +0000, olcott said:
When we disable the abort code so that HHH(DD) is a
pure function of its inputs DD() never stops running.
If the abort code is disbled then HHH is no longer HHH.
The change is of no consequence because the behavior of
DD correctly simulated by HHH remains the exact same
sequence of steps. Whether or not HHH(DD) aborts the
simulation of its input its input specifies non-halting
behavior either way.
No, DD with the real HHH specifies a halting behaviour
as can be verified with a direct execution.
That ignores the fact that DD calls HHH(DD) in
recursive simulation.
The real execution of HHH(DD) does not ignore any relevant fact.
Using the notion of naming conventions proposed by Kaz
DD.exe is executed.
DD.exe calls HHH(DD).exe
HHH.exe simulates DD.sim1
DD.sim1 calls HHH(DD).sim1
HHH.sim1 simulates DD.sim2
DD.sim2 calls HHH(DD).sim2 ... This would repeat unless aborted
if aborted then DD.exe halts
HHH(DD).exe is only being asked about DD.sim1.
HHH cannot be asked about DD.exe
On 8/30/2025 10:56 PM, Kaz Kylheku wrote:
On 2025-08-31, olcott <[email protected]> wrote:
On 8/30/2025 10:24 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <[email protected]> wrote:
On 8/30/2025 2:49 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <[email protected]> wrote:>>
Using the notion of naming conventions proposed by Kaz
HHH(DD).exe is only being asked about DD.sim1.
HHH cannot be asked about DD.exe
If you move the distinguishing suffixes outside of the expression, >>>>>> it becomes ambiguous. Does A(B).sim mean that B is simulated
or A and B are both simulated?
I think you want:
// with static fuses being used:
DD_exe is executed
DD_exe calls HHH_exe(DD_exe)
That has always been impossible
HHH has never ever been asked about
the executing process of its caller.
HHH does not have a caller. HHH is a halting decider that someone
proposed.
DD was developed after HHH to show that it's broken;
but HHH was already broken before that.
DD may be developed using a clean-room implementation of the HHH
algorithm; it doesn't call back into the decider that is operating on it >>>> or anything like that.
That's just unnecessary embellishments that you have added.
HHH has always been asked about the behavior
specified by its input finite string of x86 code.
Sure; any string whatsoever.
WE ARE ASSUMING NO STATIC DATA
WE ARE ASSUMING NO STATIC DATA
WE ARE ASSUMING NO STATIC DATA
Then we have only one HHH and one DD in the system; it is not possible >>>> to claim that HHH decides some DD other than that one DD.
An infinite number of HHH/DD pairs is decided this way.
There is only one HHH/DD pair, because HHH and DD must refer to specific
algorithms.
Other pairs must use at least one name that is different, like
HHH1/DD or HHH/DD1 or HH1/DD1, HH2/DD7, ...
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input until: >>> (a) Detects a non-terminating behavior pattern:
abort simulation and return 0.
That's readily contradicted by the diagonal program which
integrates a clean-room implementation of the HHH algorthm,
calls it on itself, obtains the zero, and promptly terminates.
Five LLM systems were smart enough to see this
and return the correct value for HHH so we
Everyone you've discussed with here is also smart enough
to see that a given DD will terminate or not, and identify
the correct halting status.
You still don't get it that HHH is only supposed to
report in the infinitely recursive behavior that its
input specifies and it not supposed to report on the
behavior of its caller: DD called from main().
On 8/30/2025 11:53 PM, Kaz Kylheku wrote:
On 2025-08-31, olcott <[email protected]> wrote:
On 8/30/2025 11:25 PM, Kaz Kylheku wrote:
But DD does not literally call HHH. That's just a feature in your
appartus; an embellishment that amounts to nothing, and only serves
as a
mechanism for perpetrating distracting cheats.
I keep bringing this up that has the same form
and you keep ignoring it.
I find the Linz approach tedious to follow; it's simply too much work to
get into it and work out an explanation of how you are misunderstanding
it and how it has nothing to do with the approach in your x86_utm.
You argued that HHH(DD) is not the same as a
TM and then I show you how it is just like a TM.
I understand that Linz is arguing for the undecidability of halting,
which disagres with you.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Machine M contains simulating halt decider H *based on a UTM*
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.∞ // accept state
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn // reject state
*Repeats until aborted proving non-halting*
(a) M copies its input ⟨M⟩
Where does your HHH in your Halt7.o test case make a copy its input?
Where does DD call a clean-room copy of HHH?
On 8/30/2025 10:24 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <[email protected]> wrote:
On 8/30/2025 2:49 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <[email protected]> wrote:>>
Using the notion of naming conventions proposed by Kaz
HHH(DD).exe is only being asked about DD.sim1.
HHH cannot be asked about DD.exe
If you move the distinguishing suffixes outside of the expression,
it becomes ambiguous. Does A(B).sim mean that B is simulated
or A and B are both simulated?
I think you want:
// with static fuses being used:
DD_exe is executed
DD_exe calls HHH_exe(DD_exe)
That has always been impossible
HHH has never ever been asked about
the executing process of its caller.
HHH does not have a caller. HHH is a halting decider that someone
proposed.
DD was developed after HHH to show that it's broken;
but HHH was already broken before that.
DD may be developed using a clean-room implementation of the HHH
algorithm; it doesn't call back into the decider that is operating on it
or anything like that.
That's just unnecessary embellishments that you have added.
HHH has always been asked about the behavior
specified by its input finite string of x86 code.
Sure; any string whatsoever.
WE ARE ASSUMING NO STATIC DATA
WE ARE ASSUMING NO STATIC DATA
WE ARE ASSUMING NO STATIC DATA
Then we have only one HHH and one DD in the system; it is not possible
to claim that HHH decides some DD other than that one DD.
An infinite number of HHH/DD pairs is decided this way.
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern:
abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
return 1.
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
What value should HHH(DD) correctly return?
<Input to LLM systems>
In the above generic definition of HHH the behavior
of DD simulated by any HHH is the same as HHH calls
DD() that calls HHH(DD).
Five LLM systems were smart enough to see this
and return the correct value for HHH so we
hypothesize an HHH that is this smart an proceed
from there. It returns 0 and DD() just sits there
in a text file doing nothing.
On 8/31/2025 4:27 AM, Mikko wrote:
On 2025-08-31 04:08:59 +0000, olcott said:When the HP requires a decider to report on its caller that contradicts
On 8/30/2025 10:56 PM, Kaz Kylheku wrote:
On 2025-08-31, olcott <[email protected]> wrote:
On 8/30/2025 10:24 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <[email protected]> wrote:An infinite number of HHH/DD pairs is decided this way.
On 8/30/2025 2:49 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <[email protected]> wrote:>>
Using the notion of naming conventions proposed by Kaz
HHH(DD).exe is only being asked about DD.sim1.
HHH cannot be asked about DD.exe
If you move the distinguishing suffixes outside of the
expression,
it becomes ambiguous. Does A(B).sim mean that B is simulated or >>>>>>>> A and B are both simulated?
I think you want:
// with static fuses being used:
DD_exe is executed DD_exe calls HHH_exe(DD_exe)
That has always been impossible HHH has never ever been asked
about the executing process of its caller.
HHH does not have a caller. HHH is a halting decider that someone
proposed.
DD was developed after HHH to show that it's broken;
but HHH was already broken before that.
DD may be developed using a clean-room implementation of the HHH
algorithm; it doesn't call back into the decider that is operating >>>>>> on it or anything like that.
That's just unnecessary embellishments that you have added.
HHH has always been asked about the behavior specified by its
input finite string of x86 code.
Sure; any string whatsoever.
WE ARE ASSUMING NO STATIC DATA WE ARE ASSUMING NO STATIC DATA WE >>>>>>> ARE ASSUMING NO STATIC DATA
Then we have only one HHH and one DD in the system; it is not
possible to claim that HHH decides some DD other than that one DD. >>>>>>
There is only one HHH/DD pair, because HHH and DD must refer to
specific algorithms.
Other pairs must use at least one name that is different, like
HHH1/DD or HHH/DD1 or HH1/DD1, HH2/DD7, ...
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input
until:
(a) Detects a non-terminating behavior pattern:
abort simulation and return 0.
That's readily contradicted by the diagonal program which integrates
a clean-room implementation of the HHH algorthm,
calls it on itself, obtains the zero, and promptly terminates.
Five LLM systems were smart enough to see this and return the
correct value for HHH so we
Everyone you've discussed with here is also smart enough to see that
a given DD will terminate or not, and identify the correct halting
status.
You still don't get it that HHH is only supposed to report in the
infinitely recursive behavior that its input specifies and it not
supposed to report on the behavior of its caller: DD called from
main().
Your suppositions make HHH irrelevant to the halting problem mentioned
on the subject line.
the definition of Turing machine deciders that only report on their
inputs.
On 8/31/2025 1:06 AM, Richard Heathfield wrote:
On 31/08/2025 06:34, olcott wrote:
On 8/30/2025 11:53 PM, Kaz Kylheku wrote:
On 2025-08-31, olcott <[email protected]> wrote:
On 8/30/2025 11:25 PM, Kaz Kylheku wrote:
But DD does not literally call HHH. That's just a feature
in your
appartus; an embellishment that amounts to nothing, and
only serves as a
mechanism for perpetrating distracting cheats.
I keep bringing this up that has the same form
and you keep ignoring it.
I find the Linz approach tedious to follow; it's simply too
much work to
get into it and work out an explanation of how you are
misunderstanding
it and how it has nothing to do with the approach in your
x86_utm.
You argued that HHH(DD) is not the same as a
TM and then I show you how it is just like a TM.
You argued that HHH(DD) is a decider for DD and then a number
of people showed you how it just isn't because it fails to
correctly decide DD.
When we remove the static data from HHH then
my current HHH has no way to see the repeating
pattern, none-the-less the repeating pattern
remains, it is merely unseen.
When HHH is as smart as an LLM then we are back
to HHH seeing this pattern and returning 0.
We still have the 89 year old error with the halting
problem proof that no halt decider HHH(DD) can ever
report on the behavior of its DD() caller.
On 8/31/2025 12:06 PM, olcott wrote:
When the HP requires a decider to report on its
caller that contradicts the definition of Turing
machine deciders that only report on their inputs.
Only if a halt decider exists. So you just agreed with Turing
and Linz.
On 8/31/2025 4:27 AM, Mikko wrote:
On 2025-08-31 04:08:59 +0000, olcott said:
On 8/30/2025 10:56 PM, Kaz Kylheku wrote:
On 2025-08-31, olcott <[email protected]> wrote:
On 8/30/2025 10:24 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <[email protected]> wrote:
On 8/30/2025 2:49 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <[email protected]> wrote:>>
Using the notion of naming conventions proposed by Kaz
HHH(DD).exe is only being asked about DD.sim1.
HHH cannot be asked about DD.exe
If you move the distinguishing suffixes outside of the expression, >>>>>>>> it becomes ambiguous. Does A(B).sim mean that B is simulated >>>>>>>> or A and B are both simulated?
I think you want:
// with static fuses being used:
DD_exe is executed
DD_exe calls HHH_exe(DD_exe)
That has always been impossible
HHH has never ever been asked about
the executing process of its caller.
HHH does not have a caller. HHH is a halting decider that someone
proposed.
DD was developed after HHH to show that it's broken;
but HHH was already broken before that.
DD may be developed using a clean-room implementation of the HHH
algorithm; it doesn't call back into the decider that is operating >>>>>> on it
or anything like that.
That's just unnecessary embellishments that you have added.
HHH has always been asked about the behavior
specified by its input finite string of x86 code.
Sure; any string whatsoever.
WE ARE ASSUMING NO STATIC DATA
WE ARE ASSUMING NO STATIC DATA
WE ARE ASSUMING NO STATIC DATA
Then we have only one HHH and one DD in the system; it is not
possible
to claim that HHH decides some DD other than that one DD.
An infinite number of HHH/DD pairs is decided this way.
There is only one HHH/DD pair, because HHH and DD must refer to
specific
algorithms.
Other pairs must use at least one name that is different, like
HHH1/DD or HHH/DD1 or HH1/DD1, HH2/DD7, ...
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input
until:
(a) Detects a non-terminating behavior pattern:
abort simulation and return 0.
That's readily contradicted by the diagonal program which
integrates a clean-room implementation of the HHH algorthm,
calls it on itself, obtains the zero, and promptly terminates.
Five LLM systems were smart enough to see this
and return the correct value for HHH so we
Everyone you've discussed with here is also smart enough
to see that a given DD will terminate or not, and identify
the correct halting status.
You still don't get it that HHH is only supposed to
report in the infinitely recursive behavior that its
input specifies and it not supposed to report on the
behavior of its caller: DD called from main().
Your suppositions make HHH irrelevant to the halting problem
mentioned on the subject line.
When the HP requires a decider to report on its
caller that contradicts the definition of Turing
machine deciders that only report on their inputs.
On 8/31/2025 1:06 AM, Richard Heathfield wrote:
On 31/08/2025 06:34, olcott wrote:
On 8/30/2025 11:53 PM, Kaz Kylheku wrote:
On 2025-08-31, olcott <[email protected]> wrote:
On 8/30/2025 11:25 PM, Kaz Kylheku wrote:
But DD does not literally call HHH. That's just a feature in your
appartus; an embellishment that amounts to nothing, and only
serves as a
mechanism for perpetrating distracting cheats.
I keep bringing this up that has the same form
and you keep ignoring it.
I find the Linz approach tedious to follow; it's simply too much
work to
get into it and work out an explanation of how you are misunderstanding >>>> it and how it has nothing to do with the approach in your x86_utm.
You argued that HHH(DD) is not the same as a
TM and then I show you how it is just like a TM.
You argued that HHH(DD) is a decider for DD and then a number of
people showed you how it just isn't because it fails to correctly
decide DD.
When we remove the static data from HHH then
my current HHH has no way to see the repeating
pattern, none-the-less the repeating pattern
remains, it is merely unseen.
When HHH is as smart as an LLM then we are back
to HHH seeing this pattern and returning 0.
We still have the 89 year old error with the halting
problem proof that no halt decider HHH(DD) can ever
report on the behavior of its DD() caller.
Machine M contains simulating halt decider H based on a UTM
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.∞ // accept state
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn // reject state
*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⟩
M.H ⟨M⟩ ⟨M⟩ cannot report on the behavior of M ⟨M⟩
if M.H ⟨M⟩ ⟨M⟩ can see the repeating state in its
input then it transitions to ⟨M.qn⟩ and M ⟨M⟩ halts.
This does not contradict M.H ⟨M⟩ ⟨M⟩ because M ⟨M⟩
is not in the scope of M.H ⟨M⟩ ⟨M⟩.
As far as I can make out, the best argument you have in its favour
appears to be that it does the best it can with what it's given when
limited by the artificial constraints you have imposed. Not the
world's most stellar argument, and not even true (as has been shown).
When the HP requires a decider to report on its
caller
On 8/31/25 12:06 PM, olcott wrote:
When the HP requires a decider to report on its
caller that contradicts the definition of Turing
machine deciders that only report on their inputs.
And where do you get that "definition"?
When HHH is as smart as an LLM then we are back
to HHH seeing this pattern and returning 0.
We still have the 89 year old error with the halting
problem proof that no halt decider HHH(DD) can ever
report on the behavior of its DD() caller.
Machine M contains simulating halt decider H based on a UTM
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.∞ // accept state
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn // reject state
On 8/31/2025 12:51 PM, Richard Heathfield wrote:
On 31/08/2025 17:40, dbush wrote:
On 8/31/2025 12:06 PM, olcott wrote:
<snip>
He does that a lot when he's not concentrating.When the HP requires a decider to report on its
caller that contradicts the definition of Turing
machine deciders that only report on their inputs.
Only if a halt decider exists. So you just agreed with Turing and Linz. >>
The funny part is he's said before he doesn't care if the halting
theorem is true or not, yet his whole argument against boils down to
"the proof is wrong because what it proves is correct".
On 8/31/2025 4:27 AM, Mikko wrote:
On 2025-08-31 04:08:59 +0000, olcott said:
On 8/30/2025 10:56 PM, Kaz Kylheku wrote:
On 2025-08-31, olcott <[email protected]> wrote:
On 8/30/2025 10:24 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <[email protected]> wrote:
On 8/30/2025 2:49 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <[email protected]> wrote:>>
Using the notion of naming conventions proposed by Kaz
HHH(DD).exe is only being asked about DD.sim1.
HHH cannot be asked about DD.exe
If you move the distinguishing suffixes outside of the expression, >>>>>>>> it becomes ambiguous. Does A(B).sim mean that B is simulated >>>>>>>> or A and B are both simulated?
I think you want:
// with static fuses being used:
DD_exe is executed
DD_exe calls HHH_exe(DD_exe)
That has always been impossible
HHH has never ever been asked about
the executing process of its caller.
HHH does not have a caller. HHH is a halting decider that someone
proposed.
DD was developed after HHH to show that it's broken;
but HHH was already broken before that.
DD may be developed using a clean-room implementation of the HHH
algorithm; it doesn't call back into the decider that is operating on it >>>>>> or anything like that.
That's just unnecessary embellishments that you have added.
HHH has always been asked about the behavior
specified by its input finite string of x86 code.
Sure; any string whatsoever.
WE ARE ASSUMING NO STATIC DATA
WE ARE ASSUMING NO STATIC DATA
WE ARE ASSUMING NO STATIC DATA
Then we have only one HHH and one DD in the system; it is not possible >>>>>> to claim that HHH decides some DD other than that one DD.
An infinite number of HHH/DD pairs is decided this way.
There is only one HHH/DD pair, because HHH and DD must refer to specific >>>> algorithms.
Other pairs must use at least one name that is different, like
HHH1/DD or HHH/DD1 or HH1/DD1, HH2/DD7, ...
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input until: >>>>> (a) Detects a non-terminating behavior pattern:
abort simulation and return 0.
That's readily contradicted by the diagonal program which
integrates a clean-room implementation of the HHH algorthm,
calls it on itself, obtains the zero, and promptly terminates.
Five LLM systems were smart enough to see this
and return the correct value for HHH so we
Everyone you've discussed with here is also smart enough
to see that a given DD will terminate or not, and identify
the correct halting status.
You still don't get it that HHH is only supposed to
report in the infinitely recursive behavior that its
input specifies and it not supposed to report on the
behavior of its caller: DD called from main().
Your suppositions make HHH irrelevant to the halting problem
mentioned on the subject line.
When the HP requires a decider to report on its
caller that contradicts the definition of Turing
machine deciders that only report on their inputs.
On 8/31/2025 12:50 PM, Kaz Kylheku wrote:
On 2025-08-31, olcott <[email protected]> wrote:
When the HP requires a decider to report on its
caller
... is never!
Thus M.H ⟨M⟩ ⟨M⟩ is not required to report on M ⟨M⟩
Instead it must report on the fact that *its input*
⟨M⟩ ⟨M⟩ correctly simulated by M.H remains stuck in
recursive simulation.
On 8/31/2025 1:04 PM, Kaz Kylheku wrote:
On 2025-08-31, olcott <[email protected]> wrote:
When HHH is as smart as an LLM then we are back
to HHH seeing this pattern and returning 0.
If you call this "smart" HHH HHH_smart, then of course
it can decide DD, which is built on HHH and not HHH_smart.
But HHH_smart will not decide a new DD_smart that is built on HHH_smart.
Not at all. I am saying that every detail of
Claude AI is copied into a virtual machine named HHH.
The smarter you make a version of the HHH algoirthm, the smarter you
make DD that is built on that same HHH algorithm.
DD integrates all the "brains" of HHH, plus the contradiction.
It never has been any actual contradiction.
It only seems to be a contradiction because
for 89 years no one ever noticed that a halt
decider must report on the actual behavior
that its actual input actually specifies as
opposed to and contrast with the behavior of
the directly executed machine.
We still have the 89 year old error with the halting
problem proof that no halt decider HHH(DD) can ever
report on the behavior of its DD() caller.
That's just a strawman version of it. The real version is that HHH(DD)
cannot correctly decide a DD which is built on an algorithm identical to
HHH, invokes that algorithm on DD and contradicts its result.
This is merely you not yet understanding the Linz
proof well enough.
DD is a "caller" of its own, private implementation of the algorithm; it
doesn't literally execute the code of the HHH that is being applied to
it.
Just like in the Linz proof.
No, they don't need to have a caller. The exist by their definition.Pure functions and Turing machines do not have a caller; they cannot
know anything about the circumstances of their use, and cannot react to
any differences in a caller.
Pure functions can and must have a caller otherwise
they cannot exist in languages like C. Their behavior
cannot be effected by their caller.
When a function A uses B, of course it is obvious in the design of A
that it relies on B. But B has no informationa about this; it exists in
its own empty universe.
DD does not know when it is calling its own emulator
and HHH does not know that DD is calling itself.
None the less DD correctly emulated by HHH cannot
possibly halt because DD is calling its own emulator.
As a result, nn application of a function denotes exactly the same thing
in every context where it appears, which is a massively important
property.
If HHH(DD) can recognize the repeating state of
its input then it does this consistently in every
context.
Machine M contains simulating halt decider H based on a UTM
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.∞ // accept state
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn // reject state
Suppose you did find an error in Linz. That would only
mean Linz made an error, not that the Halting Theorem is wrong.
Not at all. It is merely that the error is easier to
see in the Linz proof because only the Linz proof is
framed in exactingly precise state transitions.
With my correction to the error of the halting problem
proof no return value from the decider is ever contradicted
at all and the correct return value is reject.
On 9/1/2025 9:32 AM, Richard Heathfield wrote:
On 01/09/2025 15:10, olcott wrote:
On 8/31/2025 12:50 PM, Kaz Kylheku wrote:
On 2025-08-31, olcott <[email protected]> wrote:
When the HP requires a decider to report on its
caller
... is never!
Thus M.H ⟨M⟩ ⟨M⟩ is not required to report on M ⟨M⟩
Instead it must report on the fact that *its input*
⟨M⟩ ⟨M⟩ correctly simulated by M.H remains stuck in
recursive simulation.
It just has to report and get the answer right.
I guess one out of two ain't bad.
Its better than anyone else has ever done.
On 9/1/2025 9:32 AM, Richard Heathfield wrote:
On 01/09/2025 15:10, olcott wrote:
On 8/31/2025 12:50 PM, Kaz Kylheku wrote:
On 2025-08-31, olcott <[email protected]> wrote:
When the HP requires a decider to report on its
caller
... is never!
Thus M.H ⟨M⟩ ⟨M⟩ is not required to report on M ⟨M⟩
Instead it must report on the fact that *its input*
⟨M⟩ ⟨M⟩ correctly simulated by M.H remains stuck in
recursive simulation.
It just has to report and get the answer right.
I guess one out of two ain't bad.
Its better than anyone else has ever done.
On 8/31/2025 12:50 PM, Kaz Kylheku wrote:
On 2025-08-31, olcott <[email protected]> wrote:
When the HP requires a decider to report on its
caller
... is never!
Thus M.H ⟨M⟩ ⟨M⟩ is not required to report on M ⟨M⟩
Instead it must report on the fact that *its input*
⟨M⟩ ⟨M⟩ correctly simulated by M.H remains stuck in
recursive simulation.
On 8/31/2025 1:04 PM, Kaz Kylheku wrote:
On 2025-08-31, olcott <[email protected]> wrote:
When HHH is as smart as an LLM then we are back
to HHH seeing this pattern and returning 0.
If you call this "smart" HHH HHH_smart, then of course
it can decide DD, which is built on HHH and not HHH_smart.
But HHH_smart will not decide a new DD_smart that is built on HHH_smart.
Not at all. I am saying that every detail of
Claude AI is copied into a virtual machine named HHH.
The smarter you make a version of the HHH algoirthm, the smarter you
make DD that is built on that same HHH algorithm.
DD integrates all the "brains" of HHH, plus the contradiction.
It never has been any actual contradiction.
It only seems to be a contradiction because
for 89 years no one ever noticed that a halt
decider must report on the actual behavior
that its actual input actually specifies as
opposed to and contrast with the behavior of
the directly executed machine.
We still have the 89 year old error with the halting
problem proof that no halt decider HHH(DD) can ever
report on the behavior of its DD() caller.
That's just a strawman version of it. The real version is that HHH(DD)
cannot correctly decide a DD which is built on an algorithm identical to
HHH, invokes that algorithm on DD and contradicts its result.
This is merely you not yet understanding the Linz
proof well enough.
DD is a "caller" of its own, private implementation of the algorithm; it
doesn't literally execute the code of the HHH that is being applied to
it.
Just like in the Linz proof.
Pure functions and Turing machines do not have a caller; they cannot
know anything about the circumstances of their use, and cannot react to
any differences in a caller.
Pure functions can and must have a caller otherwise
they cannot exist in languages like C.
When a function A uses B, of course it is obvious in the design of A
that it relies on B. But B has no informationa about this; it exists in
its own empty universe.
DD does not know when it is calling its own emulator
and HHH does not know that DD is calling itself.
None the less DD correctly emulated by HHH cannot
possibly halt because DD is calling its own emulator.
As a result, nn application of a function denotes exactly the same thing
in every context where it appears, which is a massively important
property.
If HHH(DD) can recognize the repeating state of
its input then it does this consistently in every
context.
Machine M contains simulating halt decider H based on a UTM
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.∞ // accept state
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn // reject state
Suppose you did find an error in Linz. That would only
mean Linz made an error, not that the Halting Theorem is wrong.
Not at all. It is merely that the error is easier to
see in the Linz proof because only the Linz proof is
framed in exactingly precise state transitions.
With my correction to the error of the halting problem
proof no return value from the decider is ever contradicted
at all and the correct return value is reject.
Are you then saying that you cannot see that
M.H ⟨M⟩ ⟨M⟩ remains stuck in recursive simulation
unless and until it aborts this simulation?
On 9/1/2025 11:25 AM, Kaz Kylheku wrote:
On 2025-09-01, olcott <[email protected]> wrote:
On 8/31/2025 12:50 PM, Kaz Kylheku wrote:
On 2025-08-31, olcott <[email protected]> wrote:
When the HP requires a decider to report on its
caller
... is never!
Thus M.H ⟨M⟩ ⟨M⟩ is not required to report on M ⟨M⟩
Instead it must report on the fact that *its input*
⟨M⟩ ⟨M⟩ correctly simulated by M.H remains stuck in
recursive simulation.
The reason its input remains stuck is that the input contains an exact
copy of the decider, which it has applied to itself. Either the decider
is not terminating, or else it has returned true, and the diagonal test
case embarked on the opposite behavior of not terminating.
The decider applied to the input, and the one applied by the input
to itself, are indistinguishable. That's the important thing about the
diagonal test case; it is a non-negotiable ingredient in proofs of
the Halting Theorem.
The "outer" decider cannot report on the fact that the input is stuck in
a recursive simuation, unless the input's "inner" copy of the same halt
decider algorithm reports the same exact thing.
Because the diagonal test case ensures that whatever the "inner" decider
reports is wrong, the "outer" decider is wrong in exacty the same way.
HHH(DD) denotes exactly the same thing in every context in which
it appears. Its use within the DD test case is not distinguished
from any other in any way whatsoever.
Are you then saying that you cannot see that
M.H ⟨M⟩ ⟨M⟩ remains stuck in recursive simulation
unless and until it aborts this simulation?
On 9/1/2025 11:25 AM, Kaz Kylheku wrote:
On 2025-09-01, olcott <[email protected]> wrote:
On 8/31/2025 12:50 PM, Kaz Kylheku wrote:
On 2025-08-31, olcott <[email protected]> wrote:
When the HP requires a decider to report on its
caller
... is never!
Thus M.H ⟨M⟩ ⟨M⟩ is not required to report on M ⟨M⟩
Instead it must report on the fact that *its input*
⟨M⟩ ⟨M⟩ correctly simulated by M.H remains stuck in
recursive simulation.
The reason its input remains stuck is that the input contains an exact
copy of the decider, which it has applied to itself. Either the decider
is not terminating, or else it has returned true, and the diagonal test
case embarked on the opposite behavior of not terminating.
The decider applied to the input, and the one applied by the input
to itself, are indistinguishable. That's the important thing about the
diagonal test case; it is a non-negotiable ingredient in proofs of
the Halting Theorem.
The "outer" decider cannot report on the fact that the input is stuck in
a recursive simuation, unless the input's "inner" copy of the same halt
decider algorithm reports the same exact thing.
Because the diagonal test case ensures that whatever the "inner" decider
reports is wrong, the "outer" decider is wrong in exacty the same way.
HHH(DD) denotes exactly the same thing in every context in which
it appears. Its use within the DD test case is not distinguished
from any other in any way whatsoever.
Are you then saying that you cannot see that
M.H ⟨M⟩ ⟨M⟩ remains stuck in recursive simulation
unless and until it aborts this simulation?
On 8/31/2025 1:04 PM, Kaz Kylheku wrote:You should not reuse the same name for different things.
On 2025-08-31, olcott <[email protected]> wrote:
Not at all. I am saying that every detail of Claude AI is copied into a virtual machine named HHH.When HHH is as smart as an LLM then we are back to HHH seeing thisIf you call this "smart" HHH HHH_smart, then of course it can decide
pattern and returning 0.
DD, which is built on HHH and not HHH_smart.
But HHH_smart will not decide a new DD_smart that is built on
HHH_smart.
What do you think why nobody noticed they were applying TMs to non-inputs?The smarter you make a version of the HHH algoirthm, the smarter youIt only seems to be a contradiction because for 89 years no one ever
make DD that is built on that same HHH algorithm.
DD integrates all the "brains" of HHH, plus the contradiction.
noticed that a halt decider must report on the actual behavior that its actual input actually specifies as opposed to and contrast with the
behavior of the directly executed machine.
HHH could know that DD calls HHH (it doesn't currently).When a function A uses B, of course it is obvious in the design of ADD does not know when it is calling its own emulator and HHH does not
that it relies on B. But B has no informationa about this; it exists in
its own empty universe.
know that DD is calling itself.
None the less DD correctly emulated by HHH cannot possibly halt because
DD is calling its own emulator.
The simulated HHH apparently doesn't recognise that.As a result, an application of a function denotes exactly the sameIf HHH(DD) can recognize the repeating state of its input then it does
thing in every context where it appears, which is a massively important
property.
this consistently in every context.
You also need to show every other proof wrong.Suppose you did find an error in Linz. That would only mean Linz madeNot at all. It is merely that the error is easier to see in the Linz
an error, not that the Halting Theorem is wrong.
proof because only the Linz proof is framed in exactingly precise state transitions.
With my correction to the error of the halting problem proof no returnCool. That tells us only that HHH thinks it doesn't halt. It has no use.
value from the decider is ever contradicted at all and the correct
return value is reject.
On 9/1/2025 11:45 AM, Kaz Kylheku wrote:
Won't help HHH calculate the correct value, because whatever DD is doing
has already taken the value into account (if HHH returned), and is the
opposite behavior.
*Yes you do not understand this well enough*
The "do the opposite" code remains totally
unreachable in both HHH(DD) and M.H ⟨M⟩ ⟨M⟩.
When DD calls HHH(DD)
or
M ⟨M⟩ calls M.H ⟨M⟩ ⟨M⟩
It does not produce a contradiction because
no decider can ever see the behavior of its caller.
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
As soon as HHH(Infinite_Recursion) see that
Infinite_Recursion() cannot possibly reach
its own final halt state then it correctly
aborted Infinite_Recursion() and rejects it.
HHH(DD) must either see DD calling itself or
it must see DD calling the same function twice
in sequence. In any case (even if HHH cannot
see it) DD correctly simulated by HHH remains
stuck in recursive simulation until aborted.
On 9/1/2025 12:39 PM, Kaz Kylheku wrote:
On 2025-09-01, olcott <[email protected]> wrote:
On 9/1/2025 11:25 AM, Kaz Kylheku wrote:
On 2025-09-01, olcott <[email protected]> wrote:
On 8/31/2025 12:50 PM, Kaz Kylheku wrote:
On 2025-08-31, olcott <[email protected]> wrote:
When the HP requires a decider to report on its
caller
... is never!
Thus M.H ⟨M⟩ ⟨M⟩ is not required to report on M ⟨M⟩
Instead it must report on the fact that *its input*
⟨M⟩ ⟨M⟩ correctly simulated by M.H remains stuck in
recursive simulation.
The reason its input remains stuck is that the input contains an exact >>>> copy of the decider, which it has applied to itself. Either the decider >>>> is not terminating, or else it has returned true, and the diagonal test >>>> case embarked on the opposite behavior of not terminating.
The decider applied to the input, and the one applied by the input
to itself, are indistinguishable. That's the important thing about the >>>> diagonal test case; it is a non-negotiable ingredient in proofs of
the Halting Theorem.
The "outer" decider cannot report on the fact that the input is
stuck in
a recursive simuation, unless the input's "inner" copy of the same halt >>>> decider algorithm reports the same exact thing.
Because the diagonal test case ensures that whatever the "inner"
decider
reports is wrong, the "outer" decider is wrong in exacty the same way. >>>>
HHH(DD) denotes exactly the same thing in every context in which
it appears. Its use within the DD test case is not distinguished
from any other in any way whatsoever.
Are you then saying that you cannot see that
M.H ⟨M⟩ ⟨M⟩ remains stuck in recursive simulation
unless and until it aborts this simulation?
No, I don't. A given state machine is either stuck or it isn't.
If it stops, then it had been destined to do that; at no point
had it ever been a non-halting machine.
Machines cannot turn from halting to non-halting or vice versa,
any more than pi can turn rational, or 4 can turn odd.
What about a simple program that either halts or does not based on a
decision from a TRNG?
On 9/1/2025 2:39 PM, Kaz Kylheku wrote:
On 2025-09-01, olcott <[email protected]> wrote:
On 9/1/2025 11:25 AM, Kaz Kylheku wrote:
On 2025-09-01, olcott <[email protected]> wrote:
On 8/31/2025 12:50 PM, Kaz Kylheku wrote:
On 2025-08-31, olcott <[email protected]> wrote:
When the HP requires a decider to report on its
caller
... is never!
Thus M.H ⟨M⟩ ⟨M⟩ is not required to report on M ⟨M⟩
Instead it must report on the fact that *its input*
⟨M⟩ ⟨M⟩ correctly simulated by M.H remains stuck in
recursive simulation.
The reason its input remains stuck is that the input contains an exact >>>> copy of the decider, which it has applied to itself. Either the decider >>>> is not terminating, or else it has returned true, and the diagonal test >>>> case embarked on the opposite behavior of not terminating.
The decider applied to the input, and the one applied by the input
to itself, are indistinguishable. That's the important thing about the >>>> diagonal test case; it is a non-negotiable ingredient in proofs of
the Halting Theorem.
The "outer" decider cannot report on the fact that the input is
stuck in
a recursive simuation, unless the input's "inner" copy of the same halt >>>> decider algorithm reports the same exact thing.
Because the diagonal test case ensures that whatever the "inner"
decider
reports is wrong, the "outer" decider is wrong in exacty the same way. >>>>
HHH(DD) denotes exactly the same thing in every context in which
it appears. Its use within the DD test case is not distinguished
from any other in any way whatsoever.
Are you then saying that you cannot see that
M.H ⟨M⟩ ⟨M⟩ remains stuck in recursive simulation
unless and until it aborts this simulation?
No, I don't. A given state machine is either stuck or it isn't.
I gave you two hypothetical possibilities.
Surely you can understand the notion of hypothetical
possibilities?
Both of these two hypothetical possibilities are the
same in that ⟨M⟩ ⟨M⟩ correctly simulated by M.H cannot
possibly reach its own simulated final halt state of ⟨M.qn⟩
If it stops, then it had been destined to do that; at no point
had it ever been a non-halting machine.
The halting problem does not prove that there exists
a single machine that gets the wrong answer for a
single input.
Likewise my proof simultaneously explores every HHH/DD pair.
My proof simultaneously explores every HHH/DD pair.
My proof simultaneously explores every HHH/DD pair.
My proof simultaneously explores every HHH/DD pair.
Machines cannot turn from halting to non-halting or vice versa,
any more than pi can turn rational, or 4 can turn odd.
On 9/1/2025 11:45 AM, Kaz Kylheku wrote:
On 2025-09-01, olcott <[email protected]> wrote:
On 8/31/2025 1:04 PM, Kaz Kylheku wrote:
On 2025-08-31, olcott <[email protected]> wrote:
When HHH is as smart as an LLM then we are back
to HHH seeing this pattern and returning 0.
If you call this "smart" HHH HHH_smart, then of course
it can decide DD, which is built on HHH and not HHH_smart.
But HHH_smart will not decide a new DD_smart that is built on
HHH_smart.
Not at all. I am saying that every detail of
Claude AI is copied into a virtual machine named HHH.
Claude AI is yet another deterministic machine. If you build it into
a HHH, and wrap that in the diagonal test case DD, HHH(DD) will
be wrong. End of story.
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.∞ // accept state
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn // reject state
It is only wrong by the wrong measure. for 89
years everyone thought that the right measure
is the behavior of M applied to ⟨M⟩.
The smarter you make a version of the HHH algoirthm, the smarter you
make DD that is built on that same HHH algorithm.
DD integrates all the "brains" of HHH, plus the contradiction.
It never has been any actual contradiction.
It only seems to be a contradiction because
for 89 years no one ever noticed that a halt
decider must report on the actual behavior
that its actual input actually specifies as
opposed to and contrast with the behavior of
the directly executed machine.
There is no such oddball requirement that anyone missed.
The input is one thing, its name like DD means exactly the same thing
wherever it is mentioned and the application of the halting algorithm,
denoted by HHH(DD) or any other notation, has the same single meaning no
matter where it appears.
M.H ⟨M⟩ ⟨M⟩ remains stuck in recursive simulation
unless and until it aborts this simulation, thus
it should transition to M.qn if it can see this.
We still have the 89 year old error with the halting
problem proof that no halt decider HHH(DD) can ever
report on the behavior of its DD() caller.
That's just a strawman version of it. The real version is that HHH(DD) >>>> cannot correctly decide a DD which is built on an algorithm
identical to
HHH, invokes that algorithm on DD and contradicts its result.
This is merely you not yet understanding the Linz
proof well enough.
You are saying that stock stock Linz proves otherwise?
I am saying that the stock Linz proof shows
M.H ⟨M⟩ ⟨M⟩ remains stuck in recursive simulation
unless and until it aborts this simulation, when
we assume that M.H is based on a UTM, thus is
a simulating halt decider.
I only changed the notional conventions the
underlying semantics remains the same.
(If that were true, that would only make the Linz book wrong, worthy of
an erratum.)
DD is a "caller" of its own, private implementation of the
algorithm; it
doesn't literally execute the code of the HHH that is being applied to >>>> it.
Just like in the Linz proof.
Pure functions and Turing machines do not have a caller; they cannot
know anything about the circumstances of their use, and cannot react to >>>> any differences in a caller.
Pure functions can and must have a caller otherwise
they cannot exist in languages like C.
Well, you are wrong.
A pure function not only has no caller, but it has no arguments.
The application of a pure function has arguments.
I have no idea what you are referring to,
I am referring to this.
(1) the function return values are identical for identical arguments (no variation with local static variables, non-local variables, mutable
reference arguments or input streams, i.e., referential transparency), and (2) the function has no side effects (no mutation of non-local
variables, mutable reference arguments or input/output streams). https://en.wikipedia.org/wiki/Pure_function
The application of a pure function can be denoted in certain syntax
as an expression, and that expression may be embedded in a larger
expression.
The function application is not "aware" of being embedded in that larger
expression. It denotes the same application.
Yes, hence why it cannot report on the behavior
of its caller.
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.∞ // accept state
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn // reject state
M.H ⟨M⟩ ⟨M⟩ has no idea that it is embedded within M
thus cannot report on the behavior of M.
When a function A uses B, of course it is obvious in the design of A
that it relies on B. But B has no informationa about this; it exists in >>>> its own empty universe.
DD does not know when it is calling its own emulator
DD "knows" what it is calling because it specifies a body containing
statements and expressions.
and HHH does not know that DD is calling itself.
Even if HHH can figure that out, that won't help it produce the
correct return value.
None the less DD correctly emulated by HHH cannot
possibly halt because DD is calling its own emulator.
Won't help HHH calculate the correct value, because whatever DD is doing
has already taken the value into account (if HHH returned), and is the
opposite behavior.
*Yes you do not understand this well enough*
The "do the opposite" code remains totally
unreachable in both HHH(DD) and M.H ⟨M⟩ ⟨M⟩.
When DD calls HHH(DD)
or
M ⟨M⟩ calls M.H ⟨M⟩ ⟨M⟩
It does not produce a contradiction because
no decider can ever see the behavior of its caller.
As a result, nn application of a function denotes exactly the same
thing
in every context where it appears, which is a massively important
property.
If HHH(DD) can recognize the repeating state of
its input then it does this consistently in every
context.
If HHH(DD) recognizes that DD doesn't return, then what it must
do is not return in order to make sure that what it has
recognized remains true.
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
As soon as HHH(Infinite_Recursion) see that
Infinite_Recursion() cannot possibly reach
its own final halt state then it correctly
aborted Infinite_Recursion() and rejects it.
HHH(DD) must either see DD calling itself or
it must see DD calling the same function twice
in sequence. In any case (even if HHH cannot
see it) DD correctly simulated by HHH remains
stuck in recursive simulation until aborted.
The problem is that if HHH(DD) doesn't return, it is not
a halting decider. HHH(DD) not returning is just one of the
three possible ways that the diagonal test can proves that HHH isn't a
universal halting decider.
If there is no possible way for any HHH(DD) to see
that its input is stuck in recursive simulation then
this would be proof of the halting problem.
The we can see it should mean that some HHH can
see this too. The problem with these pathological
self-reference cases seems to be that they confound
human minds, not that they cannot be properly
resolved.
The greatest experts in the field of the philosophy
of logic still do not understand that the Liar Paradox:
"This sentence is not true"
is not a truth bearer and they have had 2000
years to think about this.
Now you can think about HHH producing an output like
"I have noticed DD doesn't terminate" while it keeps going.
So far the only way that I can see that HHH can do
this and still be a pure function of its input is
that HHH must be about as smart as a human mind. In
this case HHH can look at the grande scheme of the
relationship between itself and its input and decide
on that basis.
But pure functions must not produce output, because that is
a side effect; they only produce a result upon halting.
Machine M contains simulating halt decider H based on a UTM
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.∞ // accept state
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn // reject state
Suppose you did find an error in Linz. That would only
mean Linz made an error, not that the Halting Theorem is wrong.
Not at all. It is merely that the error is easier to
see in the Linz proof because only the Linz proof is
framed in exactingly precise state transitions.
If the error is not present in other formulations of the
proof, it's an error in that formulation.
All of the proofs have the same form in that the
"do the opposite" code is unreachable when the
input is simulated and the simulation remains stuck
until aborted.
With my correction to the error of the halting problem
By correction you mean that Linz has something different
in it from other styles of proof, and you are translating
to them?
No. The correction is the all halt decider must
only report on the actual behavior that their
actual input actually specifies.
M.H ⟨M⟩ ⟨M⟩ cannot report on the behavior of M ⟨M⟩.
The problem is, Linz doesn't. And if it did, it would
be wrong, and you would be propagating the error/misconception
to the other styles of proof.
The error cannot be seen until my 2016 idea of a
simulating halt decider is applied and thoroughly
examined.
Either you are propagating your own error, or (vanishingly
unlikely) one present in Linz.
proof no return value from the decider is ever contradicted
at all and the correct return value is reject.
The only way the return value from the decider is not contradicted is if
it fails to return.
When HHH(DD) returns 0 it is not contradicted
by DD() halting because its caller is not in
the scope of HHH.
As soon as the decider is understood as not
returning, it is disqualified from being a universal halting decider,
Yes. When HHH is as smart as a very smart human then
it can correctly reject its input. LLM systems proved this.
and so the diagonal test case takes its victim that way.
No, the diagonal itself is never involved.
On 9/1/2025 3:06 PM, joes wrote:
Am Mon, 01 Sep 2025 09:38:35 -0500 schrieb olcott:
On 8/31/2025 1:04 PM, Kaz Kylheku wrote:You should not reuse the same name for different things.
On 2025-08-31, olcott <[email protected]> wrote:
Not at all. I am saying that every detail of Claude AI is copied into aWhen HHH is as smart as an LLM then we are back to HHH seeing thisIf you call this "smart" HHH HHH_smart, then of course it can decide
pattern and returning 0.
DD, which is built on HHH and not HHH_smart.
But HHH_smart will not decide a new DD_smart that is built on
HHH_smart.
virtual machine named HHH.
Call it HHH_smart.
The smarter you make a version of the HHH algoirthm, the smarter youIt only seems to be a contradiction because for 89 years no one ever
make DD that is built on that same HHH algorithm.
DD integrates all the "brains" of HHH, plus the contradiction.
noticed that a halt decider must report on the actual behavior that its
actual input actually specifies as opposed to and contrast with the
behavior of the directly executed machine.
What do you think why nobody noticed they were applying TMs to non-Until I proposed the idea of a simulating
inputs?
halt decider that simulates its input one step
at a time to look for a repeating state everyone
rejected the notion of simulation out-of-hand
without review.
They naturally assumed that the behavior of
the direct execution of a machine described
by the input its always the exactly the same
as the behavior that this input specifies.
Only when the input is simulated by its decider
do we see that this *ACTUAL INPUT* specifies
non-halting behavior.
When a function A uses B, of course it is obvious in the design of ADD does not know when it is calling its own emulator and HHH does not
that it relies on B. But B has no informationa about this; it exists in >>>> its own empty universe.
know that DD is calling itself.
None the less DD correctly emulated by HHH cannot possibly halt because
DD is calling its own emulator.
HHH could know that DD calls HHH (it doesn't currently).
HHH cannot simulate itself halting.
That requires HHH to know its own machine address.
As a result, an application of a function denotes exactly the sameIf HHH(DD) can recognize the repeating state of its input then it does
thing in every context where it appears, which is a massively important >>>> property.
this consistently in every context.
The simulated HHH apparently doesn't recognise that.
Maybe its easier for you to think of this as
HHH(DD) recognizing its own machine address
thus stopping before any other HHH is ever simulated.
I know what Kaz would say about this and it
seems that he would be correct.
Suppose you did find an error in Linz. That would only mean Linz madeNot at all. It is merely that the error is easier to see in the Linz
an error, not that the Halting Theorem is wrong.
proof because only the Linz proof is framed in exactingly precise state
transitions.
You also need to show every other proof wrong.
There is nothing magical about Linz' TM formulation.
Not at all. All of the proofs follow the
exact same pattern.
With my correction to the error of the halting problem proof no return
value from the decider is ever contradicted at all and the correct
return value is reject.
Cool. That tells us only that HHH thinks it doesn't halt. It has no use.
Maybe its easier for you to think of this as
HHH(DD) recognizing its own machine address
and aborting its simulation and rejecting its
input on that basis.
On 9/1/2025 3:34 PM, Kaz Kylheku wrote:
On 2025-09-01, olcott <[email protected]> wrote:
On 9/1/2025 11:45 AM, Kaz Kylheku wrote:
Won't help HHH calculate the correct value, because whatever DD is
doing
has already taken the value into account (if HHH returned), and is the >>>> opposite behavior.
*Yes you do not understand this well enough*
The "do the opposite" code remains totally
unreachable in both HHH(DD) and M.H ⟨M⟩ ⟨M⟩.
In fact, I remarked upteen times to that effect; you simply do not
read what people are saying to you.
Then you still fail to understand that this
is the only basis that HHH and M.H should
report on.
That DD() and M ⟨M⟩ halts is not in the scope
of HHH and M.H, so they form no actual contradiction.
If HHH tries to analyze the halting of DD by simply simulating
it until it terminates, then HHH will not terminate.
This is the only basis that HHH can correctly report on.
The actual behavior specified by the actual input
does specify recursive simulation that cannot halt.
If you write a halting decider which simulates the input, you are
basically just developing a program that pays homage to undecidability,
because undecidability is a situation in which the best algorithm we
have for making a decision fails to terminate on some inputs.
Unless HHH is as smart as a human or an LLM that
can both generalize the relationship between HHH
and DD and reject the input on that basis.
If you try to make that program recognize something in the simulation
and then halt, then the diagnoal test case changes into one which
/does/ reach the "opposite behavior", and so the decider succumbs
that way.
I have told you many times now that neither HHH
nor M.H can report on the behavior of their caller.
You keep ignoring this because you don't understand
that M ⟨M⟩ is essentially the caller of M.H ⟨M⟩ ⟨M⟩.
When DD calls HHH(DD)
or
M ⟨M⟩ calls M.H ⟨M⟩ ⟨M⟩
It does not produce a contradiction because
no decider can ever see the behavior of its caller.
Sure; but in that situation the decider is doing nothing to show
that halting is deciable (the Halting Theorem is wrong).
Unless HHH is as smart as a human or LLM that
can correctly reject DD as non-halting on the
basis of the relationship between HHH and DD.
The Diagonal Program's weapon activates against any decider
that actually tries to be a decider and decide all cases.
Only when you fail to reject that HHH is supposed
to report on DD(). HHH is not supposed to report
on the behavior of its caller.
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
As soon as HHH(Infinite_Recursion) see that
Infinite_Recursion() cannot possibly reach
its own final halt state then it correctly
aborted Infinite_Recursion() and rejects it.
But the above Infinite_Recursion case isn't the Diagonal Case.
And neither is the diagonal case the diagonal case
when we reject that HHH is supposed to report on DD().
Proofs of the Halting Theorem do not assert that halting deciders
cannot decide infinite recursive cases that are not instances of the
Diagonal Case.
In other words, ... so what?
HHH(DD) must either see DD calling itself or
it must see DD calling the same function twice
in sequence. In any case (even if HHH cannot
see it) DD correctly simulated by HHH remains
stuck in recursive simulation until aborted.
I agree that your above Infinite_Recursion is absolutely infinitely
recursive. If it is simulated by a halting decider which notices the
runaway recursion, the decider can halt the simulation and return 0. I
further agree that halting the simulation does not turn
Infinite_Recursion from non-halting to halting; to argue that would be
absurd.
The problem is that the DD diagnol case is different.
It contains a call to HHH(DD), which is identical to the
decision being made.
If HHH(DD) decides to abort the infinite simulation of DD and return 0,
the HHH(DD) invoked by DD must do exactly the same thing.
Provably incorrect.
The source code of HHH and HHH1
are identical except for name.
For HHH(DD) unless it aborts its input it never stop running.
HHH1(DD) relies on HHH(DD) aborting its input.
And, thus, DD
is not actually infinitely recursive.
That is why I changed this to DD correctly simulated
by any HHH that can possibly exist cannot reach its
own simulated "return" statement.
DD is terminating! Moreover,
Not at all. Stops running because simulation is
aborted it not the same as reaching a final halt state.
HHH(DD) is incorrect to be returning 0.
Only when analyzed incorrectly.
If you insist that the top level HHH(DD) which controls the top-level
simulation is different from the HHH(DD), then you are saying that
we do not have a proper Diagonal Case which requires them to be
absolutely identical.
If every HHH can see all of the recursive simulations
below it then the outermost one sees this first.
Now I sort of see what you are saying. If the outer HH(DD) aborts
the simulation, it can do that at a such a point that none of the
simulated HH(DD) calls reach a return statement.
Thus HH(DD) is returning 0 at the top level, and the simulated HH(DD)
didn't return. So in that way, the outermost HH(DD) call appears
be telling the truth.
But the simulated computation is headed toward returning zero.
The outermost one cannot wait on the next
inner one or none of them ever abort.
You can't just pull the plug on a simulation before it reached a return
statement, and declare that it's non-terminating!
No it is the repeating state of HHH seeing that
DD is calling the same function twice in sequence.
My original version of this was HHH sees that DD
is calling itself.
Willfully neglecting to carrying a simulation to the end is not
same as showing non-terminationg.
Shooting witnesses to obtain a "not guilty" verdict does work in
life, but mathematics isn't run by the mob.
You are proving to be my best reviewer of several
years. Few people have the required skill in both
software engineering and computer science.
Mike has also been very excellent at understanding
how my code works.
Several of my reviewers only ever intended to be trolls.
Its pretty easy to spot them.
Until I proposed the idea of a simulating
halt decider that simulates its input one step
at a time to look for a repeating state everyone
rejected the notion of simulation out-of-hand
without review.
They naturally assumed that the behavior of
the direct execution of a machine described
by the input its always the exactly the same
as the behavior that this input specifies.
Only when the input is simulated by its decider
do we see that this *ACTUAL INPUT* specifies
non-halting behavior.
Maybe its easier for you to think of this as
HHH(DD) recognizing its own machine address
and aborting its simulation and rejecting its
input on that basis.
On 9/1/2025 3:34 PM, Kaz Kylheku wrote:
You can't just pull the plug on a simulation before it reached a return
statement, and declare that it's non-terminating!
No it is the repeating state of HHH seeing that
DD is calling the same function twice in sequence.
My original version of this was HHH sees that DD
is calling itself.
On 9/1/2025 3:06 PM, joes wrote:
Am Mon, 01 Sep 2025 09:38:35 -0500 schrieb olcott:
On 8/31/2025 1:04 PM, Kaz Kylheku wrote:You should not reuse the same name for different things.
On 2025-08-31, olcott <[email protected]> wrote:
Not at all. I am saying that every detail of Claude AI is copied into aWhen HHH is as smart as an LLM then we are back to HHH seeing thisIf you call this "smart" HHH HHH_smart, then of course it can decide
pattern and returning 0.
DD, which is built on HHH and not HHH_smart.
But HHH_smart will not decide a new DD_smart that is built on
HHH_smart.
virtual machine named HHH.
Call it HHH_smart.
The smarter you make a version of the HHH algoirthm, the smarter youIt only seems to be a contradiction because for 89 years no one ever
make DD that is built on that same HHH algorithm.
DD integrates all the "brains" of HHH, plus the contradiction.
noticed that a halt decider must report on the actual behavior that its
actual input actually specifies as opposed to and contrast with the
behavior of the directly executed machine.
What do you think why nobody noticed they were applying TMs to non-inputs? >>Until I proposed the idea of a simulating
halt decider that simulates its input one step
at a time to look for a repeating state everyone
rejected the notion of simulation out-of-hand
without review.
They naturally assumed that the behavior of
the direct execution of a machine described
by the input its always the exactly the same
as the behavior that this input specifies.
Only when the input is simulated by its decider
do we see that this *ACTUAL INPUT* specifies
non-halting behavior.
Maybe its easier for you to think of this as
HHH(DD) recognizing its own machine address
and aborting its simulation and rejecting its
input on that basis.
On 9/1/2025 2:39 PM, Kaz Kylheku wrote:In contrast to you...
On 2025-09-01, olcott <[email protected]> wrote:
On 9/1/2025 11:25 AM, Kaz Kylheku wrote:
The decider applied to the input, and the one applied by the input to
itself, are indistinguishable. That's the important thing about the
diagonal test case; it is a non-negotiable ingredient in proofs of
the Halting Theorem.
The "outer" decider cannot report on the fact that the input is stuck
in a recursive simuation, unless the input's "inner" copy of the same
halt decider algorithm reports the same exact thing.
HHH(DD) denotes exactly the same thing in every context in which it
appears. Its use within the DD test case is not distinguished from
any other in any way whatsoever.
I gave you two hypothetical possibilities.
Surely you can understand the notion of hypothetical possibilities?
Indeed. It proves that there are infinitely many machines that get theIf it stops, then it had been destined to do that; at no point had itThe halting problem does not prove that there exists a single machine
ever been a non-halting machine.
that gets the wrong answer for a single input.
Likewise my proof simultaneously explores every HHH/DD pair.Likewise the HP proof.
On 9/1/2025 3:06 PM, joes wrote:Have you checked?
Am Mon, 01 Sep 2025 09:38:35 -0500 schrieb olcott:
On 8/31/2025 1:04 PM, Kaz Kylheku wrote:
On 2025-08-31, olcott <[email protected]> wrote:
You should not reuse the same name for different things.If you call this "smart" HHH HHH_smart, then of course it can decideNot at all. I am saying that every detail of Claude AI is copied into
DD, which is built on HHH and not HHH_smart.
But HHH_smart will not decide a new DD_smart that is built on
HHH_smart.
a virtual machine named HHH.
Call it HHH_smart.
Until I proposed the idea of a simulating halt decider that simulatesIt only seems to be a contradiction because for 89 years no one everWhat do you think why nobody noticed they were applying TMs to
noticed that a halt decider must report on the actual behavior that
its actual input actually specifies as opposed to and contrast with
the behavior of the directly executed machine.
non-inputs?
its input one step at a time to look for a repeating state everyone
rejected the notion of simulation out-of-hand without review.
They naturally assumed that the behavior of the direct execution of aWhy "naturally"?
machine described by the input its always the exactly the same as the behavior that this input specifies.
Only when the input is simulated by its decider do we see that thisBut not when it isn't simulated?
*ACTUAL INPUT* specifies non-halting behavior.
No, it can analyse the source and compare it against its own.That requires HHH to know its own machine address.DD does not know when it is calling its own emulator and HHH does notHHH could know that DD calls HHH (it doesn't currently).
know that DD is calling itself.
None the less DD correctly emulated by HHH cannot possibly halt
because DD is calling its own emulator.
HHH cannot simulate itself halting.
The inner HHH isn't simulated to recognise repetition.Maybe its easier for you to think of this as HHH(DD) recognizing its own machine address thus stopping before any other HHH is ever simulated.If HHH(DD) can recognize the repeating state of its input then it doesThe simulated HHH apparently doesn't recognise that.
this consistently in every context.
Can you show it on another proof?Not at all. All of the proofs follow the exact same pattern.You also need to show every other proof wrong.Suppose you did find an error in Linz. That would only mean Linz madeNot at all. It is merely that the error is easier to see in the Linz
an error, not that the Halting Theorem is wrong.
proof because only the Linz proof is framed in exactingly precise
state transitions.
There is nothing magical about Linz' TM formulation.
--With my correction to the error of the halting problem proof no returnCool. That tells us only that HHH thinks it doesn't halt. It has no
value from the decider is ever contradicted at all and the correct
return value is reject.
use.
On 9/1/2025 2:58 AM, Mikko wrote:
On 2025-08-31 16:06:14 +0000, olcott said:
On 8/31/2025 4:27 AM, Mikko wrote:
On 2025-08-31 04:08:59 +0000, olcott said:
On 8/30/2025 10:56 PM, Kaz Kylheku wrote:
On 2025-08-31, olcott <[email protected]> wrote:
On 8/30/2025 10:24 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <[email protected]> wrote:
On 8/30/2025 2:49 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <[email protected]> wrote:>>
Using the notion of naming conventions proposed by Kaz
HHH(DD).exe is only being asked about DD.sim1.
HHH cannot be asked about DD.exe
If you move the distinguishing suffixes outside of the expression, >>>>>>>>>> it becomes ambiguous. Does A(B).sim mean that B is simulated >>>>>>>>>> or A and B are both simulated?
I think you want:
// with static fuses being used:
DD_exe is executed
DD_exe calls HHH_exe(DD_exe)
That has always been impossible
HHH has never ever been asked about
the executing process of its caller.
HHH does not have a caller. HHH is a halting decider that someone >>>>>>>> proposed.
DD was developed after HHH to show that it's broken;
but HHH was already broken before that.
DD may be developed using a clean-room implementation of the HHH >>>>>>>> algorithm; it doesn't call back into the decider that is operating on it
or anything like that.
That's just unnecessary embellishments that you have added.
HHH has always been asked about the behavior
specified by its input finite string of x86 code.
Sure; any string whatsoever.
WE ARE ASSUMING NO STATIC DATA
WE ARE ASSUMING NO STATIC DATA
WE ARE ASSUMING NO STATIC DATA
Then we have only one HHH and one DD in the system; it is not possible >>>>>>>> to claim that HHH decides some DD other than that one DD.
An infinite number of HHH/DD pairs is decided this way.
There is only one HHH/DD pair, because HHH and DD must refer to specific >>>>>> algorithms.
Other pairs must use at least one name that is different, like
HHH1/DD or HHH/DD1 or HH1/DD1, HH2/DD7, ...
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern:
abort simulation and return 0.
That's readily contradicted by the diagonal program which
integrates a clean-room implementation of the HHH algorthm,
calls it on itself, obtains the zero, and promptly terminates.
Five LLM systems were smart enough to see this
and return the correct value for HHH so we
Everyone you've discussed with here is also smart enough
to see that a given DD will terminate or not, and identify
the correct halting status.
You still don't get it that HHH is only supposed to
report in the infinitely recursive behavior that its
input specifies and it not supposed to report on the
behavior of its caller: DD called from main().
Your suppositions make HHH irrelevant to the halting problem
mentioned on the subject line.
When the HP requires a decider to report on its
caller that contradicts the definition of Turing
machine deciders that only report on their inputs.
The problem simply asks for a method to determine whether a given
Turing machine with a given input halts or not.
No Turing machine can ever directly answer that question
even if the machine in question immediately halts.
No one besides me has ever discovered that when we
use a simulating halt decider that the relationship
between the decider and its halting problem input
is essentially infinite recursion.
Also no one besides me ever notices that when a
simulating halt decider is used that the
"do the opposite" code remains totally unreachable.
Not simulating a terminating machine completely and then declaring it
non-terminating is simply incorrect.
It is simulated until a non terminating behavior
pattern is matched.
counter-factual.Only when the input is simulated by its decider
do we see that this *ACTUAL INPUT* specifies
non-halting behavior.
Nope; it specifies halting behavior on which the decider
pulls the plug, and returns a "non-halting" indication.
If the simulation were continued, it would reach its
return statement.
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
It is just like you are saying that Infinite_Recursion()
will reach its "return" statement, eventually.
On 9/2/2025 2:42 AM, joes wrote:Can you actually answer my questions?
Am Mon, 01 Sep 2025 16:10:24 -0500 schrieb olcott:
On 9/1/2025 3:06 PM, joes wrote:
Am Mon, 01 Sep 2025 09:38:35 -0500 schrieb olcott:
On 8/31/2025 1:04 PM, Kaz Kylheku wrote:
On 2025-08-31, olcott <[email protected]> wrote:
Not at all. I am saying that every detail of Claude AI is copiedYou should not reuse the same name for different things.
into a virtual machine named HHH.
Call it HHH_smart.
A simulating halt decider proves that the correct return value for the halting problem input is reject.Have you checked?Until I proposed the idea of a simulating halt decider that simulatesIt only seems to be a contradiction because for 89 years no one ever >>>>> noticed that a halt decider must report on the actual behavior thatWhat do you think why nobody noticed they were applying TMs to
its actual input actually specifies as opposed to and contrast with
the behavior of the directly executed machine.
non-inputs?
its input one step at a time to look for a repeating state everyone
rejected the notion of simulation out-of-hand without review.
This is a huge advancement from both return values are contradicted.
What do you think why nobody came up with self-simulation?They never had any counter-exampleThey naturally assumed that the behavior of the direct execution of aWhy "naturally"?
machine described by the input its always the exactly the same as the
behavior that this input specifies.
Take advantage of what? HHH detects recursive simulation and aborts.If HHH(DD) does see the repeating pattern it aborts its simulation. The executed DD()Only when the input is simulated by its decider do we see that thisBut not when it isn't simulated?
*ACTUAL INPUT* specifies non-halting behavior.
takes advantage of this. HHH could not take advantage of this.
No, it can analyse the source and compare it against its own.HHH could know that DD calls HHH (it doesn't currently).That requires HHH to know its own machine address.
HHH cannot simulate itself halting.
The inner HHH isn't simulated to recognise repetition.If HHH(DD) can recognize the repeating state of its input then it
does this consistently in every context.
And how does your disproof work in non-TM formulations?It is always loop if H reports halting and halt if H reports looping.Can you show it on another proof?Not at all. All of the proofs follow the exact same pattern.You also need to show every other proof wrong.Suppose you did find an error in Linz. That would only mean LinzNot at all. It is merely that the error is easier to see in the Linz >>>>> proof because only the Linz proof is framed in exactingly precise
made an error, not that the Halting Theorem is wrong.
state transitions.
There is nothing magical about Linz' TM formulation.
On 9/2/2025 1:36 AM, Kaz Kylheku wrote:That doesn't answer my question. It's also wrong.
On 2025-09-01, olcott <[email protected]> wrote:
On 9/1/2025 3:06 PM, joes wrote:
Am Mon, 01 Sep 2025 09:38:35 -0500 schrieb olcott:
On 8/31/2025 1:04 PM, Kaz Kylheku wrote:You should not reuse the same name for different things.
On 2025-08-31, olcott <[email protected]> wrote:
If you call this "smart" HHH HHH_smart, then of course it canNot at all. I am saying that every detail of Claude AI is copied
decide DD, which is built on HHH and not HHH_smart.
But HHH_smart will not decide a new DD_smart that is built on
HHH_smart.
into a virtual machine named HHH.
Call it HHH_smart.
What do you think why nobody noticed they were applying TMs toUntil I proposed the idea of a simulating halt decider that simulates
non-inputs?
its input one step at a time to look for a repeating state everyone
rejected the notion of simulation out-of-hand without review.
That is untrue, see above.You did not introduce this. The architecture of single stepping aNo one besides me has ever discovered that when we use a simulating halt decider that the relationship between the decider and its halting
machine while looking for non-terminating behaviors is the #1 most
obvious way of beginning to implement a halting decider.
I believe it was discussed in literature long before you. Some book I
don't remember in which I first read about the halting problem talked
about this very obvious thing.
problem input is essentially infinite recursion.
Also no one besides me ever notices that when a simulating halt deciderIt is very obvious, but it doesn't matter.
is used that the "do the opposite" code remains totally unreachable.
The point is that the input refers to one thing only.The machine described by the input has exactly that one behavior.The input to a halt decider could be an English poem encoded as binary
(If it has two or more behaviors, it's not a Turing Machine,
and so the whole show is disqualified from being related to the Turing
Machine Halting Problem.)
digits of ASCII values. Although the halt decider must implement a
computable function the input can be any kind of garbage.
You obviously haven't tried simulating HHH with HHH1.Nope; it specifies halting behavior on which the decider pulls thecounter-factual.
plug, and returns a "non-halting" indication.
If the simulation were continued, it would reach its return statement.
It is just like you are saying that Infinite_Recursion()Nobody is saying that.
will reach its "return" statement, eventually.
--How does that sound like anything but a wrong decider,
that jumps to a premature conclusion that is blatantly incorrect?
DD is squarely headed for its return statement when, poof, the
simulation ends and it is declared nonterminating. WTF? No!
There are no machine addresses in the halting problem; you cannot
introduce unnecessary embellishments and then disprove anything based
on the properties of these embellishments.
On 9/2/2025 11:29 AM, Kaz Kylheku wrote:
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
As I have proved by disabling the abort code
so that the static data is ignored
Without the static data my HHH cannot see the repeating pattern. YouWrong and irrelevant here.
keep forgetting this.
DD correctly simulated by HHH DOES NOT HALT! This is proven by removingLet DD and HHH be how you coded them. Let HHH' denote a non-aborting
the abort code and DD() never stops running.
On 9/2/2025 12:53 PM, joes wrote:
Am Tue, 02 Sep 2025 09:49:01 -0500 schrieb olcott:
On 9/2/2025 1:36 AM, Kaz Kylheku wrote:That doesn't answer my question. It's also wrong.
On 2025-09-01, olcott <[email protected]> wrote:
On 9/1/2025 3:06 PM, joes wrote:
Am Mon, 01 Sep 2025 09:38:35 -0500 schrieb olcott:
On 8/31/2025 1:04 PM, Kaz Kylheku wrote:You should not reuse the same name for different things.
On 2025-08-31, olcott <[email protected]> wrote:
If you call this "smart" HHH HHH_smart, then of course it canNot at all. I am saying that every detail of Claude AI is copied >>>>>>> into a virtual machine named HHH.
decide DD, which is built on HHH and not HHH_smart.
But HHH_smart will not decide a new DD_smart that is built on
HHH_smart.
Call it HHH_smart.
What do you think why nobody noticed they were applying TMs toUntil I proposed the idea of a simulating halt decider that
non-inputs?
simulates its input one step at a time to look for a repeating state >>>>> everyone rejected the notion of simulation out-of-hand without
review.
That is untrue, see above.You did not introduce this. The architecture of single stepping aNo one besides me has ever discovered that when we use a simulating
machine while looking for non-terminating behaviors is the #1 most
obvious way of beginning to implement a halting decider.
I believe it was discussed in literature long before you. Some book
I don't remember in which I first read about the halting problem
talked about this very obvious thing.
halt decider that the relationship between the decider and its halting
problem input is essentially infinite recursion.
Also no one besides me ever notices that when a simulating haltIt is very obvious, but it doesn't matter.
decider is used that the "do the opposite" code remains totally
unreachable.
The machine described by the input has exactly that one behavior.The input to a halt decider could be an English poem encoded as binary
(If it has two or more behaviors, it's not a Turing Machine,
and so the whole show is disqualified from being related to the
Turing Machine Halting Problem.)
digits of ASCII values. Although the halt decider must implement a
computable function the input can be any kind of garbage.
The point is that the input refers to one thing only.
Yes. This means that *it does not refer to* the directly executed DD().
(Computability has nothing to do with malformed inputs.)Never halting is the key malformed input that is being tested.
Nope; it specifies halting behavior on which the decider pulls thecounter-factual.
plug, and returns a "non-halting" indication.
If the simulation were continued, it would reach its return
statement.
You obviously haven't tried simulating HHH with HHH1.When we disable the abort code then no DD ever stops running.
It is just like you are saying that Infinite_Recursion()
will reach its "return" statement, eventually.
Nobody is saying that.Both Mike and Kaz have said that when referring to DD correctly
simulated by HHH.
*Five LLM systems all agree that they are wrong*
All five of these systems figured out my reasoning on their own.
On 9/2/2025 1:05 PM, joes wrote:I just did, and you should, too. You are talking about the second case,
Am Tue, 02 Sep 2025 09:37:20 -0500 schrieb olcott:
We don't go through all that complicated mess.DD correctly simulated by HHH DOES NOT HALT! This is proven byLet DD and HHH be how you coded them. Let HHH' denote a non-aborting
removing the abort code and DD() never stops running.
simulator and DD' the program that only calls HHH'(DD'). Then:
DD halts; DD' doesn't.
HHH(DD) returns "non-halting".
HHH'(DD') doesn't halt.
HHH(DD') returns "non-halting" (correctly).
HHH'(DD) halts!
So either the result is wrong or you are talking about a different
program.
We simply disable the abort code then every DD() never stops running conclusively proving that HHH(DD) is correct to reject its input.
On 9/2/2025 12:53 PM, joes wrote:
The point is that the input refers to one thing only.
Yes. This means that *it does not refer to* the directly executed
DD().
On 9/2/2025 1:09 PM, Kaz Kylheku wrote:
On 2025-09-02, olcott <[email protected]> wrote:
On 9/2/2025 11:29 AM, Kaz Kylheku wrote:
</MIT Professor Sipser agreed to ONLY these verbatim words
10/13/2022>
You are dreaming.
Ben checked with professor Sipser confirming this.
One HHH and one DD, the DD never stops running.
On 9/2/2025 2:46 PM, Richard Heathfield wrote:
You seem to think that there's more than one DD, but there just
isn't.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
That's it. That's the whole thing.
Actually that's not the whole thing,
HHH and everything it calls
it part of it,
and PO's argument hinges on the above being the
whole thing.
The point is that the input refers to one thing only.
Yes. This means that *it does not refer to* the directly executed DD().
When we disable the abort code then no DD ever stops running.
No one besides me has ever discovered that when we
use a simulating halt decider that the relationship
between the decider and its halting problem input
is essentially infinite recursion.
C. A. R. Hoare (a.k.a "Tony
Hoare") published on the subject of halting in 1972,
a paper called "Undecidability", co-authored with another British
four-name bloke named D. C. S. Allison.
On 02/09/2025 20:44, Kaz Kylheku wrote:
C. A. R. Hoare (a.k.a "Tony Hoare") published on the subject of halting
in 1972,
a paper called "Undecidability", co-authored with another British
four-name bloke named D. C. S. Allison.
A thoroughly enjoyable read, and one that alone justifies persevering
with this "debate" as long as I have.
On 9/2/2025 2:21 PM, Kaz Kylheku wrote:
On 2025-09-02, olcott <[email protected]> wrote:
The point is that the input refers to one thing only.
Yes. This means that *it does not refer to* the directly executed DD().
In one instance of diagonalization against one specific decider, there
can only be on HHH and one DD. Every instance of the expression DD
refers to the same entity. Every HHH(DD) is the same expression with the
same result value or else the same nontermination.
If DD somehow refers to two or more things, the whole situation does
not conform to the assumptions of the Halting Theorem.
When we disable the abort code then no DD ever stops running.
For no reason other than that HHH(DD) doesn't stop running. Oops!
I have proved that it is correct for every HP proof
decider to reject every HP proof input.
On 9/2/2025 2:21 PM, Kaz Kylheku wrote:
On 2025-09-02, olcott <[email protected]> wrote:
The point is that the input refers to one thing only.
Yes. This means that *it does not refer to* the directly executed DD().
In one instance of diagonalization against one specific decider, there
can only be on HHH and one DD. Every instance of the expression DD
refers to the same entity. Every HHH(DD) is the same expression with the
same result value or else the same nontermination.
If DD somehow refers to two or more things, the whole situation does
not conform to the assumptions of the Halting Theorem.
When we disable the abort code then no DD ever stops running.
For no reason other than that HHH(DD) doesn't stop running. Oops!
I have proved that it is correct for every HP proof
decider to reject every HP proof input.
On 9/2/2025 2:44 PM, Kaz Kylheku wrote:
On 2025-09-02, olcott <[email protected]> wrote:
No one besides me has ever discovered that when we
use a simulating halt decider that the relationship
between the decider and its halting problem input
is essentially infinite recursion.
This is wishful thinking. For example, C. A. R. Hoare (a.k.a "Tony
Hoare") published on the subject of halting in 1972,
I know him from mathematical proof of correctness.
a paper called "Undecidability", co-authored with another British
four-name bloke named D. C. S. Allison.
*Here is the actual paper*
Incomputability
C. A. R. HOARE AND D. C. S. ALSON https://dl.acm.org/doi/pdf/10.1145/356603.356606
Hoare and Allison come up with the following theorem:
THEOREM: Any language containing conditionals and recursive function
definitions which is powerful enough to program its own interpreter
cannot be used to program its own "terminates" function.
Same idea as the Tarski undefinability proof. Tarski was wrong.
hetero(p) := if (halts(p, p))
return not p(p)
else
return true
That would be the same as the Sipser proof when
"return not p(p)" is replaced with "return false"
I have no idea what "not p(p)" could mean:
negating a Boolean return value from p(p) ?
No looping behavior here; rather if halts(p, p) says halts, then
we call p(p), and return the opposite value.
iff p(p) is Boolean and not Void.
The uniqueness of my work is that I show that every HP proof
decider is always correct to reject every HP proof input.
On 9/2/2025 3:08 PM, Richard Heathfield wrote:
On 02/09/2025 20:44, Kaz Kylheku wrote:
C. A. R. Hoare (a.k.a "Tony
Hoare") published on the subject of halting in 1972,
a paper called "Undecidability", co-authored with another British
four-name bloke named D. C. S. Allison.
A thoroughly enjoyable read, and one that alone justifies
persevering with this "debate" as long as I have.
Ah so you didn't notice that the title was incorrect?
On 9/2/2025 4:16 PM, Richard Heathfield wrote:
On 02/09/2025 21:19, olcott wrote:
On 9/2/2025 3:08 PM, Richard Heathfield wrote:
On 02/09/2025 20:44, Kaz Kylheku wrote:
C. A. R. Hoare (a.k.a "Tony
Hoare") published on the subject of halting in 1972,
a paper called "Undecidability", co-authored with another
British
four-name bloke named D. C. S. Allison.
A thoroughly enjoyable read, and one that alone justifies
persevering with this "debate" as long as I have.
Ah so you didn't notice that the title was incorrect?
You do like to leap to unsupported conclusions, don't you?
That you didn't notice the title was incorrect
is strong evidence that you didn't just look up
the paper to read it.
On 9/2/2025 3:38 PM, Kaz Kylheku wrote:
On 2025-09-02, olcott <[email protected]> wrote:
On 9/2/2025 2:21 PM, Kaz Kylheku wrote:
On 2025-09-02, olcott <[email protected]> wrote:
In one instance of diagonalization against one specific decider, there >>>> can only be on HHH and one DD. Every instance of the expression DDThe point is that the input refers to one thing only.
Yes. This means that *it does not refer to* the directly executed DD(). >>>>
refers to the same entity. Every HHH(DD) is the same expression with the >>>> same result value or else the same nontermination.
If DD somehow refers to two or more things, the whole situation does
not conform to the assumptions of the Halting Theorem.
When we disable the abort code then no DD ever stops running.
For no reason other than that HHH(DD) doesn't stop running. Oops!
I have proved that it is correct for every HP proof
decider to reject every HP proof input.
HHH(DD) failing to terminate doesn't amount to a rejection.
This is much farther than anyone else has ever gotten.
It is much more advanced than the historical:
both return values are incorrect. Reject *is* correct.
On 2025-09-02, olcott <[email protected]> wrote:
On 9/2/2025 3:38 PM, Kaz Kylheku wrote:
On 2025-09-02, olcott <[email protected]> wrote:This is much farther than anyone else has ever gotten.
On 9/2/2025 2:21 PM, Kaz Kylheku wrote:
On 2025-09-02, olcott <[email protected]> wrote:
The point is that the input refers to one thing only.
Yes. This means that *it does not refer to* the directly executed
DD().
In one instance of diagonalization against one specific decider,
there can only be on HHH and one DD. Every instance of the
expression DD refers to the same entity. Every HHH(DD) is the same
expression with the same result value or else the same
nontermination.
If DD somehow refers to two or more things, the whole situation does >>>>> not conform to the assumptions of the Halting Theorem.
When we disable the abort code then no DD ever stops running.
For no reason other than that HHH(DD) doesn't stop running. Oops!
I have proved that it is correct for every HP proof decider to reject
every HP proof input.
HHH(DD) failing to terminate doesn't amount to a rejection.
It is much more advanced than the historical:
both return values are incorrect. Reject *is* correct.
If you want halting deciders to have a third value, it has to be a
concrete value, and they have to be required to terminate with that
value.
suppose we have a three-valued halting problem whereby instead of just
TRUE and FALSE we also have REJECT.
HHH must only return REJECT when it has correctly detected that DD is a diagnonal test case that contradicts it. It must return this value for
all possible incarnations of DD, and must not return that value for
anything that is not equivalent to DD.
Under these circumstances, it is not clear to me that it is still
sufficient to trivially construct a diagonal test case in order to show
that HHH cannot be a total halt decider.
What we need to show is that HHH makes a mistake; when given a certain non-diagonal test case, it wrongly returns REJECT. Or else, when given
some version of a diagonal test case, it wrongly returns TRUE or FALSE.
HHH has certain criteria, a certain algorithm by which it determines
that the input is any version of the diagonal test case DD.
If a non-diagonal test case could fake the behavior which triggers HHH's detection, then a false REJECT can be obtained.
In any case, the three-valued halt decider is not a valid two-valued
halt decider. Why? Because for all the diagonal test cases, it produces
the same value REJECT, whether they halt or not. Thus it fails to be a
total halt decider.
Yet, I suspect that a total three-valued halt decision is also not computable, like the regular one: it is not possible to totally,
correctly, classify Turing Machines into these three categories, even
though the REJECT category contains machines that either halt or do not,
but are not required to be resolved into TRUE and FALSE,
and that category's membership differs based on which decider is looking
at the problem.
On 9/2/2025 3:54 PM, Kaz Kylheku wrote:
On 2025-09-02, olcott <[email protected]> wrote:
I have proved that it is correct for every HP proof
decider to reject every HP proof input.
It is not correct for a HP decider to do anything other than halt,
and return true or false.
That is not exactly correct. The HP decide must halt
(that is the biggy)
Intuitively, a decider should be a Turing machine that given an input,
halts and either accepts or rejects, relaying its answer in one of many equivalent ways, such as halting at an ACCEPT or REJECT state, or
leaving its answer on the output tape.
In this case we assume that HHH has the intelligence
of an LLM system and can generalize recursive simulation
as equivalent to mutual recursion:
HHH1 reaps the benefit of HHH(DD) having already aborted
its simulation. HHH cannot reap this same benefit.
On 2025-09-02, olcott <[email protected]> wrote:
On 9/2/2025 3:54 PM, Kaz Kylheku wrote:
On 2025-09-02, olcott <[email protected]> wrote:
I have proved that it is correct for every HP proof
decider to reject every HP proof input.
It is not correct for a HP decider to do anything other than halt,
and return true or false.
That is not exactly correct. The HP decide must halt
(that is the biggy)
Intuitively, a decider should be a Turing machine that given an input,
halts and either accepts or rejects, relaying its answer in one of many
equivalent ways, such as halting at an ACCEPT or REJECT state, or
leaving its answer on the output tape.
I don't understand the values. How does ACCEPT remark up on the halting status of the input? And REJECT?
I understand you'd like to REJECT inputs that contain an embedded
copy of the same decider and contradict it in their behavior.
If ACCEPT merely stands in contrast with that value all it means is
"this test case does not contradict this decider", without telling that
it halts.
On 9/2/2025 1:24 AM, Kaz Kylheku wrote:
On 2025-09-01, olcott <[email protected]> wrote:
On 9/1/2025 3:34 PM, Kaz Kylheku wrote:
You can't just pull the plug on a simulation before it reached a return >>>> statement, and declare that it's non-terminating!
No it is the repeating state of HHH seeing that
DD is calling the same function twice in sequence.
My original version of this was HHH sees that DD
is calling itself.
The details don't matter that much. The point is that when abort
decision is introduced into HHH such that HHH(DD) is able to return 0,
it means that DD becomes terminating, since it also uses HHH(DD).
Halting is never reaching a final halt state.
DD correctly simulated by HHH cannot possibly halt.
Yanking the power cord from your computer does
not mean that a program halts.
That HHH pulls the plug on the simulation before DD reaches its return
statement is immaterial; that does not cause DD to be nonterminating.
We know that DD does reach that statement if simulated farther.
I thought that you said that yo understand these things.
When zero to infinity instructions of DD are correctly
simulated by HHH DD never reaches its own simulated
"return" statement final halt state.
When HHH aborts its simulation of DD there is no
possibility of stack unwinding that would require
these pop instructions to be simulated.
I'm afraid that what you have there is not a computer science research
project, but a kind of art exhibit, which uses code to put on
a sort of comedy sketch about the halting problem.
Unfortunately, you are very poor at explaining the joke to
those who don't get it; i.e. pretty much everyone.
You've gone to a great length to create a contraption in which a
simulated process is murdered by the halting decider before it is able
to contradict it, and that process is thereby declared immortal.
No the problem is that you have lost track of the details.
The only problem is that there is no way to cover up the obvious:
that a top level nonsimulated call to DD will call HH(DD),
which will run the simulation, return 0 and cause DD to terminate.
That is what I mean by you have lost track of the details.
Without the static data my HHH cannot see the repeating
pattern. You keep forgetting this. DD() keeps on running
proving that DD simulated by HHH DOES NOT HALT.
Most computing people interacting with you and your apparatus will take
/that/ behavior as being the source of truth for whether DD halts or
not, and dismiss the situation about the doubly simulated HHH(DD) being
before it is able to return 0 to the simulated DD, such that the
simulated DD never had a chance to behave in the opposite manner.
You don't even understand the basic software engineering
of this. Five LLM systems do understand this. DD correctly
simulated by HHH is the same as mutual infinite recursion.
Those who delve it into it a bit deeper will disagree with the idea that
we can simply stop simulating a function call that terminates, and
declare it to be nonterminating.
It looks like you are pretending to not understand
infinite recursion. DD correctly simulated by HHH
DOES NOT HALT! This is proven by removing the abort
code and DD() never stops running.
On 9/2/2025 12:53 PM, joes wrote:
Am Tue, 02 Sep 2025 09:49:01 -0500 schrieb olcott:
On 9/2/2025 1:36 AM, Kaz Kylheku wrote:That doesn't answer my question. It's also wrong.
On 2025-09-01, olcott <[email protected]> wrote:
On 9/1/2025 3:06 PM, joes wrote:
Am Mon, 01 Sep 2025 09:38:35 -0500 schrieb olcott:
On 8/31/2025 1:04 PM, Kaz Kylheku wrote:You should not reuse the same name for different things.
On 2025-08-31, olcott <[email protected]> wrote:
If you call this "smart" HHH HHH_smart, then of course it canNot at all. I am saying that every detail of Claude AI is copied >>>>>>> into a virtual machine named HHH.
decide DD, which is built on HHH and not HHH_smart.
But HHH_smart will not decide a new DD_smart that is built on
HHH_smart.
Call it HHH_smart.
What do you think why nobody noticed they were applying TMs toUntil I proposed the idea of a simulating halt decider that simulates >>>>> its input one step at a time to look for a repeating state everyone
non-inputs?
rejected the notion of simulation out-of-hand without review.
That is untrue, see above.You did not introduce this. The architecture of single stepping aNo one besides me has ever discovered that when we use a simulating halt >>> decider that the relationship between the decider and its halting
machine while looking for non-terminating behaviors is the #1 most
obvious way of beginning to implement a halting decider.
I believe it was discussed in literature long before you.� Some book I >>>> don't remember in which I first read about the halting problem talked
about this very obvious thing.
problem input is essentially infinite recursion.
Also no one besides me ever notices that when a simulating halt deciderIt is very obvious, but it doesn't matter.
is used that the "do the opposite" code remains totally unreachable.
The machine described by the input has exactly that one behavior.The input to a halt decider could be an English poem encoded as binary
(If it has two or more behaviors, it's not a Turing Machine,
and so the whole show is disqualified from being related to the Turing >>>> Machine Halting Problem.)
digits of ASCII values. Although the halt decider must implement a
computable function the input can be any kind of garbage.
The point is that the input refers to one thing only.
Yes. This means that *it does not refer to* the directly executed DD().
(Computability has nothing to do with malformed inputs.)
Never halting is the key malformed input that
is being tested.
Nope; it specifies halting behavior on which the decider pulls thecounter-factual.
plug, and returns a "non-halting" indication.
If the simulation were continued, it would reach its return statement.
You obviously haven't tried simulating HHH with HHH1.
When we disable the abort code then no DD ever stops running.
It is just like you are saying that Infinite_Recursion()
will reach its "return" statement, eventually.
Nobody is saying that.
Both Mike and Kaz have said that when referring
to DD correctly simulated by HHH.
On 9/2/2025 6:26 PM, André G. Isaak wrote:
I think at one point Olcott claimed this and was implying some
sort of three-value system, but I don't think he is any longer.
I think he's now using ACCEPT and REJECT in their usual senses
(though his analysis is still hopelessly flawed).
No one can point to any actual flaw.
DD correctly simulated by HHH will never reach its final
halt state even when infinite instructions of DD are
simulated.
Recursive emulation proved too difficult for most
people here so I had to explain this in terms of
mutual recursion between HHH and DD.
Look, the long and short of this is that you lack the
intellectual capacity to understand what people are saying to you.
If that was true then I would not have been in the
top 20% of my computer science classes.
Your understanding has generally been very good.
You might still have one blind spot.
Those people here only playing trollish head games
have now been out voted by five chat bots.
On 9/2/2025 6:26 PM, André G. Isaak wrote:
On 2025-09-02 16:54, Kaz Kylheku wrote:
On 2025-09-02, olcott <[email protected]> wrote:
On 9/2/2025 3:54 PM, Kaz Kylheku wrote:
On 2025-09-02, olcott <[email protected]> wrote:
I have proved that it is correct for every HP proof
decider to reject every HP proof input.
It is not correct for a HP decider to do anything other than halt,
and return true or false.
That is not exactly correct. The HP decide must halt
(that is the biggy)
Intuitively, a decider should be a Turing machine that given an input, >>>> halts and either accepts or rejects, relaying its answer in one of many >>>> equivalent ways, such as halting at an ACCEPT or REJECT state, or
leaving its answer on the output tape.
I don't understand the values. How does ACCEPT remark up on the halting
status of the input? And REJECT?
I understand you'd like to REJECT inputs that contain an embedded
copy of the same decider and contradict it in their behavior.
I think at one point Olcott claimed this and was implying some sort of
three-value system, but I don't think he is any longer. I think he's now
using ACCEPT and REJECT in their usual senses (though his analysis is
still hopelessly flawed).
No one can point to any actual flaw. All the "flaws"
ever pointed out have been false assumptions.
Kaz reminded me that HHH is not currently a pure
function of its inputs.
That is, a halt decider ACCEPTS every input that represents a halting
computation and REJECTS every input that does not represent a halting
computation.
A universal halt decider would need to do this.
Refuting the HP proofs only requires an HHH
that can decide DD.
On 9/2/2025 3:19 AM, Mikko wrote:
On 2025-09-01 14:56:31 +0000, olcott said:
On 9/1/2025 2:58 AM, Mikko wrote:
On 2025-08-31 16:06:14 +0000, olcott said:
On 8/31/2025 4:27 AM, Mikko wrote:
On 2025-08-31 04:08:59 +0000, olcott said:
On 8/30/2025 10:56 PM, Kaz Kylheku wrote:
On 2025-08-31, olcott <[email protected]> wrote:
On 8/30/2025 10:24 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <[email protected]> wrote:
On 8/30/2025 2:49 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <[email protected]> wrote:>> >>>>>>>>>>>>> Using the notion of naming conventions proposed by Kaz >>>>>>>>>>>>>
HHH(DD).exe is only being asked about DD.sim1.
HHH cannot be asked about DD.exe
If you move the distinguishing suffixes outside of the expression, >>>>>>>>>>>> it becomes ambiguous. Does A(B).sim mean that B is simulated >>>>>>>>>>>> or A and B are both simulated?
I think you want:
// with static fuses being used:
DD_exe is executed
DD_exe calls HHH_exe(DD_exe)
That has always been impossible
HHH has never ever been asked about
the executing process of its caller.
HHH does not have a caller. HHH is a halting decider that someone >>>>>>>>>> proposed.
DD was developed after HHH to show that it's broken;
but HHH was already broken before that.
DD may be developed using a clean-room implementation of the HHH >>>>>>>>>> algorithm; it doesn't call back into the decider that is operating on it
or anything like that.
That's just unnecessary embellishments that you have added. >>>>>>>>>>
HHH has always been asked about the behavior
specified by its input finite string of x86 code.
Sure; any string whatsoever.
WE ARE ASSUMING NO STATIC DATA
WE ARE ASSUMING NO STATIC DATA
WE ARE ASSUMING NO STATIC DATA
Then we have only one HHH and one DD in the system; it is not possible
to claim that HHH decides some DD other than that one DD.
An infinite number of HHH/DD pairs is decided this way.
There is only one HHH/DD pair, because HHH and DD must refer to specific
algorithms.
Other pairs must use at least one name that is different, like >>>>>>>> HHH1/DD or HHH/DD1 or HH1/DD1, HH2/DD7, ...
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern:
abort simulation and return 0.
That's readily contradicted by the diagonal program which
integrates a clean-room implementation of the HHH algorthm,
calls it on itself, obtains the zero, and promptly terminates. >>>>>>>>
Five LLM systems were smart enough to see this
and return the correct value for HHH so we
Everyone you've discussed with here is also smart enough
to see that a given DD will terminate or not, and identify
the correct halting status.
You still don't get it that HHH is only supposed to
report in the infinitely recursive behavior that its
input specifies and it not supposed to report on the
behavior of its caller: DD called from main().
Your suppositions make HHH irrelevant to the halting problem
mentioned on the subject line.
When the HP requires a decider to report on its
caller that contradicts the definition of Turing
machine deciders that only report on their inputs.
The problem simply asks for a method to determine whether a given
Turing machine with a given input halts or not.
No Turing machine can ever directly answer that question
even if the machine in question immediately halts.
Irroevant to the fact that the problem staement reuires a method
to determine whether a given Turing macine with a given input
halts or not.
A TM can report on the behavior of its input.
A TM cannot report anything about non-inputs.
TMs also cannot compute the correct square-root
of a dead chicken even if required to do so.
On 9/2/2025 3:52 PM, Kaz Kylheku wrote:
On 2025-09-02, olcott <[email protected]> wrote:
On 9/2/2025 2:44 PM, Kaz Kylheku wrote:
On 2025-09-02, olcott <[email protected]> wrote:
No one besides me has ever discovered that when we
use a simulating halt decider that the relationship
between the decider and its halting problem input
is essentially infinite recursion.
This is wishful thinking. For example, C. A. R. Hoare (a.k.a "Tony
Hoare") published on the subject of halting in 1972,
I know him from mathematical proof of correctness.
People in computing know him from stuff all over the place.
E.g. inventor of Quick Sort. Funny story with Quick Sort. The way
Hoare's version does the partitioning with two pointers/indices that move
in opposite direction is the key to handling the already-sorted
input case without blowing up into quadratic behavior. Authors after
Hoare have presented vandalized versions of Quick Sort in which
they thought they could simplify the array partitioning, only to
end up with quadratic behavior on sorted or nearly sorted inputs.
a paper called "Undecidability", co-authored with another British
four-name bloke named D. C. S. Allison.
*Here is the actual paper*
Incomputability
C. A. R. HOARE AND D. C. S. ALSON
https://dl.acm.org/doi/pdf/10.1145/356603.356606
Thank you. Incomputability and undecidability are the same thing, so I
slipped that up. Anyway, you found it.
Yes. You are my best reviewer. Most of the rest
of my reviewers only want to be trolls.
Hoare and Allison come up with the following theorem:
THEOREM: Any language containing conditionals and recursive
function
definitions which is powerful enough to program its own interpreter >>>> cannot be used to program its own "terminates" function.
Same idea as the Tarski undefinability proof. Tarski was wrong.
But anyway, this is one example of authors exploring simulation in the
context of halting, over 50 years ago now.
Yet did not conclude as my work has shown that
for the HP proof input the HP decider would be
correct to reject.
On 9/2/2025 12:38 PM, joes wrote:
Am Tue, 02 Sep 2025 09:58:21 -0500 schrieb olcott:
On 9/2/2025 2:42 AM, joes wrote:
Am Mon, 01 Sep 2025 16:10:24 -0500 schrieb olcott:
On 9/1/2025 3:06 PM, joes wrote:
Am Mon, 01 Sep 2025 09:38:35 -0500 schrieb olcott:
On 8/31/2025 1:04 PM, Kaz Kylheku wrote:
On 2025-08-31, olcott <[email protected]> wrote:
Not at all. I am saying that every detail of Claude AI is copied >>>>>>> into a virtual machine named HHH.You should not reuse the same name for different things.
Call it HHH_smart.
Have you checked?Until I proposed the idea of a simulating halt decider that simulates >>>>> its input one step at a time to look for a repeating state everyoneIt only seems to be a contradiction because for 89 years no one ever >>>>>>> noticed that a halt decider must report on the actual behavior that >>>>>>> its actual input actually specifies as opposed to and contrast with >>>>>>> the behavior of the directly executed machine.What do you think why nobody noticed they were applying TMs to
non-inputs?
rejected the notion of simulation out-of-hand without review.
A simulating halt decider proves that the correct return value for the
halting problem input is reject.
This is a huge advancement from both return values are contradicted.
Can you actually answer my questions?
I am sorry, I am not all knowing.
My idea changes things so much that
if done before it would be known.
They never had any counter-exampleThey naturally assumed that the behavior of the direct execution of a >>>>> machine described by the input its always the exactly the same as the >>>>> behavior that this input specifies.Why "naturally"?
What do you think why nobody came up with self-simulation?
IDK. After 2000 years they still don't get it
that the Liar Paradox cannot possibly be true
or false even when proven. They must be stupid.
If HHH(DD) does see the repeating pattern it aborts its simulation. TheOnly when the input is simulated by its decider do we see that thisBut not when it isn't simulated?
*ACTUAL INPUT* specifies non-halting behavior.
executed DD()
takes advantage of this. HHH could not take advantage of this.
Take advantage of what? HHH detects recursive simulation and aborts.
DD() would only halt because HHH(DD) correctly determined
that its input does not halt. That not the same as DD()
just halting on its own.
No, it can analyse the source and compare it against its own.HHH could know that DD calls HHH (it doesn't currently).That requires HHH to know its own machine address.
HHH cannot simulate itself halting.
The inner HHH isn't simulated to recognise repetition.If HHH(DD) can recognize the repeating state of its input then it >>>>>>> does this consistently in every context.
It is always loop if H reports halting and halt if H reports looping.Can you show it on another proof?Not at all. All of the proofs follow the exact same pattern.You also need to show every other proof wrong.Suppose you did find an error in Linz. That would only mean Linz >>>>>>>> made an error, not that the Halting Theorem is wrong.Not at all. It is merely that the error is easier to see in the Linz >>>>>>> proof because only the Linz proof is framed in exactingly precise >>>>>>> state transitions.
There is nothing magical about Linz' TM formulation.
And how does your disproof work in non-TM formulations?
The proofs are always exactly the same.
Its always loop if halts and halt if loops.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 23:07:30 |
| Calls: | 12,105 |
| Calls today: | 5 |
| Files: | 15,006 |
| Messages: | 6,518,139 |