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.
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.
...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.
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.
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.
All that HHH need know is that DD correctly simulatedChanges the input.
by HHH
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
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?
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.
[ .... ]
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
That all the proofs that I know of Linz in
particular require that mapping from non-input
Turing machines that are not mere descriptions.
On 8/21/2025 12:13 PM, olcott wrote:
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 11:20 AM, dbush wrote:
On 8/21/2025 12:13 PM, olcott wrote:
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.
I am saying that when DD calls HHH(DD)
in recursive simulation that this cannot
f-cking be simply ignored.
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
Turing Machine Linz Ĥ applied to its own machine description ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
*When Ĥ.embedded_H is based on a UTM*
*Repeats until aborted*
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
If Ĥ.embedded_H cannot possibly see the repeating
state then we know something we never knew before:
that Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn would be correct.
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 theIt is because you don't know logic IF/AND/OR/NOT. People have difficulty discussing with you. Let's try this one:
significance of it as I outlined above.
If Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ is smart enough to see the
repeating state then the repeating state in the
correct simulation of the input supersedes the
behavior of non-input Ĥ applied to ⟨Ĥ⟩.
[ .... ]
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
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.
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 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 21/08/2025 16:23, olcott wrote:
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?
Capitals, eh?
Turing machine deciders only compute the mapping
from their inputs...
HHH isn't a TM, but let's run with it. HHH's input is DD, so that's what
HHH has to work with.
DD calls HHH, so HHH is therefore part of what HHH has to work with, and
its behaviour affects DD's behaviour. You need to account for that, but
you don't seem terribly interested. You just want to exercise your caps lock. Wake me up when you find your ears.
I keep telling you that stopping does not
DOES NOT COUNT AS HALTING
Yeah it does.
On 8/21/2025 10:54 AM, Alan Mackenzie wrote:Either you've misunderstood those proofs, or the authors of those proofs misunderstood turing machines. My bet is on the former.
olcott <polcott333@gmail.com> wrote:That all the proofs that I know of Linz in
[ .... ]
HOW MANY TIMES DO I HAVE TO SAY THIS BEFOREWhy do you bother saying it at all? How could it be otherwise?
YOU NOTICE THAT I EVER SAID IT AT LEAST ONCE?
Turing machine deciders only compute the mapping
from their inputs...
particular require that mapping from non-input
Turing machines that are not mere descriptions.
Linz requires Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ to report onAt the risk of repeating myself, a turing machine is a system of states
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[ Irrelevant material removed. ]
No, I think you have failed to grasp the concept of the turing machine.From the very definition of a turing machine, it does nothing but moveThey don't pay close enough attention to see the
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.
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
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.
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 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,Nope, TM cannot see, TM reads symbols on its tape.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
No Turing machine can see its own behavior
thus no Turing machine can report on itsSo, all your deduction are base on false assumption and dogma
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 Thu, 2025-08-21 at 17:50 -0500, olcott wrote:
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
Nope, TM cannot see, TM reads symbols on its tape.
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.
So, all your deduction are base on false assumption and dogma
On 8/21/2025 6:02 PM, wij wrote:
On Thu, 2025-08-21 at 17:50 -0500, olcott wrote:
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
Nope, TM cannot see, TM reads symbols on its tape.
The symbols on its tape are not its actual self.What is exactly "its actual self" on its tape?
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.
So, all your deduction are base on false assumption and dogma
No, yet again you do not pay enough attention.
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.
Op 22.aug.2025 om 00:50 schreef olcott:
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.
Incorrect. There is no need to report on its own behaviour. It must
report the behaviour specified in the input.
Further it does not need to report on its own behaviour, but on the behaviour of a copy of the code specified in the input. This input has everything needed to analyse the behaviour.
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.
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.
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 22/08/2025 17:09, olcott wrote:
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;
}
It's /not/ the same, though, is it?
Infinite_Recursion() doesn't take any steps to avoid infinite recursion. INFINITE
expr() { term(); op(); term(); }
term() { factor(); op(); factor(); }
factor() { expr(); /* or number */}
/looks/ like infinite recursion, but of course the grammar will stop it.
NOT INFINITE
factorial() { while not base case{calc * factorial()}} stops itself with
a base case. NOT INFINITE
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.
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 2:50 AM, Fred. Zwarts wrote:False, as you have admitted on the record (see below):
Op 22.aug.2025 om 00:50 schreef olcott:
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.
Incorrect. There is no need to report on its own behaviour. It must
report the behaviour specified in the input.
Further it does not need to report on its own behaviour, but on the
behaviour of a copy of the code specified in the input. This input has
everything needed to analyse the behaviour.
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
On 8/15/2025 10:24 AM, olcott wrote:return 1.
On 8/15/2025 7:58 AM, dbush wrote:
On 8/15/2025 8:48 AM, olcott wrote:
<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:
--- Synchronet 3.21a-Linux NewsLink 1.2
And HHH fails to do so as the pattern it detects exists in the
halting program DD and is therefore not a non-halting behavior pattern.
Failing to explain why this is wrong in your next reply or within one
hour of your next post in this newsgroup will be taken as your
official on-the-record admission that the pattern HHH detects is NOT
a non- halting behavior pattern
Let the record show that Peter Olcott made no attempt to explain why the above is wrong. Therefore:
Let The Record Show:
That Peter Olcott
Has *officially* admitted
That the pattern detected by HHH is in fact NOT a non-halting behavior pattern because it exists in the halting computation DD, and furthermore than HHH fails to meet the specification that he gave.
On 8/22/2025 11:36 AM, Richard Heathfield wrote:
On 22/08/2025 17:09, olcott wrote:
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;
}
It's /not/ the same, though, is it?
Infinite_Recursion() doesn't take any steps to avoid infinite
recursion. INFINITE
expr() { term(); op(); term(); }
term() { factor(); op(); factor(); }
factor() { expr(); /* or number */}
/looks/ like infinite recursion, but of course the grammar will stop
it. NOT INFINITE
factorial() { while not base case{calc * factorial()}} stops itself
with a base case. NOT INFINITE
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
final halt state
On 8/22/2025 12:09 PM, olcott wrote:
On 8/22/2025 2:50 AM, Fred. Zwarts wrote:False, as you have admitted on the record (see below):
Op 22.aug.2025 om 00:50 schreef olcott:
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.
Incorrect. There is no need to report on its own behaviour. It must
report the behaviour specified in the input.
Further it does not need to report on its own behaviour, but on the
behaviour of a copy of the code specified in the input. This input
has everything needed to analyse the behaviour.
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
On 8/22/2025 12:27 PM, dbush wrote:
On 8/22/2025 12:09 PM, olcott wrote:
On 8/22/2025 2:50 AM, Fred. Zwarts wrote:False, as you have admitted on the record (see below):
Op 22.aug.2025 om 00:50 schreef olcott:
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.
Incorrect. There is no need to report on its own behaviour. It must
report the behaviour specified in the input.
Further it does not need to report on its own behaviour, but on the
behaviour of a copy of the code specified in the input. This input
has everything needed to analyse the behaviour.
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
Liar
Erasing the immediate context that you are
responding to is deceitful and dishonest.
On 8/15/2025 11:37 AM, dbush wrote:
On 8/15/2025 10:24 AM, olcott wrote:return 1.
On 8/15/2025 7:58 AM, dbush wrote:
On 8/15/2025 8:48 AM, olcott wrote:
<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:
pattern.
And HHH fails to do so as the pattern it detects exists in the
halting program DD and is therefore not a non-halting behavior
Failing to explain why this is wrong in your next reply or within one >> >>> hour of your next post in this newsgroup will be taken as your
official on-the-record admission that the pattern HHH detects is NOT
a non- halting behavior pattern
Let the record show that Peter Olcott made no attempt to explain why the >> > above is wrong. Therefore:
Let The Record Show:
That Peter Olcott
Has *officially* admitted
That the pattern detected by HHH is in fact NOT a non-halting behavior
pattern because it exists in the halting computation DD, and furthermore> >> > than HHH fails to meet the specification that he gave.
Liar
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.
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);
}
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,064 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 152:44:17 |
| Calls: | 13,691 |
| Calls today: | 1 |
| Files: | 186,936 |
| D/L today: |
2,522 files (731M bytes) |
| Messages: | 2,411,051 |