| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 23 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 52:33:19 |
| Calls: | 583 |
| Files: | 1,139 |
| D/L today: |
179 files (27,921K bytes) |
| Messages: | 111,616 |
When we disable the abort code so that HHH(DD) is a
pure function of its inputs DD() never stops running.
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,
so it must return 0 (non-
halting), whereupon DD promptly halts.
You keep wishing that HHH's opinion matters. It really *really* doesn't because, however it answers, DD will always prove it wrong.
<snip>
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 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,
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>
-a-a-a If simulating halt decider H correctly simulates its
-a-a-a input D until H correctly determines that its simulated D
-a-a-a would never stop running unless aborted then
-a-a-a H can abort its simulation of D and correctly report that D
-a-a-a 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:
-a-a-a abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
-a-a-a return 1.
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
-a int Halt_Status = HHH(DD);
-a if (Halt_Status)
-a-a-a HERE: goto HERE;
-a 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>
-a-a-a If simulating halt decider H correctly simulates its
-a-a-a input D until H correctly determines that its simulated D
-a-a-a would never stop running unless aborted then
-a-a-a H can abort its simulation of D and correctly report that D
-a-a-a 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:
-a-a-a abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
-a-a-a return 1.
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
-a int Halt_Status = HHH(DD);
-a if (Halt_Status)
-a-a-a HERE: goto HERE;
-a 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>
-a-a-a If simulating halt decider H correctly simulates its
-a-a-a input D until H correctly determines that its simulated D
-a-a-a would never stop running unless aborted then
-a-a-a H can abort its simulation of D and correctly report that D
-a-a-a 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:
-a-a-a abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
-a-a-a return 1.
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
-a int Halt_Status = HHH(DD);
-a if (Halt_Status)
-a-a-a HERE: goto HERE;
-a 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 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()
{
-a int Halt_Status = HHH(DD);
-a if (Halt_Status)
-a-a-a HERE: goto HERE;
-a return Halt_Status;
}
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()
{
-a-a int Halt_Status = HHH(DD);
-a-a if (Halt_Status)
-a-a-a-a HERE: goto HERE;
-a-a return Halt_Status;
}
*Incorrect the machine code bytes are the input*
_DD()
[00002162] 55-a-a-a-a-a-a-a-a push ebp
[00002163] 8bec-a-a-a-a-a-a mov ebp,esp
[00002165] 51-a-a-a-a-a-a-a-a push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404-a-a-a-a add esp,+04
[00002173] 8945fc-a-a-a-a mov [ebp-04],eax
[00002176] 837dfc00-a-a cmp dword [ebp-04],+00
[0000217a] 7402-a-a-a-a-a-a jz 0000217e
[0000217c] ebfe-a-a-a-a-a-a jmp 0000217c
[0000217e] 8b45fc-a-a-a-a mov eax,[ebp-04]
[00002181] 8be5-a-a-a-a-a-a mov esp,ebp
[00002183] 5d-a-a-a-a-a-a-a-a pop ebp
[00002184] c3-a-a-a-a-a-a-a-a ret
Size in bytes:(0035) [00002184]
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()
{
-a-a int Halt_Status = HHH(DD);
-a-a if (Halt_Status)
-a-a-a-a HERE: goto HERE;
-a-a return Halt_Status;
}
*Incorrect the machine code bytes are the input*
_DD()
[00002162] 55-a-a-a-a-a-a-a-a push ebp
[00002163] 8bec-a-a-a-a-a-a mov ebp,esp
[00002165] 51-a-a-a-a-a-a-a-a push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404-a-a-a-a add esp,+04
[00002173] 8945fc-a-a-a-a mov [ebp-04],eax
[00002176] 837dfc00-a-a cmp dword [ebp-04],+00
[0000217a] 7402-a-a-a-a-a-a jz 0000217e
[0000217c] ebfe-a-a-a-a-a-a jmp 0000217c
[0000217e] 8b45fc-a-a-a-a mov eax,[ebp-04]
[00002181] 8be5-a-a-a-a-a-a mov esp,ebp
[00002183] 5d-a-a-a-a-a-a-a-a pop ebp
[00002184] c3-a-a-a-a-a-a-a-a ret
Size in bytes:(0035) [00002184]
The first five instructions are as
far as DD simulated by HHH can get.
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.
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.
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()
{
-a-a int Halt_Status = HHH(DD);
-a-a if (Halt_Status)
-a-a-a-a HERE: goto HERE;
-a-a return Halt_Status;
}
*Incorrect the machine code bytes are the input*
The input is the C function.
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()
{
-a-a int Halt_Status = HHH(DD);
-a-a if (Halt_Status)
-a-a-a-a HERE: goto HERE;
-a-a 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 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.
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()
{
-a Infinite_Recursion();
-a return;
}
void Infinite_Loop()
{
-a HERE: goto HERE;
-a OutputString("I never get here you dumb bunny!\n");
-a return;
}
These simulations halt too you dumb bunny!
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()
{
-a-a Infinite_Recursion();
-a-a return;
}
Doesn't call HHH(DD).
void Infinite_Loop()
{
-a-a HERE: goto HERE;
-a-a OutputString("I never get here you dumb bunny!\n");
-a-a return;
}
Doesn't call HHH(DD).
These simulations halt too you dumb bunny!
So you cannot reasonably claim that they don't.
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.
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()
{
-a-a Infinite_Recursion();
-a-a return;
}
Doesn't call HHH(DD).
void Infinite_Loop()
{
-a-a HERE: goto HERE;
-a-a OutputString("I never get here you dumb bunny!\n");
-a-a 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.
On 28/08/2025 16:22, olcott wrote:
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()
{
-a-a Infinite_Recursion();
-a-a return;
}
Doesn't call HHH(DD).
void Infinite_Loop()
{
-a-a HERE: goto HERE;
-a-a OutputString("I never get here you dumb bunny!\n");
-a-a 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.
You just claimed that they halt. "These simulations halt too you dumb bunny!" as you so eloquently put it.
So they're non-halting, but they halt, yes?
HHH correctly determines that its input
does not halt then HHH halts.
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.
So, whatever happens, the simulation stops.
And then HHH returns 0.
Is that right?
That is and was my understanding, but you've called me a liar for saying
so before, so I'm just checking that what you said was a lie has stopped being a lie and is now true.
Or is it lying again? It's so hard to keep track.
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()
{
-a int Halt_Status = HHH(DD);
-a if (Halt_Status)
-a-a-a HERE: goto HERE;
-a 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 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.
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.
A Turing machine has no 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()
{
-a-a int Halt_Status = HHH(DD);
-a-a if (Halt_Status)
-a-a-a-a HERE: goto HERE;
-a-a return Halt_Status;
}
*Incorrect the machine code bytes are the input*
_DD()
[00002162] 55-a-a-a-a-a-a-a-a push ebp
[00002163] 8bec-a-a-a-a-a-a mov ebp,esp
[00002165] 51-a-a-a-a-a-a-a-a push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404-a-a-a-a add esp,+04
[00002173] 8945fc-a-a-a-a mov [ebp-04],eax
[00002176] 837dfc00-a-a cmp dword [ebp-04],+00
[0000217a] 7402-a-a-a-a-a-a jz 0000217e
[0000217c] ebfe-a-a-a-a-a-a jmp 0000217c
[0000217e] 8b45fc-a-a-a-a mov eax,[ebp-04]
[00002181] 8be5-a-a-a-a-a-a mov esp,ebp
[00002183] 5d-a-a-a-a-a-a-a-a pop ebp
[00002184] c3-a-a-a-a-a-a-a-a ret
Size in bytes:(0035) [00002184]
The first five instructions are as
far as DD simulated by HHH can get.
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.
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 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 2025-08-30, olcott <polcott333@gmail.com> 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)
On 8/30/2025 2:49 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <polcott333@gmail.com> 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 A(B).sim mean that B is simulated
or A and B are both simulated?
I think you want:
-a // with static fuses being used:
-a DD_exe is executed
-a 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.
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 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 <polcott333@gmail.com> 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 A(B).sim mean that B is simulated
or A and B are both simulated?
I think you want:
-a // with static fuses being used:
-a DD_exe is executed
-a 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 <polcott333@gmail.com> 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 2025-08-30, olcott <polcott333@gmail.com> wrote:
On 8/30/2025 2:49 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <polcott333@gmail.com> 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.
On 8/30/2025 10:24 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <polcott333@gmail.com> wrote:
On 8/30/2025 2:49 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <polcott333@gmail.com> 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 2025-08-31, olcott <polcott333@gmail.com> wrote:
On 8/30/2025 10:24 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <polcott333@gmail.com> wrote:
On 8/30/2025 2:49 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <polcott333@gmail.com> 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.
What is not smart enough to return the correct value is HHH
itself.
None of the five LLM systems is identifiable as HHH,
so you are not making any interesting point here.
Yes, something other than HHH can decide DD.
On 8/30/2025 10:56 PM, Kaz Kylheku wrote:
On 2025-08-31, olcott <polcott333@gmail.com> wrote:
On 8/30/2025 10:24 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <polcott333@gmail.com> wrote:
On 8/30/2025 2:49 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <polcott333@gmail.com> 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 2025-08-31, olcott <polcott333@gmail.com> wrote:
On 8/30/2025 10:56 PM, Kaz Kylheku wrote:
On 2025-08-31, olcott <polcott333@gmail.com> wrote:
On 8/30/2025 10:24 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <polcott333@gmail.com> wrote:
On 8/30/2025 2:49 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <polcott333@gmail.com> 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().
You still don't get that there is no caller. In the strongest version of
the proof, DD doesn't literally call HHH. It calls its own clean-room reimplementation of the same algorithm that HHH is based on.
If DD is found to halt, then it means that it called
HHH_clean_room_copy(DD) which returned zero.
Because HHH_clean_room_copy is engineered to be precisely equivalent to
HHH in all externaly visible behaviors, it means that HHH(DD) also
returns 0.
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.
When HHH(DD) is deciding, it cannot be excused on the grounds that DD is
an input which its caller. It isn't. It's an input which calls its own internal HHH_clean_room_copy function, which is all part of the
instructions to be analyzed.
If you wnat to dispprove the Halting Theorem, you must assume that DD
has a clean room, independently developed implementation of the HHH algorithm. This implementation could be in any language; it deosn't
have identical code, only identical results; it HHH_clean_room
halts on all the inputs that HHH halts on and returns the same
values, and halt on all inputs that HHH also fails to halt on.
HHH_clean_room wrapped inside DD is a Turing Machine; it is a perfectly legitimate request to ask HHH to decide it and insist that the decision
is about that input.
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 rf?Mrf- reo* M.H rf?Mrf- rf?Mrf- reo* M.reR // accept state
M.q0 rf?Mrf- reo* M.H rf?Mrf- rf?Mrf- reo* M.qn // reject state
*Repeats until aborted proving non-halting*
(a) M copies its input rf?Mrf-
On 2025-08-31, olcott <polcott333@gmail.com> 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.
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 rf?Mrf- reo* M.H rf?Mrf- rf?Mrf- reo* M.reR // accept state
M.q0 rf?Mrf- reo* M.H rf?Mrf- rf?Mrf- reo* M.qn // reject state
*Repeats until aborted proving non-halting*
(a) M copies its input rf?Mrf-
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 11:53 PM, Kaz Kylheku wrote:
On 2025-08-31, olcott <polcott333@gmail.com> 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 <polcott333@gmail.com> wrote:
On 8/30/2025 10:24 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <polcott333@gmail.com> wrote:
On 8/30/2025 2:49 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <polcott333@gmail.com> 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 10:24 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <polcott333@gmail.com> wrote:
On 8/30/2025 2:49 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <polcott333@gmail.com> 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 A(B).sim mean that B is simulated
or A and B are both simulated?
I think you want:
-a-a // with static fuses being used:
-a-a DD_exe is executed
-a-a 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:
-a-a-a abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
-a-a-a return 1.
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
-a int Halt_Status = HHH(DD);
-a if (Halt_Status)
-a-a-a HERE: goto HERE;
-a 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/30/2025 11:53 PM, Kaz Kylheku wrote:
On 2025-08-31, olcott <polcott333@gmail.com> 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 rf?Mrf- reo* M.H rf?Mrf- rf?Mrf- reo* M.reR-a // accept state
M.q0 rf?Mrf- reo* M.H rf?Mrf- rf?Mrf- reo* M.qn // reject state
*Repeats until aborted proving non-halting*
(a) M copies its input rf?Mrf-
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 31/08/2025 06:34, olcott wrote:
On 8/30/2025 11:53 PM, Kaz Kylheku wrote:
On 2025-08-31, olcott <polcott333@gmail.com> 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.
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).
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 <polcott333@gmail.com> wrote:
On 8/30/2025 10:24 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <polcott333@gmail.com> wrote:
On 8/30/2025 2:49 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <polcott333@gmail.com> 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 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.
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 <polcott333@gmail.com> wrote:
On 8/30/2025 10:24 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <polcott333@gmail.com> 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 <polcott333@gmail.com> 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 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 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 <polcott333@gmail.com> wrote:
On 8/30/2025 10:24 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <polcott333@gmail.com> wrote:
On 8/30/2025 2:49 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <polcott333@gmail.com> 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 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 <polcott333@gmail.com> 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.-a So you just agreed with Turing
and Linz.
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 <polcott333@gmail.com> 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 rf?Mrf- reo* M.H rf?Mrf- rf?Mrf- reo* M.reR-a // accept state
M.q0 rf?Mrf- reo* M.H rf?Mrf- rf?Mrf- reo* M.qn // reject state
*Repeats until aborted proving non-halting*
(a) M copies its input rf?Mrf-
(b) M invokes M.H rf?Mrf- rf?Mrf-
(c) M.H simulates rf?Mrf- rf?Mrf-
M.H rf?Mrf- rf?Mrf- cannot report on the behavior of M rf?Mrf-
if M.H rf?Mrf- rf?Mrf- can see the repeating state in its
input then it transitions to rf?M.qnrf- and M rf?Mrf- halts.
This does not contradict M.H rf?Mrf- rf?Mrf- because M rf?Mrf-
is not in the scope of M.H rf?Mrf- rf?Mrf-.
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).
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 <polcott333@gmail.com> wrote:
On 8/30/2025 10:24 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <polcott333@gmail.com> wrote:
On 8/30/2025 2:49 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <polcott333@gmail.com> 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 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 31/08/2025 17:40, dbush wrote:
On 8/31/2025 12:06 PM, olcott wrote:
<snip>
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.-a So you just agreed with Turing and Linz.
He does that a lot when he's not concentrating.
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 rf?Mrf- reo* M.H rf?Mrf- rf?Mrf- reo* M.reR // accept state
M.q0 rf?Mrf- reo* M.H rf?Mrf- rf?Mrf- reo* 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.-a 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 <polcott333@gmail.com> wrote:
On 8/30/2025 10:24 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <polcott333@gmail.com> wrote:
On 8/30/2025 2:49 PM, Kaz Kylheku wrote:
On 2025-08-30, olcott <polcott333@gmail.com> 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 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.