Turing machine deciders only compute the mapping from their inputs...
Thus HHH(DD) is not supposed to report on the behavior of its caller
because its caller *IS NOT ITS INPUT*
Turing machine deciders only compute the mapping
from their inputs...
Thus HHH(DD) is not supposed to report on the behavior
of its caller because its caller *IS NOT ITS INPUT*
<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>
Three different LLM systems figured out that the execution
trace of DD correctly simulated by HHH does match the
*recursive simulation non-halting behavior pattern*
on their own without prompting that such a pattern even
exists. They also figured out that HHH(DD)==0 is correct.
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
Two other LLM systems ChatGPT 5.0 and Gemini did the
same thing yet had to be explicitly told not to guess.
ChatGPT 5.0 admitted that guessing is its new default.
It also wrote a script that forces it and every other
LLM system into *think it through do not guess* mode.
Turing machine deciders only compute the mapping
from their inputs...
Thus HHH(DD) is not supposed to report on the behavior
of its caller because its caller *IS NOT ITS INPUT*
<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>
Three different LLM systems figured out that the execution
trace of DD correctly simulated by HHH does match the
*recursive simulation non-halting behavior pattern*
on their own without prompting that such a pattern even
exists. They also figured out that HHH(DD)==0 is correct.
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
Two other LLM systems ChatGPT 5.0 and Gemini did the
same thing yet had to be explicitly told not to guess.
ChatGPT 5.0 admitted that guessing is its new default.
It also wrote a script that forces it and every other
LLM system into *think it through do not guess* mode.
Op 20.aug.2025 om 18:20 schreef olcott:
Turing machine deciders only compute the mapping
from their inputs...
Thus HHH(DD) is not supposed to report on the behavior
of its caller because its caller *IS NOT ITS INPUT*
<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.
Here Olcott injects his prejudice in the input.
When HHH returns 0, it did not detect a non-termination behaviour
pattern, but it incorrectly assumes a non-termination behaviour
pattern.
HHH does not analyse the conditional branch instructions
encountered during the simulation and it does not prove that the
conditions for alternate branches will not be met when the
simulation would be continued.
Therefore, the abort is premature, and the return value is based
on incorrect assumptions.
Three different LLM systems figured out that the execution
trace of DD correctly simulated by HHH does match the
*recursive simulation non-halting behavior pattern*
on their own without prompting that such a pattern even
exists. They also figured out that HHH(DD)==0 is correct.
Which follows directly from the incorrect input. The conclusion
that HHH is correct is based on the assumption that HHH is
correct. A circular reasoning, that is not a proof.
HOW MANY TIMES DO I HAVE TO SAY THIS BEFORE
YOU NOTICE THAT I EVER SAID IT AT LEAST ONCE?
Turing machine deciders only compute the mapping
from their inputs...
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 8/21/2025 11:20 AM, dbush wrote:
On 8/21/2025 12:13 PM, olcott wrote:I am saying that when DD calls HHH(DD) in recursive simulation that this cannot f-cking be simply ignored.
That all the proofs that I know of Linz in particular require that
mapping from non-input Turing machines that are not mere descriptions.
In other words, you're saying Turing machines can't do arithmetic
because that would require mapping from non-input numbers that are not
mere descriptions.
On 8/21/2025 3:15 AM, Richard Heathfield wrote:
On 21/08/2025 08:55, Fred. Zwarts wrote:
Op 20.aug.2025 om 18:20 schreef olcott:
Turing machine deciders only compute the mapping
from their inputs...
Thus HHH(DD) is not supposed to report on the behavior
of its caller because its caller *IS NOT ITS INPUT*
<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.
Here Olcott injects his prejudice in the input.
When HHH returns 0, it did not detect a non-termination
behaviour pattern, but it incorrectly assumes a
non-termination behaviour pattern.
I did not even tell the LLM systems whether not
not DD halts. They figured out that DD matches the
*recursive simulation non-halting behavior pattern*
on their own and I did not even tell them that this
pattern exists. They figured out the HHH(DD)==0 is
correct and I did not even tell them that DD doesn't halt.
...which is odd, because it then terminates DD. Since DD calls
HHH in the first place (and whether directly or in simulation
shouldn't matter if the simulation is faithful), we may
reasonably deduce that DD exhibits terminating behaviour. HHH
is therefore duty-bound to report to its caller that DD halts.
HOW MANY TIMES DO I HAVE TO SAY THIS BEFORE
YOU NOTICE THAT I EVER SAID IT AT LEAST ONCE?
Turing machine deciders only compute the mapping
from their inputs...
I keep telling you that stopping does not
DOES NOT COUNT AS HALTING
On 8/21/2025 10:54 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
[ .... ]
HOW MANY TIMES DO I HAVE TO SAY THIS BEFORE
YOU NOTICE THAT I EVER SAID IT AT LEAST ONCE?
Turing machine deciders only compute the mapping
from their inputs...
Why do you bother saying it at all? How could it be otherwise?
That all the proofs that I know of Linz in
particular require that mapping from non-input
Turing machines that are not mere descriptions.
Linz requires Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ to report on
the behavior of Ĥ applied to ⟨Ĥ⟩
*From the bottom of page 319 has been adapted to this* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
From the very definition of a turing machine, it does nothing but move
from state to state and read from, write to, and move a tape of
unbounded length.
When you write stuff like the above, people just filter it out because
it is meaninglessly tautological. And boring.
They don't pay close enough attention to see the
significance of it as I outlined above.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 8/21/2025 5:27 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 8/21/2025 10:54 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
[ .... ]
HOW MANY TIMES DO I HAVE TO SAY THIS BEFORE
YOU NOTICE THAT I EVER SAID IT AT LEAST ONCE?
Turing machine deciders only compute the mapping
from their inputs...
Why do you bother saying it at all? How could it be otherwise?
That all the proofs that I know of Linz in
particular require that mapping from non-input
Turing machines that are not mere descriptions.
Either you've misunderstood those proofs, or the authors of those proofs
misunderstood turing machines. My bet is on the former.
What does "non-input turing machine" even mean?
Linz requires Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ to report on
the behavior of Ĥ applied to ⟨Ĥ⟩
At the risk of repeating myself, a turing machine is a system of states
and a tape which can be moved and both read from and written to. The
tape has an initial content, and there is an initial state. Given these
the machine changes state step by step.
There is no "can", there is no "is permitted to", there is no "input"
(except for the initial contents of the tape), there is no need to write
"only ... from their inputs". The turing machine, including its tape
contents, is a mathematical abstraction which is fully determined.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
[ Irrelevant material removed. ]
From the very definition of a turing machine, it does nothing but move >>>> from state to state and read from, write to, and move a tape of
unbounded length.
When you write stuff like the above, people just filter it out because >>>> it is meaninglessly tautological. And boring.
They don't pay close enough attention to see the
significance of it as I outlined above.
No, I think you have failed to grasp the concept of the turing machine.
It was conceived to be as economical as possible whilst still being able
to model any computation. This makes it the standard thing for
discussing computations and proving things about them.
I was just trying to explain to you why people appeared not to notice you
writing truisms about turing machines. They ignore them because they're
of no interest. There's nothing to discuss about these truisms. If you >> repeatedly wrote 2 + 2 = 4, that would likewise get ignored. It's not
interesting either.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
No Turing machine can see its own behavior
thus no Turing machine can report on its
own behavior thus Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ cannot
report on Ĥ applied to ⟨Ĥ⟩ even if Linz and
other proofs say that it must.
On the other hand when Ĥ.embedded_H correctly
simulates its input ⟨Ĥ⟩ ⟨Ĥ⟩ this results in a
non-halting sequence of steps.
On 8/21/2025 2:55 AM, Fred. Zwarts wrote:
Op 20.aug.2025 om 18:20 schreef olcott:
Turing machine deciders only compute the mapping
from their inputs...
Thus HHH(DD) is not supposed to report on the behavior
of its caller because its caller *IS NOT ITS INPUT*
<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.
Here Olcott injects his prejudice in the input.
Incorrect. I just defined the notion of
Simulating Termination Analyzer HHH.
They figured out the *recursive simulation non-halting behavior pattern* entirely on their own without prompting and figured out that HHH(DD)==0
is correct also without prompting. I gave then no hint about whether
DD correctly simulated by HHH halts.
; When HHH returns 0, it did not detect a non-termination behaviour
pattern, but it incorrectly assumes a non-termination behaviour pattern.
HHH does not analyse the conditional branch instructions encountered
during the simulation and it does not prove that the conditions for
alternate branches will not be met when the simulation would be
continued.
Therefore, the abort is premature, and the return value is based on
incorrect assumptions.
(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>
Three different LLM systems figured out that the execution
trace of DD correctly simulated by HHH does match the
*recursive simulation non-halting behavior pattern*
on their own without prompting that such a pattern even
exists. They also figured out that HHH(DD)==0 is correct.
Which follows directly from the incorrect input. The conclusion that
HHH is correct is based on the assumption that HHH is correct. A
circular reasoning, that is not a proof.
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
Two other LLM systems ChatGPT 5.0 and Gemini did the
same thing yet had to be explicitly told not to guess.
ChatGPT 5.0 admitted that guessing is its new default.
It also wrote a script that forces it and every other
LLM system into *think it through do not guess* mode.
On 8/21/2025 3:15 AM, Richard Heathfield wrote:
On 21/08/2025 08:55, Fred. Zwarts wrote:
Op 20.aug.2025 om 18:20 schreef olcott:
Turing machine deciders only compute the mapping
from their inputs...
Thus HHH(DD) is not supposed to report on the behavior
of its caller because its caller *IS NOT ITS INPUT*
<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.
Here Olcott injects his prejudice in the input.
When HHH returns 0, it did not detect a non-termination behaviour
pattern, but it incorrectly assumes a non-termination behaviour pattern.
I did not even tell the LLM systems whether not
not DD halts. They figured out that DD matches the
*recursive simulation non-halting behavior pattern*
on their own and I did not even tell them that this
pattern exists. They figured out the HHH(DD)==0 is
correct and I did not even tell them that DD doesn't halt.
...which is odd, because it then terminates DD. Since DD calls HHH in
the first place (and whether directly or in simulation shouldn't
matter if the simulation is faithful), we may reasonably deduce that
DD exhibits terminating behaviour. HHH is therefore duty-bound to
report to its caller that DD halts.
HOW MANY TIMES DO I HAVE TO SAY THIS BEFORE
YOU NOTICE THAT I EVER SAID IT AT LEAST ONCE?
Turing machine deciders only compute the mapping
from their inputs...
HHH does not analyse the conditional branch instructions encountered
during the simulation and it does not prove that the conditions for
alternate branches will not be met when the simulation would be
continued.
Agreed.
All that HHH need know is that DD correctly simulated
by HHH cannot possibly reach its own "return" instruction
final halt state NO MATTER WHAT HHH DOES.
I keep telling you that stopping does not
DOES NOT COUNT AS HALTING and you keep forgetting.
Therefore, the abort is premature, and the return value is based on
incorrect assumptions.
Agreed.
Three different LLM systems figured out that the execution
trace of DD correctly simulated by HHH does match the
*recursive simulation non-halting behavior pattern*
on their own without prompting that such a pattern even
exists. They also figured out that HHH(DD)==0 is correct.
Should be 1, of course.
Which follows directly from the incorrect input. The conclusion that
HHH is correct is based on the assumption that HHH is correct. A
circular reasoning, that is not a proof.
Agreed.
On 8/22/2025 2:50 AM, Fred. Zwarts wrote:
Op 22.aug.2025 om 00:50 schreef olcott:
On the other hand when Ĥ.embedded_H correctly
simulates its input ⟨Ĥ⟩ ⟨Ĥ⟩ this results in a
non-halting sequence of steps.
Incorrect, it results in a finite recursion.
It *is* an infinite recursion behavior pattern that
is recognized in a finite number of steps the same
way that this infinite recursion behavior pattern
is recognized in a finite number of steps:
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
On 8/22/2025 11:36 AM, Richard Heathfield wrote:
DD() { HHH(); } NOT INFINITE because it has a built-in brake
called HHH.
Conclusion: if HHH detects runaway recursion, it does so
erroneously. DD can't runaway recurse because HHH stops it by
erroneously detecting non- existent runaway recursion and
aborting the run.
When-so-ever HHH correctly predicts that DD
correctly simulated by HHH cannot possibly
reach its own simulated "return" statement
On 8/22/2025 11:36 AM, Richard Heathfield wrote:
When-so-ever HHH correctly predicts that DD
correctly simulated by HHH cannot possibly
reach its own simulated "return" statement
final halt state then HHH is correct to kill
its entire simulation process and return 0.
Liar
On 8/22/2025 2:54 AM, Fred. Zwarts wrote:
Op 21.aug.2025 om 18:36 schreef olcott:
On 8/21/2025 2:55 AM, Fred. Zwarts wrote:
Op 20.aug.2025 om 18:20 schreef olcott:
Turing machine deciders only compute the mapping
from their inputs...
Thus HHH(DD) is not supposed to report on the behavior
of its caller because its caller *IS NOT ITS INPUT*
<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.
Here Olcott injects his prejudice in the input.
Incorrect. I just defined the notion of
Simulating Termination Analyzer HHH.
Pretending that such a thing exists is a prejudice.
A simulating Termination Analyser does not exist.
Assuming that it exists, is not a proof that it does exist. That is an
invalid circular reasoning.
It does not exist, therefore all conclusions are void.
Unlike a halt decider that is required to be all
knowing and correctly decide every input a
termination analyzer only needs to get one input
and all of the inputs to this input correctly.
Since HHH() only takes inputs having no inputs
HHH is a termination analyzer for:
void Infinite_Recursion()
void Infinite_Loop()
int factorial_caller()
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
int factorial(int n)
{
if (n >= 1)
return n*factorial(n-1);
else
return 1;
}
int factorial_caller()
{
factorial(5);
}
On 8/23/2025 3:38 AM, Fred. Zwarts wrote:
Op 22.aug.2025 om 18:27 schreef olcott:
On 8/22/2025 2:54 AM, Fred. Zwarts wrote:
Op 21.aug.2025 om 18:36 schreef olcott:
On 8/21/2025 2:55 AM, Fred. Zwarts wrote:
Op 20.aug.2025 om 18:20 schreef olcott:
Turing machine deciders only compute the mapping
from their inputs...
Thus HHH(DD) is not supposed to report on the behavior
of its caller because its caller *IS NOT ITS INPUT*
<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.
Here Olcott injects his prejudice in the input.
Incorrect. I just defined the notion of
Simulating Termination Analyzer HHH.
Pretending that such a thing exists is a prejudice.
A simulating Termination Analyser does not exist.
Assuming that it exists, is not a proof that it does exist. That is
an invalid circular reasoning.
It does not exist, therefore all conclusions are void.
Unlike a halt decider that is required to be all
knowing and correctly decide every input a
termination analyzer only needs to get one input
and all of the inputs to this input correctly.
Since HHH() only takes inputs having no inputs
HHH is a termination analyzer for:
void Infinite_Recursion()
void Infinite_Loop()
int factorial_caller()
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
int factorial(int n)
{
if (n >= 1)
return n*factorial(n-1);
else
return 1;
}
int factorial_caller()
{
factorial(5);
}
As usual irrelevant claims.
That a buggy program produces a few correct reports by chance is not a
proof that a correct simulating termination analyser exists.
HHH fails for DD, as has been proven many times.
There are no bugs.
It is your lack of technical ability.
HHH uses cooperative multi-tasking to switch between
itself and its simulated DD instance.
DD[0] is invoked and calls HHH[0] that creates a
separate DD[1] process context with its own set of
16 virtual registers and virtual stack.
When HHH[0] encounters the call from DD[1] to HHH[1](DD)
HHH[0] simulates this HHH[1] instance within this same
DD[1] process context.
When HHH[1] begins simulating its own DD[2] it must
create a separate DD[2] process context with its own
set of 16 virtual registers and virtual stack...
on and on until OOM error (proving non-halting) when
we eliminate the u32* execution_trace data.
On 8/23/2025 3:38 AM, Fred. Zwarts wrote:
Op 22.aug.2025 om 18:27 schreef olcott:
On 8/22/2025 2:54 AM, Fred. Zwarts wrote:
Op 21.aug.2025 om 18:36 schreef olcott:
On 8/21/2025 2:55 AM, Fred. Zwarts wrote:
Op 20.aug.2025 om 18:20 schreef olcott:
Turing machine deciders only compute the mapping
from their inputs...
Thus HHH(DD) is not supposed to report on the behavior
of its caller because its caller *IS NOT ITS INPUT*
<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.
Here Olcott injects his prejudice in the input.
Incorrect. I just defined the notion of
Simulating Termination Analyzer HHH.
Pretending that such a thing exists is a prejudice.
A simulating Termination Analyser does not exist.
Assuming that it exists, is not a proof that it does exist. That is
an invalid circular reasoning.
It does not exist, therefore all conclusions are void.
Unlike a halt decider that is required to be all
knowing and correctly decide every input a
termination analyzer only needs to get one input
and all of the inputs to this input correctly.
Since HHH() only takes inputs having no inputs
HHH is a termination analyzer for:
void Infinite_Recursion()
void Infinite_Loop()
int factorial_caller()
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
int factorial(int n)
{
if (n >= 1)
return n*factorial(n-1);
else
return 1;
}
int factorial_caller()
{
factorial(5);
}
As usual irrelevant claims.
That a buggy program produces a few correct reports by chance is not a
proof that a correct simulating termination analyser exists.
HHH fails for DD, as has been proven many times.
There are no bugs.
It is your lack of technical ability.
HHH uses cooperative multi-tasking to switch between
itself and its simulated DD instance.
DD[0] is invoked and calls HHH[0] that creates a
separate DD[1] process context with its own set of
16 virtual registers and virtual stack.
When HHH[0] encounters the call from DD[1] to HHH[1](DD)
HHH[0] simulates this HHH[1] instance within this same
DD[1] process context.
When HHH[1] begins simulating its own DD[2] it must
create a separate DD[2] process context with its own
set of 16 virtual registers and virtual stack...
on and on until OOM error (proving non-halting) when
we eliminate the u32* execution_trace data.
Turing machine deciders only compute the mapping
from their inputs...
Thus HHH(DD) is not supposed to report on the behavior
of its caller because its caller *IS NOT ITS INPUT*
On 8/26/2025 4:29 AM, Mikko wrote:
On 2025-08-20 16:20:21 +0000, olcott said:Turing machines never compute the mapping from their own behavior or the behavior of their caller.
Turing machine deciders only compute the mapping from their inputs...
Not the mapping but some computable mapping. And so do other Turing
machines.
If the mapping is uncomputable there is no Turing machine that computes
it.
No we know that you can't bake a cake in a blender because blenders areThus HHH(DD) is not supposed to report on the behavior of its caller
because its caller *IS NOT ITS INPUT*
Thus we know that HHH is not a halt decider.
not made for baking cakes. Deciders are not made to report on
non-inputs.
On 8/26/2025 12:35 PM, Mr Flibble wrote:
In the case of the Halting Problem diagonalization proofs the
input and
the caller are one in the same you dense muthaf--k.
/Flibble
If that was true then you could prove this at
the C level
On 8/26/2025 12:35 PM, Mr Flibble wrote:
On Tue, 26 Aug 2025 11:29:41 -0500, olcott wrote:If that was true then you could prove this at the C level where the
On 8/26/2025 4:29 AM, Mikko wrote:
On 2025-08-20 16:20:21 +0000, olcott said:Turing machines never compute the mapping from their own behavior or
Turing machine deciders only compute the mapping from their
inputs...
Not the mapping but some computable mapping. And so do other Turing
machines.
If the mapping is uncomputable there is no Turing machine that
computes it.
the behavior of their caller.
No we know that you can't bake a cake in a blender because blendersThus HHH(DD) is not supposed to report on the behavior of its caller >>>>> because its caller *IS NOT ITS INPUT*
Thus we know that HHH is not a halt decider.
are not made for baking cakes. Deciders are not made to report on
non-inputs.
In the case of the Halting Problem diagonalization proofs the input and
the caller are one in the same you dense muthaf--k.
/Flibble
executing process of DD is exactly one-and-the-same-thing as the static finite string of x86 machine code.
On 8/26/2025 12:47 PM, Mr Flibble wrote:
On Tue, 26 Aug 2025 12:39:10 -0500, olcott wrote:You are just not going to get this.
On 8/26/2025 12:35 PM, Mr Flibble wrote:
On Tue, 26 Aug 2025 11:29:41 -0500, olcott wrote:If that was true then you could prove this at the C level where the
On 8/26/2025 4:29 AM, Mikko wrote:
On 2025-08-20 16:20:21 +0000, olcott said:Turing machines never compute the mapping from their own behavior or >>>>> the behavior of their caller.
Turing machine deciders only compute the mapping from their
inputs...
Not the mapping but some computable mapping. And so do other Turing >>>>>> machines.
If the mapping is uncomputable there is no Turing machine that
computes it.
No we know that you can't bake a cake in a blender because blendersThus HHH(DD) is not supposed to report on the behavior of its
caller because its caller *IS NOT ITS INPUT*
Thus we know that HHH is not a halt decider.
are not made for baking cakes. Deciders are not made to report on
non-inputs.
In the case of the Halting Problem diagonalization proofs the input
and the caller are one in the same you dense muthaf--k.
/Flibble
executing process of DD is exactly one-and-the-same-thing as the
static finite string of x86 machine code.
x86 machine code is not "at the C level" however DD can pass,
"at the C level", a pointer to itself to HHH and that pointer will
point to the x86 machine code *representation* of DD. But, yet again, I
must remind you that it doesn't matter what HHH decides because the
caller of HHH, DD, will do the opposite thus confirming that you have
not refuted the Halting Problem diagonalization proofs.
/Flibble
That does not make me wrong.
Turing machines cannot report on the behavior of their caller for the
same kind of reason that you cannot bake an actual cake in a blender.
On 8/26/2025 12:47 PM, Mr Flibble wrote:
On Tue, 26 Aug 2025 12:39:10 -0500, olcott wrote:
On 8/26/2025 12:35 PM, Mr Flibble wrote:
On Tue, 26 Aug 2025 11:29:41 -0500, olcott wrote:If that was true then you could prove this at the C level
On 8/26/2025 4:29 AM, Mikko wrote:
On 2025-08-20 16:20:21 +0000, olcott said:Turing machines never compute the mapping from their own
Turing machine deciders only compute the mapping from their
inputs...
Not the mapping but some computable mapping. And so do
other Turing
machines.
If the mapping is uncomputable there is no Turing machine that
computes it.
behavior or
the behavior of their caller.
No we know that you can't bake a cake in a blender becauseThus HHH(DD) is not supposed to report on the behavior of
its caller
because its caller *IS NOT ITS INPUT*
Thus we know that HHH is not a halt decider.
blenders
are not made for baking cakes. Deciders are not made to
report on
non-inputs.
In the case of the Halting Problem diagonalization proofs the
input and
the caller are one in the same you dense muthaf--k.
/Flibble
where the
executing process of DD is exactly one-and-the-same-thing as
the static
finite string of x86 machine code.
x86 machine code is not "at the C level" however DD can pass,
"at the C level", a pointer to itself to HHH and that pointer
will point
to the x86 machine code *representation* of DD. But, yet again,
I must
remind you that it doesn't matter what HHH decides because the
caller of
HHH, DD, will do the opposite thus confirming that you have not
refuted
the Halting Problem diagonalization proofs.
/Flibble
You are just not going to get this.
That does not make me wrong.
Turing machines cannot report on the behavior
of their caller for the same kind of reason
that you cannot bake an actual cake in a blender.
On 8/26/2025 1:14 PM, Mr Flibble wrote:
On Tue, 26 Aug 2025 13:08:35 -0500, olcott wrote:
On 8/26/2025 12:47 PM, Mr Flibble wrote:
On Tue, 26 Aug 2025 12:39:10 -0500, olcott wrote:You are just not going to get this.
On 8/26/2025 12:35 PM, Mr Flibble wrote:
On Tue, 26 Aug 2025 11:29:41 -0500, olcott wrote:If that was true then you could prove this at the C level where the
On 8/26/2025 4:29 AM, Mikko wrote:
On 2025-08-20 16:20:21 +0000, olcott said:Turing machines never compute the mapping from their own behavior >>>>>>> or the behavior of their caller.
Turing machine deciders only compute the mapping from their
inputs...
Not the mapping but some computable mapping. And so do other
Turing machines.
If the mapping is uncomputable there is no Turing machine that >>>>>>>> computes it.
No we know that you can't bake a cake in a blender becauseThus HHH(DD) is not supposed to report on the behavior of its >>>>>>>>> caller because its caller *IS NOT ITS INPUT*
Thus we know that HHH is not a halt decider.
blenders are not made for baking cakes. Deciders are not made to >>>>>>> report on non-inputs.
In the case of the Halting Problem diagonalization proofs the input >>>>>> and the caller are one in the same you dense muthaf--k.
/Flibble
executing process of DD is exactly one-and-the-same-thing as the
static finite string of x86 machine code.
x86 machine code is not "at the C level" however DD can pass,
"at the C level", a pointer to itself to HHH and that pointer will
point to the x86 machine code *representation* of DD. But, yet again,
I must remind you that it doesn't matter what HHH decides because the
caller of HHH, DD, will do the opposite thus confirming that you have
not refuted the Halting Problem diagonalization proofs.
/Flibble
That does not make me wrong.
Turing machines cannot report on the behavior of their caller for the
same kind of reason that you cannot bake an actual cake in a blender.
Meaningless vapid analogy. Again: DD has *two* roles: caller *and*
input,
DD can act as *both* simultaneously.You must not know C very well.
/Flibble
On 8/26/2025 12:45 PM, Richard Heathfield wrote:
On 26/08/2025 18:39, olcott wrote:
On 8/26/2025 12:35 PM, Mr Flibble wrote:
<snip>
In the case of the Halting Problem diagonalization proofs the
input and
the caller are one in the same you dense muthaf--k.
/Flibble
If that was true then you could prove this at
the C level
You *really* don't want to go there. You have quite enough
problems already.
Dishonest dodge noted.
On 8/26/2025 1:14 PM, Mr Flibble wrote:
On Tue, 26 Aug 2025 13:08:35 -0500, olcott wrote:
On 8/26/2025 12:47 PM, Mr Flibble wrote:
On Tue, 26 Aug 2025 12:39:10 -0500, olcott wrote:You are just not going to get this.
On 8/26/2025 12:35 PM, Mr Flibble wrote:
On Tue, 26 Aug 2025 11:29:41 -0500, olcott wrote:If that was true then you could prove this at the C level
On 8/26/2025 4:29 AM, Mikko wrote:
On 2025-08-20 16:20:21 +0000, olcott said:Turing machines never compute the mapping from their own
Turing machine deciders only compute the mapping from their
inputs...
Not the mapping but some computable mapping. And so do
other Turing
machines.
If the mapping is uncomputable there is no Turing machine
that
computes it.
behavior or
the behavior of their caller.
No we know that you can't bake a cake in a blender becauseThus HHH(DD) is not supposed to report on the behavior
of its
caller because its caller *IS NOT ITS INPUT*
Thus we know that HHH is not a halt decider.
blenders
are not made for baking cakes. Deciders are not made to
report on
non-inputs.
In the case of the Halting Problem diagonalization proofs
the input
and the caller are one in the same you dense muthaf--k.
/Flibble
where the
executing process of DD is exactly one-and-the-same-thing as
the
static finite string of x86 machine code.
x86 machine code is not "at the C level" however DD can pass,
"at the C level", a pointer to itself to HHH and that pointer
will
point to the x86 machine code *representation* of DD. But,
yet again, I
must remind you that it doesn't matter what HHH decides
because the
caller of HHH, DD, will do the opposite thus confirming that
you have
not refuted the Halting Problem diagonalization proofs.
/Flibble
That does not make me wrong.
Turing machines cannot report on the behavior of their caller
for the
same kind of reason that you cannot bake an actual cake in a
blender.
Meaningless vapid analogy. Again: DD has *two* roles: caller
*and* input,
DD can act as *both* simultaneously.
/Flibble
You must not know C very well.
On 8/26/2025 1:19 PM, Mr Flibble wrote:
On Tue, 26 Aug 2025 13:15:44 -0500, olcott wrote:
DD can act as *both* simultaneously.You must not know C very well.
I know C better than you: I have been coding C/C++ since 1992.
I have been coding C long before that since K&R was
the standard.
DD can act as both because it *calls* HHH passing a
*description* of
itself to HHH as an *input*.
A pointer to a static string of x86 code
*IS NOT* exactly one-and-the-same-thing
as an executing process.
On 8/26/2025 1:19 PM, Mr Flibble wrote:
On Tue, 26 Aug 2025 13:15:44 -0500, olcott wrote:I have been coding C long before that since K&R was the standard.
On 8/26/2025 1:14 PM, Mr Flibble wrote:
On Tue, 26 Aug 2025 13:08:35 -0500, olcott wrote:
On 8/26/2025 12:47 PM, Mr Flibble wrote:
On Tue, 26 Aug 2025 12:39:10 -0500, olcott wrote:You are just not going to get this.
On 8/26/2025 12:35 PM, Mr Flibble wrote:
On Tue, 26 Aug 2025 11:29:41 -0500, olcott wrote:If that was true then you could prove this at the C level where
On 8/26/2025 4:29 AM, Mikko wrote:
On 2025-08-20 16:20:21 +0000, olcott said:Turing machines never compute the mapping from their own
Turing machine deciders only compute the mapping from their >>>>>>>>>>> inputs...
Not the mapping but some computable mapping. And so do other >>>>>>>>>> Turing machines.
If the mapping is uncomputable there is no Turing machine that >>>>>>>>>> computes it.
behavior or the behavior of their caller.
No we know that you can't bake a cake in a blender becauseThus HHH(DD) is not supposed to report on the behavior of its >>>>>>>>>>> caller because its caller *IS NOT ITS INPUT*
Thus we know that HHH is not a halt decider.
blenders are not made for baking cakes. Deciders are not made to >>>>>>>>> report on non-inputs.
In the case of the Halting Problem diagonalization proofs the
input and the caller are one in the same you dense muthaf--k.
/Flibble
the executing process of DD is exactly one-and-the-same-thing as >>>>>>> the static finite string of x86 machine code.
x86 machine code is not "at the C level" however DD can pass,
"at the C level", a pointer to itself to HHH and that pointer will >>>>>> point to the x86 machine code *representation* of DD. But, yet
again,
I must remind you that it doesn't matter what HHH decides because
the caller of HHH, DD, will do the opposite thus confirming that
you have not refuted the Halting Problem diagonalization proofs.
/Flibble
That does not make me wrong.
Turing machines cannot report on the behavior of their caller for
the same kind of reason that you cannot bake an actual cake in a
blender.
Meaningless vapid analogy. Again: DD has *two* roles: caller *and*
input,
DD can act as *both* simultaneously.You must not know C very well.
/Flibble
I know C better than you: I have been coding C/C++ since 1992.
DD can act as both because it *calls* HHH passing a *description* of
itself to HHH as an *input*.
A pointer to a static string of x86 code *IS NOT* exactly one-and-the-same-thing as an executing process.
On 8/26/2025 4:29 AM, Mikko wrote:
On 2025-08-20 16:20:21 +0000, olcott said:
Turing machine deciders only compute the mapping
from their inputs...
Not the mapping but some computable mapping. And so do other Turing
machines.
If the mapping is uncomputable there is no Turing machine that computes it. >>
Turing machines never compute the mapping
from their own behavior or the behavior
of their caller.
On 8/26/2025 4:29 AM, Mikko wrote:
On 2025-08-20 16:20:21 +0000, olcott said:
Turing machine deciders only compute the mapping
from their inputs...
Not the mapping but some computable mapping. And so do other Turing
machines.
If the mapping is uncomputable there is no Turing machine that
computes it.
Turing machines never compute the mapping
from their own behavior or the behavior
of their caller.
Thus HHH(DD) is not supposed to report on the behavior
of its caller because its caller *IS NOT ITS INPUT*
Thus we know that HHH is not a halt decider.
No we know that you can't bake a cake in a blender
because blenders are not made for baking cakes.
Deciders are not made to report on non-inputs.
On 8/26/2025 4:39 PM, Kaz Kylheku wrote:
On 2025-08-26, olcott <polcott333@gmail.com> wrote:
On 8/26/2025 4:29 AM, Mikko wrote:
On 2025-08-20 16:20:21 +0000, olcott said:
Turing machine deciders only compute the mapping
from their inputs...
Not the mapping but some computable mapping. And so do other Turing
machines.
If the mapping is uncomputable there is no Turing machine that computes it.
Turing machines never compute the mapping
from their own behavior or the behavior
of their caller.
Turing machines do not have a caller.
Turing Machine Linz Ĥ applied to its own machine description ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
its simulated final halt state of ⟨Ĥ.qn⟩, and
On 8/26/2025 4:29 AM, Mikko wrote:
On 2025-08-20 16:20:21 +0000, olcott said:
Turing machine deciders only compute the mapping
from their inputs...
Not the mapping but some computable mapping. And so do other Turing
machines.
If the mapping is uncomputable there is no Turing machine that computes it.
Turing machines never compute the mapping
from their own behavior or the behavior
of their caller.
Thus HHH(DD) is not supposed to report on the behavior
of its caller because its caller *IS NOT ITS INPUT*
Thus we know that HHH is not a halt decider.
No we know that you can't bake a cake in a blender
because blenders are not made for baking cakes.
Deciders are not made to report on non-inputs.
On 2025-08-26 16:29:41 +0000, olcott said:
No we know that you can't bake a cake in a blender
because blenders are not made for baking cakes.
Deciders are not made to report on non-inputs.
Requirements for a new blender may specify that it must be possible
to bake a cake in that new blender.
Sure and we can say that TM Y is required
to provide the square-root of a dead squirrel.
On 8/27/2025 10:30 AM, Richard Heathfield wrote:
On 27/08/2025 16:09, olcott wrote:
<snip>
Sure and we can say that TM Y is required
to provide the square-root of a dead squirrel.
You have failed to make a case for a TM being unable to read
and process a tape. Squirrels are not tapes.
M.q0 ⟨M⟩ ⊢* M.embedded_H ⟨M⟩ ⟨M⟩ ⊢* M.∞,
if M applied to ⟨M⟩ halts, and
M.q0 ⟨M⟩ ⊢* M.embedded_H ⟨M⟩ ⟨M⟩ ⊢* M.qn
if M applied to ⟨M⟩ does not halt.
M.embedded_H cannot report on the behavior of its
caller machine M because no TM can take another
actual TM as its input.
M.embedded_H can report on the non-halting
behavior of its input in that ⟨M⟩ ⟨M⟩ correctly
simulated by M.embedded_H cannot possibly reach
its own simulated final halt state of ⟨M.qn⟩
On 8/27/2025 10:50 AM, Richard Heathfield wrote:
On 27/08/2025 16:40, olcott wrote:
On 8/27/2025 10:30 AM, Richard Heathfield wrote:
On 27/08/2025 16:09, olcott wrote:
<snip>
Sure and we can say that TM Y is required
to provide the square-root of a dead squirrel.
You have failed to make a case for a TM being unable to read
and process a tape. Squirrels are not tapes.
M.q0 ⟨M⟩ ⊢* M.embedded_H ⟨M⟩ ⟨M⟩ ⊢* M.∞,
if M applied to ⟨M⟩ halts, and
M.q0 ⟨M⟩ ⊢* M.embedded_H ⟨M⟩ ⟨M⟩ ⊢* M.qn
if M applied to ⟨M⟩ does not halt.
M.embedded_H cannot report on the behavior of its
caller machine M because no TM can take another
actual TM as its input.
M.embedded_H can report on the non-halting
behavior of its input in that ⟨M⟩ ⟨M⟩ correctly
simulated by M.embedded_H cannot possibly reach
its own simulated final halt state of ⟨M.qn⟩
That is not a case for a TM being unable to read and process a
tape.
Assume you can write a universal halt decider.
That correctly determines the halt status specified
by its inputs. Then the Linz proof does not show that
such a decider does not exist.
On 8/27/2025 10:50 AM, Richard Heathfield wrote:It can still compute what it would do when executed.
On 27/08/2025 16:40, olcott wrote:
On 8/27/2025 10:30 AM, Richard Heathfield wrote:
On 27/08/2025 16:09, olcott wrote:
You have failed to make a case for a TM being unable to read and
process a tape.
M.embedded_H cannot report on the behavior of its caller machine M
because no TM can take another actual TM as its input.
A string does not behave. Inside the simulation DD halts; only HHHM.embedded_H can report on the non-halting behavior of its input in
That correctly determines the halt status specified by its inputs. ThenIt shows that no decider can report on the direct execution of at least
the Linz proof does not show that such a decider does not exist.
On 8/27/2025 12:25 PM, Richard Heathfield wrote:
On 27/08/2025 17:07, olcott wrote:
On 8/27/2025 10:50 AM, Richard Heathfield wrote:
Assume you can write a universal halt decider.
That correctly determines the halt status specified
by its inputs. Then the Linz proof does not show that
such a decider does not exist.
Yes it does, and on the way he scuppers simulation. No wonder
you don't like him.
WTF does scuppers mean?
No HHH cannot report on the behavior of its caller.
DD correctly simulated by HHH cannot possibly halt.
On 8/27/2025 1:48 PM, Richard Heathfield wrote:
On 27/08/2025 19:43, olcott wrote:
<snip>
DD correctly simulated by HHH cannot possibly halt.
And yet it halts, as you yourself have conceded.
Is the same as Bill's identical twin brother
John robbed a liquor store thus making Bill guilty.
On 8/27/2025 1:47 PM, Richard Heathfield wrote:
On 27/08/2025 19:42, olcott wrote:
<snip>
No HHH cannot report on the behavior of its caller.
Then it's not fit for purpose,
In the same way that no blender is fit for the
purpose of baking a cake.
On 8/27/2025 2:10 PM, Richard Heathfield wrote:
On 27/08/2025 19:54, olcott wrote:
On 8/27/2025 1:47 PM, Richard Heathfield wrote:
On 27/08/2025 19:42, olcott wrote:
<snip>
No HHH cannot report on the behavior of its caller.
Then it's not fit for purpose,
In the same way that no blender is fit for the
purpose of baking a cake.
No, in the same way that no blender is fit for purpose if it
can't blend.
No it the same as a Turing machine halt decider
cannot bake you a cake even if it is required to.
On 8/27/2025 2:03 PM, Richard Heathfield wrote:
On 27/08/2025 19:53, olcott wrote:
On 8/27/2025 1:48 PM, Richard Heathfield wrote:
On 27/08/2025 19:43, olcott wrote:
<snip>
DD correctly simulated by HHH cannot possibly halt.
And yet it halts, as you yourself have conceded.
Is the same as Bill's identical twin brother
John robbed a liquor store thus making Bill guilty.
No, it's the same as John robbing a liquor store thus making
John guilty.
Not at all You said that HHH is wrong because something
that looks like (yet is not) its input halts.
On 8/27/2025 2:03 PM, Richard Heathfield wrote:
On 27/08/2025 19:53, olcott wrote:
On 8/27/2025 1:48 PM, Richard Heathfield wrote:
On 27/08/2025 19:43, olcott wrote:
<snip>
DD correctly simulated by HHH cannot possibly halt.
And yet it halts, as you yourself have conceded.
Is the same as Bill's identical twin brother
John robbed a liquor store thus making Bill guilty.
No, it's the same as John robbing a liquor store thus making
John guilty.
As Kaz said (paraphrase) DD.executed has a different
name than DD.simulated_by_HHH.
DD.executed looks like DD.simulated_by_HHH yet
because they specify a different sequence of steps
(that you already acknowledged) they are not the same.
On 8/27/2025 2:30 PM, Richard Heathfield wrote:
On 27/08/2025 20:16, olcott wrote:
On 8/27/2025 2:10 PM, Richard Heathfield wrote:
On 27/08/2025 19:54, olcott wrote:
On 8/27/2025 1:47 PM, Richard Heathfield wrote:
On 27/08/2025 19:42, olcott wrote:
<snip>
No HHH cannot report on the behavior of its caller.
Then it's not fit for purpose,
In the same way that no blender is fit for the
purpose of baking a cake.
No, in the same way that no blender is fit for purpose if it
can't blend.
No it the same as a Turing machine halt decider
cannot bake you a cake even if it is required to.
This really is a rubbish analogy.
It is the same as requiring a halt decider
to report on the behavior of its caller.
On 8/27/2025 3:44 PM, olcott wrote:
On 8/27/2025 2:36 PM, Richard Heathfield wrote:
On 27/08/2025 20:24, olcott wrote:
On 8/27/2025 2:03 PM, Richard Heathfield wrote:
On 27/08/2025 19:53, olcott wrote:
On 8/27/2025 1:48 PM, Richard Heathfield wrote:
On 27/08/2025 19:43, olcott wrote:
<snip>
DD correctly simulated by HHH cannot possibly halt.
And yet it halts, as you yourself have conceded.
Is the same as Bill's identical twin brother
John robbed a liquor store thus making Bill guilty.
No, it's the same as John robbing a liquor store thus making
John guilty.
Not at all You said that HHH is wrong because something
that looks like (yet is not) its input halts.
Citation needed. I don't recall saying those words.
DD.executed looks like DD.simulated_by_HHH yet
because they specify a different sequence of steps
(that you already acknowledged) they are not the same.
In other words, the directly executed DD calls HHH with an empty
stack trace, and that is what is given to the directly executed
HHH(DD), but HHH then simulates DD calling HHH with a non-empty
stack trace.
A halt decider correctly reports on the behavior
that its input specifies
On 8/27/2025 2:54 PM, Richard Heathfield wrote:
On 27/08/2025 20:44, olcott wrote:
<snip>
DD.executed looks like DD.simulated_by_HHH yet
because they specify a different sequence of steps
(that you already acknowledged) they are not the same.
They're constraint violations requiring diagnostic messages
from your implementation.
DD() does not halt
, it looks like it halts because
the infinite recursion that it specifies
On 8/27/2025 3:39 PM, Richard Heathfield wrote:
On 27/08/2025 21:01, olcott wrote:
<snip>
A halt decider correctly reports on the behavior
that its input specifies
Then you don't have one, because it doesn't.
*Thats not what you said*
On 8/18/2025 6:05 PM, Richard Heathfield wrote:
It is an easily verified fact, as you love to say,
that if DD calls HHH (as it does) and HHH calls DD
(as, through simulation, it effectively does) that
HHH(DD) can never halt naturally, so it will have
to abort the recursion and report its result as 0
- didn't halt.
On 8/27/2025 3:43 PM, Richard Heathfield wrote:
On 27/08/2025 21:04, olcott wrote:
On 8/27/2025 2:54 PM, Richard Heathfield wrote:
On 27/08/2025 20:44, olcott wrote:
<snip>
DD.executed looks like DD.simulated_by_HHH yet
because they specify a different sequence of steps
(that you already acknowledged) they are not the same.
They're constraint violations requiring diagnostic messages
from your implementation.
DD() does not halt
Yeah, it does.
, it looks like it halts because
the infinite recursion that it specifies
But it specifies no such thing. It specifies a call to a
function that plays silly buggers and then returns a value.
Over and over and over you have said that HHH returns a value
--- which indeed it must in order to report its decision.
Since it returns a value, there is clearly no infinite recursion.
It returns a value indicating that DD correctly
simulated by HHH cannot possibly reach its own
halt state.
On 8/27/2025 4:43 PM, Richard Heathfield wrote:V--- returns 0
On 27/08/2025 22:15, olcott wrote:
On 8/27/2025 3:39 PM, Richard Heathfield wrote:
On 27/08/2025 21:01, olcott wrote:
<snip>
A halt decider correctly reports on the behavior
that its input specifies
Then you don't have one, because it doesn't.
*Thats not what you said*
Yeah, it is.
On 8/18/2025 6:05 PM, Richard Heathfield wrote:
It is an easily verified fact, as you love to say,
that if DD calls HHH (as it does) and HHH calls DD
(as, through simulation, it effectively does) that
HHH(DD) can never halt naturally, so it will have
to abort the recursion and report its result as 0
- didn't halt.
;
Yup. HHH has to report, right? So it has to pull the plug on
what it thinks is unhalting behaviour. Now it can report. But
what? Well, the simulator didn't reach a halt state, so it
can't report 1, but that only leaves 0.
HHH that reports in the same behavior as five chat bots
<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);receives 0--^
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
What value should HHH(DD) correctly return?
<Input to LLM systems>
returns 0 on the basis of the above static text.
On 8/27/2025 4:49 PM, Richard Heathfield wrote:
On 27/08/2025 22:17, olcott wrote:
On 8/27/2025 3:43 PM, Richard Heathfield wrote:
On 27/08/2025 21:04, olcott wrote:
On 8/27/2025 2:54 PM, Richard Heathfield wrote:
On 27/08/2025 20:44, olcott wrote:
<snip>
DD.executed looks like DD.simulated_by_HHH yet
because they specify a different sequence of steps
(that you already acknowledged) they are not the same.
They're constraint violations requiring diagnostic messages
from your implementation.
DD() does not halt
Yeah, it does.
, it looks like it halts because
the infinite recursion that it specifies
But it specifies no such thing. It specifies a call to a
function that plays silly buggers and then returns a value.
Over and over and over you have said that HHH returns a value
--- which indeed it must in order to report its decision.
Since it returns a value, there is clearly no infinite
recursion.
It returns a value indicating that DD correctly
simulated by HHH cannot possibly reach its own
halt state.
"Correctly simulated" would surely entail getting the answer
right.
Besides, HHH /could/ simulate DD better than it does, by *not*
canning the simulation when it detects running away recursion.
It could say "okay, that's going off down the rabbit hole, so
instead of chasing it or killing it let's /imagine/ we killed
it, and plug in a 0 return from... er... *that* HHH call, and
continue simulating from there."
That way, at least you'd /reach/ the Turing Twist. Got to be an
improvement, surely?
I am going to stop responding to posts as dumb as this one too.
Richard Heathfield <rjh@cpax.org.uk> writes:
[...]
If you're curious, see Theorem 12.1 in AN INTRODUCTION TO FORMAL
LANGUAGES AND AUTOMATA.
<https://[SNIP]>
That's a PDF copy of the 6th edition of Peter Linz's book, provided
on the personal website of a computer science student. Page 3
includes a clear copyright statement, dated 2017. I don't believe
the copyright holder has given permission to freely distribute
the book.
On 8/27/2025 5:07 PM, Richard Heathfield wrote:
On 27/08/2025 22:59, olcott wrote:
On 8/27/2025 4:43 PM, Richard Heathfield wrote:V--- returns 0
On 27/08/2025 22:15, olcott wrote:
On 8/27/2025 3:39 PM, Richard Heathfield wrote:
On 27/08/2025 21:01, olcott wrote:
<snip>
A halt decider correctly reports on the behavior
that its input specifies
Then you don't have one, because it doesn't.
*Thats not what you said*
Yeah, it is.
On 8/18/2025 6:05 PM, Richard Heathfield wrote:
It is an easily verified fact, as you love to say,
that if DD calls HHH (as it does) and HHH calls DD
(as, through simulation, it effectively does) that
HHH(DD) can never halt naturally, so it will have
to abort the recursion and report its result as 0
- didn't halt.
;
Yup. HHH has to report, right? So it has to pull the plug on
what it thinks is unhalting behaviour. Now it can report. But
what? Well, the simulator didn't reach a halt state, so it
can't report 1, but that only leaves 0.
HHH that reports in the same behavior as five chat bots
<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);receives 0--^
VVVVVVVVVVVVVVVV if(0) is false
if (Halt_Status)
VVVVVVVVVVVVVVV doesn't happen
HERE: goto HERE;
V---- reaches return statement and halts
return Halt_Status;
}
What value should HHH(DD) correctly return?
<Input to LLM systems>
returns 0 on the basis of the above static text.
0 means "non-halting". Nice try. Wrong, but nice try.
If it's any consolation, 1 is wrong as well.
No the problem is that in 89 years no one noticed
that the short-hand notion of M halts in input P
does not always correspond to the input to H(⟨M⟩,P)
specifies a halting computation.
I have proven this and you acknowledged this
On 8/18/2025 6:05 PM, Richard Heathfield wrote:
It is an easily verified fact, as you love to say,
that if DD calls HHH (as it does) and HHH calls DD
(as, through simulation, it effectively does) that
HHH(DD) can never halt naturally, so it will have
to abort the recursion and report its result as 0
On 8/27/2025 5:11 PM, Richard Heathfield wrote:
On 27/08/2025 23:03, olcott wrote:
On 8/27/2025 4:49 PM, Richard Heathfield wrote:
On 27/08/2025 22:17, olcott wrote:
On 8/27/2025 3:43 PM, Richard Heathfield wrote:
On 27/08/2025 21:04, olcott wrote:
On 8/27/2025 2:54 PM, Richard Heathfield wrote:
On 27/08/2025 20:44, olcott wrote:
<snip>
DD.executed looks like DD.simulated_by_HHH yet
because they specify a different sequence of steps
(that you already acknowledged) they are not the same.
They're constraint violations requiring diagnostic
messages from your implementation.
DD() does not halt
Yeah, it does.
, it looks like it halts because
the infinite recursion that it specifies
But it specifies no such thing. It specifies a call to a
function that plays silly buggers and then returns a value.
Over and over and over you have said that HHH returns a
value --- which indeed it must in order to report its
decision.
Since it returns a value, there is clearly no infinite
recursion.
It returns a value indicating that DD correctly
simulated by HHH cannot possibly reach its own
halt state.
"Correctly simulated" would surely entail getting the answer
right.
Besides, HHH /could/ simulate DD better than it does, by
*not* canning the simulation when it detects running away
recursion.
It could say "okay, that's going off down the rabbit hole, so
instead of chasing it or killing it let's /imagine/ we killed
it, and plug in a 0 return from... er... *that* HHH call, and
continue simulating from there."
That way, at least you'd /reach/ the Turing Twist. Got to be
an improvement, surely?
I am going to stop responding to posts as dumb as this one too.
Since olcott is too "dumb" (as he puts it) to figure out what
I'm getting at, perhaps someone else would be good enough to
comment on my suggestion for improving HHH's coverage of DD's
code.
You know that your idea was ridiculously stupid.
(1) When HHH(DD) would return 0 THIS WOULD BE CORRECT
(2) Halt decider ONLY report on the behavior that
actual their input actually specifies
and the input
to HHH(DD) SPECIFIES NON-HALTING.
On 8/27/2025 10:30 PM, Richard Heathfield wrote:
On 28/08/2025 03:59, olcott wrote:
(1) When HHH(DD) would return 0 THIS WOULD BE CORRECT
Only until it isn't.
(2) Halt decider ONLY report on the behavior that
actual their input actually specifies
The input is DD.
and the input
to HHH(DD) SPECIFIES NON-HALTING.
And so HHH(DD)'s output to DD is non-halting, which DD uses to
halt, making HHH's answer wrong.
If you really understood Turing machine deciders you
would already know that they only compute the mapping
from their actual input finite strings.
On 8/27/2025 11:46 PM, olcott wrote:
If you really understood Turing machine deciders you
would already know that they only compute the mapping
from their actual input finite strings.
Yet you claim they must report on non-inputs (see below):
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
If you really understood the question you would realise that
nobody gives a damn whether DD halts when being simulated.
This is the key that proves the HP proofs are incorrect.
DD simulated by HHH is a correct measure the behavior
that the input to HHH(DD) specifies.
On 8/26/2025 4:29 AM, Mikko wrote:
On 2025-08-20 16:20:21 +0000, olcott said:
Turing machine deciders only compute the mapping
from their inputs...
Not the mapping but some computable mapping. And so do other Turing
machines.
If the mapping is uncomputable there is no Turing machine that computes it.
Turing machines never compute the mapping
from their own behavior or the behavior
of their caller.
On 8/27/2025 3:05 AM, Mikko wrote:
On 2025-08-26 16:29:41 +0000, olcott said:
On 8/26/2025 4:29 AM, Mikko wrote:
On 2025-08-20 16:20:21 +0000, olcott said:
Turing machine deciders only compute the mapping
from their inputs...
Not the mapping but some computable mapping. And so do other Turing
machines.
If the mapping is uncomputable there is no Turing machine that computes it.
Turing machines never compute the mapping
from their own behavior or the behavior
of their caller.
However, a requirement may define the required mapping in terms of the
behaviour (or other properties) of some Turing machine.
Sure and we can say that TM Y is required
to provide the square-root of a dead squirrel.
On 8/27/2025 9:45 PM, Richard Heathfield wrote:
On 27/08/2025 23:27, olcott wrote:
On 8/27/2025 5:11 PM, Richard Heathfield wrote:
On 27/08/2025 23:03, olcott wrote:
On 8/27/2025 4:49 PM, Richard Heathfield wrote:
On 27/08/2025 22:17, olcott wrote:
On 8/27/2025 3:43 PM, Richard Heathfield wrote:
On 27/08/2025 21:04, olcott wrote:
On 8/27/2025 2:54 PM, Richard Heathfield wrote:
On 27/08/2025 20:44, olcott wrote:
<snip>
DD.executed looks like DD.simulated_by_HHH yet
because they specify a different sequence of steps
(that you already acknowledged) they are not the same.
They're constraint violations requiring diagnostic messages >>>>>>>>>> from your implementation.
DD() does not halt
Yeah, it does.
, it looks like it halts because
the infinite recursion that it specifies
But it specifies no such thing. It specifies a call to a
function that plays silly buggers and then returns a value.
Over and over and over you have said that HHH returns a value
--- which indeed it must in order to report its decision.
Since it returns a value, there is clearly no infinite recursion. >>>>>>>>
It returns a value indicating that DD correctly
simulated by HHH cannot possibly reach its own
halt state.
"Correctly simulated" would surely entail getting the answer right. >>>>>>
Besides, HHH /could/ simulate DD better than it does, by *not*
canning the simulation when it detects running away recursion.
It could say "okay, that's going off down the rabbit hole, so
instead of chasing it or killing it let's /imagine/ we killed it,
and plug in a 0 return from... er... *that* HHH call, and continue >>>>>> simulating from there."
That way, at least you'd /reach/ the Turing Twist. Got to be an
improvement, surely?
I am going to stop responding to posts as dumb as this one too.
Since olcott is too "dumb" (as he puts it) to figure out what I'm
getting at, perhaps someone else would be good enough to comment on
my suggestion for improving HHH's coverage of DD's code.
You know that your idea was ridiculously stupid.
No stupider than trying to overturn a self-evident proof.
What I just said in my prior reply to you is:
PROVEN TOTALLY TRUE ENTIRELY ON THE BASIS OF THE MEANING OF ITS WORDS (SELF-EVIDENTLY TRUE)
On 27/08/2025 23:24, olcott wrote:
On 8/27/2025 5:07 PM, Richard Heathfield wrote:
On 27/08/2025 22:59, olcott wrote:
On 8/27/2025 4:43 PM, Richard Heathfield wrote:V--- returns 0
On 27/08/2025 22:15, olcott wrote:
On 8/27/2025 3:39 PM, Richard Heathfield wrote:
On 27/08/2025 21:01, olcott wrote:
<snip>
A halt decider correctly reports on the behavior
that its input specifies
Then you don't have one, because it doesn't.
*Thats not what you said*
Yeah, it is.
On 8/18/2025 6:05 PM, Richard Heathfield wrote:
It is an easily verified fact, as you love to say,
that if DD calls HHH (as it does) and HHH calls DD
(as, through simulation, it effectively does) that
HHH(DD) can never halt naturally, so it will have
to abort the recursion and report its result as 0
- didn't halt.
;
Yup. HHH has to report, right? So it has to pull the plug on what
it thinks is unhalting behaviour. Now it can report. But what?
Well, the simulator didn't reach a halt state, so it can't report
1, but that only leaves 0.
HHH that reports in the same behavior as five chat bots
<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);receives 0--^
VVVVVVVVVVVVVVVV if(0) is false
if (Halt_Status)
VVVVVVVVVVVVVVV doesn't happen
HERE: goto HERE;
V---- reaches return statement and halts
return Halt_Status;
}
What value should HHH(DD) correctly return?
<Input to LLM systems>
returns 0 on the basis of the above static text.
0 means "non-halting". Nice try. Wrong, but nice try.
If it's any consolation, 1 is wrong as well.
No the problem is that in 89 years no one noticed
that the short-hand notion of M halts in input P
does not always correspond to the input to H(⟨M⟩,P)
specifies a halting computation.
I have proven this and you acknowledged this
On 8/18/2025 6:05 PM, Richard Heathfield wrote:
It is an easily verified fact, as you love to say,
that if DD calls HHH (as it does) and HHH calls DD
(as, through simulation, it effectively does) that
HHH(DD) can never halt naturally, so it will have
to abort the recursion and report its result as 0
I literally just answered that point
See above. You *cannot* be this stupid!
On 8/27/2025 9:42 PM, Richard Heathfield wrote:
On 27/08/2025 23:24, olcott wrote:
On 8/27/2025 5:07 PM, Richard Heathfield wrote:
On 27/08/2025 22:59, olcott wrote:
On 8/27/2025 4:43 PM, Richard Heathfield wrote:V--- returns 0
On 27/08/2025 22:15, olcott wrote:
On 8/27/2025 3:39 PM, Richard Heathfield wrote:
On 27/08/2025 21:01, olcott wrote:
<snip>
A halt decider correctly reports on the behavior
that its input specifies
Then you don't have one, because it doesn't.
*Thats not what you said*
Yeah, it is.
On 8/18/2025 6:05 PM, Richard Heathfield wrote:
It is an easily verified fact, as you love to say,
that if DD calls HHH (as it does) and HHH calls DD
(as, through simulation, it effectively does) that
HHH(DD) can never halt naturally, so it will have
to abort the recursion and report its result as 0
- didn't halt.
;
Yup. HHH has to report, right? So it has to pull the plug on what
it thinks is unhalting behaviour. Now it can report. But what?
Well, the simulator didn't reach a halt state, so it can't report
1, but that only leaves 0.
HHH that reports in the same behavior as five chat bots
<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);receives 0--^
VVVVVVVVVVVVVVVV if(0) is false
if (Halt_Status)
VVVVVVVVVVVVVVV doesn't happen
HERE: goto HERE;
V---- reaches return statement and halts
return Halt_Status;
}
What value should HHH(DD) correctly return?
<Input to LLM systems>
returns 0 on the basis of the above static text.
0 means "non-halting". Nice try. Wrong, but nice try.
If it's any consolation, 1 is wrong as well.
No the problem is that in 89 years no one noticed
that the short-hand notion of M halts in input P
does not always correspond to the input to H(⟨M⟩,P)
specifies a halting computation.
I have proven this and you acknowledged this
On 8/18/2025 6:05 PM, Richard Heathfield wrote:
It is an easily verified fact, as you love to say,
that if DD calls HHH (as it does) and HHH calls DD
(as, through simulation, it effectively does) that
HHH(DD) can never halt naturally, so it will have
to abort the recursion and report its result as 0
I literally just answered that point
See above. You *cannot* be this stupid!
(1) When HHH(DD) would return 0 THIS WOULD BE CORRECT
(2) Halt decider ONLY report on the behavior that
actual their input actually specifies and the input
to HHH(DD) SPECIFIES NON-HALTING.
This is the key that proves the HP proofs are incorrect.
DD simulated by HHH is a correct measure the behavior
that the input to HHH(DD) specifies.
On 8/27/2025 11:34 PM, Richard Heathfield wrote:
The question is not "does DD halt under simulation?" but "does
DD halt?" And you have to include the whole function.
The question is: Does DD correctly simulated by HHH halt?
You keep ignoring that halt deciders only
COMPUTE THE MAPPING FROM THEIR INPUTS
On 8/27/2025 11:44 PM, Richard Heathfield wrote:
On 28/08/2025 04:50, dbush wrote:
On 8/27/2025 11:46 PM, olcott wrote:
If you really understood Turing machine deciders you
would already know that they only compute the mapping
from their actual input finite strings.
Yet you claim they must report on non-inputs (see below):
He does. And yet he is content to discard actual input.
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
is never simulated by HHH.
Certainly you understand unreachable code?
On 8/28/2025 9:39 AM, Richard Heathfield wrote:
On 28/08/2025 15:10, olcott wrote:
On 8/27/2025 11:44 PM, Richard Heathfield wrote:
On 28/08/2025 04:50, dbush wrote:
On 8/27/2025 11:46 PM, olcott wrote:
If you really understood Turing machine deciders you
would already know that they only compute the mapping
from their actual input finite strings.
Yet you claim they must report on non-inputs (see below):
He does. And yet he is content to discard actual input.
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
is never simulated by HHH.
Certainly you understand unreachable code?
What unreachable code?
You know that you are cheating Jackass.
On 8/28/2025 9:32 AM, Richard Heathfield wrote:
On 28/08/2025 15:08, olcott wrote:
On 8/27/2025 11:34 PM, Richard Heathfield wrote:
<snip>
The question is not "does DD halt under simulation?" but "does
DD halt?" And you have to include the whole function.
The question is: Does DD correctly simulated by HHH halt?
No, that's the question you want to answer. It's not the
question the Halting Problem poses.
You keep ignoring that halt deciders only
COMPUTE THE MAPPING FROM THEIR INPUTS
Your input is (a pointer to)
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The only bit you bother with is
int DD()
{
HHH(DD);
You seem to think that you can pick and choose which behaviour
you model.
Pathetic.
You know that you are lying.
_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
On 8/28/2025 10:45 AM, Richard Heathfield wrote:
On 28/08/2025 15:58, olcott wrote:
On 8/28/2025 9:32 AM, Richard Heathfield wrote:
On 28/08/2025 15:08, olcott wrote:
On 8/27/2025 11:34 PM, Richard Heathfield wrote:
<snip>
The question is not "does DD halt under simulation?" but "does
DD halt?" And you have to include the whole function.
The question is: Does DD correctly simulated by HHH halt?
No, that's the question you want to answer. It's not the
question the Halting Problem poses.
You keep ignoring that halt deciders only
COMPUTE THE MAPPING FROM THEIR INPUTS
Your input is (a pointer to)
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The only bit you bother with is
int DD()
{
HHH(DD);
You seem to think that you can pick and choose which
behaviour you model.
Pathetic.
You know that you are lying.
Are you now claiming that you can reach the code you said was
unreachable?
_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
*****************************************************
Presumably this is where you halt your simulation (when you do
halt it).
Instead of halting, why not replace the push and the call
000015d2 with a mov of 0 into Halt_Status (because you know HHH
would return 0) and then keep simulating?
Bingo! Unreachable code becomes reachable.
Or explain why you don't.
*****************************************************
You and most everyone else here (besides Fred) knows
that is cheating. Mike would know this is cheating.
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
If you really understood the question you would realise that nobody
gives a damn whether DD halts when being simulated.
This is the key that proves the HP proofs are incorrect.
DD simulated by HHH is a correct measure the behavior
that the input to HHH(DD) specifies.
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
No, it isn't. You don't get to dictate what HHH(DD) means!That Turing machine halt deciders only compute the mapping from their
inputs does entail that HHH must report on the behavior that *ITS ACTUAL INPUT ACTUALLY SPECIFIES*
When we Unit Test DD(), we find that it halts.I carefully studied all of this and my original comment still applies.
When we Unit Test HHH(DD), we find that it returns 0.
Unit Testing establishes the ground truths.
The meaning of "HHH(DD)" is this: "does the Unit Test of DD halt?"
Unit Testing means probing the behavior of an expression, isolated into
its own program, run under prisitine initial condition so that there
are no interactions with previously run Unit Tests.
A Unit Test of an expression like DD() is this: a test case is created
with a main() which calls that expression before doing anything else,
and this is executed by a brand new instance of the x86utm which has
not previously loaded and executed anything else.
All claims of yours that are refer to and are based on the behavior of
your apparatus, in which you are not using the Unit Test interpretation
of the expression terms being discussed, are simply incorrect.
On 8/28/2025 3:35 PM, joes wrote:
Am Thu, 28 Aug 2025 14:24:56 -0500 schrieb olcott:
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
No, it isn't. You don't get to dictate what HHH(DD) means!That Turing machine halt deciders only compute the mapping
from their
inputs does entail that HHH must report on the behavior that
*ITS ACTUAL
INPUT ACTUALLY SPECIFIES*
No, it must compute *from* the input, which is the code of DD.
Nothing
is stopping from computing its direct execution.
The call from DD to HHH(DD) (its own simulator)
prevents this DD (not some other DD somewhere else)
from ever halting.
On 8/28/2025 4:00 PM, Richard Heathfield wrote:
On 28/08/2025 21:40, olcott wrote:void Infinite_Recursion()
On 8/28/2025 3:35 PM, joes wrote:
Am Thu, 28 Aug 2025 14:24:56 -0500 schrieb olcott:
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
No, it isn't. You don't get to dictate what HHH(DD) means!That Turing machine halt deciders only compute the mapping
from their
inputs does entail that HHH must report on the behavior that
*ITS ACTUAL
INPUT ACTUALLY SPECIFIES*
No, it must compute *from* the input, which is the code of
DD. Nothing
is stopping from computing its direct execution.
The call from DD to HHH(DD) (its own simulator)
prevents this DD (not some other DD somewhere else)
from ever halting.
But if that's true, HHH never reports.
{
Infinite_Recursion();
return;
}
Yet HHH(Infinite_Recursion) does report
because
it can see the repeating pattern.
DD correctly simulated by HHH has this exact same
repeating pattern.
On 8/28/2025 4:11 PM, Richard Heathfield wrote:
On 28/08/2025 22:04, olcott wrote:
On 8/28/2025 4:00 PM, Richard Heathfield wrote:
On 28/08/2025 21:40, olcott wrote:void Infinite_Recursion()
On 8/28/2025 3:35 PM, joes wrote:
Am Thu, 28 Aug 2025 14:24:56 -0500 schrieb olcott:
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
No, it isn't. You don't get to dictate what HHH(DD) means!That Turing machine halt deciders only compute the mapping
from their
inputs does entail that HHH must report on the behavior
that *ITS ACTUAL
INPUT ACTUALLY SPECIFIES*
No, it must compute *from* the input, which is the code of
DD. Nothing
is stopping from computing its direct execution.
The call from DD to HHH(DD) (its own simulator)
prevents this DD (not some other DD somewhere else)
from ever halting.
But if that's true, HHH never reports.
{
Infinite_Recursion();
return;
}
Yet HHH(Infinite_Recursion) does report
So it halts the simulation. Has to.
because
it can see the repeating pattern.
DD correctly simulated by HHH has this exact same
repeating pattern.
Right. So it *has* to halt the simulation, so calling HHH(DD)
is one way to guarantee that the simulation halts.
Therefore, DD (correctly simulated) halts.
Not when Halting is properly defined as reaching a
final halt state. DD simulated by HHH never does that.
On 8/28/2025 4:47 PM, Richard Heathfield wrote:
On 28/08/2025 22:32, olcott wrote:
On 8/28/2025 4:11 PM, Richard Heathfield wrote:
On 28/08/2025 22:04, olcott wrote:
On 8/28/2025 4:00 PM, Richard Heathfield wrote:
On 28/08/2025 21:40, olcott wrote:void Infinite_Recursion()
On 8/28/2025 3:35 PM, joes wrote:
Am Thu, 28 Aug 2025 14:24:56 -0500 schrieb olcott:
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
No, it isn't. You don't get to dictate what HHH(DD) means! >>>>>>>>>>That Turing machine halt deciders only compute the
mapping from their
inputs does entail that HHH must report on the behavior
that *ITS ACTUAL
INPUT ACTUALLY SPECIFIES*
No, it must compute *from* the input, which is the code
of DD. Nothing
is stopping from computing its direct execution.
The call from DD to HHH(DD) (its own simulator)
prevents this DD (not some other DD somewhere else)
from ever halting.
But if that's true, HHH never reports.
{
Infinite_Recursion();
return;
}
Yet HHH(Infinite_Recursion) does report
So it halts the simulation. Has to.
because
it can see the repeating pattern.
DD correctly simulated by HHH has this exact same
repeating pattern.
Right. So it *has* to halt the simulation, so calling HHH(DD)
is one way to guarantee that the simulation halts.
Therefore, DD (correctly simulated) halts.
Not when Halting is properly defined as reaching a
final halt state. DD simulated by HHH never does that.
DD simulated by HHH is guaranteed to reach a final halt state
because HHH guarantees to halt it.
Either you halt it or you don't. You can't have it both ways.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.
On 8/28/2025 6:13 PM, olcott wrote:
On 8/28/2025 5:09 PM, Richard Heathfield wrote:
*Therefore*, properly simulated, HHH(DD) should detect
terminating behaviour...
...and return 1, thereby guaranteeing that DD will *not* reach
its own return statement, and so requiring HHH to return 0
after all, and so we rock back and forth over the two choices,
and it's literally impossible to choose between them,
*exactly* as Turing predicted.
Yes that is the way that cheaters think.
HHH(DD) has always correctly reported that DD
would never stop running unless aborted.
In other words, if DD was changed into something that is no
longer DD.
Changing the input and reporting on that changed input is not
allowed.
On 8/28/2025 5:09 PM, Richard Heathfield wrote:
On 28/08/2025 22:52, olcott wrote:
On 8/28/2025 4:47 PM, Richard Heathfield wrote:
Either you halt it or you don't. You can't have it both ways.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an Hdetermines
(it's trivial to do for this one case) that correctly
that P(P) *would* never stop running *unless* aborted.
Ben is rarely wrong. I think he's wrong here.
HHH claims to be a decider. *Therefore* it must halt.
*Therefore* any function calling it can rely on the fact that
it will return. *Therefore* there can be no risk of infinite
descent.
By calling HHH(DD), DD assures its own demise at the hands of
its own return statement.
*Therefore*, properly simulated, HHH(DD) should detect
terminating behaviour...
...and return 1, thereby guaranteeing that DD will *not* reach
its own return statement, and so requiring HHH to return 0
after all, and so we rock back and forth over the two choices,
and it's literally impossible to choose between them, *exactly*
as Turing predicted.
Yes that is the way that cheaters think.
HHH(DD) has always correctly reported that DD
would never stop running unless aborted.
On 8/28/2025 6:31 PM, Richard Heathfield wrote:
On 28/08/2025 23:24, dbush wrote:
Changing the input and reporting on that changed input is not
allowed.
It hardly matters. Whatever he returns, he's screwed.
Even when he cheats, he loses.
He attempts to sidestep things by claiming that the question to
be answered isn't the actual question to be answered.
He thinks the simulation *must* be correct because replacing HHH
with a pure simulator results in a DD that doesn't halt, not
understanding that he's changing the input by doing so.
And by that logic, since the simulation *must* be correct, the
answer of non-halting *must* be correct, therefore the question
that was asked was actually a different question.
This is faulty because:
* An aborted simulation by definition is not a correct simulation
* It's changing the entity to be decided on and reporting on what
was changed
* HHH is dead before it starts because of the execution_trace
variable in the static code area. This is an extra input to the
algorithm, and the spec for a halt decider takes *only* a
description of an algorithm (and that algorithm's input) as
input, so based on that alone HHH is not a halt decider.
Turing machine halt deciders
DO NOT REPORT ON THE BEHAVIOR OF THEIR CALLER
THEY REPORT ON THE (in this case) RECURSIVE
SIMULATION BEHAVIOR OF THEIR INPUT !!!
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
If you really understood the question you would realise that nobody
gives a damn whether DD halts when being simulated.
This is the key that proves the HP proofs are incorrect.
DD simulated by HHH is a correct measure the behavior
that the input to HHH(DD) specifies.
No, it isn't.
You don't get to dictate what HHH(DD) means!
That Turing machine halt deciders only compute
the mapping from their inputs does entail that
HHH must report on the behavior that
*ITS ACTUAL INPUT ACTUALLY SPECIFIES*
This *is* correctly measured by DD correctly
simulated by HHH.
*Here is is again in terms of the Linz proof*
On 8/28/2025 3:35 PM, joes wrote:
Am Thu, 28 Aug 2025 14:24:56 -0500 schrieb olcott:
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
No, it isn't. You don't get to dictate what HHH(DD) means!That Turing machine halt deciders only compute the mapping from their
inputs does entail that HHH must report on the behavior that *ITS ACTUAL >>> INPUT ACTUALLY SPECIFIES*
No, it must compute *from* the input, which is the code of DD. Nothing
is stopping from computing its direct execution.
The call from DD to HHH(DD) (its own simulator)
prevents this DD (not some other DD somewhere else)
On 8/28/2025 4:00 PM, Richard Heathfield wrote:
On 28/08/2025 21:40, olcott wrote:void Infinite_Recursion()
On 8/28/2025 3:35 PM, joes wrote:
Am Thu, 28 Aug 2025 14:24:56 -0500 schrieb olcott:
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
No, it isn't. You don't get to dictate what HHH(DD) means!That Turing machine halt deciders only compute the mapping from their >>>>> inputs does entail that HHH must report on the behavior that *ITS
ACTUAL
INPUT ACTUALLY SPECIFIES*
No, it must compute *from* the input, which is the code of DD. Nothing >>>> is stopping from computing its direct execution.
The call from DD to HHH(DD) (its own simulator)
prevents this DD (not some other DD somewhere else)
from ever halting.
But if that's true, HHH never reports.
{
Infinite_Recursion();
return;
}
Yet HHH(Infinite_Recursion) does report because
it can see the repeating pattern.
DD correctly simulated by HHH has this exact same
repeating pattern.
On 8/28/2025 4:11 PM, Richard Heathfield wrote:
On 28/08/2025 22:04, olcott wrote:
On 8/28/2025 4:00 PM, Richard Heathfield wrote:
On 28/08/2025 21:40, olcott wrote:void Infinite_Recursion()
On 8/28/2025 3:35 PM, joes wrote:
Am Thu, 28 Aug 2025 14:24:56 -0500 schrieb olcott:
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
No, it isn't. You don't get to dictate what HHH(DD) means!That Turing machine halt deciders only compute the mapping from their >>>>>>> inputs does entail that HHH must report on the behavior that *ITS >>>>>>> ACTUAL
INPUT ACTUALLY SPECIFIES*
No, it must compute *from* the input, which is the code of DD. Nothing >>>>>> is stopping from computing its direct execution.
The call from DD to HHH(DD) (its own simulator)
prevents this DD (not some other DD somewhere else)
from ever halting.
But if that's true, HHH never reports.
{
Infinite_Recursion();
return;
}
Yet HHH(Infinite_Recursion) does report
So it halts the simulation. Has to.
because
it can see the repeating pattern.
DD correctly simulated by HHH has this exact same
repeating pattern.
Right. So it *has* to halt the simulation, so calling HHH(DD) is one way
to guarantee that the simulation halts.
Therefore, DD (correctly simulated) halts.
Not when Halting is properly defined as reaching a
final halt state. DD simulated by HHH never does that.
On 8/28/2025 6:45 PM, Richard Heathfield wrote:
On 29/08/2025 00:20, olcott wrote:I AM SAYING THAT THIS APPLIES TO 100% OF ALL
<snip>
Turing machine halt deciders
DO NOT REPORT ON THE BEHAVIOR OF THEIR CALLER
THEY REPORT ON THE (in this case) RECURSIVE
SIMULATION BEHAVIOR OF THEIR INPUT !!!
No. A universal Turing machine halt decider,
HALT DECIDERS INCLDUING THOSE THAT HAVE A
SINGLE ELEMENT IN THEIR ENTIRE DOMAIN.
He thinks the simulation *must* be correct because replacing HHH with a
pure simulator results in a DD that doesn't halt, not understanding that
he's changing the input by doing so.
On 8/28/2025 6:13 PM, olcott wrote:
On 8/28/2025 5:09 PM, Richard Heathfield wrote:
On 28/08/2025 22:52, olcott wrote:
On 8/28/2025 4:47 PM, Richard Heathfield wrote:
On 28/08/2025 22:32, olcott wrote:
On 8/28/2025 4:11 PM, Richard Heathfield wrote:
On 28/08/2025 22:04, olcott wrote:
On 8/28/2025 4:00 PM, Richard Heathfield wrote:
On 28/08/2025 21:40, olcott wrote:void Infinite_Recursion()
On 8/28/2025 3:35 PM, joes wrote:
Am Thu, 28 Aug 2025 14:24:56 -0500 schrieb olcott:
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>> On 8/27/2025 11:12 PM, Richard Heathfield wrote:
No, it isn't. You don't get to dictate what HHH(DD) means! >>>>>>>>>>>>>That Turing machine halt deciders only compute the mapping >>>>>>>>>>>> from their
inputs does entail that HHH must report on the behavior that >>>>>>>>>>>> *ITS ACTUAL
INPUT ACTUALLY SPECIFIES*
No, it must compute *from* the input, which is the code of DD. >>>>>>>>>>> Nothing
is stopping from computing its direct execution.
The call from DD to HHH(DD) (its own simulator)
prevents this DD (not some other DD somewhere else)
from ever halting.
But if that's true, HHH never reports.
{
Infinite_Recursion();
return;
}
Yet HHH(Infinite_Recursion) does report
So it halts the simulation. Has to.
because
it can see the repeating pattern.
DD correctly simulated by HHH has this exact same
repeating pattern.
Right. So it *has* to halt the simulation, so calling HHH(DD) is >>>>>>> one way to guarantee that the simulation halts.
Therefore, DD (correctly simulated) halts.
Not when Halting is properly defined as reaching a
final halt state. DD simulated by HHH never does that.
DD simulated by HHH is guaranteed to reach a final halt state
because HHH guarantees to halt it.
Either you halt it or you don't. You can't have it both ways.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.
Ben is rarely wrong. I think he's wrong here.
HHH claims to be a decider. *Therefore* it must halt. *Therefore* any
function calling it can rely on the fact that it will return.
*Therefore* there can be no risk of infinite descent.
By calling HHH(DD), DD assures its own demise at the hands of its own
return statement.
*Therefore*, properly simulated, HHH(DD) should detect terminating
behaviour...
...and return 1, thereby guaranteeing that DD will *not* reach its own
return statement, and so requiring HHH to return 0 after all, and so
we rock back and forth over the two choices, and it's literally
impossible to choose between them, *exactly* as Turing predicted.
Yes that is the way that cheaters think.
HHH(DD) has always correctly reported that DD
would never stop running unless aborted.
In other words, if DD was changed into something that is no longer DD.
Changing the input and reporting on that changed input is not allowed.
On 8/28/2025 6:14 PM, Richard Heathfield wrote:
On 28/08/2025 23:52, dbush wrote:
On 8/28/2025 6:31 PM, Richard Heathfield wrote:
On 28/08/2025 23:24, dbush wrote:
<snip>
Changing the input and reporting on that changed input is not allowed. >>>>It hardly matters. Whatever he returns, he's screwed.
Even when he cheats, he loses.
He attempts to sidestep things by claiming that the question to be
answered isn't the actual question to be answered.
I sometimes think the question he's really asking is how long he can
keep this gag running. I am genuinely torn between "nobody can be this
dense" and "just maybe they can".
If you make sure to put 100% of ALL of your
concentration into not hearing a word that
I say then you would get that view AND BE DISHONEST.
Turing machine halt deciders
DO NOT REPORT ON THE BEHAVIOR OF THEIR CALLER
THEY REPORT ON THE (in this case) RECURSIVE
SIMULATION BEHAVIOR OF THEIR INPUT !!!
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
If you really understood the question you would realise that nobody
gives a damn whether DD halts when being simulated.
This is the key that proves the HP proofs are incorrect.
DD simulated by HHH is a correct measure the behavior
that the input to HHH(DD) specifies.
No, it isn't.
You don't get to dictate what HHH(DD) means!
DD correctly simulated by HHH makes sure that it
includes the changes to the behavior of DD that are
caused by the fact that DD is calling its own simulator
in recursive simulation.
For three years now everyone here has essentially said
that the correct thing to do is to ignore the fact that
DD calls HHH(DD) in recursive simulation and just make
pretend that it does not do this.
On 8/28/2025 7:06 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
If you really understood the question you would realise that nobody >>>>>> gives a damn whether DD halts when being simulated.
This is the key that proves the HP proofs are incorrect.
DD simulated by HHH is a correct measure the behavior
that the input to HHH(DD) specifies.
No, it isn't.
You don't get to dictate what HHH(DD) means!
That Turing machine halt deciders only compute
the mapping from their inputs does entail that
HHH must report on the behavior that
*ITS ACTUAL INPUT ACTUALLY SPECIFIES*
If there is any difference between a top-level being executed other than
by HHH, and the DD which is processed by the HHH(DD) expression inside
DD itself, then you have a problem.
First you must understand that the measure of the behavior
of the input to HHH(DD) is only DD correctly simulated by
HHH that takes into account rather than ignores that DD
does call HHH in recursive simulation.
Second you must understand that HHH(DD) is only responsible
for reporting on the above behavior that its actual input
actually specifies. This means that the behavior of the
caller of HHH(DD) (that can be an executed DD) has nothing
to do with the correctness of HHH rejecting its input.
But, never mind, we sidestep dealing with such a problem by insisting on
the Unit Test interpretation: HHH(DD) must decide what is the halting
behavior of DD in an isolated Unit Test in which nothing but DD is
executed. Whatever HHH(DD) return is interpreted as a comment on the
Unit-Tested DD, and not the nonsensical interpretation that it is a
comment on the modified DD that was simulated by the second HHH call
that takes place /in/ DD.
Let us make the change that x86utm stands for "unit test machine".
This *is* correctly measured by DD correctly
simulated by HHH.
DD isn't correctly simulated because it behaves differently from its
Unit Test semantics.
When you measure this by the semantics of the
x86 language then this overrules everything else.
DD correctly emulated by HHH cannot possibly ever
get past its own [0000216b] machine address.
I am just saying that the actual execution trace
cannot by truthfully denied.
DD correctly simulated
by HHH cannot possibly reach its own final state.
On 8/28/2025 7:22 PM, Richard Heathfield wrote:
On 29/08/2025 01:07, olcott wrote:
On 8/28/2025 6:45 PM, Richard Heathfield wrote:
On 29/08/2025 00:20, olcott wrote:I AM SAYING THAT THIS APPLIES TO 100% OF ALL
<snip>
Turing machine halt deciders
DO NOT REPORT ON THE BEHAVIOR OF THEIR CALLER
THEY REPORT ON THE (in this case) RECURSIVE
SIMULATION BEHAVIOR OF THEIR INPUT !!!
No. A universal Turing machine halt decider,
HALT DECIDERS INCLDUING THOSE THAT HAVE A
SINGLE ELEMENT IN THEIR ENTIRE DOMAIN.
Yeah, I get that. Thing is, though - and I realise this may
come as a shock - you saying it doesn't necessarily make it so.
The definition of deciders makes it so.
No Turing machine halt decider can ever
report in the behavior of its own caller.
On 8/28/2025 8:12 PM, Kaz Kylheku wrote:
On 2025-08-29, olcott <polcott333@gmail.com> wrote:
On 8/28/2025 7:06 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
If you really understood the question you would realise that nobody >>>>>>>> gives a damn whether DD halts when being simulated.
This is the key that proves the HP proofs are incorrect.
DD simulated by HHH is a correct measure the behavior
that the input to HHH(DD) specifies.
No, it isn't.
You don't get to dictate what HHH(DD) means!
That Turing machine halt deciders only compute
the mapping from their inputs does entail that
HHH must report on the behavior that
*ITS ACTUAL INPUT ACTUALLY SPECIFIES*
If there is any difference between a top-level being executed other than >>>> by HHH, and the DD which is processed by the HHH(DD) expression inside >>>> DD itself, then you have a problem.
First you must understand that the measure of the behavior
of the input to HHH(DD) is only DD correctly simulated by
HHH that takes into account rather than ignores that DD
does call HHH in recursive simulation.
No, I don't understand taht; it is complete nonsense.
The symbol DD refers to the Unit Test semantics of the computation DD()
Not really. DD as the actual input to HHH is a
finite string of machine code.
As the actual
input to HHH it does specify that DD does call
its own simulator in recursive simulation.
Everyone on this forum has been trying to get
away with denying that for three years.
Changing HHH to HHH' and DD to DD' and then saying DD cannot reach its
final state is a horrible equivocation over symbols.
DD and HHH simulated by HHH cannot possibly reach
their final halt state.
No Turing machine halt decider can ever
report in the behavior of its own caller.
On 8/28/2025 7:26 PM, Kaz Kylheku wrote:
DD always refers to the original DD, which in the present Halt7.c is
defined such that DD() is a halting computation according to its Unit
Test semantics.
Not when you get rid of the static data DD() never halts.
On 8/28/2025 11:07 PM, Kaz Kylheku wrote:
On 2025-08-29, olcott <polcott333@gmail.com> wrote:
No Turing machine halt decider can ever
report in the behavior of its own caller.
Only in the sense that there is no such thing.
When I say decider I also include a decider with a domain
of one single finite string. When I use the proper term
partial halt decider most people here get confused.
M.H ⟨M⟩ ⟨M⟩ cannot report M ⟨M⟩ because no TM
can take another TM as its actual input.
I dropped the use of the static data in my
reference to HHH when you first mentioned it.
Now we either have an HHH(DD) that cannot
recognize the repeating state of its input
that never stops running
OR
We have an HHH that by some other means
detects the repeating state of its input
and it somehow does this as a pure function
of its input.
As the actual
input to HHH it does specify that DD does call
its own simulator in recursive simulation.
In a new instance of the x86utm in which the first thing that
is called is HHH(DD), DD clearly refers to the original DD.
HHH never has its own caller as its input.
The HHH(DD) refers only to a finite string
of x86 machine code.
On 8/28/2025 5:29 PM, Richard Heathfield wrote:
On 28/08/2025 23:13, olcott wrote:
On 8/28/2025 5:09 PM, Richard Heathfield wrote:
On 28/08/2025 22:52, olcott wrote:
On 8/28/2025 4:47 PM, Richard Heathfield wrote:
<snip>
Either you halt it or you don't. You can't have it both ways.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines >>>>> > that P(P) *would* never stop running *unless* aborted.
Ben is rarely wrong. I think he's wrong here.
HHH claims to be a decider. *Therefore* it must halt. *Therefore*
any function calling it can rely on the fact that it will return.
*Therefore* there can be no risk of infinite descent.
By calling HHH(DD), DD assures its own demise at the hands of its
own return statement.
*Therefore*, properly simulated, HHH(DD) should detect terminating
behaviour...
...and return 1, thereby guaranteeing that DD will *not* reach its
own return statement, and so requiring HHH to return 0 after all,
and so we rock back and forth over the two choices, and it's
literally impossible to choose between them, *exactly* as Turing
predicted.
Yes that is the way that cheaters think.
No, cheaters think they can ignore most of the code in a function and
still claim to "correctly simulate".
void Infinite_Recursion()
{
Infinite_Recursion();
printf("Never gets here without cheating!\n");
return;
}
On 8/28/2025 9:06 PM, Richard Heathfield wrote:
On 29/08/2025 02:56, olcott wrote:
On 8/28/2025 7:22 PM, Richard Heathfield wrote:
On 29/08/2025 01:07, olcott wrote:
On 8/28/2025 6:45 PM, Richard Heathfield wrote:
On 29/08/2025 00:20, olcott wrote:I AM SAYING THAT THIS APPLIES TO 100% OF ALL
<snip>
Turing machine halt deciders
DO NOT REPORT ON THE BEHAVIOR OF THEIR CALLER
THEY REPORT ON THE (in this case) RECURSIVE
SIMULATION BEHAVIOR OF THEIR INPUT !!!
No. A universal Turing machine halt decider,
HALT DECIDERS INCLDUING THOSE THAT HAVE A
SINGLE ELEMENT IN THEIR ENTIRE DOMAIN.
Yeah, I get that. Thing is, though - and I realise this may come as
a shock - you saying it doesn't necessarily make it so.
The definition of deciders makes it so.
No, it doesn't.
No Turing machine halt decider can ever
report in the behavior of its own caller.
A TM decider, should one exist, would be required to report on the TM
specified on the tape.
The whole tape, not just the first five minutes.
Only the initial input that is on the tape.
On 8/28/2025 7:26 PM, Kaz Kylheku wrote:More like olcott is misunderstanding him. Note the „unless”: it is a counterfactual, since DD *is* in fact aborted.
On 2025-08-28, dbush <dbush.mobile@gmail.com> wrote:
On 8/28/2025 6:13 PM, olcott wrote:
On 8/28/2025 5:09 PM, Richard Heathfield wrote:
On 28/08/2025 22:52, olcott wrote:
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:Ben is rarely wrong. I think he's wrong here.
; I don't think that is the shell game. PO really /has/ an H
; (it's trivial to do for this one case) that correctly
; determines that P(P) *would* never stop running *unless*
; aborted.
Of course. A bounded loop doesn’t halt either when you take out the termination check. That is neither here nor there.What's not allowed is taking DD, deriving a different procedure DD'Not when you get rid of the static data DD() never halts.
(whether purely or by mutating DD), analyzing the derived DD' instead
of DD and then *dishonestly* insisting that statements which are true
about DD' are actually talking about the original DD.
DD always refers to the original DD, which in the present Halt7.c is
defined such that DD() is a halting computation according to its Unit
Test semantics.
Ah, but HHH doesn’t report on the direct execution, but on itself ;-)This means that when DD() is executed in isolation in a
brand new x86utm_exe instance, without any other test case code run
before it that could sneakily modify static state, that's the behavior
which is the source of truth about whether DD is halting or not. If it
so happens that DD() launches some recursive simulations of DD which
behave differently, those are irrelevant; those do not have the Unit
Test semantics. They are allowed to exist, but we do not allow them
being talked about as if they were DD.
On 8/27/2025 11:44 PM, Richard Heathfield wrote:
On 28/08/2025 04:50, dbush wrote:
On 8/27/2025 11:46 PM, olcott wrote:
If you really understood Turing machine deciders you
would already know that they only compute the mapping
from their actual input finite strings.
Yet you claim they must report on non-inputs (see below):
He does. And yet he is content to discard actual input.
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
is never simulated by HHH.
Certainly you understand unreachable code?
void Infinite_Loop()
{
HERE: goto HERE;
printf("I never get here you dumb bunny!\n");
return;
}
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
If you really understood the question you would realise that nobody
gives a damn whether DD halts when being simulated.
This is the key that proves the HP proofs are incorrect.
DD simulated by HHH is a correct measure the behavior
that the input to HHH(DD) specifies.
No, it isn't.
You don't get to dictate what HHH(DD) means!
That Turing machine halt deciders only compute
the mapping from their inputs does entail that
HHH must report on the behavior that
*ITS ACTUAL INPUT ACTUALLY SPECIFIES*
On 8/27/2025 11:34 PM, Richard Heathfield wrote:
On 28/08/2025 05:21, olcott wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
<snip>
If you really understood the question you would realise that nobody
gives a damn whether DD halts when being simulated.
This is the key that proves the HP proofs are incorrect.
No, it isn't. It's the key that proves you don't get the question. Your
"decider" demonstrates very neatly that HHH cannot correctly analyse
DD. It can't even /see/ DD!
DD simulated by HHH is a correct measure the behavior
that the input to HHH(DD) specifies.
Well, you forgot the last three lines of DD. Careless.
The question is not "does DD halt under simulation?" but "does
DD halt?" And you have to include the whole function.
The question is: Does DD correctly simulated by HHH halt?
On 8/28/2025 2:46 AM, Mikko wrote:
On 2025-08-26 16:29:41 +0000, olcott said:
On 8/26/2025 4:29 AM, Mikko wrote:
On 2025-08-20 16:20:21 +0000, olcott said:
Turing machine deciders only compute the mapping
from their inputs...
Not the mapping but some computable mapping. And so do other Turing
machines.
If the mapping is uncomputable there is no Turing machine that computes it.
Turing machines never compute the mapping
from their own behavior or the behavior
of their caller.
A Turing machine never refuses to compute from their the behaviour of
its caller because it doesn't know that it has a caller, let alone the
identity of the caller.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt.
Yet Linz requires Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ to report
on the behavior of its caller: Ĥ applied to ⟨Ĥ⟩
On 8/28/2025 7:15 PM, Kaz Kylheku wrote:
The simulated DD is a decoy which doesn't conform to the Unit Test
semantics of DD, defined by the behavior of DD started in complete
isolation in a brand new x86utm_exe instance.
It is an easily verified fact that DD correctly
simulated by HHH cannot possibly reach its "return"
statement final halt state because the input to
HHH(DD) specifies recursive simulation that is
equivalent to mutual recursion.
When people deny easily verified facts they are
not telling the truth.
*DD simulated by HHH as a pure function of its input*
cannot possibly reach its "return" statement
On 8/29/2025 3:25 AM, Mikko wrote:
On 2025-08-28 14:08:09 +0000, olcott said:
On 8/27/2025 11:34 PM, Richard Heathfield wrote:
On 28/08/2025 05:21, olcott wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
<snip>
If you really understood the question you would realise that nobody >>>>>> gives a damn whether DD halts when being simulated.
This is the key that proves the HP proofs are incorrect.
No, it isn't. It's the key that proves you don't get the question. Your >>>> "decider" demonstrates very neatly that HHH cannot correctly analyse
DD. It can't even /see/ DD!
DD simulated by HHH is a correct measure the behavior
that the input to HHH(DD) specifies.
Well, you forgot the last three lines of DD. Careless.
The question is not "does DD halt under simulation?" but "does
DD halt?" And you have to include the whole function.
The question is: Does DD correctly simulated by HHH halt?
That is your question. Others ask other questions.
That is the only question that takes into
account the fact that DD does call HHH in
recursive simulation, thus provides the
actual behavior that the input to HHH(DD)
actually specifies.
On 8/29/2025 12:07 AM, Kaz Kylheku wrote:
On 2025-08-29, olcott <polcott333@gmail.com> wrote:
On 8/28/2025 7:26 PM, Kaz Kylheku wrote:
DD always refers to the original DD, which in the present Halt7.c is
defined such that DD() is a halting computation according to its Unit
Test semantics.
Not when you get rid of the static data DD() never halts.
Yes; but then all instances of the expression HHH(DD) do not halt; you
never get your HHH(DD) -> 0 result.
You will never get a HHH(DD) -> 0 for a non-halting DD other than
by faking the appearance of the result with the help of
invalid communication between simulation levels equivalent
to the current static data.
So we hypothesize two cases:
(a) HHH(DD) never halts
(b) HHH(DD) sees the repeating state as a pure function of its input.
On 8/29/2025 3:33 AM, Mikko wrote:Requiring HHH(DD) to report on a DD based on another hypothetical HHH
On 2025-08-28 19:24:56 +0000, olcott said:
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
If you really understood the question you would realise that nobody >>>>>> gives a damn whether DD halts when being simulated.
This is the key that proves the HP proofs are incorrect.
DD simulated by HHH is a correct measure the behavior
that the input to HHH(DD) specifies.
No, it isn't.
You don't get to dictate what HHH(DD) means!
That Turing machine halt deciders only compute
the mapping from their inputs does entail that
HHH must report on the behavior that
*ITS ACTUAL INPUT ACTUALLY SPECIFIES*
No, there is no such entailment. Never heard of Hume's guillotine?
https://en.wikipedia.org/wiki/Is%E2%80%93ought_problem
int sum(int x, int y){return x + y;}
requiring sum(3,5) to report on the sum of 5 + 7
is an incorrect requirement.
On 8/29/2025 2:41 AM, Fred. Zwarts wrote:
Op 29.aug.2025 om 00:49 schreef olcott:
On 8/28/2025 5:29 PM, Richard Heathfield wrote:
On 28/08/2025 23:13, olcott wrote:
On 8/28/2025 5:09 PM, Richard Heathfield wrote:
On 28/08/2025 22:52, olcott wrote:
On 8/28/2025 4:47 PM, Richard Heathfield wrote:
<snip>
Either you halt it or you don't. You can't have it both ways.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines >>>>>>> > that P(P) *would* never stop running *unless* aborted.
Ben is rarely wrong. I think he's wrong here.
HHH claims to be a decider. *Therefore* it must halt. *Therefore*
any function calling it can rely on the fact that it will return.
*Therefore* there can be no risk of infinite descent.
By calling HHH(DD), DD assures its own demise at the hands of its
own return statement.
*Therefore*, properly simulated, HHH(DD) should detect terminating >>>>>> behaviour...
...and return 1, thereby guaranteeing that DD will *not* reach its >>>>>> own return statement, and so requiring HHH to return 0 after all,
and so we rock back and forth over the two choices, and it's
literally impossible to choose between them, *exactly* as Turing
predicted.
Yes that is the way that cheaters think.
No, cheaters think they can ignore most of the code in a function
and still claim to "correctly simulate".
void Infinite_Recursion()
{
Infinite_Recursion();
printf("Never gets here without cheating!\n");
return;
}
As usual irrelevant. Nobody said that Infinite_Recursion halts.
It is the same thing with recursive simulation,
yet simply too difficult for you to understand.
When HHH(DD) reaches its abort criteria (if it can)
then it aborts its simulation of DD such that no
DD can possibly have any behavior at all such as
stack unwinding.
But the input specifying a DD based on an aborting HHH specifies only
a finite recursion.
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
HHH(Infinite_Recursion) also only has finite
recursion so the measure is:
Can Infinite_Recursion correctly simulated by
HHH possibly reach its own "return" statement
final halt state?
void Finite_Recursion () {
static int N = 5;
if (N > 0) Finite_Recursion ();
printf ("Olcott thinks this is never printed.\n");
}
On 8/29/2025 2:53 AM, joes wrote:
Am Thu, 28 Aug 2025 23:19:31 -0500 schrieb olcott:
On 8/28/2025 7:26 PM, Kaz Kylheku wrote:
On 2025-08-28, dbush <dbush.mobile@gmail.com> wrote:
On 8/28/2025 6:13 PM, olcott wrote:
On 8/28/2025 5:09 PM, Richard Heathfield wrote:
On 28/08/2025 22:52, olcott wrote:
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:Ben is rarely wrong. I think he's wrong here.
I don't think that is the shell game. PO really /has/ an H >>>>>>>> > (it's trivial to do for this one case) that correctly
determines that P(P) *would* never stop running *unless*
aborted.
More like olcott is misunderstanding him. Note the „unless”: it is a
counterfactual, since DD *is* in fact aborted.
*This is the full context*
*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>
On 8/29/2025 2:41 AM, Fred. Zwarts wrote:
Op 29.aug.2025 om 00:49 schreef olcott:
On 8/28/2025 5:29 PM, Richard Heathfield wrote:
On 28/08/2025 23:13, olcott wrote:
On 8/28/2025 5:09 PM, Richard Heathfield wrote:
On 28/08/2025 22:52, olcott wrote:
On 8/28/2025 4:47 PM, Richard Heathfield wrote:
<snip>
Either you halt it or you don't. You can't have it both ways.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines >>>>>>> > that P(P) *would* never stop running *unless* aborted.
Ben is rarely wrong. I think he's wrong here.
HHH claims to be a decider. *Therefore* it must halt. *Therefore* any >>>>>> function calling it can rely on the fact that it will return.
*Therefore* there can be no risk of infinite descent.
By calling HHH(DD), DD assures its own demise at the hands of its own >>>>>> return statement.
*Therefore*, properly simulated, HHH(DD) should detect terminating behaviour...
...and return 1, thereby guaranteeing that DD will *not* reach its own >>>>>> return statement, and so requiring HHH to return 0 after all, and so we >>>>>> rock back and forth over the two choices, and it's literally impossible >>>>>> to choose between them, *exactly* as Turing predicted.
Yes that is the way that cheaters think.
No, cheaters think they can ignore most of the code in a function and
still claim to "correctly simulate".
void Infinite_Recursion()
{
Infinite_Recursion();
printf("Never gets here without cheating!\n");
return;
}
As usual irrelevant. Nobody said that Infinite_Recursion halts.
It is the same thing with recursive simulation,
yet simply too difficult for you to understand.
When HHH(DD) reaches its abort criteria (if it can)
then it aborts its simulation of DD such that no
DD can possibly have any behavior at all such as
stack unwinding.
But the input specifying a DD based on an aborting HHH specifies only a
finite recursion.
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
HHH(Infinite_Recursion) also only has finite
recursion so the measure is:
Can Infinite_Recursion correctly simulated by
HHH possibly reach its own "return" statement
final halt state?
On 8/29/2025 3:33 AM, Mikko wrote:
On 2025-08-28 19:24:56 +0000, olcott said:
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
If you really understood the question you would realise that nobody >>>>>> gives a damn whether DD halts when being simulated.
This is the key that proves the HP proofs are incorrect.
DD simulated by HHH is a correct measure the behavior
that the input to HHH(DD) specifies.
No, it isn't.
You don't get to dictate what HHH(DD) means!
That Turing machine halt deciders only compute
the mapping from their inputs does entail that
HHH must report on the behavior that
*ITS ACTUAL INPUT ACTUALLY SPECIFIES*
No, there is no such entailment. Never heard of Hume's guillotine?
https://en.wikipedia.org/wiki/Is%E2%80%93ought_problem
int sum(int x, int y){return x + y;}
requiring sum(3,5) to report on the sum of 5 + 7
is an incorrect requirement.
Requiring HHH(DD) to report on the behavior of
its caller is this same mistake.
On 8/28/2025 7:15 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/28/2025 4:00 PM, Richard Heathfield wrote:
On 28/08/2025 21:40, olcott wrote:void Infinite_Recursion()
On 8/28/2025 3:35 PM, joes wrote:
Am Thu, 28 Aug 2025 14:24:56 -0500 schrieb olcott:
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
No, it isn't. You don't get to dictate what HHH(DD) means!That Turing machine halt deciders only compute the mapping from their >>>>>>> inputs does entail that HHH must report on the behavior that *ITS >>>>>>> ACTUAL
INPUT ACTUALLY SPECIFIES*
No, it must compute *from* the input, which is the code of DD. Nothing >>>>>> is stopping from computing its direct execution.
The call from DD to HHH(DD) (its own simulator)
prevents this DD (not some other DD somewhere else)
from ever halting.
But if that's true, HHH never reports.
{
Infinite_Recursion();
return;
}
Yet HHH(Infinite_Recursion) does report because
it can see the repeating pattern.
HHH can correctly decide this Infinite_Recursion procedure because that
procedure isn't the instance (DD) of the Diagonal (D) test case template
which embeds the decider and behaves in a contradictory m anner.
DD correctly simulated by HHH has this exact same
repeating pattern.
If HHH(DD) returns 0, and the simulated DD still has this pattern,
it means that something is seriously wrong, because HHH(DD) returning
zero requires DD to halt.
The simulated DD is a decoy which doesn't conform to the Unit Test
semantics of DD, defined by the behavior of DD started in complete
isolation in a brand new x86utm_exe instance.
It is an easily verified fact that DD correctly
simulated by HHH cannot possibly reach its "return"
statement final halt state because the input to
HHH(DD) specifies recursive simulation that is
equivalent to mutual recursion.
When people deny easily verified facts they are
not telling the truth.
On 8/28/2025 7:35 PM, Kaz Kylheku wrote:If only! Instead it descends into infinitely recursive simulation.
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
That only effects the means of reporting and does not have any effect onTuring machine halt deciders DO NOT REPORT ON THE BEHAVIOR OF THEIR
CALLER THEY REPORT ON THE (in this case) RECURSIVE SIMULATION BEHAVIOR
OF THEIR INPUT !!!
While that is true,
In your apparatus, the x86utm_exe and its Halt7.o test case,
this is not the case.
The behavior of HHH and DD is being informed of the calling context due
to examining and mutating a static variable that is shared between
instances of HHH.
the behavior. An LLM system is smart enough to determine that the
behavior of mutual recursion is equivalent to DD correctly simulated by
HHH. If HHH was this smart then it could perform this pseudo execution
trace and return 0 on this basis.
…in the way that it chooses to manipulate it, which isn’t much ofThe HHH that is invoked by DD is precisely doing that which you areFactually incorrect. The directly executed outermost HHH is only
above saying halt deciders do not do! It is reporting on a behavior of
its caller, because its caller (HHH grandparent two levels up) diddled
a static variable, which is observed by the HHH grandchild.
reporting on the behavior of its input data that it manipulates.
On 8/29/2025 3:38 AM, Mikko wrote:
On 2025-08-28 14:48:35 +0000, olcott said:
On 8/28/2025 2:46 AM, Mikko wrote:
On 2025-08-26 16:29:41 +0000, olcott said:
On 8/26/2025 4:29 AM, Mikko wrote:
On 2025-08-20 16:20:21 +0000, olcott said:
Turing machine deciders only compute the mapping
from their inputs...
Not the mapping but some computable mapping. And so do other Turing >>>>>> machines.
If the mapping is uncomputable there is no Turing machine that computes it.
Turing machines never compute the mapping
from their own behavior or the behavior
of their caller.
A Turing machine never refuses to compute from their the behaviour of
its caller because it doesn't know that it has a caller, let alone the >>>> identity of the caller.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt.
Yet Linz requires Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ to report
on the behavior of its caller: Ĥ applied to ⟨Ĥ⟩
Linz does not require anything about Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩. He only
infers from the construction what it might do and evaluates the
consequences of every possibility that can't be excluded.
*Quoted from above and the requirement that I referred to*
if Ĥ applied to ⟨Ĥ⟩ does not halt.
if Ĥ applied to ⟨Ĥ⟩ does not halt.
Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ is required to report on the
behavior of its caller Ĥ ⟨Ĥ⟩.
On 8/27/2025 11:44 PM, Richard Heathfield wrote:
On 28/08/2025 04:50, dbush wrote:
On 8/27/2025 11:46 PM, olcott wrote:
If you really understood Turing machine deciders you
would already know that they only compute the mapping
from their actual input finite strings.
Yet you claim they must report on non-inputs (see below):
He does. And yet he is content to discard actual input.
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
is never simulated by HHH.
Certainly you understand unreachable code?
void Infinite_Loop()
{
HERE: goto HERE;
printf("I never get here you dumb bunny!\n");
return;
}
On 8/28/25 10:10 AM, olcott wrote:
On 8/27/2025 11:44 PM, Richard Heathfield wrote:
On 28/08/2025 04:50, dbush wrote:
On 8/27/2025 11:46 PM, olcott wrote:
If you really understood Turing machine deciders you
would already know that they only compute the mapping
from their actual input finite strings.
Yet you claim they must report on non-inputs (see below):
He does. And yet he is content to discard actual input.
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
is never simulated by HHH.
Certainly you understand unreachable code?
void Infinite_Loop()
{
HERE: goto HERE;
printf("I never get here you dumb bunny!\n");
return;
}
But the code in DD isn't unreachable, at least if HHH meets its
requirement to be a decider.
It is just not reachable in the simulation done by HHH because it
doesn't do a correct simulation of it.
On 30/08/2025 13:37, Richard Damon wrote:
On 8/28/25 10:10 AM, olcott wrote:
On 8/27/2025 11:44 PM, Richard Heathfield wrote:
On 28/08/2025 04:50, dbush wrote:
On 8/27/2025 11:46 PM, olcott wrote:
If you really understood Turing machine deciders you
would already know that they only compute the mapping
from their actual input finite strings.
Yet you claim they must report on non-inputs (see below):
He does. And yet he is content to discard actual input.
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
is never simulated by HHH.
Certainly you understand unreachable code?
void Infinite_Loop()
{
HERE: goto HERE;
printf("I never get here you dumb bunny!\n");
return;
}
But the code in DD isn't unreachable, at least if HHH meets its
requirement to be a decider.
It is just not reachable in the simulation done by HHH because it
doesn't do a correct simulation of it.
I've already explained to him how he could fix it, but he clearly isn't interested in correct simulation.
On 8/29/2025 2:23 PM, Richard Heathfield wrote:
It is an easily verified fact that
int main(void)
{
DD();
return 0;
}
halts. Several of us /have/ verified that fact (easily).
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
On 8/30/2025 10:55 AM, Richard Heathfield wrote:
On 30/08/2025 16:52, olcott wrote:
On 8/29/2025 2:23 PM, Richard Heathfield wrote:
<snip>
It is an easily verified fact that
int main(void)
{
DD();
return 0;
}
halts. Several of us /have/ verified that fact (easily).
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
Nonsense. It can't. HHH *must* return and *does* return.
HHH.exe is required to return.
HHH.sim1 cannot possibly return any requirement
to the contrary is simply counter-factual.
On 8/30/2025 10:55 AM, Richard Heathfield wrote:
On 30/08/2025 16:52, olcott wrote:
On 8/29/2025 2:23 PM, Richard Heathfield wrote:
<snip>
It is an easily verified fact that
int main(void)
{
DD();
return 0;
}
halts. Several of us /have/ verified that fact (easily).
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
Nonsense. It can't. HHH *must* return and *does* return.
HHH.exe is required to return.
On 8/29/2025 2:24 PM, Richard Heathfield wrote:
On 29/08/2025 17:49, olcott wrote:
*DD simulated by HHH as a pure function of its input*
cannot possibly reach its "return" statement
So what you're saying is that HHH is incapable of correctly
analysing the halting behaviour of DD (which is known to halt).
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.
On 8/29/2025 2:24 PM, Richard Heathfield wrote:
On 29/08/2025 17:49, olcott wrote:
*DD simulated by HHH as a pure function of its input*
cannot possibly reach its "return" statement
So what you're saying is that HHH is incapable of correctly analysing
the halting behaviour of DD (which is known to halt).
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.
On 8/30/2025 10:55 AM, Richard Heathfield wrote:That is to say, it doesn't repeat because it is aborted.
On 30/08/2025 16:52, olcott wrote:
On 8/29/2025 2:23 PM, Richard Heathfield wrote:
It is an easily verified fact thatDD.exe is executed.
int main(void) {
DD();
return 0;
}
halts. Several of us /have/ verified that fact (easily).
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
Nonsense. It can't. HHH *must* return and *does* return.
HHH.exe is required to return.Requirements aren't factual or not, they are fulfilled or not.
HHH.sim1 cannot possibly return any requirement to the contrary is
simply counter-factual.
On 8/29/2025 2:24 PM, Richard Heathfield wrote:
On 29/08/2025 17:49, olcott wrote:
*DD simulated by HHH as a pure function of its input*
cannot possibly reach its "return" statement
So what you're saying is that HHH is incapable of correctly analysing
the halting behaviour of DD (which is known to halt).
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.
On 8/30/2025 5:42 AM, Mikko wrote:
On 2025-08-29 17:19:32 +0000, olcott said:
On 8/29/2025 3:38 AM, Mikko wrote:
On 2025-08-28 14:48:35 +0000, olcott said:
On 8/28/2025 2:46 AM, Mikko wrote:
On 2025-08-26 16:29:41 +0000, olcott said:
On 8/26/2025 4:29 AM, Mikko wrote:
On 2025-08-20 16:20:21 +0000, olcott said:
Turing machine deciders only compute the mapping
from their inputs...
Not the mapping but some computable mapping. And so do other Turing >>>>>>>> machines.
If the mapping is uncomputable there is no Turing machine that computes it.
Turing machines never compute the mapping
from their own behavior or the behavior
of their caller.
A Turing machine never refuses to compute from their the behaviour of >>>>>> its caller because it doesn't know that it has a caller, let alone the >>>>>> identity of the caller.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
if Ĥ applied to ⟨Ĥ⟩ halts, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if Ĥ applied to ⟨Ĥ⟩ does not halt.
Yet Linz requires Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ to report
on the behavior of its caller: Ĥ applied to ⟨Ĥ⟩
Linz does not require anything about Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩. He only
infers from the construction what it might do and evaluates the
consequences of every possibility that can't be excluded.
*Quoted from above and the requirement that I referred to*
if Ĥ applied to ⟨Ĥ⟩ does not halt.
if Ĥ applied to ⟨Ĥ⟩ does not halt.
That is not neither a requirement nor a condition but a condition.
It is not a condition because it is a condition?
As Dennis Bush keeps saying *it is a requirement*
Original Linz Turing Machine H
H.q0 ⟨M⟩ w ⊢* H.qy
if M applied to w halts, and
H.q0 ⟨M⟩ w ⊢* H.qn
if M applied to w does not halt
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ is required to report on the
behavior of its caller Ĥ ⟨Ĥ⟩.
Linz does not specify any requirements on Ĥ or any part of it. Instead
Ĥ is fully specified with a construction from H.
That you can't pay attention is not a rebuttal.
On 8/30/2025 3:25 AM, Fred. Zwarts wrote:
As usual incorrect and irrelevant claims.
I perfectly understand that a finite recursion is different from an
infinite recursion.
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
HHH(Infinite_Recursion); // is finite recursion
when measured by the screwy incorrect way that
you measure it.
On 8/30/2025 3:55 PM, joes wrote:
Am Sat, 30 Aug 2025 11:28:52 -0500 schrieb olcott:
On 8/30/2025 10:55 AM, Richard Heathfield wrote:That is to say, it doesn't repeat because it is aborted.
On 30/08/2025 16:52, olcott wrote:
On 8/29/2025 2:23 PM, Richard Heathfield wrote:
It is an easily verified fact thatDD.exe is executed.
int main(void) {
DD();
return 0;
}
halts. Several of us /have/ verified that fact (easily).
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
Nonsense. It can't. HHH *must* return and *does* return.
You haven't been paying attention to the static data issue.
The requirement that a TM compute the square root ofHHH.exe is required to return.Requirements aren't factual or not, they are fulfilled or not.
HHH.sim1 cannot possibly return any requirement to the
contrary is
simply counter-factual.
a dead rabbit is an incorrect requirement.
Likewise a requirement that HHH(DD) report
in the behavior of its DD() caller is also incorrect.
Halting *IS NOT* stopping running. Halting is only reaching a final
halt state.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 8/31/2025 5:58 AM, Fred. Zwarts wrote:
Op 30.aug.2025 om 17:12 schreef olcott:
On 8/30/2025 3:25 AM, Fred. Zwarts wrote:
As usual incorrect and irrelevant claims.
I perfectly understand that a finite recursion is different
from an infinite recursion.
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
HHH(Infinite_Recursion); // is finite recursion
when measured by the screwy incorrect way that
you measure it.
As usual irrelevant claims.
The DD based on the HHH that aborts does in no way compare to
Infinite_Recursion.
The problem is that HHH (and probably olcott, as well) does not
understand the difference between finite recursion and
non-termination.
This problem is all your mistake. Halting *IS NOT* stopping running.
Halting is only reaching a final halt state.
On 8/31/2025 5:58 AM, Fred. Zwarts wrote:
Op 30.aug.2025 om 17:12 schreef olcott:
On 8/30/2025 3:25 AM, Fred. Zwarts wrote:
As usual incorrect and irrelevant claims.
I perfectly understand that a finite recursion is different from an
infinite recursion.
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
HHH(Infinite_Recursion); // is finite recursion
when measured by the screwy incorrect way that
you measure it.
As usual irrelevant claims.
The DD based on the HHH that aborts does in no way compare to
Infinite_Recursion.
The problem is that HHH (and probably olcott, as well) does not
understand the difference between finite recursion and non-termination.
This problem is all your mistake. Halting *IS NOT* stopping running.
Halting is only reaching a final halt state.
The programmer of HHH ignores conditional branch instructions
encountered during the simulation. Then it aborts, but odes not prove
that these alternative branches will not be followed in a correct
continuation of the simulation. So, it does not prove non-termination
behaviour.
That is his attitude: he assumes that it is correct and uses that as a
proof that it is correct. An invalid circular reasoning.
On 8/30/2025 3:55 PM, joes wrote:
Am Sat, 30 Aug 2025 11:28:52 -0500 schrieb olcott:
On 8/30/2025 10:55 AM, Richard Heathfield wrote:That is to say, it doesn't repeat because it is aborted.
On 30/08/2025 16:52, olcott wrote:
On 8/29/2025 2:23 PM, Richard Heathfield wrote:
It is an easily verified fact thatDD.exe is executed.
int main(void) {
DD();
return 0;
}
halts. Several of us /have/ verified that fact (easily).
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
Nonsense. It can't. HHH *must* return and *does* return.
You haven't been paying attention to the static data issue.
The requirement that a TM compute the square root ofHHH.exe is required to return.Requirements aren't factual or not, they are fulfilled or not.
HHH.sim1 cannot possibly return any requirement to the contrary is
simply counter-factual.
a dead rabbit is an incorrect requirement.
Likewise a requirement that HHH(DD) report
in the behavior of its DD() caller is also incorrect.
An adapted UTM would not be required to simulate
all of the steps of its input Turing machine description.
On 8/31/2025 5:58 AM, Fred. Zwarts wrote:
Op 30.aug.2025 om 17:12 schreef olcott:
On 8/30/2025 3:25 AM, Fred. Zwarts wrote:
As usual incorrect and irrelevant claims.
I perfectly understand that a finite recursion is different from an
infinite recursion.
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
HHH(Infinite_Recursion); // is finite recursion
when measured by the screwy incorrect way that
you measure it.
As usual irrelevant claims.
The DD based on the HHH that aborts does in no way compare to
Infinite_Recursion.
The problem is that HHH (and probably olcott, as well) does not
understand the difference between finite recursion and non-termination.
This problem is all your mistake. Halting *IS NOT* stopping running.
Halting is only reaching a final halt state.
The programmer of HHH ignores conditional branch instructions
encountered during the simulation. Then it aborts, but odes not prove
that these alternative branches will not be followed in a correct
continuation of the simulation. So, it does not prove non-termination
behaviour.
That is his attitude: he assumes that it is correct and uses that as a
proof that it is correct. An invalid circular reasoning.
On 8/31/2025 11:36 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
[ .... ]
Halting *IS NOT* stopping running. Halting is only reaching a final
halt state.
How can a turing machine stop running without reaching a final halt
state?
An adapted UTM would not be required to simulate
all of the steps of its input Turing machine description.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
olcott <polcott333@gmail.com> wrote:
On 8/31/2025 11:36 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
[ .... ]
Halting *IS NOT* stopping running. Halting is only reaching a final
halt state.
How can a turing machine stop running without reaching a final halt
state?
An adapted UTM would not be required to simulate
all of the steps of its input Turing machine description.
Which has got precisely nothing to do with the (rhetorical) question I
asked.
The answer is that a TM stopping running is exactly equivalent to it
reaching a final halt state. That has some relevance to your
unsupported assertion that "halting is not stopping running".
If your primary goal is to be disagreeable that
reply met the mark. It looks like you tried as
hard as possible to make sure to disagree.
On the other hand when the simulated Turing
machine description is only partially simulated
by an adapted UTM such that this partial
simulation does not reach a simulated final
halt state this is the example of a simulated
TM that stops running yet has not halted.
On 9/1/2025 4:50 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 8/31/2025 11:36 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
[ .... ]
Halting *IS NOT* stopping running. Halting is only reaching a final >>>>> halt state.
How can a turing machine stop running without reaching a final halt
state?
An adapted UTM would not be required to simulate
all of the steps of its input Turing machine description.
Which has got precisely nothing to do with the (rhetorical) question I
asked.
The answer is that a TM stopping running is exactly equivalent to it
reaching a final halt state. That has some relevance to your
unsupported assertion that "halting is not stopping running".
If your primary goal is to be disagreeable that
reply met the mark. It looks like you tried as
hard as possible to make sure to disagree.
On the other hand when the simulated Turing
machine description is only partially simulated
by an adapted UTM such that this partial
simulation does not reach a simulated final
halt state this is the example of a simulated
TM that stops running yet has not halted.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 8/31/2025 11:36 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
[ .... ]
Halting *IS NOT* stopping running. Halting is only reaching a final
halt state.
How can a turing machine stop running without reaching a final halt
state?
An adapted UTM would not be required to simulate
all of the steps of its input Turing machine description.
[ .... ]
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 9/1/2025 9:41 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 9/1/2025 4:50 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 8/31/2025 11:36 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
[ .... ]
Halting *IS NOT* stopping running. Halting is only reaching a final >>>>>>> halt state.
How can a turing machine stop running without reaching a final halt >>>>>> state?
An adapted UTM would not be required to simulate
all of the steps of its input Turing machine description.
Which has got precisely nothing to do with the (rhetorical) question I >>>> asked.
The answer is that a TM stopping running is exactly equivalent to it
reaching a final halt state. That has some relevance to your
unsupported assertion that "halting is not stopping running".
If your primary goal is to be disagreeable that
reply met the mark. It looks like you tried as
hard as possible to make sure to disagree.
No, I'm just pointing out one of your misunderstandings.
On the other hand when the simulated Turing
machine description is only partially simulated
by an adapted UTM such that this partial
simulation does not reach a simulated final
halt state this is the example of a simulated
TM that stops running yet has not halted.
We're talking about the halting problem here, and all the computation
(including any simulation) is done in a single universal turing machine.
Should this UTM stop running, it is in a halt state. Unless, and until
it does, it's not.
The decider is a UTM that has been adapted so that
it aborts its simulation once it sees that its input
cannot possibly reach its own simulated final halt state.
This machine and its input are not one-and-the-same thing.
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⟩
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
This problem is all your mistake. Halting *IS NOT* stopping running.
Halting is only reaching a final halt state.
The decider is a UTM that has been adapted so that
it aborts its simulation once it sees that its input
cannot possibly reach its own simulated final halt state.
On 9/1/2025 11:14 AM, Kaz Kylheku wrote:
On 2025-08-31, olcott <polcott333@gmail.com> wrote:
This problem is all your mistake. Halting *IS NOT* stopping running.
Halting is only reaching a final halt state.
It seems that the long list of things you don't understand includes the
word "final"? As in there not being a next?
"Running" is an informal term referring to tracing the state
transitions of a machine. The "final" state has no transition to a next
state, so the running comes to a halt there.
computation that halts… “the Turing machine will halt
whenever it enters a final state” (Linz:1990:234)
⟨M⟩ ⟨M⟩ correctly simulated by M.H cannot possibly
reach its simulated final halt state of ⟨M.qn⟩
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⟩
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 03:46:59 |
| Calls: | 10,386 |
| Calls today: | 1 |
| Files: | 14,057 |
| Messages: | 6,416,597 |