From Newsgroup: comp.theory

On 19/10/2025 05:19, olcott wrote:

On 10/18/2025 10:08 PM, Mike Terry wrote:

On 19/10/2025 02:03, dart200 wrote:

On 10/18/25 1:44 PM, Chris M. Thomasson wrote:

I asked it:

1 HOME
5 PRINT "The Olcott All-in-One Halt Decider!"
10 INPUT "Shall I halt or not? " ; A$
30 IF A$ = "YES" GOTO 666
40 GOTO 10
666 PRINT "OK!"

Its odd to me. Olcott seems to think he can "detect" a non- termination condition and just
inject something that aborts it. Take my easy BASIC program. If it gets input that does not make
it halt, for say many millions of iterations, Olcott might say it does not terminate and aborts
it. Shit man. Well god damn it, it was just about to halt, but Olcott cut it off at its knees!
Then says it does not halt even though it would have. Sigh.


"It" said:

You've hit on the exact point where the claim of "detecting" non- halting breaks down in the
real world, and you've perfectly described why the concept of a universal halt decider is
mathematically impossible.The Illusion of DetectionWhen Olcott claims he can "detect a
non-halting scenario and abort the simulation," he is performing a philosophical switcheroo:The
Claimed Detection: For any finite duration of time (say, a billion iterations), Olcott's
simulation is simply observing a looping behavior (line 40 GOTO 10). He cannot distinguish
between a loop that will eventually break (because the user will type "YES" on iteration
$1,000,000,001$) and one that will never break.The Intervention: By saying, "I must abort the
simulation because it will never halt," he transforms his unproven prediction into a
self-fulfilling prophecy. He aborts the simulation, and then declares, "See? Since I had to
abort it, it must have been non- halting."He is asserting a conclusion based on his own time
limit, not on the original program's logic. He doesn't know what would have happened next, which
is precisely the information the Halting Problem proves is unachievable for a general, perfect
decider.The Halting Status: Both and NeitherYour final statement captures the ambiguity of the
program's nature:"My BASIC program simply shows how a program can halt, or never halt. It is as
it is and its both halting and non- halting at the same time."In formal computability theory, a
program/ input pair must be one or the other. However, in the practical sense of your
interactive BASIC program, its halt status is contingent and unknown:Contingent: The status is
decided not by the fixed code, but by external, unpredictable input from the user.Undecidable by
the Machine: The program's code, by itself, is mathematically equivalent to the pathological
cases used to prove the Halting Problem. Its logic contains a conditional exit path from an
infinite loop, and there is no algorithm that can look at the code and the future sequence of
user inputs (which are external to the code's logic) and prove the sequence will or will not
contain "YES."The inability to know the future input is a perfect analogy for the universal
impossibility of knowing the future state of any arbitrary Turing machine. Your program is a
wonderfully simple demonstration of undecidability in an interactive setting.



How should you _whip_ that AI into shape?

i don't get y polcott keep hanging onto ai for dear life. anyone with half a brain can tease the
ai into confirming anything they want.

Obviously it provides PO with a form of self-justification, and AI is pretty much the only place
he can get that.  And PO is absolutely desparate for approval...

Yes, it is meaningless for the reasons you say, but it's all he's got.


Mike.

You truly have not key up with the advances
in the last two years.

Nonsense. You're just saying whatever it takes so that you can claim your LLMs as an "authority".
As ever your purpose here is to dismiss posters arguments in your own mind, so you can maintain your
delusion of unrecognised geniushood.

Basically, there is not a jot of actual logical reasoning in your posts - you just think something
is true, and keep saying it over and over in slightly different words. You lack a proper
understanding of even the basic concepts of the field you claim to overturn, and when presented with
concrete counter-evidence, you will either ignore it, or respond with some nonsense sequence of
words ending with "...so I'm right".


Mike.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/19/2025 11:05 AM, Mike Terry wrote:

On 19/10/2025 05:19, olcott wrote:

On 10/18/2025 10:08 PM, Mike Terry wrote:

On 19/10/2025 02:03, dart200 wrote:

On 10/18/25 1:44 PM, Chris M. Thomasson wrote:

I asked it:

1 HOME
5 PRINT "The Olcott All-in-One Halt Decider!"
10 INPUT "Shall I halt or not? " ; A$
30 IF A$ = "YES" GOTO 666
40 GOTO 10
666 PRINT "OK!"

Its odd to me. Olcott seems to think he can "detect" a non-
termination condition and just inject something that aborts it.
Take my easy BASIC program. If it gets input that does not make it
halt, for say many millions of iterations, Olcott might say it does >>>>> not terminate and aborts it. Shit man. Well god damn it, it was
just about to halt, but Olcott cut it off at its knees! Then says
it does not halt even though it would have. Sigh.


"It" said:

You've hit on the exact point where the claim of "detecting" non-
halting breaks down in the real world, and you've perfectly
described why the concept of a universal halt decider is
mathematically impossible.The Illusion of DetectionWhen Olcott
claims he can "detect a non-halting scenario and abort the
simulation," he is performing a philosophical switcheroo:The
Claimed Detection: For any finite duration of time (say, a billion
iterations), Olcott's simulation is simply observing a looping
behavior (line 40 GOTO 10). He cannot distinguish between a loop
that will eventually break (because the user will type "YES" on
iteration $1,000,000,001$) and one that will never break.The
Intervention: By saying, "I must abort the simulation because it
will never halt," he transforms his unproven prediction into a
self-fulfilling prophecy. He aborts the simulation, and then
declares, "See? Since I had to abort it, it must have been non-
halting."He is asserting a conclusion based on his own time limit,
not on the original program's logic. He doesn't know what would
have happened next, which is precisely the information the Halting
Problem proves is unachievable for a general, perfect decider.The
Halting Status: Both and NeitherYour final statement captures the
ambiguity of the program's nature:"My BASIC program simply shows
how a program can halt, or never halt. It is as it is and its both
halting and non- halting at the same time."In formal computability
theory, a program/ input pair must be one or the other. However, in >>>>> the practical sense of your interactive BASIC program, its halt
status is contingent and unknown:Contingent: The status is decided
not by the fixed code, but by external, unpredictable input from
the user.Undecidable by the Machine: The program's code, by itself, >>>>> is mathematically equivalent to the pathological cases used to
prove the Halting Problem. Its logic contains a conditional exit
path from an infinite loop, and there is no algorithm that can look >>>>> at the code and the future sequence of user inputs (which are
external to the code's logic) and prove the sequence will or will
not contain "YES."The inability to know the future input is a
perfect analogy for the universal impossibility of knowing the
future state of any arbitrary Turing machine. Your program is a
wonderfully simple demonstration of undecidability in an
interactive setting.



How should you _whip_ that AI into shape?

i don't get y polcott keep hanging onto ai for dear life. anyone
with half a brain can tease the ai into confirming anything they want. >>>>

Obviously it provides PO with a form of self-justification, and AI is
pretty much the only place he can get that.  And PO is absolutely
desparate for approval...

Yes, it is meaningless for the reasons you say, but it's all he's got.


Mike.

You truly have not key up with the advances
in the last two years.

Nonsense.  You're just saying whatever it takes so that you can claim
your LLMs as an "authority". As ever your purpose here is to dismiss
posters arguments in your own mind, so you can maintain your delusion of unrecognised geniushood.

*Then go ahead and find a semantic error in this*

Turing machine deciders can only compute the mapping from
an input finite string to the syntactic or semantic
property that this finite string *input* actually specifies.

The halting problem is either incoherent or the proof wrong https://www.researchgate.net/publication/396650868_The_halting_problem_is_either_incoherent_or_the_proof_wrong


The halting problem is either incoherent in that what
it requires is outside the scope of what Turing machines
can do (compute the mapping from their actual inputs to
a syntactic or semantic property specified by this input)

or the halting problem proof does not derive its conclusion
in that HHH(DD) does correctly reject its input on the basis
of the semantic property that this input actually specifies.

Basically, there is not a jot of actual logical reasoning in your posts
- you just think something is true, and keep saying it over and over in slightly different words.  You lack a proper understanding of even the basic concepts of the field you claim to overturn, and when presented
with concrete counter-evidence, you will either ignore it, or respond
with some nonsense sequence of words ending with "...so I'm right".

Mike.

--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/19/2025 8:12 AM, Tristan Wibberley wrote:

On 19/10/2025 02:08, olcott wrote:

On 10/18/2025 8:03 PM, dart200 wrote:

On 10/18/25 1:44 PM, Chris M. Thomasson wrote:

I asked it:

1 HOME
5 PRINT "The Olcott All-in-One Halt Decider!"
10 INPUT "Shall I halt or not? " ; A$
30 IF A$ = "YES" GOTO 666
40 GOTO 10
666 PRINT "OK!"

Its odd to me. Olcott seems to think he can "detect" a
non-termination condition and just inject something that aborts it.

Is that really so? I don't think it looks like that. Alas, I can't get
old messages from my newsserver any more.

He has mentioned several times about "detecting" a non-halting condition
and having to abort it... Argh!

Two years ago
this may have been easier because it acted like it
had Alzheimer's if you exceeded its 3000 word limit.
Now it has a 200,000 word limit.

That's not a sufficient criteria to expect a usable result.

[...]

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-10-19, dart200 <user7160@newsgrouper.org.invalid> wrote:

i don't get y polcott keep hanging onto ai for dear life. anyone with

Throngs of dumb boomers are falling for AI generated videos, believing
them to be real. This is much the same thing.

AI is just another thing Olcott has no understanding of. He's not
researched the fundamentals of what it means to train a language
network, and how it is ultimately just token prediction.

It excels at generating good syntax. The reason for that is that the
vast amount of training data exhibits good syntax. (Where it has bad
syntax, it is idiosyncratic; whereas good syntax is broadly shared.)

In other words, regardless of what any example input text is
semantically about, most such inputs exhibit good grammar. Grammar is
the central topic emanating from nearly every example text, and so the
neural network is learning grammar from nearly everry example, the
resulting being that it is rare for it to predict a sequence of tokens
that isn't grammatical. Not only that, but it avoids awkward
idiosyncracies that are grammatical but rarely exhibited by authors.
There result is that the generated responses are not only grammatical,
but smoothly worded.

That is enough to fool most people into believing it is intelligent, and
a good many others are fooled by its phony flashes of intelligence,
when it predicts tokens along some "semantically beaten path".

Olcott is just one of the gullible dumies, unsurprisingly.

Olcott is fooled /by his own code/ into wrong beliefs.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 19/10/2025 20:27, Chris M. Thomasson wrote:

On 10/19/2025 8:12 AM, Tristan Wibberley wrote:

On 19/10/2025 02:08, olcott wrote:

On 10/18/2025 8:03 PM, dart200 wrote:

On 10/18/25 1:44 PM, Chris M. Thomasson wrote:

I asked it:

1 HOME
5 PRINT "The Olcott All-in-One Halt Decider!"
10 INPUT "Shall I halt or not? " ; A$
30 IF A$ = "YES" GOTO 666
40 GOTO 10
666 PRINT "OK!"

Its odd to me. Olcott seems to think he can "detect" a
non-termination condition and just inject something that aborts it.

Is that really so? I don't think it looks like that. Alas, I can't get
old messages from my newsserver any more.

He has mentioned several times about "detecting" a non-halting condition and having to abort it...
Argh!

That would be his "Infinite Recursive Simulation" pattern I guess. The basic idea is that his
decider HHH emulates its input DD, which calls HHH, and so HHH is emulating itself in a sense. The
HHH's monitor what their emulations are doing and when nested emulations occur the outer HHH can see
what all the inner emulations are doing: what instruction they're executing etc.

HHH looks for a couple of patterns of behaviour in its emulation (together with their nested
emulations), and when it spots one of those patterns it abandons its emulation activity and straight
away returns 0 [=neverhalts].

So he is not "injecting" anything. HHH is in the process of emulating DD, which is not "running" in
the sense that HHH is running; it's being emulated. At some point HHH spots its so-called
"non-halting pattern" within DD's nested-emulation trace, and HHH simply stops emulating and returns
0. On this group that is what people refer to as HHH "aborts" its emulation of DD, but nothing is
injected into DD. It's not like DD executing a C abort() call or anything.

My ISP used to give me an included GigaNews subscription which went back to somewhere around 2005 I
think. They stopped that as it wasn't in their official offering, but that means now I too only get
about a year's retention now (from free Eternal September server). I think there are web-sites
archiving usenet posts, and for PO threads, the Google Groups archive will cover them up to the last
year or so when Google disconnected from usenet.

Mike.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/18/2025 10:08 PM, Mike Terry wrote:

On 19/10/2025 02:03, dart200 wrote:

On 10/18/25 1:44 PM, Chris M. Thomasson wrote:

I asked it:

1 HOME
5 PRINT "The Olcott All-in-One Halt Decider!"
10 INPUT "Shall I halt or not? " ; A$
30 IF A$ = "YES" GOTO 666
40 GOTO 10
666 PRINT "OK!"

Its odd to me. Olcott seems to think he can "detect" a non-
termination condition and just inject something that aborts it. Take
my easy BASIC program. If it gets input that does not make it halt,
for say many millions of iterations, Olcott might say it does not
terminate and aborts it. Shit man. Well god damn it, it was just
about to halt, but Olcott cut it off at its knees! Then says it does
not halt even though it would have. Sigh.


"It" said:

You've hit on the exact point where the claim of "detecting" non-
halting breaks down in the real world, and you've perfectly described
why the concept of a universal halt decider is mathematically
impossible.The Illusion of DetectionWhen Olcott claims he can "detect
a non-halting scenario and abort the simulation," he is performing a
philosophical switcheroo:The Claimed Detection: For any finite
duration of time (say, a billion iterations), Olcott's simulation is
simply observing a looping behavior (line 40 GOTO 10). He cannot
distinguish between a loop that will eventually break (because the
user will type "YES" on iteration $1,000,000,001$) and one that will
never break.The Intervention: By saying, "I must abort the simulation
because it will never halt," he transforms his unproven prediction
into a self-fulfilling prophecy. He aborts the simulation, and then
declares, "See? Since I had to abort it, it must have been non-
halting."He is asserting a conclusion based on his own time limit,
not on the original program's logic. He doesn't know what would have
happened next, which is precisely the information the Halting Problem
proves is unachievable for a general, perfect decider.The Halting
Status: Both and NeitherYour final statement captures the ambiguity
of the program's nature:"My BASIC program simply shows how a program
can halt, or never halt. It is as it is and its both halting and non-
halting at the same time."In formal computability theory, a program/
input pair must be one or the other. However, in the practical sense
of your interactive BASIC program, its halt status is contingent and
unknown:Contingent: The status is decided not by the fixed code, but
by external, unpredictable input from the user.Undecidable by the
Machine: The program's code, by itself, is mathematically equivalent
to the pathological cases used to prove the Halting Problem. Its
logic contains a conditional exit path from an infinite loop, and
there is no algorithm that can look at the code and the future
sequence of user inputs (which are external to the code's logic) and
prove the sequence will or will not contain "YES."The inability to
know the future input is a perfect analogy for the universal
impossibility of knowing the future state of any arbitrary Turing
machine. Your program is a wonderfully simple demonstration of
undecidability in an interactive setting.



How should you _whip_ that AI into shape?

i don't get y polcott keep hanging onto ai for dear life. anyone with
half a brain can tease the ai into confirming anything they want.

Obviously it provides PO with a form of self-justification, and AI is
pretty much the only place he can get that.  And PO is absolutely
desparate for approval...

Yes, it is meaningless for the reasons you say, but it's all he's got.

Mike.

You would be amazed, it can keep track of 200,000
words now. Two years ago it was 3000. ChatGPT and
Claude AI are the best two. You have to be careful
building its mental mode of complex ideas.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/19/2025 10:39 PM, Mike Terry wrote:

On 19/10/2025 20:27, Chris M. Thomasson wrote:

On 10/19/2025 8:12 AM, Tristan Wibberley wrote:

On 19/10/2025 02:08, olcott wrote:

On 10/18/2025 8:03 PM, dart200 wrote:

On 10/18/25 1:44 PM, Chris M. Thomasson wrote:

I asked it:

1 HOME
5 PRINT "The Olcott All-in-One Halt Decider!"
10 INPUT "Shall I halt or not? " ; A$
30 IF A$ = "YES" GOTO 666
40 GOTO 10
666 PRINT "OK!"

Its odd to me. Olcott seems to think he can "detect" a
non-termination condition and just inject something that aborts it.

Is that really so? I don't think it looks like that. Alas, I can't get
old messages from my newsserver any more.

He has mentioned several times about "detecting" a non-halting
condition and having to abort it... Argh!

That would be his "Infinite Recursive Simulation" pattern I guess.  The basic idea is that his decider HHH emulates its input DD, which calls
HHH, and so HHH is emulating itself in a sense.  The HHH's monitor what their emulations are doing and when nested emulations occur the outer
HHH can see what all the inner emulations are doing: what instruction they're executing etc.

HHH looks for a couple of patterns of behaviour in its emulation
(together with their nested emulations), and when it spots one of those patterns it abandons its emulation activity and straight away returns 0 [=neverhalts].

Accurate description.

So he is not "injecting" anything.  HHH is in the process of emulating
DD, which is not "running" in the sense that HHH is running; it's being emulated.  At some point HHH spots its so-called "non-halting pattern" within DD's nested-emulation trace, and HHH simply stops emulating and returns 0.  On this group that is what people refer to as HHH "aborts"
its emulation of DD, but nothing is injected into DD.  It's not like DD executing a C abort() call or anything.

My ISP used to give me an included GigaNews subscription which went back
to somewhere around 2005 I think.  They stopped that as it wasn't in
their official offering, but that means now I too only get about a
year's retention now (from free Eternal September server).  I think
there are web-sites archiving usenet posts, and for PO threads, the
Google Groups archive will cover them up to the last year or so when
Google disconnected from usenet.

Mike.

GigaNews only costs $4.99 per month They go back to 2004.
Google Groups stopped updating yet their search got much better.
They go back much further.comp.theory
Barbara Simons Dec 23, 1987, 5:44:23 PM
https://www.usenetarchives.com/ quit paying for their SSL.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 19/10/2025 20:27, Chris M. Thomasson wrote:

He has mentioned several times about "detecting" a non-halting condition
and having to abort it... Argh!

Yes, I just got from him what I think indicates an issue, I think he's
switched from C as pseudocode to C where unbounded recursion is
undefined after setting context that it's pseudocode in the distant past
or having it set by a conversational partner here which was either
unchallenged or not persistently challenged as one might when having
regard to the group's minds.

I think because it's now undefined by no longer being pseudo-code which
we would have assumed was merely didactive but by being real C and
definitive for that specific new challenging puzzle, it's not positively halting and not positively nonhalting because his challenge no longer
has a closed machine specification. Perhaps his halting problem (/the/
only problem on the matter of halting relevant to him at the moment)
should therefore be said to be incoherent.

With that understanding, there are some interesting and educational
things to think about for logic and computation. Best to dwell in the
bathtub for a few weeks instead of controlling his words and thoughts.
Some enjoyable real philosophy. I think he has actually thought deeply
and communicated shallowly to test either his understanding or ours as
one might with an LLM chatbot instead of a group of humans.


--
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.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/20/2025 6:30 AM, Tristan Wibberley wrote:

On 19/10/2025 20:27, Chris M. Thomasson wrote:

He has mentioned several times about "detecting" a non-halting condition
and having to abort it... Argh!

Yes, I just got from him what I think indicates an issue, I think he's switched from C as pseudocode to C where unbounded recursion is
undefined after setting context that it's pseudocode in the distant past
or having it set by a conversational partner here which was either unchallenged or not persistently challenged as one might when having
regard to the group's minds.

I think because it's now undefined by no longer being pseudo-code which
we would have assumed was merely didactive but by being real C and
definitive for that specific new challenging puzzle, it's not positively halting and not positively nonhalting because his challenge no longer
has a closed machine specification. Perhaps his halting problem (/the/
only problem on the matter of halting relevant to him at the moment)
should therefore be said to be incoherent.

<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.

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?
</Input to LLM systems>

This is the updated core of my proof.
It is from this core that I show the halting
problem is a category error in the latest
most succinct proof.

So far most C programmers seem to pretend that
that don't understand it.

The Halting Problem is a Category Error https://www.researchgate.net/publication/396689092_The_Halting_Problem_is_a_Category_Error

With that understanding, there are some interesting and educational
things to think about for logic and computation. Best to dwell in the
bathtub for a few weeks instead of controlling his words and thoughts.
Some enjoyable real philosophy. I think he has actually thought deeply
and communicated shallowly to test either his understanding or ours as
one might with an LLM chatbot instead of a group of humans.

--
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.

--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/19/2025 2:39 PM, Kaz Kylheku wrote:

On 2025-10-19, dart200 <user7160@newsgrouper.org.invalid> wrote:

i don't get y polcott keep hanging onto ai for dear life. anyone with

Throngs of dumb boomers are falling for AI generated videos, believing
them to be real. This is much the same thing.

AI is just another thing Olcott has no understanding of. He's not
researched the fundamentals of what it means to train a language
network, and how it is ultimately just token prediction.

It excels at generating good syntax. The reason for that is that the
vast amount of training data exhibits good syntax. (Where it has bad
syntax, it is idiosyncratic; whereas good syntax is broadly shared.)

I provide a basis to it and it does perform valid
semantic logical entailment on this basis and shows
all of its valid semantic logical entailment steps.

It is important that my basis is self-evidently true:

<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.

In other words, regardless of what any example input text is
semantically about, most such inputs exhibit good grammar. Grammar is
the central topic emanating from nearly every example text, and so the
neural network is learning grammar from nearly everry example, the
resulting being that it is rare for it to predict a sequence of tokens
that isn't grammatical. Not only that, but it avoids awkward
idiosyncracies that are grammatical but rarely exhibited by authors.
There result is that the generated responses are not only grammatical,
but smoothly worded.

That is enough to fool most people into believing it is intelligent, and
a good many others are fooled by its phony flashes of intelligence,
when it predicts tokens along some "semantically beaten path".

Olcott is just one of the gullible dumies, unsurprisingly.

Olcott is fooled /by his own code/ into wrong beliefs.

--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/19/2025 2:39 PM, Kaz Kylheku wrote:

On 2025-10-19, dart200 <user7160@newsgrouper.org.invalid> wrote:

i don't get y polcott keep hanging onto ai for dear life. anyone with

Throngs of dumb boomers are falling for AI generated videos, believing
them to be real. This is much the same thing.

AI is just another thing Olcott has no understanding of. He's not
researched the fundamentals of what it means to train a language
network, and how it is ultimately just token prediction.

It excels at generating good syntax. The reason for that is that the
vast amount of training data exhibits good syntax. (Where it has bad
syntax, it is idiosyncratic; whereas good syntax is broadly shared.)

I provide a basis to it and it does perform valid
semantic logical entailment on this basis and shows

But you're incapable of recognizing valid entailment from invalid.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/19/2025 8:39 PM, Mike Terry wrote:

On 19/10/2025 20:27, Chris M. Thomasson wrote:

On 10/19/2025 8:12 AM, Tristan Wibberley wrote:

On 19/10/2025 02:08, olcott wrote:

On 10/18/2025 8:03 PM, dart200 wrote:

On 10/18/25 1:44 PM, Chris M. Thomasson wrote:

I asked it:

1 HOME
5 PRINT "The Olcott All-in-One Halt Decider!"
10 INPUT "Shall I halt or not? " ; A$
30 IF A$ = "YES" GOTO 666
40 GOTO 10
666 PRINT "OK!"

Its odd to me. Olcott seems to think he can "detect" a
non-termination condition and just inject something that aborts it.

Is that really so? I don't think it looks like that. Alas, I can't get
old messages from my newsserver any more.

He has mentioned several times about "detecting" a non-halting
condition and having to abort it... Argh!

That would be his "Infinite Recursive Simulation" pattern I guess.  The basic idea is that his decider HHH emulates its input DD, which calls
HHH, and so HHH is emulating itself in a sense.  The HHH's monitor what their emulations are doing and when nested emulations occur the outer
HHH can see what all the inner emulations are doing: what instruction they're executing etc.

HHH looks for a couple of patterns of behaviour in its emulation
(together with their nested emulations), and when it spots one of those patterns it abandons its emulation activity and straight away returns 0 [=neverhalts].

So he is not "injecting" anything.

Ahhh! So that's where I am going wrong.

HHH is in the process of emulating
DD, which is not "running" in the sense that HHH is running; it's being emulated.  At some point HHH spots its so-called "non-halting pattern" within DD's nested-emulation trace, and HHH simply stops emulating and returns 0.  On this group that is what people refer to as HHH "aborts"
its emulation of DD, but nothing is injected into DD.  It's not like DD executing a C abort() call or anything.

Thank you. It seems to me that DD is beholden to HHH? So DD is just
reacting to his HHH? I keep asking Olcott to code up HHH in std C. ______________
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);
}
______________


So, Halt_Status sure seems to be kinda sorta akin to the value of A$ in
my little basic program...? Except instead of asking if it should halt
again it goes into a loop HERE: goto HERE;

Why does DD have to hook into HHH, code not shown here.. Humm.

Why can't DD be a stand alone program, say in BASIC created by somebody
else, and HHH(DD) tries to determine if it halts or not?

The problem with my BASIC code is that HHH does not know what A$ is
going to be per iteration. If the input A$ is YES it halts, if not it
asks the same question again...

In olcotts int Halt_Status = HHH(DD); well, it seems like that is not detecting an infinite recursion, or infinite loop, it can return
anything it wants to?

Damn. It feels like I am still missing something. Sigh.

My ISP used to give me an included GigaNews subscription which went back
to somewhere around 2005 I think.  They stopped that as it wasn't in
their official offering, but that means now I too only get about a
year's retention now (from free Eternal September server).  I think
there are web-sites archiving usenet posts, and for PO threads, the
Google Groups archive will cover them up to the last year or so when
Google disconnected from usenet.

Yeah. Well, it sure seems like damn near the same stuff he is writing
about now, with the exception of a "sycophantic" AI that is stroking his
ego? Humm...
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/20/2025 8:04 AM, olcott wrote:

On 10/20/2025 6:30 AM, Tristan Wibberley wrote:

On 19/10/2025 20:27, Chris M. Thomasson wrote:

He has mentioned several times about "detecting" a non-halting condition >>> and having to abort it... Argh!

Yes, I just got from him what I think indicates an issue, I think he's
switched from C as pseudocode to C where unbounded recursion is
undefined after setting context that it's pseudocode in the distant past
or having it set by a conversational partner here which was either
unchallenged or not persistently challenged as one might when having
regard to the group's minds.

I think because it's now undefined by no longer being pseudo-code which
we would have assumed was merely didactive but by being real C and
definitive for that specific new challenging puzzle, it's not positively
halting and not positively nonhalting because his challenge no longer
has a closed machine specification. Perhaps his halting problem (/the/
only problem on the matter of halting relevant to him at the moment)
should therefore be said to be incoherent.

<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.

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?
</Input to LLM systems>[...]

How about HHH returns a random number? Sounds about right? Humm...
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/20/2025 1:29 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/19/2025 2:39 PM, Kaz Kylheku wrote:

On 2025-10-19, dart200 <user7160@newsgrouper.org.invalid> wrote:

i don't get y polcott keep hanging onto ai for dear life. anyone with

Throngs of dumb boomers are falling for AI generated videos, believing
them to be real. This is much the same thing.

AI is just another thing Olcott has no understanding of. He's not
researched the fundamentals of what it means to train a language
network, and how it is ultimately just token prediction.

It excels at generating good syntax. The reason for that is that the
vast amount of training data exhibits good syntax. (Where it has bad
syntax, it is idiosyncratic; whereas good syntax is broadly shared.)

I provide a basis to it and it does perform valid
semantic logical entailment on this basis and shows

But you're incapable of recognizing valid entailment from invalid.

Any freaking idiot can spew out baseless rhetoric
such as this. I could do the same sort of thing
and say you are wrong and stupidly wrong.

It is a whole other ballgame when one attempts
to point out actual errors that are not anchored
in one's own lack of comprehension.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 1:29 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/19/2025 2:39 PM, Kaz Kylheku wrote:

On 2025-10-19, dart200 <user7160@newsgrouper.org.invalid> wrote:

i don't get y polcott keep hanging onto ai for dear life. anyone with >>>>

Throngs of dumb boomers are falling for AI generated videos, believing >>>> them to be real. This is much the same thing.

AI is just another thing Olcott has no understanding of. He's not
researched the fundamentals of what it means to train a language
network, and how it is ultimately just token prediction.

It excels at generating good syntax. The reason for that is that the
vast amount of training data exhibits good syntax. (Where it has bad
syntax, it is idiosyncratic; whereas good syntax is broadly shared.)

I provide a basis to it and it does perform valid
semantic logical entailment on this basis and shows

But you're incapable of recognizing valid entailment from invalid.

Any freaking idiot can spew out baseless rhetoric
such as this. I could do the same sort of thing
and say you are wrong and stupidly wrong.

But you don't?

It is a whole other ballgame when one attempts
to point out actual errors that are not anchored
in one's own lack of comprehension.

You don't comprehend the pointing-out.

Or, perhaps you do, but you are blinded by your ideological belief.

It's as if someone paid you a salary which depended on pretending
not to understand.

Besides money, the only other two incentives which have that power
are ideological fervor and pride/ego.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/20/2025 4:03 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 1:29 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/19/2025 2:39 PM, Kaz Kylheku wrote:

On 2025-10-19, dart200 <user7160@newsgrouper.org.invalid> wrote:

i don't get y polcott keep hanging onto ai for dear life. anyone with >>>>>

Throngs of dumb boomers are falling for AI generated videos, believing >>>>> them to be real. This is much the same thing.

AI is just another thing Olcott has no understanding of. He's not
researched the fundamentals of what it means to train a language
network, and how it is ultimately just token prediction.

It excels at generating good syntax. The reason for that is that the >>>>> vast amount of training data exhibits good syntax. (Where it has bad >>>>> syntax, it is idiosyncratic; whereas good syntax is broadly shared.) >>>>>

I provide a basis to it and it does perform valid
semantic logical entailment on this basis and shows

But you're incapable of recognizing valid entailment from invalid.

Any freaking idiot can spew out baseless rhetoric
such as this. I could do the same sort of thing
and say you are wrong and stupidly wrong.

But you don't?

It is a whole other ballgame when one attempts
to point out actual errors that are not anchored
in one's own lack of comprehension.

You don't comprehend the pointing-out.

You need to have a sound reasoning basis to prove
that an error is an actual error. The most stupid
bot that ever existed "Eliza" could mindlessly
spew out a declaration of error.

Or, perhaps you do, but you are blinded by your ideological belief.

It's as if someone paid you a salary which depended on pretending
not to understand.

Besides money, the only other two incentives which have that power
are ideological fervor and pride/ego.

--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 4:03 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 1:29 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/19/2025 2:39 PM, Kaz Kylheku wrote:

On 2025-10-19, dart200 <user7160@newsgrouper.org.invalid> wrote:

i don't get y polcott keep hanging onto ai for dear life. anyone with >>>>>>

Throngs of dumb boomers are falling for AI generated videos, believing >>>>>> them to be real. This is much the same thing.

AI is just another thing Olcott has no understanding of. He's not
researched the fundamentals of what it means to train a language
network, and how it is ultimately just token prediction.

It excels at generating good syntax. The reason for that is that the >>>>>> vast amount of training data exhibits good syntax. (Where it has bad >>>>>> syntax, it is idiosyncratic; whereas good syntax is broadly shared.) >>>>>>

I provide a basis to it and it does perform valid
semantic logical entailment on this basis and shows

But you're incapable of recognizing valid entailment from invalid.

Any freaking idiot can spew out baseless rhetoric
such as this. I could do the same sort of thing
and say you are wrong and stupidly wrong.

But you don't?

It is a whole other ballgame when one attempts
to point out actual errors that are not anchored
in one's own lack of comprehension.

You don't comprehend the pointing-out.

You need to have a sound reasoning basis to prove
that an error is an actual error.

No; /YOU/ need to have sound reasonings to prove /YOUR/
extraordinary claims. The burden is on you.

We already have the solid reasoning which says things are other than as
you say, and you don't have the faintest idea how to put a dent in it.

And there isn't one; the problem isn't that you don't have that idea
(nobody does), but that you're convinced that you do, without
justification.

The most stupid
bot that ever existed "Eliza" could mindlessly
spew out a declaration of error.

It is monumentally rude of you to insist that you've been given zero
details about how you are wrong. You either just don't understand the
details or casually dismiss them on ideological grounds that
have no place in this discipline.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/20/2025 8:27 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 4:03 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 1:29 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/19/2025 2:39 PM, Kaz Kylheku wrote:

On 2025-10-19, dart200 <user7160@newsgrouper.org.invalid> wrote: >>>>>>>> i don't get y polcott keep hanging onto ai for dear life. anyone with >>>>>>>
Throngs of dumb boomers are falling for AI generated videos, believing >>>>>>> them to be real. This is much the same thing.

AI is just another thing Olcott has no understanding of. He's not >>>>>>> researched the fundamentals of what it means to train a language >>>>>>> network, and how it is ultimately just token prediction.

It excels at generating good syntax. The reason for that is that the >>>>>>> vast amount of training data exhibits good syntax. (Where it has bad >>>>>>> syntax, it is idiosyncratic; whereas good syntax is broadly shared.) >>>>>>>

I provide a basis to it and it does perform valid
semantic logical entailment on this basis and shows

But you're incapable of recognizing valid entailment from invalid.

Any freaking idiot can spew out baseless rhetoric
such as this. I could do the same sort of thing
and say you are wrong and stupidly wrong.

But you don't?

It is a whole other ballgame when one attempts
to point out actual errors that are not anchored
in one's own lack of comprehension.

You don't comprehend the pointing-out.

You need to have a sound reasoning basis to prove
that an error is an actual error.

No; /YOU/ need to have sound reasonings to prove /YOUR/
extraordinary claims. The burden is on you.

We already have the solid reasoning which says things are other than as
you say, and you don't have the faintest idea how to put a dent in it.

In other words you assume that I must be wrong
entirely on the basis that what I say does not
conform to conventional wisdom. That is not any
actual rebuttal of the specific points that I make.

And there isn't one; the problem isn't that you don't have that idea
(nobody does), but that you're convinced that you do, without
justification.

The most stupid
bot that ever existed "Eliza" could mindlessly
spew out a declaration of error.

It is monumentally rude of you to insist that you've been given zero
details about how you are wrong. You either just don't understand the
details or casually dismiss them on ideological grounds that
have no place in this discipline.

--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-10-21, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 8:27 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 4:03 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 1:29 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/19/2025 2:39 PM, Kaz Kylheku wrote:

On 2025-10-19, dart200 <user7160@newsgrouper.org.invalid> wrote: >>>>>>>>> i don't get y polcott keep hanging onto ai for dear life. anyone with >>>>>>>>
Throngs of dumb boomers are falling for AI generated videos, believing >>>>>>>> them to be real. This is much the same thing.

AI is just another thing Olcott has no understanding of. He's not >>>>>>>> researched the fundamentals of what it means to train a language >>>>>>>> network, and how it is ultimately just token prediction.

It excels at generating good syntax. The reason for that is that the >>>>>>>> vast amount of training data exhibits good syntax. (Where it has bad >>>>>>>> syntax, it is idiosyncratic; whereas good syntax is broadly shared.) >>>>>>>>

I provide a basis to it and it does perform valid
semantic logical entailment on this basis and shows

But you're incapable of recognizing valid entailment from invalid. >>>>>>

Any freaking idiot can spew out baseless rhetoric
such as this. I could do the same sort of thing
and say you are wrong and stupidly wrong.

But you don't?

It is a whole other ballgame when one attempts
to point out actual errors that are not anchored
in one's own lack of comprehension.

You don't comprehend the pointing-out.

You need to have a sound reasoning basis to prove
that an error is an actual error.

No; /YOU/ need to have sound reasonings to prove /YOUR/
extraordinary claims. The burden is on you.

We already have the solid reasoning which says things are other than as
you say, and you don't have the faintest idea how to put a dent in it.

In other words you assume that I must be wrong
entirely on the basis that what I say does not
conform to conventional wisdom.

Yes; you are wrong entirely on the basis that what you say does not
follow a valid mode of inference for refuting an argument.

If you are trying to refute something which is not only a widely
accepted result, but whose reasoning anyone can follow to see it
for themselves, you are automatically assumed wrong.

The established result is presumed correct, pending your
presentation of a convincing argument.

That's not just wanton arbitrariness: your claims are being
directly refuted by elements of the established result which
we can refer to.

I cannot identify any flaw in the halting theorem. It's not simply
that I believe it because of the Big Names attached to it.

I'm convinced by the argumentation; and that conviction has
the side effect of convincing me of the falsehood of your
ineffective, contrary argumentation.

That is not any actual rebuttal of the specific points that I make.

No, indeed /that/ isn't; but plenty of those have also been made not
only by me but various others, over a considerable time span.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/20/2025 9:11 PM, Kaz Kylheku wrote:

On 2025-10-21, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 8:27 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 4:03 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 1:29 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/19/2025 2:39 PM, Kaz Kylheku wrote:

On 2025-10-19, dart200 <user7160@newsgrouper.org.invalid> wrote: >>>>>>>>>> i don't get y polcott keep hanging onto ai for dear life. anyone with

Throngs of dumb boomers are falling for AI generated videos, believing
them to be real. This is much the same thing.

AI is just another thing Olcott has no understanding of. He's not >>>>>>>>> researched the fundamentals of what it means to train a language >>>>>>>>> network, and how it is ultimately just token prediction.

It excels at generating good syntax. The reason for that is that the >>>>>>>>> vast amount of training data exhibits good syntax. (Where it has bad >>>>>>>>> syntax, it is idiosyncratic; whereas good syntax is broadly shared.) >>>>>>>>>

I provide a basis to it and it does perform valid
semantic logical entailment on this basis and shows

But you're incapable of recognizing valid entailment from invalid. >>>>>>>

Any freaking idiot can spew out baseless rhetoric
such as this. I could do the same sort of thing
and say you are wrong and stupidly wrong.

But you don't?

It is a whole other ballgame when one attempts
to point out actual errors that are not anchored
in one's own lack of comprehension.

You don't comprehend the pointing-out.

You need to have a sound reasoning basis to prove
that an error is an actual error.

No; /YOU/ need to have sound reasonings to prove /YOUR/
extraordinary claims. The burden is on you.

We already have the solid reasoning which says things are other than as
you say, and you don't have the faintest idea how to put a dent in it.

In other words you assume that I must be wrong
entirely on the basis that what I say does not
conform to conventional wisdom.

Yes; you are wrong entirely on the basis that what you say does not
follow a valid mode of inference for refuting an argument.

If you are trying to refute something which is not only a widely
accepted result, but whose reasoning anyone can follow to see it
for themselves, you are automatically assumed wrong.

The established result is presumed correct, pending your
presentation of a convincing argument.

That's not just wanton arbitrariness: your claims are being
directly refuted by elements of the established result which
we can refer to.

I cannot identify any flaw in the halting theorem. It's not simply
that I believe it because of the Big Names attached to it.

And when I identify a flaw yo simply ignore
whatever I say.

I'm convinced by the argumentation; and that conviction has
the side effect of convincing me of the falsehood of your
ineffective, contrary argumentation.

Not really it actually gives you the bias to refuse
to pay attention.

That is not any actual rebuttal of the specific points that I make.

No, indeed /that/ isn't; but plenty of those have also been made not
only by me but various others, over a considerable time span.

Never any actual rebuttal ever since Professor
Sipser agreed with my words. Those exact same
words still form the basis of my whole proof.

*Here is an accurate paraphrase of those words*

<Input to LLM systems>

Perform the complete simulation specified in main() and provide a
full execution trace before doing anything else.

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.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/20/2025 11:00 PM, olcott wrote:

On 10/20/2025 9:11 PM, Kaz Kylheku wrote:

On 2025-10-21, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 8:27 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 4:03 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 1:29 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/19/2025 2:39 PM, Kaz Kylheku wrote:

On 2025-10-19, dart200 <user7160@newsgrouper.org.invalid> wrote: >>>>>>>>>>> i don't get y polcott keep hanging onto ai for dear life. >>>>>>>>>>> anyone with

Throngs of dumb boomers are falling for AI generated videos, >>>>>>>>>> believing
them to be real. This is much the same thing.

AI is just another thing Olcott has no understanding of. He's not >>>>>>>>>> researched the fundamentals of what it means to train a language >>>>>>>>>> network, and how it is ultimately just token prediction.

It excels at generating good syntax. The reason for that is >>>>>>>>>> that the
vast amount of training data exhibits good syntax. (Where it >>>>>>>>>> has bad
syntax, it is idiosyncratic; whereas good syntax is broadly >>>>>>>>>> shared.)

I provide a basis to it and it does perform valid
semantic logical entailment on this basis and shows

But you're incapable of recognizing valid entailment from invalid. >>>>>>>>

Any freaking idiot can spew out baseless rhetoric
such as this. I could do the same sort of thing
and say you are wrong and stupidly wrong.

But you don't?

It is a whole other ballgame when one attempts
to point out actual errors that are not anchored
in one's own lack of comprehension.

You don't comprehend the pointing-out.

You need to have a sound reasoning basis to prove
that an error is an actual error.

No; /YOU/ need to have sound reasonings to prove /YOUR/
extraordinary claims. The burden is on you.

We already have the solid reasoning which says things are other than as >>>> you say, and you don't have the faintest idea how to put a dent in it. >>>>

In other words you assume that I must be wrong
entirely on the basis that what I say does not
conform to conventional wisdom.

Yes; you are wrong entirely on the basis that what you say does not
follow a valid mode of inference for refuting an argument.

If you are trying to refute something which is not only a widely
accepted result, but whose reasoning anyone can follow to see it
for themselves, you are automatically assumed wrong.

The established result is presumed correct, pending your
presentation of a convincing argument.

That's not just wanton arbitrariness: your claims are being
directly refuted by elements of the established result which
we can refer to.

I cannot identify any flaw in the halting theorem. It's not simply
that I believe it because of the Big Names attached to it.

And when I identify a flaw yo simply ignore
whatever I say.

I'm convinced by the argumentation; and that conviction has
the side effect of convincing me of the falsehood of your
ineffective, contrary argumentation.

Not really it actually gives you the bias to refuse
to pay attention.

That is not any actual rebuttal of the specific points that I make.

No, indeed /that/ isn't; but plenty of those have also been made not
only by me but various others, over a considerable time span.

Never any actual rebuttal ever since Professor
Sipser agreed with my words. Those exact same
words still form the basis of my whole proof.

You mean the words where he didn't agree with your interpretation of them?



On Monday, March 6, 2023 at 2:41:27 PM UTC-5, Ben Bacarisse wrote:

Fritz Feldhase <franz.fri...@gmail.com> writes:

On Monday, March 6, 2023 at 3:56:52 AM UTC+1, olcott wrote:

On 3/5/2023 8:33 PM, Fritz Feldhase wrote:

On Monday, March 6, 2023 at 3:30:38 AM UTC+1, olcott wrote:

I needed Sipser for people [bla]

Does Sipser support your view/claim that you have refuted the

halting theorem?

Does he write/teach that the halting theorem is invalid?

Tell us, oh genius!

Professor Sipser only agreed that [...]

So the answer is no. Noted.

Because he has >250 students he did not have time to examine anything
else. [...]

Oh, a CS professor does not have the time to check a refutation of the halting theorem. *lol*

I exchanged emails with him about this. He does not agree with anything substantive that PO has written. I won't quote him, as I don't have permission, but he was, let's say... forthright, in his reply to me.

On 8/23/2024 5:07 PM, Ben Bacarisse wrote:

joes <noreply@example.org> writes:

Am Wed, 21 Aug 2024 20:55:52 -0500 schrieb olcott:

Professor Sipser clearly agreed that an H that does a finite simulation
of D is to predict the behavior of an unlimited simulation of D.

If the simulator *itself* would not abort. The H called by D is,
by construction, the same and *does* abort.

We don't really know what context Sipser was given. I got in touch at
the time so do I know he had enough context to know that PO's ideas were "wacky" and that had agreed to what he considered a "minor remark".

Since PO considers his words finely crafted and key to his so-called
work I think it's clear that Sipser did not take the "minor remark" he agreed to to mean what PO takes it to mean! My own take if that he
(Sipser) read it as a general remark about how to determine some cases,
i.e. that D names an input that H can partially simulate to determine
it's halting or otherwise. We all know or could construct some such
cases.

I suspect he was tricked because PO used H and D as the names without
making it clear that D was constructed from H in the usual way (Sipser
uses H and D in at least one of his proofs). Of course, he is clued in enough know that, if D is indeed constructed from H like that, the
"minor remark" becomes true by being a hypothetical: if the moon is made
of cheese, the Martians can look forward to a fine fondue. But,
personally, I think the professor is more straight talking than that,
and he simply took as a method that can work for some inputs. That's
the only way is could be seen as a "minor remark" with being accused of being disingenuous.

On 8/23/2024 9:10 PM, Mike Terry wrote:

So that PO will have no cause to quote me as supporting his case: what Sipser understood he was agreeing to was NOT what PO interprets it as meaning. Sipser would not agree that the conclusion applies in PO's HHH(DDD) scenario, where DDD halts.

On 5/2/2025 9:16 PM, Mike Terry wrote:

PO is trying to interpret Sipser's quote:

--- Start Sipser quote
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.
--- End Sipser quote

The following interpretation is ok:

If H is given input D, and while simulating D gathers enough
information to deduce that UTM(D) would never halt, then
H can abort its simulation and decide D never halts.

I'd say it's obvious that this is what Sipser is saying, because it's natural, correct, and relevant to what was being discussed (valid
strategy for a simulating halt decider). It is trivial to check that
what my interpretation says is valid:

if UTM(D) would never halt, then D never halts, so if H(D) returns
never_halts then that is the correct answer for the input. QED :)

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/20/2025 10:05 PM, dbush wrote:

On 10/20/2025 11:00 PM, olcott wrote:

On 10/20/2025 9:11 PM, Kaz Kylheku wrote:

On 2025-10-21, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 8:27 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 4:03 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 1:29 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/19/2025 2:39 PM, Kaz Kylheku wrote:

On 2025-10-19, dart200 <user7160@newsgrouper.org.invalid> wrote: >>>>>>>>>>>> i don't get y polcott keep hanging onto ai for dear life. >>>>>>>>>>>> anyone with

Throngs of dumb boomers are falling for AI generated videos, >>>>>>>>>>> believing
them to be real. This is much the same thing.

AI is just another thing Olcott has no understanding of. He's >>>>>>>>>>> not
researched the fundamentals of what it means to train a language >>>>>>>>>>> network, and how it is ultimately just token prediction. >>>>>>>>>>>
It excels at generating good syntax. The reason for that is >>>>>>>>>>> that the
vast amount of training data exhibits good syntax. (Where it >>>>>>>>>>> has bad
syntax, it is idiosyncratic; whereas good syntax is broadly >>>>>>>>>>> shared.)

I provide a basis to it and it does perform valid
semantic logical entailment on this basis and shows

But you're incapable of recognizing valid entailment from invalid. >>>>>>>>>

Any freaking idiot can spew out baseless rhetoric
such as this. I could do the same sort of thing
and say you are wrong and stupidly wrong.

But you don't?

It is a whole other ballgame when one attempts
to point out actual errors that are not anchored
in one's own lack of comprehension.

You don't comprehend the pointing-out.

You need to have a sound reasoning basis to prove
that an error is an actual error.

No; /YOU/ need to have sound reasonings to prove /YOUR/
extraordinary claims. The burden is on you.

We already have the solid reasoning which says things are other
than as
you say, and you don't have the faintest idea how to put a dent in it. >>>>>

In other words you assume that I must be wrong
entirely on the basis that what I say does not
conform to conventional wisdom.

Yes; you are wrong entirely on the basis that what you say does not
follow a valid mode of inference for refuting an argument.

If you are trying to refute something which is not only a widely
accepted result, but whose reasoning anyone can follow to see it
for themselves, you are automatically assumed wrong.

The established result is presumed correct, pending your
presentation of a convincing argument.

That's not just wanton arbitrariness: your claims are being
directly refuted by elements of the established result which
we can refer to.

I cannot identify any flaw in the halting theorem. It's not simply
that I believe it because of the Big Names attached to it.

And when I identify a flaw yo simply ignore
whatever I say.

I'm convinced by the argumentation; and that conviction has
the side effect of convincing me of the falsehood of your
ineffective, contrary argumentation.

Not really it actually gives you the bias to refuse
to pay attention.

That is not any actual rebuttal of the specific points that I make.

No, indeed /that/ isn't; but plenty of those have also been made not
only by me but various others, over a considerable time span.

Never any actual rebuttal ever since Professor
Sipser agreed with my words. Those exact same
words still form the basis of my whole proof.

You mean the words where he didn't agree with your interpretation of them?

According to a Claude AI analysis there
are only two interpretations and one of
them is wrong and the other one is my
interpretation.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/20/2025 11:13 PM, olcott wrote:

On 10/20/2025 10:05 PM, dbush wrote:

On 10/20/2025 11:00 PM, olcott wrote:

On 10/20/2025 9:11 PM, Kaz Kylheku wrote:

On 2025-10-21, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 8:27 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 4:03 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 1:29 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/19/2025 2:39 PM, Kaz Kylheku wrote:

On 2025-10-19, dart200 <user7160@newsgrouper.org.invalid> >>>>>>>>>>>> wrote:

i don't get y polcott keep hanging onto ai for dear life. >>>>>>>>>>>>> anyone with

Throngs of dumb boomers are falling for AI generated videos, >>>>>>>>>>>> believing
them to be real. This is much the same thing.

AI is just another thing Olcott has no understanding of. >>>>>>>>>>>> He's not
researched the fundamentals of what it means to train a >>>>>>>>>>>> language
network, and how it is ultimately just token prediction. >>>>>>>>>>>>
It excels at generating good syntax. The reason for that is >>>>>>>>>>>> that the
vast amount of training data exhibits good syntax. (Where it >>>>>>>>>>>> has bad
syntax, it is idiosyncratic; whereas good syntax is broadly >>>>>>>>>>>> shared.)

I provide a basis to it and it does perform valid
semantic logical entailment on this basis and shows

But you're incapable of recognizing valid entailment from >>>>>>>>>> invalid.

Any freaking idiot can spew out baseless rhetoric
such as this. I could do the same sort of thing
and say you are wrong and stupidly wrong.

But you don't?

It is a whole other ballgame when one attempts
to point out actual errors that are not anchored
in one's own lack of comprehension.

You don't comprehend the pointing-out.

You need to have a sound reasoning basis to prove
that an error is an actual error.

No; /YOU/ need to have sound reasonings to prove /YOUR/
extraordinary claims. The burden is on you.

We already have the solid reasoning which says things are other
than as
you say, and you don't have the faintest idea how to put a dent in >>>>>> it.

In other words you assume that I must be wrong
entirely on the basis that what I say does not
conform to conventional wisdom.

Yes; you are wrong entirely on the basis that what you say does not
follow a valid mode of inference for refuting an argument.

If you are trying to refute something which is not only a widely
accepted result, but whose reasoning anyone can follow to see it
for themselves, you are automatically assumed wrong.

The established result is presumed correct, pending your
presentation of a convincing argument.

That's not just wanton arbitrariness: your claims are being
directly refuted by elements of the established result which
we can refer to.

I cannot identify any flaw in the halting theorem. It's not simply
that I believe it because of the Big Names attached to it.

And when I identify a flaw yo simply ignore
whatever I say.

I'm convinced by the argumentation; and that conviction has
the side effect of convincing me of the falsehood of your
ineffective, contrary argumentation.

Not really it actually gives you the bias to refuse
to pay attention.

That is not any actual rebuttal of the specific points that I make.

No, indeed /that/ isn't; but plenty of those have also been made not
only by me but various others, over a considerable time span.

Never any actual rebuttal ever since Professor
Sipser agreed with my words. Those exact same
words still form the basis of my whole proof.

You mean the words where he didn't agree with your interpretation of
them?

According to a Claude AI analysis there
are only two interpretations and one of
them is wrong and the other one is my
interpretation.

Whether you think one interpretation is wrong is irrelevant. What is
relevant is that that's how everyone else including Sipser interpreted
those words, so you lie by implying that he agrees with your interpretation.



On Monday, March 6, 2023 at 2:41:27 PM UTC-5, Ben Bacarisse wrote:

Fritz Feldhase <franz.fri...@gmail.com> writes:

On Monday, March 6, 2023 at 3:56:52 AM UTC+1, olcott wrote:

On 3/5/2023 8:33 PM, Fritz Feldhase wrote:

On Monday, March 6, 2023 at 3:30:38 AM UTC+1, olcott wrote:

I needed Sipser for people [bla]

Does Sipser support your view/claim that you have refuted the

halting theorem?

Does he write/teach that the halting theorem is invalid?

Tell us, oh genius!

Professor Sipser only agreed that [...]

So the answer is no. Noted.

Because he has >250 students he did not have time to examine anything
else. [...]

Oh, a CS professor does not have the time to check a refutation of the halting theorem. *lol*

I exchanged emails with him about this. He does not agree with anything substantive that PO has written. I won't quote him, as I don't have permission, but he was, let's say... forthright, in his reply to me.

On 8/23/2024 5:07 PM, Ben Bacarisse wrote:

joes <noreply@example.org> writes:

Am Wed, 21 Aug 2024 20:55:52 -0500 schrieb olcott:

Professor Sipser clearly agreed that an H that does a finite simulation
of D is to predict the behavior of an unlimited simulation of D.

If the simulator *itself* would not abort. The H called by D is,
by construction, the same and *does* abort.

We don't really know what context Sipser was given. I got in touch at
the time so do I know he had enough context to know that PO's ideas were "wacky" and that had agreed to what he considered a "minor remark".

Since PO considers his words finely crafted and key to his so-called
work I think it's clear that Sipser did not take the "minor remark" he agreed to to mean what PO takes it to mean! My own take if that he
(Sipser) read it as a general remark about how to determine some cases,
i.e. that D names an input that H can partially simulate to determine
it's halting or otherwise. We all know or could construct some such
cases.

I suspect he was tricked because PO used H and D as the names without
making it clear that D was constructed from H in the usual way (Sipser
uses H and D in at least one of his proofs). Of course, he is clued in enough know that, if D is indeed constructed from H like that, the
"minor remark" becomes true by being a hypothetical: if the moon is made
of cheese, the Martians can look forward to a fine fondue. But,
personally, I think the professor is more straight talking than that,
and he simply took as a method that can work for some inputs. That's
the only way is could be seen as a "minor remark" with being accused of being disingenuous.

On 8/23/2024 9:10 PM, Mike Terry wrote:

So that PO will have no cause to quote me as supporting his case: what Sipser understood he was agreeing to was NOT what PO interprets it as meaning. Sipser would not agree that the conclusion applies in PO's HHH(DDD) scenario, where DDD halts.

On 5/2/2025 9:16 PM, Mike Terry wrote:

PO is trying to interpret Sipser's quote:

--- Start Sipser quote
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.
--- End Sipser quote

The following interpretation is ok:

If H is given input D, and while simulating D gathers enough
information to deduce that UTM(D) would never halt, then
H can abort its simulation and decide D never halts.

I'd say it's obvious that this is what Sipser is saying, because it's natural, correct, and relevant to what was being discussed (valid
strategy for a simulating halt decider). It is trivial to check that
what my interpretation says is valid:

if UTM(D) would never halt, then D never halts, so if H(D) returns
never_halts then that is the correct answer for the input. QED :)

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-10-21, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 9:11 PM, Kaz Kylheku wrote:

On 2025-10-21, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 8:27 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 4:03 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 1:29 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/19/2025 2:39 PM, Kaz Kylheku wrote:

On 2025-10-19, dart200 <user7160@newsgrouper.org.invalid> wrote: >>>>>>>>>>> i don't get y polcott keep hanging onto ai for dear life. anyone with

Throngs of dumb boomers are falling for AI generated videos, believing
them to be real. This is much the same thing.

AI is just another thing Olcott has no understanding of. He's not >>>>>>>>>> researched the fundamentals of what it means to train a language >>>>>>>>>> network, and how it is ultimately just token prediction.

It excels at generating good syntax. The reason for that is that the >>>>>>>>>> vast amount of training data exhibits good syntax. (Where it has bad >>>>>>>>>> syntax, it is idiosyncratic; whereas good syntax is broadly shared.) >>>>>>>>>>

I provide a basis to it and it does perform valid
semantic logical entailment on this basis and shows

But you're incapable of recognizing valid entailment from invalid. >>>>>>>>

Any freaking idiot can spew out baseless rhetoric
such as this. I could do the same sort of thing
and say you are wrong and stupidly wrong.

But you don't?

It is a whole other ballgame when one attempts
to point out actual errors that are not anchored
in one's own lack of comprehension.

You don't comprehend the pointing-out.

You need to have a sound reasoning basis to prove
that an error is an actual error.

No; /YOU/ need to have sound reasonings to prove /YOUR/
extraordinary claims. The burden is on you.

We already have the solid reasoning which says things are other than as >>>> you say, and you don't have the faintest idea how to put a dent in it. >>>>

In other words you assume that I must be wrong
entirely on the basis that what I say does not
conform to conventional wisdom.

Yes; you are wrong entirely on the basis that what you say does not
follow a valid mode of inference for refuting an argument.

If you are trying to refute something which is not only a widely
accepted result, but whose reasoning anyone can follow to see it
for themselves, you are automatically assumed wrong.

The established result is presumed correct, pending your
presentation of a convincing argument.

That's not just wanton arbitrariness: your claims are being
directly refuted by elements of the established result which
we can refer to.

I cannot identify any flaw in the halting theorem. It's not simply
that I believe it because of the Big Names attached to it.

And when I identify a flaw yo simply ignore
whatever I say.

Nope; all the ways you say claim you've identified a flaw have been
dissected by multiple poeple to a much greater detail than they deserve.

It is disingenuous to say that you've simply had your details ignored.

I'm convinced by the argumentation; and that conviction has
the side effect of convincing me of the falsehood of your
ineffective, contrary argumentation.

Not really it actually gives you the bias to refuse
to pay attention.

LOL! the world at large is incredibly biased against giving a crank
like you any attention.

Those of us present are overcoming the world's /immense/ bias
and actually indulging the details of your claims.

That is not any actual rebuttal of the specific points that I make.

No, indeed /that/ isn't; but plenty of those have also been made not
only by me but various others, over a considerable time span.

Never any actual rebuttal ever since Professor
Sipser agreed with my words.

You're forgetting (of course, isnce it was more than 48-72 hours
ago) that I (almost) also agree with those words.

Those exact same
words still form the basis of my whole proof.

They don't do that, though.

*Here is an accurate paraphrase of those words*

<Input to LLM systems>

Perform the complete simulation specified in main() and provide a
full execution trace before doing anything else.

Simulating Termination Analyzer HHH correctly simulates its input until:

Yes; it correctly steps each x86 instructions with Debug_Step until:

(a) It correctly detects that its simulated input cannot
possibly reach its own simulated final halt state then:

It correctly detects the situation that: if it doesn't abort,
the simulation will not end.

What this means is that if, hypothetically, HHH //were differently
defined// as a non-aborting decider, then DD //would also be
differntly defined// as a non-terminating case.

This hypothesis doesn't mean fuck all because it's not reality. HHH is
not differently defined other than as it is, and likewise DD is not
differently defined. HHH is required to report on the current definition
of DD, which is built on the current definition of HHH.

In any case, yes; the abort is necessary to avoid non-termination.

abort simulation and return 0 rejecting its input as non-halting.

And yes, I agree that it aborts the simulation, returns 0
which indicates that it's rejecting the input as non-halting.

(Unfortunately, that is wrong).

But mostly the words can be rationally agreed to with the caveat that
HHH's result may not be interpreted to be about a hypothetical different version of itself acting on a different input.

HHH must be reporting about the actual instruction string DD
that it is actually given. (As you like to repeat.) Not some fantasy
other versions of these.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/20/2025 10:16 PM, dbush wrote:

On 10/20/2025 11:13 PM, olcott wrote:

On 10/20/2025 10:05 PM, dbush wrote:>>>

You mean the words where he didn't agree with your interpretation of
them?

According to a Claude AI analysis there
are only two interpretations and one of
them is wrong and the other one is my
interpretation.

Whether you think one interpretation is wrong is irrelevant.  What is relevant is that that's how everyone else including Sipser interpreted
those words, so you lie by implying that he agrees with your
interpretation.

<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>

There are only two possible ways to interpret those words
and one of them is wrong. The one that is not wrong is the
way that I interpret them.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/20/2025 10:20 PM, Kaz Kylheku wrote:

On 2025-10-21, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 9:11 PM, Kaz Kylheku wrote:

On 2025-10-21, olcott <polcott333@gmail.com> wrote:

In other words you assume that I must be wrong
entirely on the basis that what I say does not
conform to conventional wisdom.

Yes; you are wrong entirely on the basis that what you say does not
follow a valid mode of inference for refuting an argument.

If you are trying to refute something which is not only a widely
accepted result, but whose reasoning anyone can follow to see it
for themselves, you are automatically assumed wrong.

The established result is presumed correct, pending your
presentation of a convincing argument.

That's not just wanton arbitrariness: your claims are being
directly refuted by elements of the established result which
we can refer to.

I cannot identify any flaw in the halting theorem. It's not simply
that I believe it because of the Big Names attached to it.

And when I identify a flaw yo simply ignore
whatever I say.

Nope; all the ways you say claim you've identified a flaw have been
dissected by multiple poeple to a much greater detail than they deserve.

It is disingenuous to say that you've simply had your details ignored.

I'm convinced by the argumentation; and that conviction has
the side effect of convincing me of the falsehood of your
ineffective, contrary argumentation.

Not really it actually gives you the bias to refuse
to pay attention.

LOL! the world at large is incredibly biased against giving a crank
like you any attention.

Hence the huge advantage of LLMs.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/20/2025 11:25 PM, olcott wrote:

On 10/20/2025 10:16 PM, dbush wrote:

On 10/20/2025 11:13 PM, olcott wrote:

On 10/20/2025 10:05 PM, dbush wrote:>>>

You mean the words where he didn't agree with your interpretation of
them?

According to a Claude AI analysis there
are only two interpretations and one of
them is wrong and the other one is my
interpretation.

Whether you think one interpretation is wrong is irrelevant.  What is
relevant is that that's how everyone else including Sipser interpreted
those words, so you lie by implying that he agrees with your
interpretation.

<repeat of previously refuted point>

Repeating the point that was just refuted is less than no rebuttal, and therefore constitutes your admission that Sipser does NOT agree with
you, and that you have been lying by implying that he does.



On Monday, March 6, 2023 at 2:41:27 PM UTC-5, Ben Bacarisse wrote:

Fritz Feldhase <franz.fri...@gmail.com> writes:

On Monday, March 6, 2023 at 3:56:52 AM UTC+1, olcott wrote:

On 3/5/2023 8:33 PM, Fritz Feldhase wrote:

On Monday, March 6, 2023 at 3:30:38 AM UTC+1, olcott wrote:

I needed Sipser for people [bla]

Does Sipser support your view/claim that you have refuted the

halting theorem?

Does he write/teach that the halting theorem is invalid?

Tell us, oh genius!

Professor Sipser only agreed that [...]

So the answer is no. Noted.

Because he has >250 students he did not have time to examine anything
else. [...]

Oh, a CS professor does not have the time to check a refutation of the halting theorem. *lol*

I exchanged emails with him about this. He does not agree with anything substantive that PO has written. I won't quote him, as I don't have permission, but he was, let's say... forthright, in his reply to me.

On 8/23/2024 5:07 PM, Ben Bacarisse wrote:

joes <noreply@example.org> writes:

Am Wed, 21 Aug 2024 20:55:52 -0500 schrieb olcott:

Professor Sipser clearly agreed that an H that does a finite simulation
of D is to predict the behavior of an unlimited simulation of D.

If the simulator *itself* would not abort. The H called by D is,
by construction, the same and *does* abort.

We don't really know what context Sipser was given. I got in touch at
the time so do I know he had enough context to know that PO's ideas were "wacky" and that had agreed to what he considered a "minor remark".

Since PO considers his words finely crafted and key to his so-called
work I think it's clear that Sipser did not take the "minor remark" he agreed to to mean what PO takes it to mean! My own take if that he
(Sipser) read it as a general remark about how to determine some cases,
i.e. that D names an input that H can partially simulate to determine
it's halting or otherwise. We all know or could construct some such
cases.

I suspect he was tricked because PO used H and D as the names without
making it clear that D was constructed from H in the usual way (Sipser
uses H and D in at least one of his proofs). Of course, he is clued in enough know that, if D is indeed constructed from H like that, the
"minor remark" becomes true by being a hypothetical: if the moon is made
of cheese, the Martians can look forward to a fine fondue. But,
personally, I think the professor is more straight talking than that,
and he simply took as a method that can work for some inputs. That's
the only way is could be seen as a "minor remark" with being accused of being disingenuous.

On 8/23/2024 9:10 PM, Mike Terry wrote:

So that PO will have no cause to quote me as supporting his case: what Sipser understood he was agreeing to was NOT what PO interprets it as meaning. Sipser would not agree that the conclusion applies in PO's HHH(DDD) scenario, where DDD halts.

On 5/2/2025 9:16 PM, Mike Terry wrote:

PO is trying to interpret Sipser's quote:

--- Start Sipser quote
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.
--- End Sipser quote

The following interpretation is ok:

If H is given input D, and while simulating D gathers enough
information to deduce that UTM(D) would never halt, then
H can abort its simulation and decide D never halts.

I'd say it's obvious that this is what Sipser is saying, because it's natural, correct, and relevant to what was being discussed (valid
strategy for a simulating halt decider). It is trivial to check that
what my interpretation says is valid:

if UTM(D) would never halt, then D never halts, so if H(D) returns
never_halts then that is the correct answer for the input. QED :)

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 20/10/2025 21:04, Chris M. Thomasson wrote:

On 10/19/2025 8:39 PM, Mike Terry wrote:

On 19/10/2025 20:27, Chris M. Thomasson wrote:

On 10/19/2025 8:12 AM, Tristan Wibberley wrote:

On 19/10/2025 02:08, olcott wrote:

On 10/18/2025 8:03 PM, dart200 wrote:

On 10/18/25 1:44 PM, Chris M. Thomasson wrote:

I asked it:

1 HOME
5 PRINT "The Olcott All-in-One Halt Decider!"
10 INPUT "Shall I halt or not? " ; A$
30 IF A$ = "YES" GOTO 666
40 GOTO 10
666 PRINT "OK!"

Its odd to me. Olcott seems to think he can "detect" a
non-termination condition and just inject something that aborts it. >>>>

Is that really so? I don't think it looks like that. Alas, I can't get >>>> old messages from my newsserver any more.

He has mentioned several times about "detecting" a non-halting condition and having to abort
it... Argh!

That would be his "Infinite Recursive Simulation" pattern I guess.  The basic idea is that his
decider HHH emulates its input DD, which calls HHH, and so HHH is emulating itself in a sense.
The HHH's monitor what their emulations are doing and when nested emulations occur the outer HHH
can see what all the inner emulations are doing: what instruction they're executing etc.

HHH looks for a couple of patterns of behaviour in its emulation (together with their nested
emulations), and when it spots one of those patterns it abandons its emulation activity and
straight away returns 0 [=neverhalts].

So he is not "injecting" anything.

Ahhh! So that's where I am going wrong.

HHH is in the process of emulating DD, which is not "running" in the sense that HHH is running;
it's being emulated.  At some point HHH spots its so-called "non-halting pattern" within DD's
nested-emulation trace, and HHH simply stops emulating and returns 0.  On this group that is what
people refer to as HHH "aborts" its emulation of DD, but nothing is injected into DD.  It's not
like DD executing a C abort() call or anything.

Thank you. It seems to me that DD is beholden to HHH? So DD is just reacting to his HHH? I keep
asking Olcott to code up HHH in std C.

You should think of DD as a program built on top of HHH, so that HHH is part of DD's algorithm.
DD's "purpose in life" is to provide a test case for a (partial) halt decider HHH. Logically we
have two HHH's here:

- a proposed halt decider program HHH. We can call the halt decider HHH from main(), e.g.
int main() { if HHH(DD) OutputMessage("HHH says DD halts");
else OutputMessage("HHH says DD never halts");}
- a component of the HHH test case DD. (You can see that DD calls HHH.)

PO's HHH is supposed to "emulate" the computation P() it is called with, and monitor that emulation
for non-halting patterns. If it spots one, it will abandon the emulation and return 0
[=neverhalts]. Note: PO's actual coding of HHH spots what PO /believes/ is a non-halting pattern,
and so returns 0, but as you can see in the DD code, DD then promptly halts, so whatever pattern HHH
spotted, it certainly isn't a non-halting pattern!

You could look at PO's source code for HHH which is on Github, but it is clear enough what such an
HHH must look like, broadly speaking. It needs to perform an "emulation" of P() and monitor that
emulations progress step by step, so there needs to be some "emulation component" that provides the
step by step emulation and provides access to the emulation current state, e.g. providing the
emulations current instruction pointer/registers/virtual memory contents.

Then HHH will look broadly like this:

int HHH(ptr P)
{
EMUCTX ectx = EmuStart (P); // create new emulation, initialised to start
// at first instruction of P
while (IsRunning(&ectx))
{
EmuStep (&ectx); // single step one instruction

EMUREGS eregs = EmuGetRegs (&ectx); // we want to examine emulation's current regs below
char eopcode = EmuGetVMByte (eregs.eip) // probably we want the current instruction opcode
// etc. i.e. HHH gathers what it needs from the emulation current state to decide
// below whether its seen enough to decide P never halts

if (eopcode == 0xCC) // replace with whatever tests are needed to spot non-halting behaviour
// Note: in practice these tests are most of the code of HHH!
// In PO's HHH, this is performed in a subroutine, which
// maintains a trace table of instructions which have been
// emulated so it can spot loops etc.
return 0; // indicating P never halts

// otherwise continue emulating...
}
// ectx indicated the emulated P has ended (P returned)...
return 1; // indicating P halts
}

EMUCTX, EmuStart(), EmuStep() EmuGetRegs() etc. are provided by an imagined API for some suitable
"emulation" component. PO has DebugStep() which is like the EmuStep() above. HHH basically loops
calling EmuStep to advance the emulation one instruction at a time, gathering data it needs to
decide whether P halts, then decides whether its seen enough to abandon the emulation (returning 0)
or continue looping. If the emulation ends naturally (through P() returning), HHH returns 1.

______________
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);
}
______________

So, Halt_Status sure seems to be kinda sorta akin to the value of A$ in my little basic program...?

Bear in mind that HHH is supposed to be at least a partial halt decide that can decide whether
certain computations (represented by parameter P) halt or not. Its return code which is stored in
Halt_Status is supposed to have meaning:
0: P never halts
1: P halts

So it's like your A$, but your A$ represents an external user decision. Halt_Status is HHH's
assessment of whether DD() halts. [PO's HHH returns 0 here, i.e. it decides DD never halts.]

Except instead of asking if it should halt again it goes into a loop HERE: goto HERE;

Right. DD is an implementation of the Linz HP proof's "diagonal" program H^ which corresponds to a
hypothetical halt decider H. The Linz proof explains how, given H, we can construct a new program
H^, which decider H will decide incorrectly. Note that H is given first, /then/ from H Linz
constructs H^ so each different decider will have its own "diagonal" program that it will decide
incorrectly. If we had 3 partial halt deciders H1, H2, H3, they would have different diagonal
programs H1^, H2^, H3^. We can guarantee H2 will decide H2^ incorrectly, but H1 and H3 might decide
H2^ correctly.

HHH is PO's Linz decider H, and DD is Linz's H^.

The clever bit of the HP proof is that when H^ runs, it "invokes the logic of its corresponding
H [from which it was built]" to determine what H would do if asked whether H^ halts. But then H^
promptly behaves in the contrary manner - halting if H(H^) said neverhalts, or looping if H(H^) said
H^ halts. So PO's Halt_Status represents H's decision on whether H^ halts, and from the way H^ was
built from H we can see H's decision was incorrect.

Why does DD have to hook into HHH, code not shown here.. Humm.

The question suggests you're not familiar with the Linz-style proof that no halt decider exists. PO
is trying to show an example of Linz's H and H^ where (contrary to what the proof says) H
/correctly/ decides whether H^ halts. Linz's H is PO's HHH, and Linz's H^ is PO's DD, roughly speaking.

In the Linz proof (based on TMs) H^ has an embedded version of H's logic within itself. That is
quite distinct from H itself, i.e. H and H^ are both (related, but quite distinct) complete TMs in
isolation. Give me a TM H, and Linz says how to edit that to create the new TM H^.

In PO-world using C code and x86 emulation, DD (aka H^) /calls/ HHH to achieve the same thing, but
logically this HHH is a part of DD. Really, to avoid confusion (for himself) PO should have named
DD "DD_HHH". I don't know why PO never shows HHH - I'd guess it's historical, because he didn't
want people closely looking at HHH's implementation and spotting issues like the use of global
variables causing emulated HHH to behave differently to "native" (unemulated) HHH. You know all
PO's source code has subsequently been published on Github, right?

Why can't DD be a stand alone program, say in BASIC created by somebody else, and HHH(DD) tries to
determine if it halts or not?

Ask PO, but mainly I'd say it's down to how PO has approached implementing "emulation". Emulation
is important for PO's argument (at least for PO!). In my "sample" code above I used an API for
emulation I just made up (EmuStart()/EmuStep() and so on). If you use your favourite Basic you'll
have to write that emulation component yourself - and it needs to support recursive emulation, where
an emulation in turn emulates a more deeply nested emulation. PO already had found a x86 emulation
component he could work with (libx86emu) so that drove subsequent design decisions I'd guess.

By all means create your own versions of HHH/DD in basic and present them here! (Starting your own
thread would be best.)

The problem with my BASIC code is that HHH does not know what A$ is going to be per iteration. If
the input A$ is YES it halts, if not it asks the same question again...

In olcotts int Halt_Status = HHH(DD); well, it seems like that is not detecting an infinite
recursion, or infinite loop, it can return anything it wants to?

It is supposed to be deciding halting for DD, hardly anything it wants to!! :) E.g. perhaps when H
emulates P(), it notices that an instruction in P has unconditionally branched to itself.
Excellent! - HHH can abandon the emulation and just return 0, deciding that P never halts. Or it
might observe that the emulated P() has just returned, in which case it will return 1, deciding P
halts. And so on... Of course in the end, HHH might have decided P's halting status correctly or
incorrectly, depending on how it was coded. PO's /idea/ is that HHH should only make /sound/
decisions, guaranteeing correct halting decisions, but his HHH logic is in fact unsound.

Can you envisage how HHH /might/ be coded so that it can detect /certain/ infinite loops? Like the
case I described where P enters a tight loop? PO imagines his HHH is like that, so when it spots
what he calls his "infinite recursive emulation" pattern, that guarantees P does not halt. But that
test is unsound, and actually can match when emulating a /halting/ computation. [As is the case
when PO's HHH decides halting for DD. PO's pattern matches, so HHH decides DD never halts, but when
we just run DD() we see it halts. For the last 3 years all of PO's posts have been variations on PO
explaining why although DD() halts, HHH is still right to decide it never halts, because his pattern
matched!]


One thing you could do is bench-test the "sample" HHH code I suggested above, just on paper. The
details of how emulation works barely matter at this level. You understand "emulation" well enough
to imagine what my EmuStep() would do? Also, the specific "non-halting behaviour tests"
(surprisingly) don't make too much difference to how things go - start by imagining that HHH never
spots any non-halting pattern, and so never abandons its simulation unless it halts by itself, and
go from there. (When "going from there" you'll need to just imagine that some abort test matches at
different points in the emulation and observe the effect... No need to create your own "valid"
abort test, because if you do that correctly it won't match when HHH simulates DD - PO's abort test
only matches because it has a bug causing it to match against certain /halting/ computations...)

Not sure how far you'll get, but you should try. I suggest you could try bench-testing with
emulation at the C source code level [so EmuStep would emulate one C statement]. PO's DebugStep
emulates one x86 instruction, but the outcome will be broadly the same.

Damn. It feels like I am still missing something. Sigh.

Maybe you need to become properly familiar with the HP proof as it is presented in Linz or similar,
with it's "do the opposite of what the decider says" idea? And you need to understand that proof
properly: the order in which dependent definitions are made, the use of "TM-descriptions" as input
strings for deciders, what "contradiction" is encountered and so on. You could read the Linz book
to get all this - at least, the chapter introducing TMs (where notation is also explained) followed
by the section on the Halting Problem proof. (Other authors are available and probably clearer!)
You might find the whole Linz book somewhere as a PDF, although that would be copyrighted so you
couldn't legally download that. Or there must be many other versions of the proof in free course
notes etc...

My ISP used to give me an included GigaNews subscription which went back to somewhere around 2005
I think.  They stopped that as it wasn't in their official offering, but that means now I too only
get about a year's retention now (from free Eternal September server).  I think there are
web-sites archiving usenet posts, and for PO threads, the Google Groups archive will cover them up
to the last year or so when Google disconnected from usenet.

Yeah. Well, it sure seems like damn near the same stuff he is writing about now, with the exception
of a "sycophantic" AI that is stroking his ego? Humm...

Even a news presenter on Sky news (or was it BBC?) used the word "sycophantic" to describe them last
night! Of course PO doesn't like that at all, because it makes his use of chatbots as an Appeal to
Authority look silly! PO's counter is that "they have come on a long way and can now do xxxx,yyyy
etc." but basically he hasn't a clue what their limitations are - he just says whatever he says
because he /wants/ to believe they are some kind of Authority who agrees with him. He can't prove
his points with his own arguments...


Mike.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/21/2025 10:47 AM, Mike Terry wrote:

On 20/10/2025 21:04, Chris M. Thomasson wrote:

[...]

I basically agree with everything you wrote, thanks for taking the time.
I should have some more time tonight, but I did create a little "fuzzer"
in applesoft basic. lol. Not an emulator, that would be easier to code
the BASIC emulator in C:

Fuzzy:

https://www.calormen.com/jsbasic
___________________________
1 HOME
100 REM ct_main
110 PRINT "ct_main"
120 FOR I = 0 TO 2000
130 GOSUB 1000
135 IF RA$ == "HALT!" GOTO 145
136 I = I - 1
140 NEXT I
145 PRINT "HALT!!!"
150 END


1000 REM ct_fuzzer
1010 PRINT "ct_fuzzer"
1020 R0 = INT(RND(12) * 1003)
1025 PRINT R0
1030 GOSUB 2000
1040 RETURN


2000 REM ct_program
2010 PRINT "ct_program"
2020 RA$ = "NOPE!"
2030 IF R0 = 0 THEN RA$ = "HALT!"
2040 RETURN
___________________________


;^) lol.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/21/2025 2:12 PM, Chris M. Thomasson wrote:

On 10/21/2025 10:47 AM, Mike Terry wrote:

On 20/10/2025 21:04, Chris M. Thomasson wrote:

[...]

I basically agree with everything you wrote, thanks for taking the time.
I should have some more time tonight, but I did create a little "fuzzer"
in applesoft basic. lol. Not an emulator, that would be easier to code
the BASIC emulator in C:

[...]

As for recursion, well, I can do that as well in old AppleSoft basic as
well:

https://pastebin.com/raw/Effeg8cK
(raw pastebin link, no ads and shit)

;^)

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/21/2025 2:15 PM, Chris M. Thomasson wrote:

On 10/21/2025 2:12 PM, Chris M. Thomasson wrote:

On 10/21/2025 10:47 AM, Mike Terry wrote:

On 20/10/2025 21:04, Chris M. Thomasson wrote:

[...]

I basically agree with everything you wrote, thanks for taking the
time. I should have some more time tonight, but I did create a little
"fuzzer" in applesoft basic. lol. Not an emulator, that would be
easier to code the BASIC emulator in C:

[...]

As for recursion, well, I can do that as well in old AppleSoft basic as well:

https://pastebin.com/raw/Effeg8cK
(raw pastebin link, no ads and shit)

;^)

A fun fuzzer: It allows for halting multiple times, then says okay, we
"think" we explored ct_program:


1 HOME
100 REM ct_main
110 PRINT "ct_main"
120 FOR I = 0 TO 10
130 GOSUB 1000
135 IF RA$ = "HALT!" GOTO 140
136 I = I - 1
140 NEXT I
145 PRINT "HALT!!!"
150 END


1000 REM ct_fuzzer
1010 PRINT "ct_fuzzer"
1020 R0 = INT(RND(1) * 1003)
1025 PRINT R0
1030 GOSUB 2000
1040 RETURN


2000 REM ct_program
2010 PRINT "ct_program"
2020 RA$ = "NOPE!"
2030 IF R0 = 0 THEN RA$ = "HALT!"
2040 RETURN
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/21/2025 2:37 PM, Chris M. Thomasson wrote:

A fun fuzzer: It allows for halting multiple times, then says okay, we "think" we explored ct_program:[...]

I create a program that says for this target program, it halts. However
this same tool does not work for a slight alteration in the same program?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 21/10/2025 23:03, Chris M. Thomasson wrote:

On 10/21/2025 2:37 PM, Chris M. Thomasson wrote:

A fun fuzzer: It allows for halting multiple times, then says okay, we "think" we explored
ct_program:[...]

I create a program that says for this target program, it halts. However this same tool does not work
for a slight alteration in the same program?

Just so we're on the same page:

1. What program did you create?
2. What is the target program, exactly?
3. What is the alteration you are imagining?


Mike.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/21/2025 4:08 PM, Mike Terry wrote:

On 21/10/2025 23:03, Chris M. Thomasson wrote:

On 10/21/2025 2:37 PM, Chris M. Thomasson wrote:

A fun fuzzer: It allows for halting multiple times, then says okay,
we "think" we explored ct_program:[...]

I create a program that says for this target program, it halts.
However this same tool does not work for a slight alteration in the
same program?

Just so we're on the same page:

1.  What program did you create?
2.  What is the target program, exactly?
3.  What is the alteration you are imagining?

The target program under consideration for the "decider", lol. Anyway, its: ______________________
2000 REM ct_program
2010 PRINT "ct_program"
2020 RA$ = "NOPE!"
2030 IF R0 = 0 THEN RA$ = "HALT!"
2040 RETURN
______________________


The ct_fuzzer that calls into ct_program, well, this can exposes it to
random data...
______________________
1000 REM ct_fuzzer
1010 PRINT "ct_fuzzer"
1020 R0 = INT(RND(1) * 1003)
1025 PRINT R0
1030 GOSUB 2000
1040 RETURN
______________________


ct_main is a driver:
______________________
1 HOME
100 REM ct_main
110 PRINT "ct_main"
120 FOR I = 0 TO 10
130 GOSUB 1000
135 IF RA$ = "HALT!" GOTO 140
136 I = I - 1
140 NEXT I
145 PRINT "HALT!!!"
150 END
______________________


Can the fuzz get to "many different" paths of execution? Humm...


Full program:
________________________
1 HOME
100 REM ct_main
110 PRINT "ct_main"
120 FOR I = 0 TO 10
130 GOSUB 1000
135 IF RA$ = "HALT!" GOTO 140
136 I = I - 1
140 NEXT I
145 PRINT "HALT!!!"
150 END


1000 REM ct_fuzzer
1010 PRINT "ct_fuzzer"
1020 R0 = INT(RND(1) * 1003)
1025 PRINT R0
1030 GOSUB 2000
1040 RETURN


2000 REM ct_program
2010 PRINT "ct_program"
2020 RA$ = "NOPE!"
2030 IF R0 = 0 THEN RA$ = "HALT!"
2040 RETURN
________________________


One can try it out over on:

https://www.calormen.com/jsbasic


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 22/10/2025 00:57, Chris M. Thomasson wrote:

On 10/21/2025 4:08 PM, Mike Terry wrote:

On 21/10/2025 23:03, Chris M. Thomasson wrote:

On 10/21/2025 2:37 PM, Chris M. Thomasson wrote:

A fun fuzzer: It allows for halting multiple times, then says okay, we "think" we explored
ct_program:[...]

I create a program that says for this target program, it halts. However this same tool does not
work for a slight alteration in the same program?

Just so we're on the same page:

1.  What program did you create?
2.  What is the target program, exactly?
3.  What is the alteration you are imagining?

The target program under consideration for the "decider", lol. Anyway, its: ______________________
2000 REM ct_program
2010     PRINT "ct_program"
2020     RA$ = "NOPE!"
2030     IF R0 = 0 THEN RA$ = "HALT!"
2040 RETURN
______________________

The ct_fuzzer that calls into ct_program, well, this can exposes it to random data...
______________________
1000 REM ct_fuzzer
1010     PRINT "ct_fuzzer"
1020     R0 = INT(RND(1) * 1003)
1025     PRINT R0
1030     GOSUB 2000
1040 RETURN
______________________

ct_main is a driver:
______________________
1 HOME
100 REM ct_main
110     PRINT "ct_main"
120     FOR I = 0 TO 10
130         GOSUB 1000
135         IF RA$ = "HALT!" GOTO 140
136         I = I - 1
140     NEXT I
145 PRINT "HALT!!!"
150 END
______________________

Can the fuzz get to "many different" paths of execution? Humm...

Full program:
________________________
1 HOME
100 REM ct_main
110     PRINT "ct_main"
120     FOR I = 0 TO 10
130         GOSUB 1000
135         IF RA$ = "HALT!" GOTO 140
136         I = I - 1
140     NEXT I
145 PRINT "HALT!!!"
150 END

1000 REM ct_fuzzer
1010     PRINT "ct_fuzzer"
1020     R0 = INT(RND(1) * 1003)
1025     PRINT R0
1030     GOSUB 2000
1040 RETURN

2000 REM ct_program
2010     PRINT "ct_program"
2020     RA$ = "NOPE!"
2030     IF R0 = 0 THEN RA$ = "HALT!"
2040 RETURN
________________________

One can try it out over on:

https://www.calormen.com/jsbasic

Sooooo...

ct_program has roughly a 1/1003 chance of setting RA$="HALT!", and the main routine tries to
accumulate 10 of these RA$ settings (ignoring others) before it prints "HALT!!!". We would expect
about 10000 ct_program calls to achieve this, and after much looping (probably around 10000 times!)
that's what we get.

But:

1. Nothing is emulating anything
2. ct_program actually always returns (regardless of what it sets RA$ to)
3. there is no "decider" deciding ct_program that I can see

So all in all it's not really relevant to PO's HHH/DD code! No need to post more examples until you
have all the right bits developed to reproduce PO's counterexample! :)


Mike.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 22/10/2025 01:43, Mike Terry wrote:

On 22/10/2025 00:57, Chris M. Thomasson wrote:

On 10/21/2025 4:08 PM, Mike Terry wrote:

On 21/10/2025 23:03, Chris M. Thomasson wrote:

On 10/21/2025 2:37 PM, Chris M. Thomasson wrote:

A fun fuzzer: It allows for halting multiple times, then says okay, we "think" we explored
ct_program:[...]

I create a program that says for this target program, it halts. However this same tool does not
work for a slight alteration in the same program?

Just so we're on the same page:

1.  What program did you create?
2.  What is the target program, exactly?
3.  What is the alteration you are imagining?

The target program under consideration for the "decider", lol. Anyway, its: >> ______________________
2000 REM ct_program
2010     PRINT "ct_program"
2020     RA$ = "NOPE!"
2030     IF R0 = 0 THEN RA$ = "HALT!"
2040 RETURN
______________________


The ct_fuzzer that calls into ct_program, well, this can exposes it to random data...
______________________
1000 REM ct_fuzzer
1010     PRINT "ct_fuzzer"
1020     R0 = INT(RND(1) * 1003)
1025     PRINT R0
1030     GOSUB 2000
1040 RETURN
______________________


ct_main is a driver:
______________________
1 HOME
100 REM ct_main
110     PRINT "ct_main"
120     FOR I = 0 TO 10
130         GOSUB 1000
135         IF RA$ = "HALT!" GOTO 140
136         I = I - 1
140     NEXT I
145 PRINT "HALT!!!"
150 END
______________________


Can the fuzz get to "many different" paths of execution? Humm...


Full program:
________________________
1 HOME
100 REM ct_main
110     PRINT "ct_main"
120     FOR I = 0 TO 10
130         GOSUB 1000
135         IF RA$ = "HALT!" GOTO 140
136         I = I - 1
140     NEXT I
145 PRINT "HALT!!!"
150 END


1000 REM ct_fuzzer
1010     PRINT "ct_fuzzer"
1020     R0 = INT(RND(1) * 1003)
1025     PRINT R0
1030     GOSUB 2000
1040 RETURN


2000 REM ct_program
2010     PRINT "ct_program"
2020     RA$ = "NOPE!"
2030     IF R0 = 0 THEN RA$ = "HALT!"
2040 RETURN
________________________


One can try it out over on:

https://www.calormen.com/jsbasic

Sooooo...

ct_program has roughly a 1/1003 chance of setting RA$="HALT!", and the main routine tries to
accumulate 10 of these RA$ settings (ignoring others) before it prints "HALT!!!".  We would expect
about 10000 ct_program calls to achieve this, and after much looping (probably around 10000 times!)
that's what we get.

But:

1.  Nothing is emulating anything
2.  ct_program actually always returns (regardless of what it sets RA$ to) 3.  there is no "decider" deciding ct_program that I can see

Also, PO's HHH/DD behave deterministically, as do TMs (for a given input). In the case of PO's DD()
there is no input supplied (like a TM run with a blank tape).

So all in all it's not really relevant to PO's HHH/DD code!  No need to post more examples until you
have all the right bits developed to reproduce PO's counterexample!  :)

Mike.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/21/2025 12:47 PM, Mike Terry wrote:

On 20/10/2025 21:04, Chris M. Thomasson wrote:

On 10/19/2025 8:39 PM, Mike Terry wrote:

On 19/10/2025 20:27, Chris M. Thomasson wrote:

On 10/19/2025 8:12 AM, Tristan Wibberley wrote:

On 19/10/2025 02:08, olcott wrote:

On 10/18/2025 8:03 PM, dart200 wrote:

On 10/18/25 1:44 PM, Chris M. Thomasson wrote:

I asked it:

1 HOME
5 PRINT "The Olcott All-in-One Halt Decider!"
10 INPUT "Shall I halt or not? " ; A$
30 IF A$ = "YES" GOTO 666
40 GOTO 10
666 PRINT "OK!"

Its odd to me. Olcott seems to think he can "detect" a
non-termination condition and just inject something that aborts it. >>>>>

Is that really so? I don't think it looks like that. Alas, I can't get >>>>> old messages from my newsserver any more.

He has mentioned several times about "detecting" a non-halting
condition and having to abort it... Argh!

That would be his "Infinite Recursive Simulation" pattern I guess.
The basic idea is that his decider HHH emulates its input DD, which
calls HHH, and so HHH is emulating itself in a sense. The HHH's
monitor what their emulations are doing and when nested emulations
occur the outer HHH can see what all the inner emulations are doing:
what instruction they're executing etc.

HHH looks for a couple of patterns of behaviour in its emulation
(together with their nested emulations), and when it spots one of
those patterns it abandons its emulation activity and straight away
returns 0 [=neverhalts].

So he is not "injecting" anything.

Ahhh! So that's where I am going wrong.

HHH is in the process of emulating DD, which is not "running" in the
sense that HHH is running; it's being emulated.  At some point HHH
spots its so-called "non-halting pattern" within DD's nested-
emulation trace, and HHH simply stops emulating and returns 0.  On
this group that is what people refer to as HHH "aborts" its emulation
of DD, but nothing is injected into DD.  It's not like DD executing a
C abort() call or anything.

Thank you. It seems to me that DD is beholden to HHH? So DD is just
reacting to his HHH? I keep asking Olcott to code up HHH in std C.

You should think of DD as a program built on top of HHH, so that HHH is
part of DD's algorithm. DD's "purpose in life" is to provide a test case
for a (partial) halt decider HHH.  Logically we have two HHH's here:

- a proposed halt decider program HHH.  We can call the halt decider HHH from main(), e.g.
  int main() { if HHH(DD) OutputMessage("HHH says DD halts");
               else       OutputMessage("HHH says DD never halts");}
- a component of the HHH test case DD.  (You can see that DD calls HHH.)

PO's HHH is supposed to "emulate" the computation P() it is called with,
and monitor that emulation for non-halting patterns.  If it spots one,
it will abandon the emulation and return 0 [=neverhalts].  Note: PO's actual coding of HHH spots what PO /believes/ is a non-halting pattern,

*Five LLM's figured this all out and their own*

<Input to LLM systems>
Please think this all the way through without making any guesses.
Only report on the behavior observed in simulation.

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;
}

int main()
{
HHH(DD);
}

What value should HHH(DD) correctly return?
</Input to LLM systems>
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/21/2025 5:43 PM, Mike Terry wrote:

On 22/10/2025 00:57, Chris M. Thomasson wrote:

On 10/21/2025 4:08 PM, Mike Terry wrote:

On 21/10/2025 23:03, Chris M. Thomasson wrote:

On 10/21/2025 2:37 PM, Chris M. Thomasson wrote:

A fun fuzzer: It allows for halting multiple times, then says okay, >>>>> we "think" we explored ct_program:[...]

I create a program that says for this target program, it halts.
However this same tool does not work for a slight alteration in the
same program?

Just so we're on the same page:

1.  What program did you create?
2.  What is the target program, exactly?
3.  What is the alteration you are imagining?

The target program under consideration for the "decider", lol. Anyway,
its:
______________________
2000 REM ct_program
2010     PRINT "ct_program"
2020     RA$ = "NOPE!"
2030     IF R0 = 0 THEN RA$ = "HALT!"
2040 RETURN
______________________


The ct_fuzzer that calls into ct_program, well, this can exposes it to
random data...
______________________
1000 REM ct_fuzzer
1010     PRINT "ct_fuzzer"
1020     R0 = INT(RND(1) * 1003)
1025     PRINT R0
1030     GOSUB 2000
1040 RETURN
______________________


ct_main is a driver:
______________________
1 HOME
100 REM ct_main
110     PRINT "ct_main"
120     FOR I = 0 TO 10
130         GOSUB 1000
135         IF RA$ = "HALT!" GOTO 140
136         I = I - 1
140     NEXT I
145 PRINT "HALT!!!"
150 END
______________________


Can the fuzz get to "many different" paths of execution? Humm...


Full program:
________________________
1 HOME
100 REM ct_main
110     PRINT "ct_main"
120     FOR I = 0 TO 10
130         GOSUB 1000
135         IF RA$ = "HALT!" GOTO 140
136         I = I - 1
140     NEXT I
145 PRINT "HALT!!!"
150 END


1000 REM ct_fuzzer
1010     PRINT "ct_fuzzer"
1020     R0 = INT(RND(1) * 1003)
1025     PRINT R0
1030     GOSUB 2000
1040 RETURN


2000 REM ct_program
2010     PRINT "ct_program"
2020     RA$ = "NOPE!"
2030     IF R0 = 0 THEN RA$ = "HALT!"
2040 RETURN
________________________


One can try it out over on:

https://www.calormen.com/jsbasic

Sooooo...

ct_program has roughly a 1/1003 chance of setting RA$="HALT!", and the
main routine tries to accumulate 10 of these RA$ settings (ignoring
others) before it prints "HALT!!!".  We would expect about 10000
ct_program calls to achieve this, and after much looping (probably
around 10000 times!) that's what we get.

But:

1.  Nothing is emulating anything
2.  ct_program actually always returns (regardless of what it sets RA$ to) 3.  there is no "decider" deciding ct_program that I can see

So all in all it's not really relevant to PO's HHH/DD code!  No need to post more examples until you have all the right bits developed to
reproduce PO's counterexample!  :)

Ahhh Shit! Thanks. ;^o

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/21/2025 8:00 PM, Chris M. Thomasson wrote:

On 10/21/2025 5:43 PM, Mike Terry wrote:

[...]

So all in all it's not really relevant to PO's HHH/DD code!  No need
to post more examples until you have all the right bits developed to
reproduce PO's counterexample!  :)

Ahhh Shit! Thanks. ;^o

Still pondering on a black box that works for a given target program.
The damn thing can tell if it halts or not. Then the target alters
itself. The black box no longer works, need to a new one. The halt is
not there. We cannot know. shit happens?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/21/2025 8:46 PM, Chris M. Thomasson wrote:

On 10/21/2025 8:00 PM, Chris M. Thomasson wrote:

On 10/21/2025 5:43 PM, Mike Terry wrote:

[...]

So all in all it's not really relevant to PO's HHH/DD code!  No need
to post more examples until you have all the right bits developed to
reproduce PO's counterexample!  :)

Ahhh Shit! Thanks. ;^o

Still pondering on a black box that works for a given target program.
The damn thing can tell if it halts or not. Then the target alters
itself. The black box no longer works, need to a new one. The halt is
not there. We cannot know. shit happens?

Shit I have to code up some shader work now. Will get back to you.

If I can always say this program under consideration shall halt, and be
100% right, then welcome the lullaby? Its solved four our little realm
of programs?

LULLABY Origa:

https://youtu.be/51yVxGvsqiE?list=RDA4J7CwF0JTU


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/20/2025 10:20 PM, Kaz Kylheku wrote:

On 2025-10-21, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 9:11 PM, Kaz Kylheku wrote:

On 2025-10-21, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 8:27 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 4:03 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 1:29 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/19/2025 2:39 PM, Kaz Kylheku wrote:

On 2025-10-19, dart200 <user7160@newsgrouper.org.invalid> wrote: >>>>>>>>>>>> i don't get y polcott keep hanging onto ai for dear life. anyone with

Throngs of dumb boomers are falling for AI generated videos, believing
them to be real. This is much the same thing.

AI is just another thing Olcott has no understanding of. He's not >>>>>>>>>>> researched the fundamentals of what it means to train a language >>>>>>>>>>> network, and how it is ultimately just token prediction. >>>>>>>>>>>
It excels at generating good syntax. The reason for that is that the
vast amount of training data exhibits good syntax. (Where it has bad
syntax, it is idiosyncratic; whereas good syntax is broadly shared.)

I provide a basis to it and it does perform valid
semantic logical entailment on this basis and shows

But you're incapable of recognizing valid entailment from invalid. >>>>>>>>>

Any freaking idiot can spew out baseless rhetoric
such as this. I could do the same sort of thing
and say you are wrong and stupidly wrong.

But you don't?

It is a whole other ballgame when one attempts
to point out actual errors that are not anchored
in one's own lack of comprehension.

You don't comprehend the pointing-out.

You need to have a sound reasoning basis to prove
that an error is an actual error.

No; /YOU/ need to have sound reasonings to prove /YOUR/
extraordinary claims. The burden is on you.

We already have the solid reasoning which says things are other than as >>>>> you say, and you don't have the faintest idea how to put a dent in it. >>>>>

In other words you assume that I must be wrong
entirely on the basis that what I say does not
conform to conventional wisdom.

Yes; you are wrong entirely on the basis that what you say does not
follow a valid mode of inference for refuting an argument.

If you are trying to refute something which is not only a widely
accepted result, but whose reasoning anyone can follow to see it
for themselves, you are automatically assumed wrong.

The established result is presumed correct, pending your
presentation of a convincing argument.

That's not just wanton arbitrariness: your claims are being
directly refuted by elements of the established result which
we can refer to.

I cannot identify any flaw in the halting theorem. It's not simply
that I believe it because of the Big Names attached to it.

And when I identify a flaw yo simply ignore
whatever I say.

Nope; all the ways you say claim you've identified a flaw have been
dissected by multiple poeple to a much greater detail than they deserve.

It is disingenuous to say that you've simply had your details ignored.

Turing machines in general can only compute mappings
from their inputs. The halting problem requires computing
mappings that in some cases are not provided in the
inputs therefore the halting problem is wrong.

Blah, Blah Blah, no Olcott you are wrong, I know
that you are wrong because I simply don't believe you.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/22/2025 7:56 AM, olcott wrote:

On 10/20/2025 10:20 PM, Kaz Kylheku wrote:

On 2025-10-21, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 9:11 PM, Kaz Kylheku wrote:

On 2025-10-21, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 8:27 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 4:03 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 1:29 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/19/2025 2:39 PM, Kaz Kylheku wrote:

On 2025-10-19, dart200 <user7160@newsgrouper.org.invalid> >>>>>>>>>>>> wrote:

i don't get y polcott keep hanging onto ai for dear life. >>>>>>>>>>>>> anyone with

Throngs of dumb boomers are falling for AI generated videos, >>>>>>>>>>>> believing
them to be real. This is much the same thing.

AI is just another thing Olcott has no understanding of. >>>>>>>>>>>> He's not
researched the fundamentals of what it means to train a >>>>>>>>>>>> language
network, and how it is ultimately just token prediction. >>>>>>>>>>>>
It excels at generating good syntax. The reason for that is >>>>>>>>>>>> that the
vast amount of training data exhibits good syntax. (Where it >>>>>>>>>>>> has bad
syntax, it is idiosyncratic; whereas good syntax is broadly >>>>>>>>>>>> shared.)

I provide a basis to it and it does perform valid
semantic logical entailment on this basis and shows

But you're incapable of recognizing valid entailment from >>>>>>>>>> invalid.

Any freaking idiot can spew out baseless rhetoric
such as this. I could do the same sort of thing
and say you are wrong and stupidly wrong.

But you don't?

It is a whole other ballgame when one attempts
to point out actual errors that are not anchored
in one's own lack of comprehension.

You don't comprehend the pointing-out.

You need to have a sound reasoning basis to prove
that an error is an actual error.

No; /YOU/ need to have sound reasonings to prove /YOUR/
extraordinary claims. The burden is on you.

We already have the solid reasoning which says things are other
than as
you say, and you don't have the faintest idea how to put a dent in >>>>>> it.

In other words you assume that I must be wrong
entirely on the basis that what I say does not
conform to conventional wisdom.

Yes; you are wrong entirely on the basis that what you say does not
follow a valid mode of inference for refuting an argument.

If you are trying to refute something which is not only a widely
accepted result, but whose reasoning anyone can follow to see it
for themselves, you are automatically assumed wrong.

The established result is presumed correct, pending your
presentation of a convincing argument.

That's not just wanton arbitrariness: your claims are being
directly refuted by elements of the established result which
we can refer to.

I cannot identify any flaw in the halting theorem. It's not simply
that I believe it because of the Big Names attached to it.

And when I identify a flaw yo simply ignore
whatever I say.

Nope; all the ways you say claim you've identified a flaw have been
dissected by multiple poeple to a much greater detail than they deserve.

It is disingenuous to say that you've simply had your details ignored.

Turing machines in general can only compute mappings
from their inputs. The halting problem requires computing
mappings that in some cases are not provided in the
inputs therefore the halting problem is wrong.

False:

(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/22/2025 7:25 AM, dbush wrote:

On 10/22/2025 7:56 AM, olcott wrote:

On 10/20/2025 10:20 PM, Kaz Kylheku wrote:

On 2025-10-21, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 9:11 PM, Kaz Kylheku wrote:

On 2025-10-21, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 8:27 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 4:03 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 1:29 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/19/2025 2:39 PM, Kaz Kylheku wrote:

On 2025-10-19, dart200 <user7160@newsgrouper.org.invalid> >>>>>>>>>>>>> wrote:

i don't get y polcott keep hanging onto ai for dear life. >>>>>>>>>>>>>> anyone with

Throngs of dumb boomers are falling for AI generated >>>>>>>>>>>>> videos, believing
them to be real. This is much the same thing.

AI is just another thing Olcott has no understanding of. >>>>>>>>>>>>> He's not
researched the fundamentals of what it means to train a >>>>>>>>>>>>> language
network, and how it is ultimately just token prediction. >>>>>>>>>>>>>
It excels at generating good syntax. The reason for that is >>>>>>>>>>>>> that the
vast amount of training data exhibits good syntax. (Where >>>>>>>>>>>>> it has bad
syntax, it is idiosyncratic; whereas good syntax is broadly >>>>>>>>>>>>> shared.)

I provide a basis to it and it does perform valid
semantic logical entailment on this basis and shows

But you're incapable of recognizing valid entailment from >>>>>>>>>>> invalid.

Any freaking idiot can spew out baseless rhetoric
such as this. I could do the same sort of thing
and say you are wrong and stupidly wrong.

But you don't?

It is a whole other ballgame when one attempts
to point out actual errors that are not anchored
in one's own lack of comprehension.

You don't comprehend the pointing-out.

You need to have a sound reasoning basis to prove
that an error is an actual error.

No; /YOU/ need to have sound reasonings to prove /YOUR/
extraordinary claims. The burden is on you.

We already have the solid reasoning which says things are other >>>>>>> than as
you say, and you don't have the faintest idea how to put a dent >>>>>>> in it.

In other words you assume that I must be wrong
entirely on the basis that what I say does not
conform to conventional wisdom.

Yes; you are wrong entirely on the basis that what you say does not
follow a valid mode of inference for refuting an argument.

If you are trying to refute something which is not only a widely
accepted result, but whose reasoning anyone can follow to see it
for themselves, you are automatically assumed wrong.

The established result is presumed correct, pending your
presentation of a convincing argument.

That's not just wanton arbitrariness: your claims are being
directly refuted by elements of the established result which
we can refer to.

I cannot identify any flaw in the halting theorem. It's not simply
that I believe it because of the Big Names attached to it.

And when I identify a flaw yo simply ignore
whatever I say.

Nope; all the ways you say claim you've identified a flaw have been
dissected by multiple poeple to a much greater detail than they deserve. >>>
It is disingenuous to say that you've simply had your details ignored.

Turing machines in general can only compute mappings
from their inputs. The halting problem requires computing
mappings that in some cases are not provided in the
inputs therefore the halting problem is wrong.

False:

(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly

Yes that it the exact error that I have been
referring to.

In the case of HHH(DD) the above requires HHH to
report on the behavior of its caller and HHH has
no way to even know who its caller is.

My simulating halt decider exposed the gap of
false assumptions because there are no assumptions
everything is fully operational code.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/22/2025 8:48 AM, olcott wrote:

On 10/22/2025 7:25 AM, dbush wrote:

On 10/22/2025 7:56 AM, olcott wrote:

On 10/20/2025 10:20 PM, Kaz Kylheku wrote:

On 2025-10-21, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 9:11 PM, Kaz Kylheku wrote:

On 2025-10-21, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 8:27 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 4:03 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 1:29 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/19/2025 2:39 PM, Kaz Kylheku wrote:

On 2025-10-19, dart200 <user7160@newsgrouper.org.invalid> >>>>>>>>>>>>>> wrote:

i don't get y polcott keep hanging onto ai for dear life. >>>>>>>>>>>>>>> anyone with

Throngs of dumb boomers are falling for AI generated >>>>>>>>>>>>>> videos, believing
them to be real. This is much the same thing.

AI is just another thing Olcott has no understanding of. >>>>>>>>>>>>>> He's not
researched the fundamentals of what it means to train a >>>>>>>>>>>>>> language
network, and how it is ultimately just token prediction. >>>>>>>>>>>>>>
It excels at generating good syntax. The reason for that >>>>>>>>>>>>>> is that the
vast amount of training data exhibits good syntax. (Where >>>>>>>>>>>>>> it has bad
syntax, it is idiosyncratic; whereas good syntax is >>>>>>>>>>>>>> broadly shared.)

I provide a basis to it and it does perform valid
semantic logical entailment on this basis and shows

But you're incapable of recognizing valid entailment from >>>>>>>>>>>> invalid.

Any freaking idiot can spew out baseless rhetoric
such as this. I could do the same sort of thing
and say you are wrong and stupidly wrong.

But you don't?

It is a whole other ballgame when one attempts
to point out actual errors that are not anchored
in one's own lack of comprehension.

You don't comprehend the pointing-out.

You need to have a sound reasoning basis to prove
that an error is an actual error.

No; /YOU/ need to have sound reasonings to prove /YOUR/
extraordinary claims. The burden is on you.

We already have the solid reasoning which says things are other >>>>>>>> than as
you say, and you don't have the faintest idea how to put a dent >>>>>>>> in it.

In other words you assume that I must be wrong
entirely on the basis that what I say does not
conform to conventional wisdom.

Yes; you are wrong entirely on the basis that what you say does not >>>>>> follow a valid mode of inference for refuting an argument.

If you are trying to refute something which is not only a widely
accepted result, but whose reasoning anyone can follow to see it
for themselves, you are automatically assumed wrong.

The established result is presumed correct, pending your
presentation of a convincing argument.

That's not just wanton arbitrariness: your claims are being
directly refuted by elements of the established result which
we can refer to.

I cannot identify any flaw in the halting theorem. It's not simply >>>>>> that I believe it because of the Big Names attached to it.

And when I identify a flaw yo simply ignore
whatever I say.

Nope; all the ways you say claim you've identified a flaw have been
dissected by multiple poeple to a much greater detail than they
deserve.

It is disingenuous to say that you've simply had your details ignored. >>>>

Turing machines in general can only compute mappings
from their inputs. The halting problem requires computing
mappings that in some cases are not provided in the
inputs therefore the halting problem is wrong.

False:

(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly

Yes that it the exact error that I have been
referring to.

That is not an error. That is simply a mapping that you have admitted
exists.

In the case of HHH(DD) the above requires HHH to
report on the behavior of its caller

False. It requires HHH to report on the behavior of the machine
described by its input.

int main {
DD() // this
HHH(DD) // is not the caller of this
return 0;
}

and HHH has
no way to even know who its caller is.

Irrelevant.

My simulating halt decider

in other words, something that uses simulation to compute the following mapping:


Given any algorithm (i.e. a fixed immutable sequence of instructions) X described as <X> with input Y:

A solution to the halting problem is an algorithm H that computes the following mapping:

(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly

exposed the gap of
false assumptions

The only false assumption is that the above requirements can be
satisfied, which Turing and Linz proved to be false and that you have *explicitly* agreed with.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

Am Wed, 22 Oct 2025 07:48:51 -0500 schrieb olcott:

On 10/22/2025 7:25 AM, dbush wrote:

On 10/22/2025 7:56 AM, olcott wrote:

Turing machines in general can only compute mappings from their
inputs. The halting problem requires computing mappings that in some
cases are not provided in the inputs therefore the halting problem is
wrong.

False:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly

Yes that it the exact error that I have been referring to.
In the case of HHH(DD) the above requires HHH to report on the behavior
of its caller and HHH has no way to even know who its caller is.
My simulating halt decider exposed the gap of false assumptions because
there are no assumptions everything is fully operational code.

What assumption? HHH should report on the behaviour of its input,
wherever it is called from.
--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/22/2025 8:34 AM, joes wrote:

Am Wed, 22 Oct 2025 07:48:51 -0500 schrieb olcott:

On 10/22/2025 7:25 AM, dbush wrote:

On 10/22/2025 7:56 AM, olcott wrote:

Turing machines in general can only compute mappings from their
inputs. The halting problem requires computing mappings that in some
cases are not provided in the inputs therefore the halting problem is
wrong.

False:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly

Yes that it the exact error that I have been referring to.
In the case of HHH(DD) the above requires HHH to report on the behavior
of its caller and HHH has no way to even know who its caller is.
My simulating halt decider exposed the gap of false assumptions because
there are no assumptions everything is fully operational code.

What assumption? HHH should report on the behaviour of its input,
wherever it is called from.

The behavior of the input to HHH(DD) includes
the behavior of HHH because DD calls HHH(DD)
in recursive simulation. All of the LLM systems
immediately understood this.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/22/2025 9:43 AM, olcott wrote:

On 10/22/2025 8:34 AM, joes wrote:

Am Wed, 22 Oct 2025 07:48:51 -0500 schrieb olcott:

On 10/22/2025 7:25 AM, dbush wrote:

On 10/22/2025 7:56 AM, olcott wrote:

Turing machines in general can only compute mappings from their
inputs. The halting problem requires computing mappings that in some >>>>> cases are not provided in the inputs therefore the halting problem is >>>>> wrong.

False:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly

Yes that it the exact error that I have been referring to.
In the case of HHH(DD) the above requires HHH to report on the behavior
of its caller and HHH has no way to even know who its caller is.
My simulating halt decider exposed the gap of false assumptions because
there are no assumptions everything is fully operational code.

What assumption? HHH should report on the behaviour of its input,
wherever it is called from.

The behavior of the input to HHH(DD) includes
the behavior of HHH because DD calls HHH(DD)
in recursive simulation. All of the LLM systems
immediately understood this.

And therefore the above mapping maps finite string DD, which is defined
to be <DD> i.e. the description of machine DD, to 1 i.e. halting.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/22/2025 8:00 AM, dbush wrote:

On 10/22/2025 8:48 AM, olcott wrote:

On 10/22/2025 7:25 AM, dbush wrote:

On 10/22/2025 7:56 AM, olcott wrote:

On 10/20/2025 10:20 PM, Kaz Kylheku wrote:

On 2025-10-21, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 9:11 PM, Kaz Kylheku wrote:

On 2025-10-21, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 8:27 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 4:03 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 1:29 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>> On 10/19/2025 2:39 PM, Kaz Kylheku wrote:

On 2025-10-19, dart200 <user7160@newsgrouper.org.invalid> >>>>>>>>>>>>>>> wrote:

i don't get y polcott keep hanging onto ai for dear >>>>>>>>>>>>>>>> life. anyone with

Throngs of dumb boomers are falling for AI generated >>>>>>>>>>>>>>> videos, believing
them to be real. This is much the same thing.

AI is just another thing Olcott has no understanding of. >>>>>>>>>>>>>>> He's not
researched the fundamentals of what it means to train a >>>>>>>>>>>>>>> language
network, and how it is ultimately just token prediction. >>>>>>>>>>>>>>>
It excels at generating good syntax. The reason for that >>>>>>>>>>>>>>> is that the
vast amount of training data exhibits good syntax. (Where >>>>>>>>>>>>>>> it has bad
syntax, it is idiosyncratic; whereas good syntax is >>>>>>>>>>>>>>> broadly shared.)

I provide a basis to it and it does perform valid
semantic logical entailment on this basis and shows >>>>>>>>>>>>>

But you're incapable of recognizing valid entailment from >>>>>>>>>>>>> invalid.

Any freaking idiot can spew out baseless rhetoric
such as this. I could do the same sort of thing
and say you are wrong and stupidly wrong.

But you don't?

It is a whole other ballgame when one attempts
to point out actual errors that are not anchored
in one's own lack of comprehension.

You don't comprehend the pointing-out.

You need to have a sound reasoning basis to prove
that an error is an actual error.

No; /YOU/ need to have sound reasonings to prove /YOUR/
extraordinary claims. The burden is on you.

We already have the solid reasoning which says things are other >>>>>>>>> than as
you say, and you don't have the faintest idea how to put a dent >>>>>>>>> in it.

In other words you assume that I must be wrong
entirely on the basis that what I say does not
conform to conventional wisdom.

Yes; you are wrong entirely on the basis that what you say does not >>>>>>> follow a valid mode of inference for refuting an argument.

If you are trying to refute something which is not only a widely >>>>>>> accepted result, but whose reasoning anyone can follow to see it >>>>>>> for themselves, you are automatically assumed wrong.

The established result is presumed correct, pending your
presentation of a convincing argument.

That's not just wanton arbitrariness: your claims are being
directly refuted by elements of the established result which
we can refer to.

I cannot identify any flaw in the halting theorem. It's not simply >>>>>>> that I believe it because of the Big Names attached to it.

And when I identify a flaw yo simply ignore
whatever I say.

Nope; all the ways you say claim you've identified a flaw have been
dissected by multiple poeple to a much greater detail than they
deserve.

It is disingenuous to say that you've simply had your details ignored. >>>>>

Turing machines in general can only compute mappings
from their inputs. The halting problem requires computing
mappings that in some cases are not provided in the
inputs therefore the halting problem is wrong.

False:

(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly

Yes that it the exact error that I have been
referring to.

That is not an error.  That is simply a mapping that you have admitted exists.

In the case of HHH(DD) the above requires HHH to
report on the behavior of its caller

False.  It requires HHH to report on the behavior of the machine
described by its input.

That includes that DD calls HHH(DD) in recursive
simulation.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/22/2025 9:47 AM, olcott wrote:

On 10/22/2025 8:00 AM, dbush wrote:

On 10/22/2025 8:48 AM, olcott wrote:

On 10/22/2025 7:25 AM, dbush wrote:

On 10/22/2025 7:56 AM, olcott wrote:

On 10/20/2025 10:20 PM, Kaz Kylheku wrote:

On 2025-10-21, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 9:11 PM, Kaz Kylheku wrote:

On 2025-10-21, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 8:27 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 4:03 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 1:29 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>> On 10/19/2025 2:39 PM, Kaz Kylheku wrote:

On 2025-10-19, dart200
<user7160@newsgrouper.org.invalid> wrote:

i don't get y polcott keep hanging onto ai for dear >>>>>>>>>>>>>>>>> life. anyone with

Throngs of dumb boomers are falling for AI generated >>>>>>>>>>>>>>>> videos, believing
them to be real. This is much the same thing.

AI is just another thing Olcott has no understanding of. >>>>>>>>>>>>>>>> He's not
researched the fundamentals of what it means to train a >>>>>>>>>>>>>>>> language
network, and how it is ultimately just token prediction. >>>>>>>>>>>>>>>>
It excels at generating good syntax. The reason for that >>>>>>>>>>>>>>>> is that the
vast amount of training data exhibits good syntax. >>>>>>>>>>>>>>>> (Where it has bad
syntax, it is idiosyncratic; whereas good syntax is >>>>>>>>>>>>>>>> broadly shared.)

I provide a basis to it and it does perform valid >>>>>>>>>>>>>>> semantic logical entailment on this basis and shows >>>>>>>>>>>>>>

But you're incapable of recognizing valid entailment from >>>>>>>>>>>>>> invalid.

Any freaking idiot can spew out baseless rhetoric
such as this. I could do the same sort of thing
and say you are wrong and stupidly wrong.

But you don't?

It is a whole other ballgame when one attempts
to point out actual errors that are not anchored
in one's own lack of comprehension.

You don't comprehend the pointing-out.

You need to have a sound reasoning basis to prove
that an error is an actual error.

No; /YOU/ need to have sound reasonings to prove /YOUR/
extraordinary claims. The burden is on you.

We already have the solid reasoning which says things are >>>>>>>>>> other than as
you say, and you don't have the faintest idea how to put a >>>>>>>>>> dent in it.

In other words you assume that I must be wrong
entirely on the basis that what I say does not
conform to conventional wisdom.

Yes; you are wrong entirely on the basis that what you say does not >>>>>>>> follow a valid mode of inference for refuting an argument.

If you are trying to refute something which is not only a widely >>>>>>>> accepted result, but whose reasoning anyone can follow to see it >>>>>>>> for themselves, you are automatically assumed wrong.

The established result is presumed correct, pending your
presentation of a convincing argument.

That's not just wanton arbitrariness: your claims are being
directly refuted by elements of the established result which
we can refer to.

I cannot identify any flaw in the halting theorem. It's not simply >>>>>>>> that I believe it because of the Big Names attached to it.

And when I identify a flaw yo simply ignore
whatever I say.

Nope; all the ways you say claim you've identified a flaw have been >>>>>> dissected by multiple poeple to a much greater detail than they
deserve.

It is disingenuous to say that you've simply had your details
ignored.

Turing machines in general can only compute mappings
from their inputs. The halting problem requires computing
mappings that in some cases are not provided in the
inputs therefore the halting problem is wrong.

False:

(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly

Yes that it the exact error that I have been
referring to.

That is not an error.  That is simply a mapping that you have admitted
exists.

In the case of HHH(DD) the above requires HHH to
report on the behavior of its caller

False.  It requires HHH to report on the behavior of the machine
described by its input.

That includes that DD calls HHH(DD) in recursive
simulation.

Which therefore includes the fact that HHH(DD) will return 0 and that DD
will subsequently halt.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/22/2025 8:50 AM, dbush wrote:

On 10/22/2025 9:47 AM, olcott wrote:

On 10/22/2025 8:00 AM, dbush wrote:

On 10/22/2025 8:48 AM, olcott wrote:

On 10/22/2025 7:25 AM, dbush wrote:

On 10/22/2025 7:56 AM, olcott wrote:

On 10/20/2025 10:20 PM, Kaz Kylheku wrote:

On 2025-10-21, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 9:11 PM, Kaz Kylheku wrote:

On 2025-10-21, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 8:27 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 4:03 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>> On 10/20/2025 1:29 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>> On 10/19/2025 2:39 PM, Kaz Kylheku wrote:

On 2025-10-19, dart200
<user7160@newsgrouper.org.invalid> wrote:

i don't get y polcott keep hanging onto ai for dear >>>>>>>>>>>>>>>>>> life. anyone with

Throngs of dumb boomers are falling for AI generated >>>>>>>>>>>>>>>>> videos, believing
them to be real. This is much the same thing. >>>>>>>>>>>>>>>>>
AI is just another thing Olcott has no understanding >>>>>>>>>>>>>>>>> of. He's not
researched the fundamentals of what it means to train a >>>>>>>>>>>>>>>>> language
network, and how it is ultimately just token prediction. >>>>>>>>>>>>>>>>>
It excels at generating good syntax. The reason for >>>>>>>>>>>>>>>>> that is that the
vast amount of training data exhibits good syntax. >>>>>>>>>>>>>>>>> (Where it has bad
syntax, it is idiosyncratic; whereas good syntax is >>>>>>>>>>>>>>>>> broadly shared.)

I provide a basis to it and it does perform valid >>>>>>>>>>>>>>>> semantic logical entailment on this basis and shows >>>>>>>>>>>>>>>

But you're incapable of recognizing valid entailment from >>>>>>>>>>>>>>> invalid.

Any freaking idiot can spew out baseless rhetoric
such as this. I could do the same sort of thing
and say you are wrong and stupidly wrong.

But you don't?

It is a whole other ballgame when one attempts
to point out actual errors that are not anchored
in one's own lack of comprehension.

You don't comprehend the pointing-out.

You need to have a sound reasoning basis to prove
that an error is an actual error.

No; /YOU/ need to have sound reasonings to prove /YOUR/
extraordinary claims. The burden is on you.

We already have the solid reasoning which says things are >>>>>>>>>>> other than as
you say, and you don't have the faintest idea how to put a >>>>>>>>>>> dent in it.

In other words you assume that I must be wrong
entirely on the basis that what I say does not
conform to conventional wisdom.

Yes; you are wrong entirely on the basis that what you say does >>>>>>>>> not
follow a valid mode of inference for refuting an argument.

If you are trying to refute something which is not only a widely >>>>>>>>> accepted result, but whose reasoning anyone can follow to see it >>>>>>>>> for themselves, you are automatically assumed wrong.

The established result is presumed correct, pending your
presentation of a convincing argument.

That's not just wanton arbitrariness: your claims are being
directly refuted by elements of the established result which >>>>>>>>> we can refer to.

I cannot identify any flaw in the halting theorem. It's not simply >>>>>>>>> that I believe it because of the Big Names attached to it.

And when I identify a flaw yo simply ignore
whatever I say.

Nope; all the ways you say claim you've identified a flaw have been >>>>>>> dissected by multiple poeple to a much greater detail than they >>>>>>> deserve.

It is disingenuous to say that you've simply had your details
ignored.

Turing machines in general can only compute mappings
from their inputs. The halting problem requires computing
mappings that in some cases are not provided in the
inputs therefore the halting problem is wrong.

False:

(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly

Yes that it the exact error that I have been
referring to.

That is not an error.  That is simply a mapping that you have
admitted exists.

In the case of HHH(DD) the above requires HHH to
report on the behavior of its caller

False.  It requires HHH to report on the behavior of the machine
described by its input.

That includes that DD calls HHH(DD) in recursive
simulation.

Which therefore includes the fact that HHH(DD) will return 0 and that DD will subsequently halt.

You keep ignoring that we are only focusing on
DD correctly simulated by HHH. In other words
the behavior that HHH computes
FROM ITS ACTUAL FREAKING INPUT NOT ANY OTHER DAMN THING
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

Am Wed, 22 Oct 2025 09:25:15 -0500 schrieb olcott:

On 10/22/2025 8:50 AM, dbush wrote:

On 10/22/2025 9:47 AM, olcott wrote:

On 10/22/2025 8:00 AM, dbush wrote:

False.  It requires HHH to report on the behavior of the machine
described by its input.

That includes that DD calls HHH(DD) in recursive simulation.

Which therefore includes the fact that HHH(DD) will return 0 and that
DD will subsequently halt.

You keep ignoring that we are only focusing on DD correctly simulated by
HHH. In other words the behavior that HHH computes FROM ITS ACTUAL
FREAKING INPUT NOT ANY OTHER DAMN THING

HHH should not compute DD to call a nonterminating simulator.
--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/22/2025 10:04 AM, joes wrote:

Am Wed, 22 Oct 2025 09:25:15 -0500 schrieb olcott:

On 10/22/2025 8:50 AM, dbush wrote:

On 10/22/2025 9:47 AM, olcott wrote:

On 10/22/2025 8:00 AM, dbush wrote:

False.  It requires HHH to report on the behavior of the machine
described by its input.

That includes that DD calls HHH(DD) in recursive simulation.

Which therefore includes the fact that HHH(DD) will return 0 and that
DD will subsequently halt.

You keep ignoring that we are only focusing on DD correctly simulated by
HHH. In other words the behavior that HHH computes FROM ITS ACTUAL
FREAKING INPUT NOT ANY OTHER DAMN THING

HHH should not compute DD to call a nonterminating simulator.

The code specifies what it actually specifies
we are not playing any game of make pretend here.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

Am Wed, 22 Oct 2025 10:08:05 -0500 schrieb olcott:

On 10/22/2025 10:04 AM, joes wrote:

Am Wed, 22 Oct 2025 09:25:15 -0500 schrieb olcott:

On 10/22/2025 8:50 AM, dbush wrote:

On 10/22/2025 9:47 AM, olcott wrote:

On 10/22/2025 8:00 AM, dbush wrote:

Which therefore includes the fact that HHH(DD) will return 0 and that
DD will subsequently halt.

You keep ignoring that we are only focusing on DD correctly simulated
by HHH. In other words the behavior that HHH computes FROM ITS ACTUAL
FREAKING INPUT NOT ANY OTHER DAMN THING

HHH should not compute DD to call a nonterminating simulator.

The code specifies what it actually specifies we are not playing any
game of make pretend here.

The code of DD specifies a returning call.
--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-10-22, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 10:20 PM, Kaz Kylheku wrote:

And when I identify a flaw yo simply ignore
whatever I say.

Nope; all the ways you say claim you've identified a flaw have been
dissected by multiple poeple to a much greater detail than they deserve.

It is disingenuous to say that you've simply had your details ignored.

Turing machines in general can only compute mappings
from their inputs. The halting problem requires computing
mappings that in some cases are not provided in the
inputs therefore the halting problem is wrong.

The halting problem positively does not propose anything
like that, which would be gapingly wrong.

Blah, Blah Blah, no Olcott you are wrong, I know
that you are wrong because I simply don't believe you.

You are wrong because I (1) don't see that gaping flaw in the
definition of the halting problem, (2) you don't even
try to explain how such that flaw can be. Where, how, why
is any decider being asked to decide something other than
an input representable as a finite string.

I've repeated many times that the diagonal case is constructable as a
finite string, whose halting status can be readily ascertained.

Because it's obvious to me, of course I'm going to reject
baseless claims that simply ask me to /believe/ otherwise.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/22/2025 10:38 AM, joes wrote:

Am Wed, 22 Oct 2025 10:08:05 -0500 schrieb olcott:

On 10/22/2025 10:04 AM, joes wrote:

Am Wed, 22 Oct 2025 09:25:15 -0500 schrieb olcott:

On 10/22/2025 8:50 AM, dbush wrote:

On 10/22/2025 9:47 AM, olcott wrote:

On 10/22/2025 8:00 AM, dbush wrote:

Which therefore includes the fact that HHH(DD) will return 0 and that >>>>> DD will subsequently halt.

You keep ignoring that we are only focusing on DD correctly simulated
by HHH. In other words the behavior that HHH computes FROM ITS ACTUAL
FREAKING INPUT NOT ANY OTHER DAMN THING

HHH should not compute DD to call a nonterminating simulator.

The code specifies what it actually specifies we are not playing any
game of make pretend here.

The code of DD specifies a returning call.

It may seem that way if you don't know how to do an
execution trace of DD simulated by HHH.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/22/2025 10:40 AM, Kaz Kylheku wrote:

On 2025-10-22, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 10:20 PM, Kaz Kylheku wrote:

And when I identify a flaw yo simply ignore
whatever I say.

Nope; all the ways you say claim you've identified a flaw have been
dissected by multiple poeple to a much greater detail than they deserve. >>>
It is disingenuous to say that you've simply had your details ignored.

Turing machines in general can only compute mappings
from their inputs. The halting problem requires computing
mappings that in some cases are not provided in the
inputs therefore the halting problem is wrong.

The halting problem positively does not propose anything
like that, which would be gapingly wrong.

It only seems that way because you are unable to
provide the actual mapping that the actual input
to HHH(DD) specifies when DD is simulated by HHH
according to the semantics of the C language,
even though I do remember that you did do this once.

No sense moving on to any other point until
mutual agreement on this mandatory prerequisite.

Blah, Blah Blah, no Olcott you are wrong, I know
that you are wrong because I simply don't believe you.

You are wrong because I (1) don't see that gaping flaw in the
definition of the halting problem, (2) you don't even
try to explain how such that flaw can be. Where, how, why
is any decider being asked to decide something other than
an input representable as a finite string.

I've repeated many times that the diagonal case is constructable as a
finite string, whose halting status can be readily ascertained.

Because it's obvious to me, of course I'm going to reject
baseless claims that simply ask me to /believe/ otherwise.

--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

Am Wed, 22 Oct 2025 10:40:29 -0500 schrieb olcott:

On 10/22/2025 10:38 AM, joes wrote:

Am Wed, 22 Oct 2025 10:08:05 -0500 schrieb olcott:

On 10/22/2025 10:04 AM, joes wrote:

Am Wed, 22 Oct 2025 09:25:15 -0500 schrieb olcott:

On 10/22/2025 8:50 AM, dbush wrote:

On 10/22/2025 9:47 AM, olcott wrote:

You keep ignoring that we are only focusing on DD correctly
simulated by HHH. In other words the behavior that HHH computes FROM >>>>> ITS ACTUAL FREAKING INPUT NOT ANY OTHER DAMN THING

HHH should not compute DD to call a nonterminating simulator.

The code specifies what it actually specifies we are not playing any
game of make pretend here.

The code of DD specifies a returning call.

It may seem that way if you don't know how to do an execution trace of
DD simulated by HHH.

I know what the trace looks like. It’s just that HHH is wrong to assume
that a call to HHH doesn’t return.
--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/22/2025 10:53 AM, joes wrote:

Am Wed, 22 Oct 2025 10:40:29 -0500 schrieb olcott:

On 10/22/2025 10:38 AM, joes wrote:

Am Wed, 22 Oct 2025 10:08:05 -0500 schrieb olcott:

On 10/22/2025 10:04 AM, joes wrote:

Am Wed, 22 Oct 2025 09:25:15 -0500 schrieb olcott:

On 10/22/2025 8:50 AM, dbush wrote:

On 10/22/2025 9:47 AM, olcott wrote:

You keep ignoring that we are only focusing on DD correctly
simulated by HHH. In other words the behavior that HHH computes FROM >>>>>> ITS ACTUAL FREAKING INPUT NOT ANY OTHER DAMN THING

HHH should not compute DD to call a nonterminating simulator.

The code specifies what it actually specifies we are not playing any
game of make pretend here.

The code of DD specifies a returning call.

It may seem that way if you don't know how to do an execution trace of
DD simulated by HHH.

I know what the trace looks like. It’s just that HHH is wrong to assume that a call to HHH doesn’t return.

Yes it is wrong the same way that 2 + 3 = 5 is wrong
when you don't know how to do arithmetic. It seems
that you don't have any clue about actual computer
programming and the most that you know about computer
science is skimming at least one website.

You may know much more than this yet are not in
any way showing that you know much more than this.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-10-22, olcott <polcott333@gmail.com> wrote:

On 10/22/2025 10:40 AM, Kaz Kylheku wrote:

On 2025-10-22, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 10:20 PM, Kaz Kylheku wrote:

And when I identify a flaw yo simply ignore
whatever I say.

Nope; all the ways you say claim you've identified a flaw have been
dissected by multiple poeple to a much greater detail than they deserve. >>>>
It is disingenuous to say that you've simply had your details ignored. >>>>

Turing machines in general can only compute mappings
from their inputs. The halting problem requires computing
mappings that in some cases are not provided in the
inputs therefore the halting problem is wrong.

The halting problem positively does not propose anything
like that, which would be gapingly wrong.

It only seems that way because you are unable to

No, it doesn't only seem that way. Thanks for playing.

provide the actual mapping that the actual input
to HHH(DD) specifies when DD is simulated by HHH
according to the semantics of the C language,

DD is a "finite string input" which specifies a behavior that is
independent of what simulates it, and in what manner.

When DD is simulated by HHH, the simulation is left incomplete.

That is not permitted by the semantics of the source
or target language in which DD is written;
an incomplete simulation is an incorrect simulation.

Thus, DD being simulated by HHH according to the semantics. The
semantics say that there is a next statement or instruction to execute,
which HHH neglects to do.

Now that would be fine, because HHH's job isn't to evoke the
full behavior of DD but only to predict whether it will halt.

But HHH does that incorrectly; the correct halting status is 1,
not 0.

Thus HHH achieves neither a correct simulation, nor a correct
appraisal of the halting status.

even though I do remember that you did do this once.

I must have accidentally written something that looked
like crackpottery.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/22/2025 12:07 PM, Kaz Kylheku wrote:

On 2025-10-22, olcott <polcott333@gmail.com> wrote:

On 10/22/2025 10:40 AM, Kaz Kylheku wrote:

On 2025-10-22, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 10:20 PM, Kaz Kylheku wrote:

And when I identify a flaw yo simply ignore
whatever I say.

Nope; all the ways you say claim you've identified a flaw have been
dissected by multiple poeple to a much greater detail than they deserve. >>>>>
It is disingenuous to say that you've simply had your details ignored. >>>>>

Turing machines in general can only compute mappings
from their inputs. The halting problem requires computing
mappings that in some cases are not provided in the
inputs therefore the halting problem is wrong.

The halting problem positively does not propose anything
like that, which would be gapingly wrong.

It only seems that way because you are unable to

No, it doesn't only seem that way. Thanks for playing.

provide the actual mapping that the actual input
to HHH(DD) specifies when DD is simulated by HHH
according to the semantics of the C language,

DD is a "finite string input" which specifies a behavior that is
independent of what simulates it,

That is stupidly incorrect.
That DD calls HHH(DD) (its own simulator) IS PART OF
THE BEHAVIOR THAT THE INPUT TO HHH(DD) SPECIFIES.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/22/2025 10:25 AM, olcott wrote:

On 10/22/2025 8:50 AM, dbush wrote:

On 10/22/2025 9:47 AM, olcott wrote:

On 10/22/2025 8:00 AM, dbush wrote:

On 10/22/2025 8:48 AM, olcott wrote:

On 10/22/2025 7:25 AM, dbush wrote:

On 10/22/2025 7:56 AM, olcott wrote:

On 10/20/2025 10:20 PM, Kaz Kylheku wrote:

On 2025-10-21, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 9:11 PM, Kaz Kylheku wrote:

On 2025-10-21, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 8:27 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 4:03 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>> On 10/20/2025 1:29 PM, Kaz Kylheku wrote:

On 2025-10-20, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>>>> On 10/19/2025 2:39 PM, Kaz Kylheku wrote:

On 2025-10-19, dart200
<user7160@newsgrouper.org.invalid> wrote: >>>>>>>>>>>>>>>>>>> i don't get y polcott keep hanging onto ai for dear >>>>>>>>>>>>>>>>>>> life. anyone with

Throngs of dumb boomers are falling for AI generated >>>>>>>>>>>>>>>>>> videos, believing
them to be real. This is much the same thing. >>>>>>>>>>>>>>>>>>
AI is just another thing Olcott has no understanding >>>>>>>>>>>>>>>>>> of. He's not
researched the fundamentals of what it means to train >>>>>>>>>>>>>>>>>> a language
network, and how it is ultimately just token prediction. >>>>>>>>>>>>>>>>>>
It excels at generating good syntax. The reason for >>>>>>>>>>>>>>>>>> that is that the
vast amount of training data exhibits good syntax. >>>>>>>>>>>>>>>>>> (Where it has bad
syntax, it is idiosyncratic; whereas good syntax is >>>>>>>>>>>>>>>>>> broadly shared.)

I provide a basis to it and it does perform valid >>>>>>>>>>>>>>>>> semantic logical entailment on this basis and shows >>>>>>>>>>>>>>>>

But you're incapable of recognizing valid entailment >>>>>>>>>>>>>>>> from invalid.

Any freaking idiot can spew out baseless rhetoric >>>>>>>>>>>>>>> such as this. I could do the same sort of thing
and say you are wrong and stupidly wrong.

But you don't?

It is a whole other ballgame when one attempts
to point out actual errors that are not anchored >>>>>>>>>>>>>>> in one's own lack of comprehension.

You don't comprehend the pointing-out.

You need to have a sound reasoning basis to prove
that an error is an actual error.

No; /YOU/ need to have sound reasonings to prove /YOUR/ >>>>>>>>>>>> extraordinary claims. The burden is on you.

We already have the solid reasoning which says things are >>>>>>>>>>>> other than as
you say, and you don't have the faintest idea how to put a >>>>>>>>>>>> dent in it.

In other words you assume that I must be wrong
entirely on the basis that what I say does not
conform to conventional wisdom.

Yes; you are wrong entirely on the basis that what you say >>>>>>>>>> does not
follow a valid mode of inference for refuting an argument. >>>>>>>>>>
If you are trying to refute something which is not only a widely >>>>>>>>>> accepted result, but whose reasoning anyone can follow to see it >>>>>>>>>> for themselves, you are automatically assumed wrong.

The established result is presumed correct, pending your
presentation of a convincing argument.

That's not just wanton arbitrariness: your claims are being >>>>>>>>>> directly refuted by elements of the established result which >>>>>>>>>> we can refer to.

I cannot identify any flaw in the halting theorem. It's not >>>>>>>>>> simply
that I believe it because of the Big Names attached to it. >>>>>>>>>>

And when I identify a flaw yo simply ignore
whatever I say.

Nope; all the ways you say claim you've identified a flaw have been >>>>>>>> dissected by multiple poeple to a much greater detail than they >>>>>>>> deserve.

It is disingenuous to say that you've simply had your details >>>>>>>> ignored.

Turing machines in general can only compute mappings
from their inputs. The halting problem requires computing
mappings that in some cases are not provided in the
inputs therefore the halting problem is wrong.

False:

(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly >>>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed >>>>>> directly

Yes that it the exact error that I have been
referring to.

That is not an error.  That is simply a mapping that you have
admitted exists.

In the case of HHH(DD) the above requires HHH to
report on the behavior of its caller

False.  It requires HHH to report on the behavior of the machine
described by its input.

That includes that DD calls HHH(DD) in recursive
simulation.

Which therefore includes the fact that HHH(DD) will return 0 and that
DD will subsequently halt.

You keep ignoring that we are only focusing on
DD correctly simulated by HHH.

Which doesn't exist because HHH aborts.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/22/2025 11:47 AM, olcott wrote:

On 10/22/2025 10:40 AM, Kaz Kylheku wrote:

On 2025-10-22, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 10:20 PM, Kaz Kylheku wrote:

And when I identify a flaw yo simply ignore
whatever I say.

Nope; all the ways you say claim you've identified a flaw have been
dissected by multiple poeple to a much greater detail than they
deserve.

It is disingenuous to say that you've simply had your details ignored. >>>>

Turing machines in general can only compute mappings
from their inputs. The halting problem requires computing
mappings that in some cases are not provided in the
inputs therefore the halting problem is wrong.

The halting problem positively does not propose anything
like that, which would be gapingly wrong.

It only seems that way because you are unable to
provide the actual mapping that the actual input
to HHH(DD) specifies when DD is simulated by HHH
according to the semantics of the C language,

Then you have no mapping since DD is NOT simulated by HHH according to
the semantics of the C language because HHH aborts.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/22/2025 1:11 PM, olcott wrote:

On 10/22/2025 12:07 PM, Kaz Kylheku wrote:

On 2025-10-22, olcott <polcott333@gmail.com> wrote:

On 10/22/2025 10:40 AM, Kaz Kylheku wrote:

On 2025-10-22, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 10:20 PM, Kaz Kylheku wrote:

And when I identify a flaw yo simply ignore
whatever I say.

Nope; all the ways you say claim you've identified a flaw have been >>>>>> dissected by multiple poeple to a much greater detail than they
deserve.

It is disingenuous to say that you've simply had your details
ignored.

Turing machines in general can only compute mappings
from their inputs. The halting problem requires computing
mappings that in some cases are not provided in the
inputs therefore the halting problem is wrong.

The halting problem positively does not propose anything
like that, which would be gapingly wrong.

It only seems that way because you are unable to

No, it doesn't only seem that way. Thanks for playing.

provide the actual mapping that the actual input
to HHH(DD) specifies when DD is simulated by HHH
according to the semantics of the C language,

DD is a "finite string input" which specifies a behavior that is
independent of what simulates it,

That is stupidly incorrect.
That DD calls HHH(DD) (its own simulator) IS PART OF
THE BEHAVIOR THAT THE INPUT TO HHH(DD) SPECIFIES.

And the fact that HHH(DD) returns 0 causing DD to subsequently halt is
also part of the behavior specified by finite string DD.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-10-22, olcott <polcott333@gmail.com> wrote:

On 10/22/2025 12:07 PM, Kaz Kylheku wrote:

On 2025-10-22, olcott <polcott333@gmail.com> wrote:

On 10/22/2025 10:40 AM, Kaz Kylheku wrote:

On 2025-10-22, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 10:20 PM, Kaz Kylheku wrote:

And when I identify a flaw yo simply ignore
whatever I say.

Nope; all the ways you say claim you've identified a flaw have been >>>>>> dissected by multiple poeple to a much greater detail than they deserve. >>>>>>
It is disingenuous to say that you've simply had your details ignored. >>>>>>

Turing machines in general can only compute mappings
from their inputs. The halting problem requires computing
mappings that in some cases are not provided in the
inputs therefore the halting problem is wrong.

The halting problem positively does not propose anything
like that, which would be gapingly wrong.

It only seems that way because you are unable to

No, it doesn't only seem that way. Thanks for playing.

provide the actual mapping that the actual input
to HHH(DD) specifies when DD is simulated by HHH
according to the semantics of the C language,

DD is a "finite string input" which specifies a behavior that is
independent of what simulates it,

That is stupidly incorrect.
That DD calls HHH(DD) (its own simulator) IS PART OF
THE BEHAVIOR THAT THE INPUT TO HHH(DD) SPECIFIES.

In no way am I saying that DD is not built on HHH, and
does not have a behavior dependent on that of HHH.
Why would I ever say that?

But that entire bundle is one fixed case DD, with a single behavior,
which is a property of DD, which is a finite string.

DD can be passed as an argument to any decider, not only HHH.

For instance, don't you have a HHH1 such that HHH1(DD)
correctly steps DD to the end and returns the correct value 1?

DD's behavior is dependent on a decider which it calls;
but not dependent on anything which is analyzing DD.

Even when those two are the same, they are different
instances/activations.

DD creates an activation of HHH on whose result it depends.

The definition of DD's behavior does not depend on the ongoing
activation of something which happens to be analyzing it;
it has no knowledge of that.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

Am Wed, 22 Oct 2025 12:11:56 -0500 schrieb olcott:

On 10/22/2025 12:07 PM, Kaz Kylheku wrote:

On 2025-10-22, olcott <polcott333@gmail.com> wrote:

provide the actual mapping that the actual input to HHH(DD) specifies
when DD is simulated by HHH according to the semantics of the C
language,

DD is a "finite string input" which specifies a behavior that is
independent of what simulates it,

That is stupidly incorrect.
That DD calls HHH(DD) (its own simulator) IS PART OF THE BEHAVIOR THAT
THE INPUT TO HHH(DD) SPECIFIES.

Yes, and the simulated HHH aborts, just like the simulator.
--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

Am Wed, 22 Oct 2025 11:13:29 -0500 schrieb olcott:

On 10/22/2025 10:53 AM, joes wrote:

Am Wed, 22 Oct 2025 10:40:29 -0500 schrieb olcott:

On 10/22/2025 10:38 AM, joes wrote:

Am Wed, 22 Oct 2025 10:08:05 -0500 schrieb olcott:

On 10/22/2025 10:04 AM, joes wrote:

HHH should not compute DD to call a nonterminating simulator.

The code specifies what it actually specifies we are not playing any >>>>> game of make pretend here.

The code of DD specifies a returning call.

It may seem that way if you don't know how to do an execution trace of
DD simulated by HHH.

I know what the trace looks like. It’s just that HHH is wrong to assume
that a call to HHH doesn’t return.

Yes it is wrong the same way that 2 + 3 = 5 is wrong when you don't know
how to do arithmetic.

How is HHH correct to ignore that the HHH in its input aborts?
--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/22/2025 1:54 PM, joes wrote:

Am Wed, 22 Oct 2025 12:11:56 -0500 schrieb olcott:

On 10/22/2025 12:07 PM, Kaz Kylheku wrote:

On 2025-10-22, olcott <polcott333@gmail.com> wrote:

provide the actual mapping that the actual input to HHH(DD) specifies
when DD is simulated by HHH according to the semantics of the C
language,

DD is a "finite string input" which specifies a behavior that is
independent of what simulates it,

That is stupidly incorrect.
That DD calls HHH(DD) (its own simulator) IS PART OF THE BEHAVIOR THAT
THE INPUT TO HHH(DD) SPECIFIES.

Yes, and the simulated HHH aborts, just like the simulator.

It is the behavior of DD simulated by HHH meeting
a predefined correct non-halting behavior pattern
that is most relevant.

All of the LLMs have figured out entirely on their
own exact what this correct non-halting behavior
pattern is with DD correctly simulated by HHH.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/21/2025 6:43 PM, olcott wrote:

On 10/21/2025 12:47 PM, Mike Terry wrote:

On 20/10/2025 21:04, Chris M. Thomasson wrote:

On 10/19/2025 8:39 PM, Mike Terry wrote:

On 19/10/2025 20:27, Chris M. Thomasson wrote:

On 10/19/2025 8:12 AM, Tristan Wibberley wrote:

On 19/10/2025 02:08, olcott wrote:

On 10/18/2025 8:03 PM, dart200 wrote:

On 10/18/25 1:44 PM, Chris M. Thomasson wrote:

I asked it:

1 HOME
5 PRINT "The Olcott All-in-One Halt Decider!"
10 INPUT "Shall I halt or not? " ; A$
30 IF A$ = "YES" GOTO 666
40 GOTO 10
666 PRINT "OK!"

Its odd to me. Olcott seems to think he can "detect" a
non-termination condition and just inject something that aborts >>>>>>>>> it.

Is that really so? I don't think it looks like that. Alas, I can't >>>>>> get
old messages from my newsserver any more.

He has mentioned several times about "detecting" a non-halting
condition and having to abort it... Argh!

That would be his "Infinite Recursive Simulation" pattern I guess.
The basic idea is that his decider HHH emulates its input DD, which
calls HHH, and so HHH is emulating itself in a sense. The HHH's
monitor what their emulations are doing and when nested emulations
occur the outer HHH can see what all the inner emulations are doing:
what instruction they're executing etc.

HHH looks for a couple of patterns of behaviour in its emulation
(together with their nested emulations), and when it spots one of
those patterns it abandons its emulation activity and straight away
returns 0 [=neverhalts].

So he is not "injecting" anything.

Ahhh! So that's where I am going wrong.

HHH is in the process of emulating DD, which is not "running" in the
sense that HHH is running; it's being emulated.  At some point HHH
spots its so-called "non-halting pattern" within DD's nested-
emulation trace, and HHH simply stops emulating and returns 0.  On
this group that is what people refer to as HHH "aborts" its
emulation of DD, but nothing is injected into DD.  It's not like DD
executing a C abort() call or anything.

Thank you. It seems to me that DD is beholden to HHH? So DD is just
reacting to his HHH? I keep asking Olcott to code up HHH in std C.

You should think of DD as a program built on top of HHH, so that HHH
is part of DD's algorithm. DD's "purpose in life" is to provide a test
case for a (partial) halt decider HHH.  Logically we have two HHH's here: >>
- a proposed halt decider program HHH.  We can call the halt decider
HHH from main(), e.g.
   int main() { if HHH(DD) OutputMessage("HHH says DD halts");
                else       OutputMessage("HHH says DD never halts");}
- a component of the HHH test case DD.  (You can see that DD calls HHH.)

PO's HHH is supposed to "emulate" the computation P() it is called
with, and monitor that emulation for non-halting patterns.  If it
spots one, it will abandon the emulation and return 0 [=neverhalts].
Note: PO's actual coding of HHH spots what PO /believes/ is a non-
halting pattern,

*Five LLM's figured this all out and their own*

<Input to LLM systems>
Please think this all the way through without making any guesses.
Only report on the behavior observed in simulation.

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;
}

int main()
{
  HHH(DD);
}

What value should HHH(DD) correctly return?
</Input to LLM systems>

HHH is your black box decider for DD? So, can't it just take all paths
and say if HHH returns 0 it halts. If HHH returns 1 it does not halt?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-10-22 12:40, Kaz Kylheku wrote:

On 2025-10-22, olcott <polcott333@gmail.com> wrote:

On 10/22/2025 12:07 PM, Kaz Kylheku wrote:

On 2025-10-22, olcott <polcott333@gmail.com> wrote:

On 10/22/2025 10:40 AM, Kaz Kylheku wrote:

On 2025-10-22, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 10:20 PM, Kaz Kylheku wrote:

And when I identify a flaw yo simply ignore
whatever I say.

Nope; all the ways you say claim you've identified a flaw have been >>>>>>> dissected by multiple poeple to a much greater detail than they deserve.

It is disingenuous to say that you've simply had your details ignored. >>>>>>>

Turing machines in general can only compute mappings
from their inputs. The halting problem requires computing
mappings that in some cases are not provided in the
inputs therefore the halting problem is wrong.

The halting problem positively does not propose anything
like that, which would be gapingly wrong.

It only seems that way because you are unable to

No, it doesn't only seem that way. Thanks for playing.

provide the actual mapping that the actual input
to HHH(DD) specifies when DD is simulated by HHH
according to the semantics of the C language,

DD is a "finite string input" which specifies a behavior that is
independent of what simulates it,

That is stupidly incorrect.
That DD calls HHH(DD) (its own simulator) IS PART OF
THE BEHAVIOR THAT THE INPUT TO HHH(DD) SPECIFIES.

In no way am I saying that DD is not built on HHH, and
does not have a behavior dependent on that of HHH.
Why would I ever say that?

But that entire bundle is one fixed case DD, with a single behavior,
which is a property of DD, which is a finite string.

I think part of the problem here is that Olcott doesn't grasp that the
"finite string input" DD *must* include as a substring the entire
description of HHH.

André

DD can be passed as an argument to any decider, not only HHH.

For instance, don't you have a HHH1 such that HHH1(DD)
correctly steps DD to the end and returns the correct value 1?

DD's behavior is dependent on a decider which it calls;
but not dependent on anything which is analyzing DD.

Even when those two are the same, they are different
instances/activations.

DD creates an activation of HHH on whose result it depends.

The definition of DD's behavior does not depend on the ongoing
activation of something which happens to be analyzing it;
it has no knowledge of that.

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/22/2025 1:54 PM, joes wrote:

Am Wed, 22 Oct 2025 12:11:56 -0500 schrieb olcott:

On 10/22/2025 12:07 PM, Kaz Kylheku wrote:

On 2025-10-22, olcott <polcott333@gmail.com> wrote:

provide the actual mapping that the actual input to HHH(DD) specifies
when DD is simulated by HHH according to the semantics of the C
language,

DD is a "finite string input" which specifies a behavior that is
independent of what simulates it,

That is stupidly incorrect.
That DD calls HHH(DD) (its own simulator) IS PART OF THE BEHAVIOR THAT
THE INPUT TO HHH(DD) SPECIFIES.

Yes, and the simulated HHH aborts, just like the simulator.

The simulated HHH cannot possibly actually
ever abort. I have explained this dozens of
times. Every HHH has identical machine code
yet the outermost HHH meets its abort criteria
first.

All of the LLM systems figure all this out
on their own.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

Am Wed, 22 Oct 2025 14:00:51 -0500 schrieb olcott:

On 10/22/2025 1:54 PM, joes wrote:

Am Wed, 22 Oct 2025 12:11:56 -0500 schrieb olcott:

On 10/22/2025 12:07 PM, Kaz Kylheku wrote:

DD is a "finite string input" which specifies a behavior that is
independent of what simulates it,

That is stupidly incorrect.
That DD calls HHH(DD) (its own simulator) IS PART OF THE BEHAVIOR THAT
THE INPUT TO HHH(DD) SPECIFIES.

Yes, and the simulated HHH aborts, just like the simulator.

It is the behavior of DD simulated by HHH meeting a predefined correct non-halting behavior pattern that is most relevant.
All of the LLMs have figured out entirely on their own exact what this correct non-halting behavior pattern is with DD correctly simulated by
HHH.

There is no non-halting pattern in DD because it in fact halts.
Your pattern ignores that repeated calls to HHH do not constitute
infinite recursion; HHH will always return. Actually it will always
be aborted by the next-outer simulator.
You could attempt to fix that by matching on repeated calls except
calls to HHH (since we know HHH will always abort)…
--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/22/2025 3:00 PM, olcott wrote:

On 10/22/2025 1:54 PM, joes wrote:

Am Wed, 22 Oct 2025 12:11:56 -0500 schrieb olcott:

On 10/22/2025 12:07 PM, Kaz Kylheku wrote:

On 2025-10-22, olcott <polcott333@gmail.com> wrote:

provide the actual mapping that the actual input to HHH(DD) specifies >>>>> when DD is simulated by HHH according to the semantics of the C
language,

DD is a "finite string input" which specifies a behavior that is
independent of what simulates it,

That is stupidly incorrect.
That DD calls HHH(DD) (its own simulator) IS PART OF THE BEHAVIOR THAT
THE INPUT TO HHH(DD) SPECIFIES.

Yes, and the simulated HHH aborts, just like the simulator.

It is the behavior of DD simulated by HHH meeting
a predefined correct non-halting behavior pattern
that is most relevant.

That DD halts when executed directly is proof that any pattern found in
DD is *NOT* a non-halting behavior pattern.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/22/2025 3:25 PM, olcott wrote:

On 10/22/2025 1:54 PM, joes wrote:

Am Wed, 22 Oct 2025 12:11:56 -0500 schrieb olcott:

On 10/22/2025 12:07 PM, Kaz Kylheku wrote:

On 2025-10-22, olcott <polcott333@gmail.com> wrote:

provide the actual mapping that the actual input to HHH(DD) specifies >>>>> when DD is simulated by HHH according to the semantics of the C
language,

DD is a "finite string input" which specifies a behavior that is
independent of what simulates it,

That is stupidly incorrect.
That DD calls HHH(DD) (its own simulator) IS PART OF THE BEHAVIOR THAT
THE INPUT TO HHH(DD) SPECIFIES.

Yes, and the simulated HHH aborts, just like the simulator.

The simulated HHH cannot possibly actually
ever abort.

False, as demonstrated by UTM(DD).
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/22/2025 2:24 PM, André G. Isaak wrote:

On 2025-10-22 12:40, Kaz Kylheku wrote:

On 2025-10-22, olcott <polcott333@gmail.com> wrote:

On 10/22/2025 12:07 PM, Kaz Kylheku wrote:

On 2025-10-22, olcott <polcott333@gmail.com> wrote:

On 10/22/2025 10:40 AM, Kaz Kylheku wrote:

On 2025-10-22, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 10:20 PM, Kaz Kylheku wrote:

And when I identify a flaw yo simply ignore
whatever I say.

Nope; all the ways you say claim you've identified a flaw have been >>>>>>>> dissected by multiple poeple to a much greater detail than they >>>>>>>> deserve.

It is disingenuous to say that you've simply had your details >>>>>>>> ignored.

Turing machines in general can only compute mappings
from their inputs. The halting problem requires computing
mappings that in some cases are not provided in the
inputs therefore the halting problem is wrong.

The halting problem positively does not propose anything
like that, which would be gapingly wrong.

It only seems that way because you are unable to

No, it doesn't only seem that way. Thanks for playing.

provide the actual mapping that the actual input
to HHH(DD) specifies when DD is simulated by HHH
according to the semantics of the C language,

DD is a "finite string input" which specifies a behavior that is
independent of what simulates it,

That is stupidly incorrect.
That DD calls HHH(DD) (its own simulator) IS PART OF
THE BEHAVIOR THAT THE INPUT TO HHH(DD) SPECIFIES.

In no way am I saying that DD is not built on HHH, and
does not have a behavior dependent on that of HHH.
Why would I ever say that?

But that entire bundle is one fixed case DD, with a single behavior,
which is a property of DD, which is a finite string.

I think part of the problem here is that Olcott doesn't grasp that the "finite string input" DD *must* include as a substring the entire description of HHH.

André

That includes that HHH(DD) keeps simulating yet
another instance of itself and DD forever and ever
until it fully understands that no simulated DD
can possibly ever reach its own final halt state.

That five LLM systems immediately understood this
and figured it all out on their own seems strong
evidence that you are being disingenuous with me
right now.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

Am Wed, 22 Oct 2025 14:25:14 -0500 schrieb olcott:

On 10/22/2025 1:54 PM, joes wrote:

Am Wed, 22 Oct 2025 12:11:56 -0500 schrieb olcott:

On 10/22/2025 12:07 PM, Kaz Kylheku wrote:

DD is a "finite string input" which specifies a behavior that is
independent of what simulates it,

That is stupidly incorrect.
That DD calls HHH(DD) (its own simulator) IS PART OF THE BEHAVIOR THAT
THE INPUT TO HHH(DD) SPECIFIES.

Yes, and the simulated HHH aborts, just like the simulator.

The simulated HHH cannot possibly actually ever abort. I have explained
this dozens of times. Every HHH has identical machine code yet the
outermost HHH meets its abort criteria first.

Of course it is not simulated that far. That doesn’t mean that it is non-halting, only that it halts later.
--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/22/2025 2:27 PM, joes wrote:

Am Wed, 22 Oct 2025 14:00:51 -0500 schrieb olcott:

On 10/22/2025 1:54 PM, joes wrote:

Am Wed, 22 Oct 2025 12:11:56 -0500 schrieb olcott:

On 10/22/2025 12:07 PM, Kaz Kylheku wrote:

DD is a "finite string input" which specifies a behavior that is
independent of what simulates it,

That is stupidly incorrect.
That DD calls HHH(DD) (its own simulator) IS PART OF THE BEHAVIOR THAT >>>> THE INPUT TO HHH(DD) SPECIFIES.

Yes, and the simulated HHH aborts, just like the simulator.

It is the behavior of DD simulated by HHH meeting a predefined correct
non-halting behavior pattern that is most relevant.
All of the LLMs have figured out entirely on their own exact what this
correct non-halting behavior pattern is with DD correctly simulated by
HHH.

There is no non-halting pattern in DD because it in fact halts.

non-halting behavior pattern of the simulated input
non-halting behavior pattern of the simulated input
non-halting behavior pattern of the simulated input
non-halting behavior pattern of the simulated input
non-halting behavior pattern of the simulated input

non-halting behavior pattern of the simulated input
non-halting behavior pattern of the simulated input
non-halting behavior pattern of the simulated input
non-halting behavior pattern of the simulated input
non-halting behavior pattern of the simulated input

non-halting behavior pattern of the simulated input
non-halting behavior pattern of the simulated input
non-halting behavior pattern of the simulated input
non-halting behavior pattern of the simulated input
non-halting behavior pattern of the simulated input

non-halting behavior pattern of the simulated input
non-halting behavior pattern of the simulated input
non-halting behavior pattern of the simulated input
non-halting behavior pattern of the simulated input
non-halting behavior pattern of the simulated input

non-halting behavior pattern of the simulated input
non-halting behavior pattern of the simulated input
non-halting behavior pattern of the simulated input
non-halting behavior pattern of the simulated input
non-halting behavior pattern of the simulated input

Your pattern ignores that repeated calls to HHH do not constitute
infinite recursion; HHH will always return. Actually it will always
be aborted by the next-outer simulator.
You could attempt to fix that by matching on repeated calls except
calls to HHH (since we know HHH will always abort)…

--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/22/2025 3:30 PM, olcott wrote:

On 10/22/2025 2:24 PM, André G. Isaak wrote:

On 2025-10-22 12:40, Kaz Kylheku wrote:

On 2025-10-22, olcott <polcott333@gmail.com> wrote:

On 10/22/2025 12:07 PM, Kaz Kylheku wrote:

On 2025-10-22, olcott <polcott333@gmail.com> wrote:

On 10/22/2025 10:40 AM, Kaz Kylheku wrote:

On 2025-10-22, olcott <polcott333@gmail.com> wrote:

On 10/20/2025 10:20 PM, Kaz Kylheku wrote:

And when I identify a flaw yo simply ignore
whatever I say.

Nope; all the ways you say claim you've identified a flaw have >>>>>>>>> been
dissected by multiple poeple to a much greater detail than they >>>>>>>>> deserve.

It is disingenuous to say that you've simply had your details >>>>>>>>> ignored.

Turing machines in general can only compute mappings
from their inputs. The halting problem requires computing
mappings that in some cases are not provided in the
inputs therefore the halting problem is wrong.

The halting problem positively does not propose anything
like that, which would be gapingly wrong.

It only seems that way because you are unable to

No, it doesn't only seem that way. Thanks for playing.

provide the actual mapping that the actual input
to HHH(DD) specifies when DD is simulated by HHH
according to the semantics of the C language,

DD is a "finite string input" which specifies a behavior that is
independent of what simulates it,

That is stupidly incorrect.
That DD calls HHH(DD) (its own simulator) IS PART OF
THE BEHAVIOR THAT THE INPUT TO HHH(DD) SPECIFIES.

In no way am I saying that DD is not built on HHH, and
does not have a behavior dependent on that of HHH.
Why would I ever say that?

But that entire bundle is one fixed case DD, with a single behavior,
which is a property of DD, which is a finite string.

I think part of the problem here is that Olcott doesn't grasp that the
"finite string input" DD *must* include as a substring the entire
description of HHH.

André

That includes that HHH(DD) keeps simulating yet
another instance of itself and DD forever and ever

False, as demonstrated by the fact that HHH(DD) returns.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/22/2025 3:31 PM, olcott wrote:

On 10/22/2025 2:27 PM, joes wrote:

Am Wed, 22 Oct 2025 14:00:51 -0500 schrieb olcott:

On 10/22/2025 1:54 PM, joes wrote:

Am Wed, 22 Oct 2025 12:11:56 -0500 schrieb olcott:

On 10/22/2025 12:07 PM, Kaz Kylheku wrote:

DD is a "finite string input" which specifies a behavior that is
independent of what simulates it,

That is stupidly incorrect.
That DD calls HHH(DD) (its own simulator) IS PART OF THE BEHAVIOR THAT >>>>> THE INPUT TO HHH(DD) SPECIFIES.

Yes, and the simulated HHH aborts, just like the simulator.

It is the behavior of DD simulated by HHH meeting a predefined correct
non-halting behavior pattern that is most relevant.
All of the LLMs have figured out entirely on their own exact what this
correct non-halting behavior pattern is with DD correctly simulated by
HHH.

There is no non-halting pattern in DD because it in fact halts.

non-halting behavior pattern of the simulated input

And since UTM(DD) halts, DD does not contain a non-halting behavior pattern.

non-halting behavior pattern of the simulated input
non-halting behavior pattern of the simulated input
non-halting behavior pattern of the simulated input
non-halting behavior pattern of the simulated input

non-halting behavior pattern of the simulated input
non-halting behavior pattern of the simulated input
non-halting behavior pattern of the simulated input
non-halting behavior pattern of the simulated input
non-halting behavior pattern of the simulated input

non-halting behavior pattern of the simulated input
non-halting behavior pattern of the simulated input
non-halting behavior pattern of the simulated input
non-halting behavior pattern of the simulated input
non-halting behavior pattern of the simulated input

non-halting behavior pattern of the simulated input
non-halting behavior pattern of the simulated input
non-halting behavior pattern of the simulated input
non-halting behavior pattern of the simulated input
non-halting behavior pattern of the simulated input

non-halting behavior pattern of the simulated input
non-halting behavior pattern of the simulated input
non-halting behavior pattern of the simulated input
non-halting behavior pattern of the simulated input
non-halting behavior pattern of the simulated input

Your pattern ignores that repeated calls to HHH do not constitute
infinite recursion; HHH will always return. Actually it will always
be aborted by the next-outer simulator.
You could attempt to fix that by matching on repeated calls except
calls to HHH (since we know HHH will always abort)…

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 10/21/2025 8:00 PM, Chris M. Thomasson wrote:

On 10/21/2025 5:43 PM, Mike Terry wrote:

On 22/10/2025 00:57, Chris M. Thomasson wrote:

On 10/21/2025 4:08 PM, Mike Terry wrote:

On 21/10/2025 23:03, Chris M. Thomasson wrote:

On 10/21/2025 2:37 PM, Chris M. Thomasson wrote:

A fun fuzzer: It allows for halting multiple times, then says
okay, we "think" we explored ct_program:[...]

I create a program that says for this target program, it halts.
However this same tool does not work for a slight alteration in the >>>>> same program?

Just so we're on the same page:

1.  What program did you create?
2.  What is the target program, exactly?
3.  What is the alteration you are imagining?

The target program under consideration for the "decider", lol.
Anyway, its:
______________________
2000 REM ct_program
2010     PRINT "ct_program"
2020     RA$ = "NOPE!"
2030     IF R0 = 0 THEN RA$ = "HALT!"
2040 RETURN
______________________


The ct_fuzzer that calls into ct_program, well, this can exposes it
to random data...
______________________
1000 REM ct_fuzzer
1010     PRINT "ct_fuzzer"
1020     R0 = INT(RND(1) * 1003)
1025     PRINT R0
1030     GOSUB 2000
1040 RETURN
______________________


ct_main is a driver:
______________________
1 HOME
100 REM ct_main
110     PRINT "ct_main"
120     FOR I = 0 TO 10
130         GOSUB 1000
135         IF RA$ = "HALT!" GOTO 140
136         I = I - 1
140     NEXT I
145 PRINT "HALT!!!"
150 END
______________________


Can the fuzz get to "many different" paths of execution? Humm...


Full program:
________________________
1 HOME
100 REM ct_main
110     PRINT "ct_main"
120     FOR I = 0 TO 10
130         GOSUB 1000
135         IF RA$ = "HALT!" GOTO 140
136         I = I - 1
140     NEXT I
145 PRINT "HALT!!!"
150 END


1000 REM ct_fuzzer
1010     PRINT "ct_fuzzer"
1020     R0 = INT(RND(1) * 1003)
1025     PRINT R0
1030     GOSUB 2000
1040 RETURN


2000 REM ct_program
2010     PRINT "ct_program"
2020     RA$ = "NOPE!"
2030     IF R0 = 0 THEN RA$ = "HALT!"
2040 RETURN
________________________


One can try it out over on:

https://www.calormen.com/jsbasic

Sooooo...

ct_program has roughly a 1/1003 chance of setting RA$="HALT!", and the
main routine tries to accumulate 10 of these RA$ settings (ignoring
others) before it prints "HALT!!!".  We would expect about 10000
ct_program calls to achieve this, and after much looping (probably
around 10000 times!) that's what we get.

But:

1.  Nothing is emulating anything
2.  ct_program actually always returns (regardless of what it sets RA$
to)
3.  there is no "decider" deciding ct_program that I can see

Well, the fuzzer can "sometimes" hit all paths for ct_program. So, it
can say sometimes it halts, sometimes it does not? Not a decider, but
fuzzing the damn thing until all paths are hit?

Humm... Think of an instrumented more complex ct_program with a counter per-path. When a path is taken in ct_program its counter becomes
non-zero. When ct_main notices that all of the per-path counters are
non-zero, it can say, okay we hit all paths and halt. Sound okay?

So all in all it's not really relevant to PO's HHH/DD code!  No need
to post more examples until you have all the right bits developed to
reproduce PO's counterexample!  :)

Ahhh Shit! Thanks. ;^o

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 22/10/2025 20:24, André G. Isaak wrote:

On 2025-10-22 12:40, Kaz Kylheku wrote:

On 2025-10-22, olcott <polcott333@gmail.com> wrote:

On 10/22/2025 12:07 PM, Kaz Kylheku wrote:

<snip>

DD is a "finite string input" which specifies a behavior that is
independent of what simulates it,

That is stupidly incorrect.
That DD calls HHH(DD) (its own simulator) IS PART OF
THE BEHAVIOR THAT THE INPUT TO HHH(DD) SPECIFIES.

In no way am I saying that DD is not built on HHH, and
does not have a behavior dependent on that of HHH.
Why would I ever say that?

But that entire bundle is one fixed case DD, with a single
behavior,
which is a property of DD, which is a finite string.

I think part of the problem here is that Olcott doesn't grasp
that the "finite string input" DD *must* include as a substring
the entire description of HHH.

He also seems to be missing the fact that HHH's sole input is a
function pointer that it immediately invalidates by casting the
pointer into into a uint32_t.

HHH's ability to simulate DD is like a dog's walking on his hind
legs. It doesn't work well, but you are surprised to find it
working at all.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
With apologies to Dr Johnson.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

Am Wed, 22 Oct 2025 14:31:21 -0500 schrieb olcott:

On 10/22/2025 2:27 PM, joes wrote:

Am Wed, 22 Oct 2025 14:00:51 -0500 schrieb olcott:

On 10/22/2025 1:54 PM, joes wrote:

Am Wed, 22 Oct 2025 12:11:56 -0500 schrieb olcott:

On 10/22/2025 12:07 PM, Kaz Kylheku wrote:

DD is a "finite string input" which specifies a behavior that is
independent of what simulates it,

That is stupidly incorrect.
That DD calls HHH(DD) (its own simulator) IS PART OF THE BEHAVIOR
THAT THE INPUT TO HHH(DD) SPECIFIES.

Yes, and the simulated HHH aborts, just like the simulator.

It is the behavior of DD simulated by HHH meeting a predefined correct
non-halting behavior pattern that is most relevant.
All of the LLMs have figured out entirely on their own exact what this
correct non-halting behavior pattern is with DD correctly simulated by
HHH.

There is no non-halting pattern in DD because it in fact halts.

non-halting behavior pattern of the simulated input

Your pattern ignores that repeated calls to HHH do not constitute
infinite recursion; HHH will always return. Actually it will always be
aborted by the next-outer simulator.
You could attempt to fix that by matching on repeated calls except
calls to HHH (since we know HHH will always abort)…

Yes. The way that HHH simulates its inputs falsely matches simulators
that abort after two or more recursions - such as itself.
--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.
--- Synchronet 3.21a-Linux NewsLink 1.2