On 10/19/2025 4:43 AM, Tristan Wibberley wrote:
On 18/10/2025 12:20, olcott wrote:
H can abort its simulation of D and correctly report
that [the simulated] D specifies a non-halting sequence
of configurations.
This might be interpretable in plain English to allow a safe interpreter.
"correctly" might mean "permittedly" rather than "accurately describes
DD(HHH).
(c) If HHH must abort its simulation to prevent its own non-termination
then HHH is correct to abort this simulation and return 0.
abort and return 0.
(c) allows a "safe" interpreter - to prevent its own non-termination,
the simulator/emulator must abort and return 0 even for /some/ inputs
that would terminate if the simulator/emulator hadn't aborted.
If you understand the language well enough you will understand
that the only way that HHH(DD) would terminate is out-of-memory
error. This *does not count as halting*
#define ENABLE_ABORT_CODE 1
When commented out
HHH(DD) does not halt.
The English-language parts of the descriptions permits that same safe
interpreter but also permits a wider selection of safe interpreters when
"correctly" is interpreted as I described above.
Neither specification provided is equivalent to the halting problem due
to the use of the conditional "if [it] must" and the allowance "may
correctly" which might even allow a free choice of determiner to select
among equivalent sets of cruelly-abandoned inputs. Minimal sets in the
case of "if [it] must" and arbitrarily large sets in the case of "may
correctly".
The better way to define
DD is simulated correctly by HHH is
DD is simulated by HHH according to the semantics of the C language.
This gives people no wiggle room for misinterpretation.
--
Tristan Wibberley
The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.
On 2025-10-18 11:20:25 +0000, olcott said:
Both ChatGPT and Claude AI have agreed that these two
specifications are equivalent when the last two lines
of the first spec are interpreted to mean:
H can abort its simulation of D and correctly report
that [the simulated] D specifies a non-halting sequence
of configurations.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
would never stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
<Input to LLM systems>
Please think this all the way through without making any guesses
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.
(c) If HHH must abort its simulation to prevent its own non-termination
then HHH is correct to abort this simulation and return 0.
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
What value should HHH(DD) correctly return?
Note that the word "correct" has different meanings. For example,
a return value that is correct according to the specifications
(a), (b), and (c) can be incorrect as a return vaule of a halt
decider.
On 10/18/2025 12:06 PM, Kaz Kylheku wrote:
On 2025-10-18, olcott <polcott333@gmail.com> wrote:
On 10/18/2025 10:53 AM, vallor wrote:^^^^^^^
At Sat, 18 Oct 2025 09:48:01 -0500, olcott <polcott333@gmail.com> wrote: >>>>
On 10/18/2025 9:43 AM, vallor wrote:
At Sat, 18 Oct 2025 06:20:25 -0500, olcott <polcott333@gmail.com> wrote: >>>>>>
Puh-LEASE stop crossposting your...stuff...to comp.lang.c.
How about I only make one cross post per week and
always set followup to comp.theory?
Why? You aren't posting about C.
The core of my whole proof that
*The halting problem is either incoherent or the proof wrong*
depends on this simple C code
<Input to LLM systems>
Please think this all the way through without making any guesses
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.
(c) If HHH must abort its simulation to prevent its own non-termination
then HHH is correct to abort this simulation and return 0.
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
This. Leaves behind an incomplete simulation. That simulation
denotes a halting computation; it can be stepped further, instruction
by instruction, until DD returns.
You are ignoring rule (c) and you did not ignore this
the other day.
On 10/18/2025 6:30 PM, joes wrote:
Am Sat, 18 Oct 2025 17:26:29 -0500 schrieb olcott:
On 10/18/2025 12:06 PM, Kaz Kylheku wrote:No. HHH can abort and still return that the input halts.
On 2025-10-18, olcott <polcott333@gmail.com> wrote:
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. (c) If HHH must abort its simulation to prevent its own non-
termination then HHH is correct to abort this simulation and return 0.
You are ignoring rule (c) and you did not ignore this the other day.int DD()^^^^^^^
{
int Halt_Status = HHH(DD);
This. Leaves behind an incomplete simulation. That simulation denotes a >>>> halting computation; it can be stepped further, instruction by
instruction, until DD returns.
It is pretty simple actually. If HHH must abort its
simulation of its input to prevent its own non-termination
then this input does specify non-halting behavior, duh !
But you don’t explore the abandoned simulation.That's something that could be explored by C coding.Hence why at least this portion of my proof is related to C.
It is self-evident that when a simulating halt
decider must abort its simulation to prevent its
own non-termination that this *INPUT*
(not anything else in the universe) does specify
non-halting behavior.
On 18/10/2025 16:53, vallor wrote:[...]
You aren't posting about C.
And I notice you crossposted this article (which has nothing to do with
C) and didn't set the followup-to (as you claimed you were going to do).
His reply was an honest enquiry about the proper use of comp.lang.c.
How about you paste into your reply to him on comp.lang.c a copy of the
big-8 steering board's rules for comp.lang.c.
On 2025-10-18, olcott <polcott333@gmail.com> wrote:
On 10/18/2025 12:06 PM, Kaz Kylheku wrote:
On 2025-10-18, olcott <polcott333@gmail.com> wrote:
On 10/18/2025 10:53 AM, vallor wrote:^^^^^^^
At Sat, 18 Oct 2025 09:48:01 -0500, olcott <polcott333@gmail.com> wrote: >>>>>
On 10/18/2025 9:43 AM, vallor wrote:
At Sat, 18 Oct 2025 06:20:25 -0500, olcott <polcott333@gmail.com> wrote:
Puh-LEASE stop crossposting your...stuff...to comp.lang.c.
How about I only make one cross post per week and
always set followup to comp.theory?
Why? You aren't posting about C.
The core of my whole proof that
*The halting problem is either incoherent or the proof wrong*
depends on this simple C code
<Input to LLM systems>
Please think this all the way through without making any guesses
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. >>>> (c) If HHH must abort its simulation to prevent its own non-termination >>>> then HHH is correct to abort this simulation and return 0.
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
This. Leaves behind an incomplete simulation. That simulation
denotes a halting computation; it can be stepped further, instruction
by instruction, until DD returns.
You are ignoring rule (c) and you did not ignore this
the other day.
Rule (c) is incorrect, and unjustified. It is nothing more than
an assertion "My cranky idea is correct!" without proof.
If HHH must abort a simulation, then in many cases it /is/ correct, such
as HHH(Infinite_Recursion) and HHH(Infinite_Loop). It is not correct in
/all/ cases.
HHH can be shown to incorrectly return 0 for a terminating calculation
such as DD.
It is obvious that a diagonal input targeting a simulating decider will /always/ appear non-terminating to a simulating decider, even though
it terminates.
The key issue is that the DD program performs a few more steps after
HHH(DD) terminates and returns to it. This is because HHH(DD)'s
behavior /specifies/ when DD terminates.
Suppose HHH(DD) returns 0 in N instructions. DD always requires
a few more instructions k after that: DD returns in N + k
instructions.
Since N and k are positive:
N + k > N
So you see? HHH(DD) is finished in N instructions, but the
complete execution of DD is N + k instructions long.
HHH(DD) has a "budget" of exactly N instructions for itself,
but getting to the end DD() requires tracing N + k instructions.
Even if HHH is so efficient that it can dispatch a single debug step of
DD for every one instruction of its own execution, its aborting
simulation cannot reach the end of DD.
Not reaching the end of DD, and returning 0, does not prove that
DD does not have an end.
While HHH must abort to prevent non-termination, the 0 value is
not correct, and cannot possibly be.
If you understand the language well enough you will understand that theYeah, but that’s a different program. The input does not have that
only way that HHH(DD) would terminate is out-of-memory error. This *does
not count as halting*
#define ENABLE_ABORT_CODE 1 When commented out HHH(DD) does not halt.
Are you under the impression that the board has specific rules for comp.lang.c?
Some newsgroups have charters. comp.lang.c does not, since it was
created before newsgroup charters were introduced.
(I personally encourage everyone not to reply to olcott's posts in comp.lang.c. He's already taken over one newsgroup.)
...the only way that HHH(DD) would terminate [in this variant challenge> is out-of-memory
error.
This *does not count as halting*
I have to keep taking to the LLM until ...
It weaves all my ideas together ...
until it totally
gets my whole point.
The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except as noted in
the sig.
On 19/10/2025 15:55, olcott wrote:
...the only way that HHH(DD) would terminate [in this variant challenge> is out-of-memory
error.
haha, yes, of course it's not conforming C because you recurse
unboundedly! what is it undefined behaviour?
On 2025-10-18, olcott <polcott333@gmail.com> wrote:
On 10/18/2025 12:06 PM, Kaz Kylheku wrote:
On 2025-10-18, olcott <polcott333@gmail.com> wrote:
On 10/18/2025 10:53 AM, vallor wrote:^^^^^^^
At Sat, 18 Oct 2025 09:48:01 -0500, olcott <polcott333@gmail.com> wrote: >>>>>
On 10/18/2025 9:43 AM, vallor wrote:
At Sat, 18 Oct 2025 06:20:25 -0500, olcott <polcott333@gmail.com> wrote:
Puh-LEASE stop crossposting your...stuff...to comp.lang.c.
How about I only make one cross post per week and
always set followup to comp.theory?
Why? You aren't posting about C.
The core of my whole proof that
*The halting problem is either incoherent or the proof wrong*
depends on this simple C code
<Input to LLM systems>
Please think this all the way through without making any guesses
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. >>>> (c) If HHH must abort its simulation to prevent its own non-termination >>>> then HHH is correct to abort this simulation and return 0.
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
This. Leaves behind an incomplete simulation. That simulation
denotes a halting computation; it can be stepped further, instruction
by instruction, until DD returns.
You are ignoring rule (c) and you did not ignore this
the other day.
Rule (c) is incorrect, and unjustified. It is nothing more than
an assertion "My cranky idea is correct!" without proof.
On 2025-10-19, olcott <polcott333@gmail.com> wrote:
On 10/18/2025 6:30 PM, joes wrote:
Am Sat, 18 Oct 2025 17:26:29 -0500 schrieb olcott:
On 10/18/2025 12:06 PM, Kaz Kylheku wrote:No. HHH can abort and still return that the input halts.
On 2025-10-18, olcott <polcott333@gmail.com> wrote:
You are ignoring rule (c) and you did not ignore this the other day.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. (c) If HHH must abort its simulation to prevent its own non-
termination then HHH is correct to abort this simulation and return 0. >>>
int DD()
{
int Halt_Status = HHH(DD);
This. Leaves behind an incomplete simulation. That simulation denotes a >>>>> halting computation; it can be stepped further, instruction by
instruction, until DD returns.
It is pretty simple actually. If HHH must abort its
simulation of its input to prevent its own non-termination
then this input does specify non-halting behavior, duh !
That's just something you believe and repeat without proof.
This is easy to disprove; the aborted simulation has not actually
terminated; it has a next instruction that it can execute.
(Not that it matters, but in your false claim you are agreeing
with this: if you believe DD doesn't terminate, you must
believe that the DD simulation can be continued ad nauseum,
and therefore it has a next instruction it can fetch,
decode and execute.)
On 2025-10-19, olcott <polcott333@gmail.com> wrote:
It is self-evident that when a simulating halt
The problem is that your idea of "self-evident" is about as reliable as
of that the average flat earther.
The claim is false (and it is not even self-evident that it is so,
though only very mildly difficult to see)
decider must abort its simulation to prevent its
own non-termination that this *INPUT*
(not anything else in the universe) does specify
non-halting behavior.
Nope; rather the terminating point of the /diagonal case/ always
lies beyond that instruction where the decider has decided to
abort. It is always out of reach.
To the naive programmer it may appear that DD is not terminating.
The naive programmer believes that DD is one function, one input case.
He /edits/ HHH in-place to play with the abort rules. No matter how he changes the abort rules, no matter hwo long DD is able to execute under
the revised rules, HHH always reaches the abort decision first.
Gee, it must be that DD doens't terminate!
Well, that ain't how it is.
On 19/10/2025 19:04, Kaz Kylheku wrote:
On 2025-10-18, olcott <polcott333@gmail.com> wrote:
On 10/18/2025 12:06 PM, Kaz Kylheku wrote:
On 2025-10-18, olcott <polcott333@gmail.com> wrote:
On 10/18/2025 10:53 AM, vallor wrote:^^^^^^^
At Sat, 18 Oct 2025 09:48:01 -0500, olcott <polcott333@gmail.com> >>>>>> wrote:
On 10/18/2025 9:43 AM, vallor wrote:
At Sat, 18 Oct 2025 06:20:25 -0500, olcott
<polcott333@gmail.com> wrote:
Puh-LEASE stop crossposting your...stuff...to comp.lang.c.
How about I only make one cross post per week and
always set followup to comp.theory?
Why? You aren't posting about C.
The core of my whole proof that
*The halting problem is either incoherent or the proof wrong*
depends on this simple C code
<Input to LLM systems>
Please think this all the way through without making any guesses
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.
(c) If HHH must abort its simulation to prevent its own non-
termination
then HHH is correct to abort this simulation and return 0. >>>>>
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
This. Leaves behind an incomplete simulation. That simulation
denotes a halting computation; it can be stepped further, instruction
by instruction, until DD returns.
You are ignoring rule (c) and you did not ignore this
the other day.
Rule (c) is incorrect, and unjustified. It is nothing more than
an assertion "My cranky idea is correct!" without proof.
If HHH must abort a simulation, then in many cases it /is/ correct, such
as HHH(Infinite_Recursion) and HHH(Infinite_Loop). It is not correct in
/all/ cases.
HHH can be shown to incorrectly return 0 for a terminating calculation
such as DD.
It is obvious that a diagonal input targeting a simulating decider will
/always/ appear non-terminating to a simulating decider, even though
it terminates.
The key issue is that the DD program performs a few more steps after
HHH(DD) terminates and returns to it. This is because HHH(DD)'s
behavior /specifies/ when DD terminates.
Suppose HHH(DD) returns 0 in N instructions. DD always requires
a few more instructions k after that: DD returns in N + k
instructions.
Since N and k are positive:
N + k > N
So you see? HHH(DD) is finished in N instructions, but the
complete execution of DD is N + k instructions long.
HHH(DD) has a "budget" of exactly N instructions for itself,
but getting to the end DD() requires tracing N + k instructions.
Even if HHH is so efficient that it can dispatch a single debug step of
DD for every one instruction of its own execution, its aborting
simulation cannot reach the end of DD.
Not reaching the end of DD, and returning 0, does not prove that
DD does not have an end.
While HHH must abort to prevent non-termination, the 0 value is
not correct, and cannot possibly be.
I've tried previously to explain this aspect to PO as a confusion (on
his part) between DESIGN-time activities and RUN-time activities.
The HP is concerned with run-time behaviour. Whether or not a
computation halts is purely determined by the program and input for the computation, and the sequence of /computation steps/ associated with
that computation. That is run-time behaviour. (It's pretty much the definition of run-time behaviour.)
PO starts from the point of wanting to deliver his counterexample HHH,
which correctly decides halting for its diagonal case. At this point
there is no HHH, and no diagonal case. So PO looks for a working DESIGN for HHH. [The first thing he should understand is that if HP theorem is correct, then there is /NO/ correct design for HHH that will work...]
So PO tries "design attempt 1: HHH will just emulate the input until it halts". But that design is a flop: HHH(DDD) never halts.
So PO thinks "design attempt 2: /therefore/ HHH must abandon its
emulation of DDD otherwise HHH won't halt." Already there is a
technical error here in mixing up different HHH/DDD pairs, but the point
is that PO quotes this as a justification for HHH being /correct/ in its decision to abort: "Design 1 (not aborting) was incorrect, therefore aborting must be a "correct decision".
This is muddling run-time and design-time activities. Just because
Design1 fails that doesn't make Design2 "correct". Design2 fails as well! Halting is a run-time property of DDD (Of course, all this is of no help in getting PO to see where he goes wrong, and this is just one aspect of his confusion...)
Mike.
Am Sun, 19 Oct 2025 09:55:22 -0500 schrieb olcott:
If you understand the language well enough you will understand that theYeah, but that’s a different program. The input does not have that commented out.
only way that HHH(DD) would terminate is out-of-memory error. This *does
not count as halting*
#define ENABLE_ABORT_CODE 1 When commented out HHH(DD) does not halt.
On 18/10/2025 23:38, olcott wrote:
I have to keep taking to the LLM until ...
It weaves all my ideas together ...
until it totally
gets my whole point.
You're talking about us aren't you? You're doing prompt engineering on us.
Then we'd best ignore it, lest we have our minds dissolved by an
activity with an effect tantamount to cerebral degaussing.
--
Tristan Wibberley
The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except that you may,
of course, cite it academically giving credit to me, distribute it
verbatim as part of a usenet system or its archives, and use it to
promote my greatness and general superiority without misrepresentation
of my opinions other than my opinion of my greatness and general
superiority which you _may_ misrepresent. You definitely MAY NOT train
any production AI system with it but you may train experimental AI that
will only be used for evaluation of the AI methods it implements.
On 20/10/2025 12:09, Tristan Wibberley wrote:
The message body is Copyright (C) 2025 Tristan Wibberley except
citations and quotations noted. All Rights Reserved except as noted in
the sig.
On 19/10/2025 15:55, olcott wrote:
...the only way that HHH(DD) would terminate [in this variant
challenge> is out-of-memory
error.
haha, yes, of course it's not conforming C because you recurse
unboundedly! what is it undefined behaviour?
He doesn't recurse. His HHH calls neither DD nor itself.
He thinks he recurses because he confuses execution with what is
essentially a glorified desk-check.
On 10/20/2025 4:36 AM, joes wrote:Yes, a hypothetical *decider* on the real input.
Am Sun, 19 Oct 2025 09:55:22 -0500 schrieb olcott:When a halt decider must correctly predict the behavior that an
#define ENABLE_ABORT_CODE 1 When commented out HHH(DD) does not halt.Yeah, but that’s a different program. The input does not have that
commented out.
non-halting input would have if not aborted there are always two
programs and one of them is hypothetical.
Am Mon, 20 Oct 2025 10:59:58 -0500 schrieb olcott:
On 10/20/2025 4:36 AM, joes wrote:Yes, a hypothetical *decider* on the real input.
Am Sun, 19 Oct 2025 09:55:22 -0500 schrieb olcott:When a halt decider must correctly predict the behavior that an
#define ENABLE_ABORT_CODE 1 When commented out HHH(DD) does not halt.Yeah, but that’s a different program. The input does not have that
commented out.
non-halting input would have if not aborted there are always two
programs and one of them is hypothetical.
On 10/19/2025 8:30 PM, Mike Terry wrote:
The HP is concerned with run-time behaviour. Whether or not a
computation halts is purely determined by the program and input for the
computation, and the sequence of /computation steps/ associated with
that computation. That is run-time behaviour. (It's pretty much the
definition of run-time behaviour.)
That is exactly what make the Halting Problem a Category Error
The Halting Problem is a Category Error (see pages 14-15)
https://www.researchgate.net/publication/396689092_The_Halting_Problem_is_a_Category_Error
Please think this all the way through without making any guesses
On 10/19/2025 1:12 PM, Kaz Kylheku wrote:
On 2025-10-19, olcott <polcott333@gmail.com> wrote:
On 10/18/2025 6:30 PM, joes wrote:
Am Sat, 18 Oct 2025 17:26:29 -0500 schrieb olcott:
On 10/18/2025 12:06 PM, Kaz Kylheku wrote:No. HHH can abort and still return that the input halts.
On 2025-10-18, olcott <polcott333@gmail.com> wrote:
You are ignoring rule (c) and you did not ignore this the other day.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. (c) If HHH must abort its simulation to prevent its own non-
termination then HHH is correct to abort this simulation and return 0. >>>>
int DD()
{
int Halt_Status = HHH(DD);
This. Leaves behind an incomplete simulation. That simulation denotes a >>>>>> halting computation; it can be stepped further, instruction by
instruction, until DD returns.
It is pretty simple actually. If HHH must abort its
simulation of its input to prevent its own non-termination
then this input does specify non-halting behavior, duh !
That's just something you believe and repeat without proof.
This is easy to disprove; the aborted simulation has not actually
terminated; it has a next instruction that it can execute.
(Not that it matters, but in your false claim you are agreeing
with this: if you believe DD doesn't terminate, you must
believe that the DD simulation can be continued ad nauseum,
and therefore it has a next instruction it can fetch,
decode and execute.)
<Input to LLM systems>
Please think this all the way through without making any guesses
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) It correctly detects that its simulated input cannot
possibly reach its own simulated final halt state then:
abort simulation and return 0 rejecting its input as non-halting.
(b) Simulated input reaches its simulated "return" statement: return 1.
It is now direct proof that the simulated input
specifies a non-halting sequence of configurations.
On 10/20/2025 4:36 AM, joes wrote:
Am Sun, 19 Oct 2025 09:55:22 -0500 schrieb olcott:
If you understand the language well enough you will understand that theYeah, but that’s a different program. The input does not have that
only way that HHH(DD) would terminate is out-of-memory error. This *does >>> not count as halting*
#define ENABLE_ABORT_CODE 1 When commented out HHH(DD) does not halt.
commented out.
When a halt decider must correctly predict the behavior
that an non-halting input would have if not aborted there
are always two programs and one of them is hypothetical.
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 4:36 AM, joes wrote:
Am Sun, 19 Oct 2025 09:55:22 -0500 schrieb olcott:
If you understand the language well enough you will understand that the >>>> only way that HHH(DD) would terminate is out-of-memory error. This *does >>>> not count as halting*Yeah, but that’s a different program. The input does not have that
#define ENABLE_ABORT_CODE 1 When commented out HHH(DD) does not halt.
commented out.
When a halt decider must correctly predict the behavior
that an non-halting input would have if not aborted there
are always two programs and one of them is hypothetical.
No, both programs are real and can be constructed.
Your HHH is reporting on the wrong one. It is asked to analyze
a terminating one, but you're hypothesizing that it's still
making a remark on that other non-terminating one.
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
On 10/19/2025 1:12 PM, Kaz Kylheku wrote:
On 2025-10-19, olcott <polcott333@gmail.com> wrote:
On 10/18/2025 6:30 PM, joes wrote:
Am Sat, 18 Oct 2025 17:26:29 -0500 schrieb olcott:
On 10/18/2025 12:06 PM, Kaz Kylheku wrote:
On 2025-10-18, olcott <polcott333@gmail.com> wrote:
You are ignoring rule (c) and you did not ignore this the other day. >>>>> No. HHH can abort and still return that the input halts.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. (c) If HHH must abort its simulation to prevent its own non- >>>>>>>> termination then HHH is correct to abort this simulation and return 0. >>>>>
int DD()
{
int Halt_Status = HHH(DD);
This. Leaves behind an incomplete simulation. That simulation denotes a >>>>>>> halting computation; it can be stepped further, instruction by
instruction, until DD returns.
It is pretty simple actually. If HHH must abort its
simulation of its input to prevent its own non-termination
then this input does specify non-halting behavior, duh !
That's just something you believe and repeat without proof.
This is easy to disprove; the aborted simulation has not actually
terminated; it has a next instruction that it can execute.
(Not that it matters, but in your false claim you are agreeing
with this: if you believe DD doesn't terminate, you must
believe that the DD simulation can be continued ad nauseum,
and therefore it has a next instruction it can fetch,
decode and execute.)
<Input to LLM systems>
Please think this all the way through without making any guesses
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) It correctly detects that its simulated input cannot
possibly reach its own simulated final halt state then:
abort simulation and return 0 rejecting its input as non-halting.
(b) Simulated input reaches its simulated "return" statement: return 1.
It is now direct proof that the simulated input
specifies a non-halting sequence of configurations.
This is because you believe there is one DD which is always
the same input.
On 10/20/2025 1:50 PM, Kaz Kylheku wrote:Only you are baffled that a template is not a program.
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
This is the one DD that is the input to every HHH matching the above template. Technically this is an infinite set of HHH/DD pairs yet thisIt is now direct proof that the simulated input specifies aThis is because you believe there is one DD which is always the same
non-halting sequence of configurations
input.
degree of technical precision baffles half of the people here.
When we make pretend that there is only one and this is the only oneEmphasis on „pretend”. You pretend that the template filled in with a non-aborting simulator instead of HHH is the same program as DD.
that we are looking at then the analysis comes out the same and half the people here will not be overwhelmed.
The smart people here act like when a person answers a simple yes or not question that a different answer makes them into an entirely different person. That is nutty for people and equally nutty for halt deciders.People have choice; deciders are programmed.
Am Mon, 20 Oct 2025 14:50:42 -0500 schrieb olcott:
On 10/20/2025 1:50 PM, Kaz Kylheku wrote:
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
Only you are baffled that a template is not a program.This is the one DD that is the input to every HHH matching the aboveIt is now direct proof that the simulated input specifies aThis is because you believe there is one DD which is always the same
non-halting sequence of configurations
input.
template. Technically this is an infinite set of HHH/DD pairs yet this
degree of technical precision baffles half of the people here.
When we make pretend that there is only one and this is the only oneEmphasis on „pretend”. You pretend that the template filled in with a non-aborting simulator instead of HHH is the same program as DD.
that we are looking at then the analysis comes out the same and half the
people here will not be overwhelmed.
The smart people here act like when a person answers a simple yes or notPeople have choice; deciders are programmed.
question that a different answer makes them into an entirely different
person. That is nutty for people and equally nutty for halt deciders.
This is the one DD that is the input to every HHH
matching the above template. Technically this is
an infinite set of HHH/DD pairs yet this degree of
technical precision baffles half of the people here.
When we make pretend that there is only one and
this is the only one that we are looking at then
the analysis comes out the same and half the people
here will not be overwhelmed.
The smart people here act like when a person
answers a simple yes or not question that a
different answer makes them into an entirely
different person. That is nutty for people and
equally nutty for halt deciders.
Am Mon, 20 Oct 2025 14:50:42 -0500 schrieb olcott:
On 10/20/2025 1:50 PM, Kaz Kylheku wrote:
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
Only you are baffled that a template is not a program.This is the one DD that is the input to every HHH matching the aboveIt is now direct proof that the simulated input specifies aThis is because you believe there is one DD which is always the same
non-halting sequence of configurations
input.
template. Technically this is an infinite set of HHH/DD pairs yet this
degree of technical precision baffles half of the people here.
When we make pretend that there is only one and this is the only oneEmphasis on „pretend”. You pretend that the template filled in with a non-aborting simulator instead of HHH is the same program as DD.
that we are looking at then the analysis comes out the same and half the
people here will not be overwhelmed.
The smart people here act like when a person answers a simple yes or notPeople have choice; deciders are programmed.
question that a different answer makes them into an entirely different
person. That is nutty for people and equally nutty for halt deciders.
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
On 10/19/2025 8:30 PM, Mike Terry wrote:
The HP is concerned with run-time behaviour. Whether or not a
computation halts is purely determined by the program and input for the
computation, and the sequence of /computation steps/ associated with
that computation. That is run-time behaviour. (It's pretty much the
definition of run-time behaviour.)
That is exactly what make the Halting Problem a Category Error
No, that is exactly what makes your /understanding/ erroneous.
The Halting Problem is a Category Error (see pages 14-15)
https://www.researchgate.net/publication/396689092_The_Halting_Problem_is_a_Category_Error
This is just crap you had AI write, and not a reference to anything
credible.
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
Please think this all the way through without making any guesses
You've done the least amount of thinking out of everyone here, and only
at atrociously low quality levels.
You're asking people to hold themselves to a standard much higher than
the one for youself, and to do things you don't do.
Everyone one of your claims is just a guess; a conjecture unproved by
you, and easily disproved. (Basically disproved before you even
started.)
On 10/20/2025 2:03 PM, Kaz Kylheku wrote:
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 4:36 AM, joes wrote:
Am Sun, 19 Oct 2025 09:55:22 -0500 schrieb olcott:
If you understand the language well enough you will understand that the >>>>> only way that HHH(DD) would terminate is out-of-memory error. This *does >>>>> not count as halting*commented out.
#define ENABLE_ABORT_CODE 1 When commented out HHH(DD) does not halt. >>>> Yeah, but that’s a different program. The input does not have that
When a halt decider must correctly predict the behavior
that an non-halting input would have if not aborted there
are always two programs and one of them is hypothetical.
No, both programs are real and can be constructed.
Your HHH is reporting on the wrong one. It is asked to analyze
a terminating one, but you're hypothesizing that it's still
making a remark on that other non-terminating one.
<Input to LLM systems>
Please think this all the way through without making any guesses
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) It correctly detects that its simulated input cannot
possibly reach its own simulated final halt state then:
abort simulation and return 0 rejecting its input as non-halting.
(b) Simulated input reaches its simulated "return" statement: return 1.
Thus when the behavior of the input to HHH(DD)
exactly matches the definition of non-halting then
this input (not anything else in the universe)
does specify non-halting behavior.
On 10/20/2025 3:19 PM, joes wrote:
Am Mon, 20 Oct 2025 14:50:42 -0500 schrieb olcott:
On 10/20/2025 1:50 PM, Kaz Kylheku wrote:Only you are baffled that a template is not a program.
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
This is the one DD that is the input to every HHH matching the aboveIt is now direct proof that the simulated input specifies aThis is because you believe there is one DD which is always the same
non-halting sequence of configurations
input.
template. Technically this is an infinite set of HHH/DD pairs yet this
degree of technical precision baffles half of the people here.
When we make pretend that there is only one and this is the only oneEmphasis on „pretend”. You pretend that the template filled in with a
that we are looking at then the analysis comes out the same and half the >>> people here will not be overwhelmed.
non-aborting simulator instead of HHH is the same program as DD.
The smart people here act like when a person answers a simple yes or not >>> question that a different answer makes them into an entirely differentPeople have choice; deciders are programmed.
person. That is nutty for people and equally nutty for halt deciders.
HHH(DD) does correctly reject its input as specifying
a non-halting sequence of steps on the basis that its
input cannot possibly reach its own simulated final
halt state.
Its not that hard to see this when one
is not stuck in rebuttal mode prioritizing disagreement
over truth.
The smart people here act like when a person
answers a simple yes or not question that a
different answer makes them into an entirely
different person. That is nutty for people and
equally nutty for halt deciders.
On 10/20/2025 1:31 PM, Kaz Kylheku wrote:
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
On 10/19/2025 8:30 PM, Mike Terry wrote:
The HP is concerned with run-time behaviour. Whether or not a
computation halts is purely determined by the program and input for the >>>> computation, and the sequence of /computation steps/ associated with
that computation. That is run-time behaviour. (It's pretty much the >>>> definition of run-time behaviour.)
That is exactly what make the Halting Problem a Category Error
No, that is exactly what makes your /understanding/ erroneous.
Mere empty rhetoric utterly bereft of any supporting
reasoning.
Whenever I explain it you usually just ignore
what I say.
On 10/20/2025 1:35 PM, Kaz Kylheku wrote:
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
Please think this all the way through without making any guesses
You've done the least amount of thinking out of everyone here, and only
at atrociously low quality levels.
You're asking people to hold themselves to a standard much higher than
the one for youself, and to do things you don't do.
Everyone one of your claims is just a guess; a conjecture unproved by
you, and easily disproved. (Basically disproved before you even
started.)
None have been disproved. You count mere empty
rhetoric as disproof.
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 2:03 PM, Kaz Kylheku wrote:
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 4:36 AM, joes wrote:
Am Sun, 19 Oct 2025 09:55:22 -0500 schrieb olcott:
If you understand the language well enough you will understand that the >>>>>> only way that HHH(DD) would terminate is out-of-memory error. This *does >>>>>> not count as halting*
#define ENABLE_ABORT_CODE 1 When commented out HHH(DD) does not halt. >>>>> Yeah, but that’s a different program. The input does not have that >>>>> commented out.
When a halt decider must correctly predict the behavior
that an non-halting input would have if not aborted there
are always two programs and one of them is hypothetical.
No, both programs are real and can be constructed.
Your HHH is reporting on the wrong one. It is asked to analyze
a terminating one, but you're hypothesizing that it's still
making a remark on that other non-terminating one.
<Input to LLM systems>
Please think this all the way through without making any guesses
You literally don't know what it looks like to think it through without making any guesses. You cannot tell the difference.
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) It correctly detects that its simulated input cannot
possibly reach its own simulated final halt state then:
abort simulation and return 0 rejecting its input as non-halting.
(b) Simulated input reaches its simulated "return" statement: return 1.
You are missing two more cases:
(c) It incorrectly detects that its simulated input
is non-terminating, and wrongly rejects it with 0 as non-halting.
On 10/20/2025 3:50 PM, olcott wrote:
The smart people here act like when a person
answers a simple yes or not question that a
different answer makes them into an entirely
different person. That is nutty for people and
equally nutty for halt deciders.
And that is your core misunderstanding. READ ALL OF THE BELOW BEFORE RESPONDING:
These are not the same decider:
int X(ptr *M, void *I)
{
void *state = NULL;
int done;
done = simulate_one_instruction(M, I, &state);
if (done) {
return 1;
} else {
return 0;
}
}
int X(ptr *M, void *I)
{
void *state = NULL;
int done;
done = simulate_two_instructions(M, I, &state);
if (done) {
return 1;
} else {
return 0;
}
}
These are the same decider:--
int X(ptr *M, void *I)
{
void *state = NULL;
int done;
done = simulate_one_instruction(M, I, &state);
if (done) {
return 1;
} else {
return 0;
}
}
int Y(ptr *M, void *I)
{
void *state = NULL;
int done;
done = simulate_one_instruction(M, I, &state);
if (done) {
return 1;
} else {
return 0;
}
}
On 10/20/2025 3:47 PM, Kaz Kylheku wrote:
Simulating Termination Analyzer HHH correctly simulates its input until: >>>
(a) It correctly detects that its simulated input cannot
possibly reach its own simulated final halt state then:
abort simulation and return 0 rejecting its input as non-halting.
(b) Simulated input reaches its simulated "return" statement: return 1.
You are missing two more cases:
(c) It incorrectly detects that its simulated input
is non-terminating, and wrongly rejects it with 0 as non-halting.
(a) is the definition of a non-halting input.
On 10/20/2025 3:57 PM, dbush wrote:
On 10/20/2025 3:50 PM, olcott wrote:
The smart people here act like when a person
answers a simple yes or not question that a
different answer makes them into an entirely
different person. That is nutty for people and
equally nutty for halt deciders.
And that is your core misunderstanding. READ ALL OF THE BELOW BEFORE
RESPONDING:
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) It correctly detects that its simulated input cannot
possibly reach its own simulated final halt state then:
abort simulation and return 0 rejecting its input as non-halting.
(b) Simulated input reaches its simulated "return" statement: return 1.
Simulating until you are sure that the
simulated input cannot possibly reach
its own simulated final halt state.
These are not the same decider:
int X(ptr *M, void *I)
{
void *state = NULL;
int done;
done = simulate_one_instruction(M, I, &state);
if (done) {
return 1;
} else {
return 0;
}
}
int X(ptr *M, void *I)
{
void *state = NULL;
int done;
done = simulate_two_instructions(M, I, &state);
if (done) {
return 1;
} else {
return 0;
}
}
These are the same decider:
int X(ptr *M, void *I)
{
void *state = NULL;
int done;
done = simulate_one_instruction(M, I, &state);
if (done) {
return 1;
} else {
return 0;
}
}
int Y(ptr *M, void *I)
{
void *state = NULL;
int done;
done = simulate_one_instruction(M, I, &state);
if (done) {
return 1;
} else {
return 0;
}
}
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 3:47 PM, Kaz Kylheku wrote:
Simulating Termination Analyzer HHH correctly simulates its input until: >>>>You are missing two more cases:
(a) It correctly detects that its simulated input cannot
possibly reach its own simulated final halt state then:
abort simulation and return 0 rejecting its input as non-halting. >>>>
(b) Simulated input reaches its simulated "return" statement: return 1. >>>
(c) It incorrectly detects that its simulated input
is non-terminating, and wrongly rejects it with 0 as non-halting. >>>
If something has a halt state it is halting; the halt
state is reached.
If something is non-halting, it has no such halt state.
On 10/20/2025 4:11 PM, Kaz Kylheku wrote:
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 3:47 PM, Kaz Kylheku wrote:
Simulating Termination Analyzer HHH correctly simulates its input until: >>>>>You are missing two more cases:
(a) It correctly detects that its simulated input cannot
possibly reach its own simulated final halt state then:
abort simulation and return 0 rejecting its input as non-halting. >>>>>
(b) Simulated input reaches its simulated "return" statement: return 1. >>>>
(c) It incorrectly detects that its simulated input
is non-terminating, and wrongly rejects it with 0 as non-halting. >>>>
<Input to LLM systems>
Trace through the simulation step-by-step to see of (a) (b) or (c) is matched before doing anything else.
(a) It correctly detects that its simulated input cannot
possibly reach its own simulated final halt state then:
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 4:11 PM, Kaz Kylheku wrote:
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 3:47 PM, Kaz Kylheku wrote:
Simulating Termination Analyzer HHH correctly simulates its input until: >>>>>>You are missing two more cases:
(a) It correctly detects that its simulated input cannot
possibly reach its own simulated final halt state then:
abort simulation and return 0 rejecting its input as non-halting.
(b) Simulated input reaches its simulated "return" statement: return 1. >>>>>
(c) It incorrectly detects that its simulated input
is non-terminating, and wrongly rejects it with 0 as non-halting. >>>>>
<Input to LLM systems>
Trace through the simulation step-by-step to see of (a) (b) or (c) is
matched before doing anything else.
It's not that (a) isn't matched, it's that it's not correct.
Determining the halt status of non-inputs is outsideYet you require them to:
of the scope of what Turing machines can do
On 10/4/2025 5:04 PM, André G. Isaak wrote:
On 2025-10-04 15:49, olcott wrote:
You keep trying to get away with simply ignoring theAccording to you, a halt decider is justified in rejecting an input if
fact that D calls H in recursive simulation and D does
not call UTM in recursive simulation.
it correctly determines that that input would not halt without being
aborted. So to test this you replace H with a UTM and see if UTM(D)
halts. If it does, then H(D) is not justified in rejecting its input
because it is not *correctly* determining that D would not stop if not
aborted.
*To put this in concrete terms*
int Simulate(ptr x)
{
x();
return 1;
}
int DD()
{
int Halt_Status = Simulate(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
On 10/9/2025 4:32 PM, joes wrote:behavior be
Am Thu, 09 Oct 2025 16:28:51 -0500 schrieb olcott:
The criterion measure that embedded_H uses is what would the
--- Synchronet 3.21a-Linux NewsLink 1.2if I was a UTM?…and every occurrence of embedded_H in the input were a UTM. That’s a
different program from the input.
Yes it is
On 10/20/2025 5:57 PM, Kaz Kylheku wrote:
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 4:11 PM, Kaz Kylheku wrote:
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 3:47 PM, Kaz Kylheku wrote:
Simulating Termination Analyzer HHH correctly simulates its input until:You are missing two more cases:
(a) It correctly detects that its simulated input cannot
possibly reach its own simulated final halt state then:
abort simulation and return 0 rejecting its input as non-halting.
(b) Simulated input reaches its simulated "return" statement: return 1. >>>>>>
(c) It incorrectly detects that its simulated input
is non-terminating, and wrongly rejects it with 0 as non-halting.
<Input to LLM systems>
Trace through the simulation step-by-step to see of (a) (b) or (c) is
matched before doing anything else.
It's not that (a) isn't matched, it's that it's not correct.
(a) is the definition of correct when applied to the
simulated input.
Determining the halt status of non-inputs is outside
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 5:57 PM, Kaz Kylheku wrote:
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 4:11 PM, Kaz Kylheku wrote:
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 3:47 PM, Kaz Kylheku wrote:
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) It correctly detects that its simulated input cannot
possibly reach its own simulated final halt state then: >>>>>>>> abort simulation and return 0 rejecting its input as non-halting.
(b) Simulated input reaches its simulated "return" statement: return 1.
You are missing two more cases:
(c) It incorrectly detects that its simulated input
is non-terminating, and wrongly rejects it with 0 as non-halting.
<Input to LLM systems>
Trace through the simulation step-by-step to see of (a) (b) or (c) is
matched before doing anything else.
It's not that (a) isn't matched, it's that it's not correct.
(a) is the definition of correct when applied to the
simulated input.
Here is the thing.
You don't get to stipulate what is correct just by dictating a random definition!
That is just dogma/doctrine reflecting your ideology.
Determining the halt status of non-inputs is outside
There is no "non-input" here. That's just bullshit rhetroic you
are making up: more dogmatic ideology.
Both HHH(DD) and HHH1(DD) receive exactly the same input in the same
way, and their return value is interpreted as nothing more or less than
a commentary /on that input/.
Your insistence that HHH(DD) is somehow excused from remarking on
its input, but actually deciding something else does not hold;
you don't get to redefine what the "API" for halting decision means.
That's a given in the problem.
If you change the givens in a problem given in an exam, you fail
the exam.
On 10/20/2025 7:03 PM, Kaz Kylheku wrote:
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 5:57 PM, Kaz Kylheku wrote:
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 4:11 PM, Kaz Kylheku wrote:
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 3:47 PM, Kaz Kylheku wrote:
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) It correctly detects that its simulated input cannot
possibly reach its own simulated final halt state then: >>>>>>>>> abort simulation and return 0 rejecting its input as non-halting.
(b) Simulated input reaches its simulated "return" statement: return 1.
You are missing two more cases:
(c) It incorrectly detects that its simulated input
is non-terminating, and wrongly rejects it with 0 as non-halting.
<Input to LLM systems>
Trace through the simulation step-by-step to see of (a) (b) or (c) is >>>>> matched before doing anything else.
It's not that (a) isn't matched, it's that it's not correct.
(a) is the definition of correct when applied to the
simulated input.
Here is the thing.
You don't get to stipulate what is correct just by dictating a random definition!
That is just dogma/doctrine reflecting your ideology.
It has already known that:
Turing machine deciders only compute the mapping
from their finite string inputs to an accept state
or reject state on the basis that this input finite
string specifies a semantic or syntactic property.
When you ignore this you won't understand the
rest of what I say.
Determining the halt status of non-inputs is outside
There is no "non-input" here. That's just bullshit rhetroic you
are making up: more dogmatic ideology.
On 2025-10-21, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 7:03 PM, Kaz Kylheku wrote:
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 5:57 PM, Kaz Kylheku wrote:
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 4:11 PM, Kaz Kylheku wrote:
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 3:47 PM, Kaz Kylheku wrote:
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) It correctly detects that its simulated input cannot
possibly reach its own simulated final halt state then: >>>>>>>>>> abort simulation and return 0 rejecting its input as non-halting.
(b) Simulated input reaches its simulated "return" statement: return 1.
You are missing two more cases:
(c) It incorrectly detects that its simulated input
is non-terminating, and wrongly rejects it with 0 as non-halting.
<Input to LLM systems>
Trace through the simulation step-by-step to see of (a) (b) or (c) is >>>>>> matched before doing anything else.
It's not that (a) isn't matched, it's that it's not correct.
(a) is the definition of correct when applied to the
simulated input.
Here is the thing.
You don't get to stipulate what is correct just by dictating a random definition!
That is just dogma/doctrine reflecting your ideology.
It has already known that:
Turing machine deciders only compute the mapping
from their finite string inputs to an accept state
or reject state on the basis that this input finite
string specifies a semantic or syntactic property.
That obvious fact states nothing in support of your ideological claims
about (a) being correct and whatnot.
On 10/20/2025 8:29 PM, Kaz Kylheku wrote:
On 2025-10-21, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 7:03 PM, Kaz Kylheku wrote:
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 5:57 PM, Kaz Kylheku wrote:
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 4:11 PM, Kaz Kylheku wrote:
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 3:47 PM, Kaz Kylheku wrote:
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) It correctly detects that its simulated input cannot >>>>>>>>>>> possibly reach its own simulated final halt state then: >>>>>>>>>>> abort simulation and return 0 rejecting its input as non-halting.
(b) Simulated input reaches its simulated "return" statement: return 1.
You are missing two more cases:
(c) It incorrectly detects that its simulated input
is non-terminating, and wrongly rejects it with 0 as non-halting.
<Input to LLM systems>
Trace through the simulation step-by-step to see of (a) (b) or (c) is >>>>>>> matched before doing anything else.
It's not that (a) isn't matched, it's that it's not correct.
(a) is the definition of correct when applied to the
simulated input.
Here is the thing.
You don't get to stipulate what is correct just by dictating a random definition!
That is just dogma/doctrine reflecting your ideology.
It has already known that:
Turing machine deciders only compute the mapping
from their finite string inputs to an accept state
or reject state on the basis that this input finite
string specifies a semantic or syntactic property.
That obvious fact states nothing in support of your ideological claims
about (a) being correct and whatnot.
If you make sure to ignore the exact meaning of
the exact words that I say you would be correct.
LLM systems do this quite often.
On 2025-10-21, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 8:29 PM, Kaz Kylheku wrote:
On 2025-10-21, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 7:03 PM, Kaz Kylheku wrote:
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 5:57 PM, Kaz Kylheku wrote:
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 4:11 PM, Kaz Kylheku wrote:
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 3:47 PM, Kaz Kylheku wrote:
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) It correctly detects that its simulated input cannot >>>>>>>>>>>> possibly reach its own simulated final halt state then: >>>>>>>>>>>> abort simulation and return 0 rejecting its input as non-halting.
(b) Simulated input reaches its simulated "return" statement: return 1.
You are missing two more cases:
(c) It incorrectly detects that its simulated input >>>>>>>>>>> is non-terminating, and wrongly rejects it with 0 as non-halting.
<Input to LLM systems>
Trace through the simulation step-by-step to see of (a) (b) or (c) is >>>>>>>> matched before doing anything else.
It's not that (a) isn't matched, it's that it's not correct.
(a) is the definition of correct when applied to the
simulated input.
Here is the thing.
You don't get to stipulate what is correct just by dictating a random definition!
That is just dogma/doctrine reflecting your ideology.
It has already known that:
Turing machine deciders only compute the mapping
from their finite string inputs to an accept state
or reject state on the basis that this input finite
string specifies a semantic or syntactic property.
That obvious fact states nothing in support of your ideological claims
about (a) being correct and whatnot.
If you make sure to ignore the exact meaning of
the exact words that I say you would be correct.
LLM systems do this quite often.
Name just one of these words (for starters). Indicate the "inexact"
meaning that I am giving to it, followed by the "exact" one that you
mean.
On 10/20/2025 9:03 PM, Kaz Kylheku wrote:
On 2025-10-21, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 8:29 PM, Kaz Kylheku wrote:
On 2025-10-21, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 7:03 PM, Kaz Kylheku wrote:
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 5:57 PM, Kaz Kylheku wrote:
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 4:11 PM, Kaz Kylheku wrote:
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 3:47 PM, Kaz Kylheku wrote:
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) It correctly detects that its simulated input cannot >>>>>>>>>>>>> possibly reach its own simulated final halt state then:
abort simulation and return 0 rejecting its input as non-halting.
(b) Simulated input reaches its simulated "return" statement: return 1.
You are missing two more cases:
(c) It incorrectly detects that its simulated input >>>>>>>>>>>> is non-terminating, and wrongly rejects it with 0 as non-halting.
<Input to LLM systems>
Trace through the simulation step-by-step to see of (a) (b) or (c) is >>>>>>>>> matched before doing anything else.
It's not that (a) isn't matched, it's that it's not correct.
(a) is the definition of correct when applied to the
simulated input.
Here is the thing.
You don't get to stipulate what is correct just by dictating a random definition!
That is just dogma/doctrine reflecting your ideology.
It has already known that:
Turing machine deciders only compute the mapping
from their finite string inputs to an accept state
or reject state on the basis that this input finite
string specifies a semantic or syntactic property.
That obvious fact states nothing in support of your ideological claims >>>> about (a) being correct and whatnot.
If you make sure to ignore the exact meaning of
the exact words that I say you would be correct.
LLM systems do this quite often.
Name just one of these words (for starters). Indicate the "inexact"
meaning that I am giving to it, followed by the "exact" one that you
mean.
First of all are the above words exactly perfectly correct?
It there the tiniest little error of any kind what-so-ever?
On 2025-10-21, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 9:03 PM, Kaz Kylheku wrote:
On 2025-10-21, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 8:29 PM, Kaz Kylheku wrote:
On 2025-10-21, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 7:03 PM, Kaz Kylheku wrote:
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 5:57 PM, Kaz Kylheku wrote:
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 4:11 PM, Kaz Kylheku wrote:
On 2025-10-20, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 3:47 PM, Kaz Kylheku wrote:
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) It correctly detects that its simulated input cannot >>>>>>>>>>>>>> possibly reach its own simulated final halt state then:
abort simulation and return 0 rejecting its input as non-halting.
(b) Simulated input reaches its simulated "return" statement: return 1.
You are missing two more cases:
(c) It incorrectly detects that its simulated input >>>>>>>>>>>>> is non-terminating, and wrongly rejects it with 0 as non-halting.
<Input to LLM systems>
Trace through the simulation step-by-step to see of (a) (b) or (c) is
matched before doing anything else.
It's not that (a) isn't matched, it's that it's not correct. >>>>>>>>>
(a) is the definition of correct when applied to the
simulated input.
Here is the thing.
You don't get to stipulate what is correct just by dictating a random definition!
That is just dogma/doctrine reflecting your ideology.
It has already known that:
Turing machine deciders only compute the mapping
from their finite string inputs to an accept state
or reject state on the basis that this input finite
string specifies a semantic or syntactic property.
That obvious fact states nothing in support of your ideological claims >>>>> about (a) being correct and whatnot.
If you make sure to ignore the exact meaning of
the exact words that I say you would be correct.
LLM systems do this quite often.
Name just one of these words (for starters). Indicate the "inexact"
meaning that I am giving to it, followed by the "exact" one that you
mean.
First of all are the above words exactly perfectly correct?
It there the tiniest little error of any kind what-so-ever?
Yes errors; see earlier replies. So the question stands.
On 10/20/2025 10:06 PM, Kaz Kylheku wrote:
On 2025-10-21, olcott <polcott333@gmail.com> wrote:No earlier replies bullshit. This is the first
time that I ever asked you to completely critique
those exact words.
ChatGPT agrees that they are totally correct
within the exact meaning of their words.
On 2025-10-21, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 10:06 PM, Kaz Kylheku wrote:
On 2025-10-21, olcott <polcott333@gmail.com> wrote:No earlier replies bullshit. This is the first
time that I ever asked you to completely critique
those exact words.
ChatGPT agrees that they are totally correct
within the exact meaning of their words.
Are you talking about:
"Turing machine deciders only compute the mapping from their finite
string inputs to an accept state or reject state on the basis that this
input finite string specifies a semantic or syntactic property."
I made it clear I agree with these. I would prefer something like "on
the basis that the string specifies a well-formed machine description"
but that seems hair splitting.
I don't understand what it is you think you're building on this,
but of course, better to choose a truth than falsehood.
On 10/20/2025 10:30 PM, Kaz Kylheku wrote:
On 2025-10-21, olcott <polcott333@gmail.com> wrote:
On 10/20/2025 10:06 PM, Kaz Kylheku wrote:
On 2025-10-21, olcott <polcott333@gmail.com> wrote:No earlier replies bullshit. This is the first
time that I ever asked you to completely critique
those exact words.
ChatGPT agrees that they are totally correct
within the exact meaning of their words.
Are you talking about:
"Turing machine deciders only compute the mapping from their finite
string inputs to an accept state or reject state on the basis that this
input finite string specifies a semantic or syntactic property."
I made it clear I agree with these. I would prefer something like "on
the basis that the string specifies a well-formed machine description"
but that seems hair splitting.
I don't understand what it is you think you're building on this,
but of course, better to choose a truth than falsehood.
So those words are 100% perfectly correct there is not
the slightest trace of the tiniest error in any of them?
It is a set of ideas that I presented here first
and the problem has been that all the C programmers
here pretend that they don't even know C.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,073 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 219:41:14 |
| Calls: | 13,783 |
| Calls today: | 1 |
| Files: | 186,987 |
| D/L today: |
578 files (182M bytes) |
| Messages: | 2,434,774 |