These terms are replaced:
(a) "Turing machine description" is replaced with
[Finite string source code for a Turing Machine]
The term: "description" is too vague the finite string
source code actually specifies an exact sequence of steps. >
The term: "machine description" enables indirect
reference to behavior other than the behavior specified
by the input finite string of source code.
(b) "Decider" and replace it with sequence of inference
steps that are applied to an input static finite string
that are syntactically or semantically relevant to the
decision criteria.
Concrete example of a decider where relevance is required.
int strcmp(const char *str1, const char *str2);
and the finite string inputs are the entire basis.
This tightens the term "decider" to the actual requirements
that are never expressly stated. We can see things much
more clearly with these additional details.
On 2026-10-23 12:10, olcott wrote:
These terms are replaced:
(a) "Turing machine description" is replaced with
[Finite string source code for a Turing Machine]
The term: "description" is too vague the finite string
source code actually specifies an exact sequence of steps. >
The term: "machine description" enables indirect
reference to behavior other than the behavior specified
by the input finite string of source code.
The term 'description' as using in computational theory normally refers
to a 7-tuple as described here:
<https://en.wikipedia.org/wiki/Turing_machine#Formal_definition>
How is that any more vague that your alternative? Note also that the
term 'source code' isn't normally used for Turing Machines since Turing Machines are mathematical objects, not things that are compiled to run
on digital computers.
(b) "Decider" and replace it with sequence of inference
steps that are applied to an input static finite string
that are syntactically or semantically relevant to the
decision criteria.
Concrete example of a decider where relevance is required.
int strcmp(const char *str1, const char *str2);
and the finite string inputs are the entire basis.
strcmp() isn't a decider at all. A decider takes a single input and
either accepts it or rejects it. It is an algorithm implementing the membership function of a set.
This tightens the term "decider" to the actual requirements
that are never expressly stated. We can see things much
more clearly with these additional details.
Since your example isn't a decider, it rather difficult to see how your claims somehow 'tightens' the term.
André
Nit-picky irrelevant details. The idea was to show
that the decision criteria restricts the steps to
those that are syntactically relevant.
This is a key missing element of the foundations
of computation that prevents computation from being
understood more deeply.
Nit-picky irrelevant details. The idea was to show
that the decision criteria restricts the steps to
those that are syntactically relevant.
This is a key missing element of the foundations
of computation that prevents computation from being
understood more deeply.
No, Peter.
That is not a "missing element of the foundations of computation."
That is a new restriction you have just invented.
You started with:
computation operates on finite strings
which nobody disputes.
You have now silently strengthened that into:
computation may use only steps that Peter declares
"syntactically relevant" to the decision criterion.
Those propositions are not remotely equivalent.
Post's characterization of effective computation does not give you a
magical "relevance" filter that permits a purported decider to ignore consequences of its own result.
And `strcmp()` proves nothing of the sort.
It merely computes a particular function of two finite strings.
More importantly, André's objection is not "nit-picky."
You are claiming to have discovered an error in the foundations of computability while simultaneously redefining its basic terms.
When someone points out that your example is not even a decider in the standard technical sense, answering:
"irrelevant details"
is rather spectacular.
Definitions ARE the details when your claimed revolution consists of changing definitions.
And now we have yet another newly introduced term:
"syntactically relevant"
Please define it mathematically.
Then prove your claimed theorem:
A decision procedure may consider only
syntactically relevant inference steps.
In particular, define "relevant" without circularly meaning:
whatever allows HHH to return the answer
Peter wants while ignoring the consequence
that makes that answer wrong.
Because until you do that, you have not discovered a missing foundation--
of computation.
You have invented an undefined restriction and declared it foundational.
That is not deeper understanding.
That is moving the goalposts and giving the new goalpost a name.
On 10/23/2026 4:16 PM, Python wrote:
Nit-picky irrelevant details. The idea was to show
that the decision criteria restricts the steps to
those that are syntactically relevant.
This is a key missing element of the foundations
of computation that prevents computation from being
understood more deeply.
No, Peter.
That is not a "missing element of the foundations of computation."
That is a new restriction you have just invented.
You started with:
computation operates on finite strings
which nobody disputes.
You have now silently strengthened that into:
computation may use only steps that Peter declares
"syntactically relevant" to the decision criterion.
Those propositions are not remotely equivalent.
Of course they aren't otherwise my contribution
would be trivial instead of overturning 90 years
of misconception by filling in the missing gaps
in the foundation of computation that no one even
noticed were missing.
Post's characterization of effective computation does not give you a
magical "relevance" filter that permits a purported decider to ignore
consequences of its own result.
And `strcmp()` proves nothing of the sort.
It merely computes a particular function of two finite strings.
It decides whether or not a pair of finite strings
are equal on the basis of applying inference steps
that are relevant to the decision criteria.
More importantly, André's objection is not "nit-picky."
*This is the simplified essence*
A decider applies finite string transformation
inference steps relevant to the decision criteria
to finite string inputs.
You are claiming to have discovered an error in the foundations of
computability while simultaneously redefining its basic terms.
When someone points out that your example is not even a decider in the
standard technical sense, answering:
"irrelevant details"
is rather spectacular.
Definitions ARE the details when your claimed revolution consists of
changing definitions.
And now we have yet another newly introduced term:
"syntactically relevant"
Please define it mathematically.
This is the whole Rice's theorem
Semantic Property versus syntactic property thing.
You can look up the details.
Then prove your claimed theorem:
A decision procedure may consider only
syntactically relevant inference steps.
I didn't say that.
In particular, define "relevant" without circularly meaning:
It has its common meaning.
On 2026-10-23 17:08, olcott wrote:
On 10/23/2026 4:16 PM, Python wrote:
Nit-picky irrelevant details. The idea was to show
that the decision criteria restricts the steps to
those that are syntactically relevant.
This is a key missing element of the foundations
of computation that prevents computation from being
understood more deeply.
No, Peter.
That is not a "missing element of the foundations of computation."
That is a new restriction you have just invented.
You started with:
computation operates on finite strings
which nobody disputes.
You have now silently strengthened that into:
computation may use only steps that Peter declares
"syntactically relevant" to the decision criterion.
Those propositions are not remotely equivalent.
Of course they aren't otherwise my contribution
would be trivial instead of overturning 90 years
of misconception by filling in the missing gaps
in the foundation of computation that no one even
noticed were missing.
Post's characterization of effective computation does not give you a
magical "relevance" filter that permits a purported decider to ignore
consequences of its own result.
And `strcmp()` proves nothing of the sort.
It merely computes a particular function of two finite strings.
It decides whether or not a pair of finite strings
are equal on the basis of applying inference steps
that are relevant to the decision criteria.
More importantly, André's objection is not "nit-picky."
*This is the simplified essence*
A decider applies finite string transformation
inference steps relevant to the decision criteria
to finite string inputs.
Putting aside, for the moment, what constitutes 'relevance', you have
this strange obsession with 'finite strings' which highlights the fact
that you really have no clue what computational theory is all about. You object when people introduce the mathematical halting function into the discussion or talk about deciding whether a given computation halts and insist that they instead talk about 'finite strings'.
Yes, it is true that TMs perform computations on a tape containing a sequence of symbols and thus operate on finite strings, but the theory
of computation is not really about strings. It is about /mathematical/ functions, and the majority of mathematical functions of interest don't
have finite strings as either their domain or their codomain. Yet it is
these functions that computational theory asks about. It is concerned
with determining which /mathematical/ functions can be computed using a purely mechanical procedure.
If a function maps natural numbers to natural numbers, it can still be computable. Yes, you need to encode the integers as finite strings, but
the computation is still concerned with the natural numbers themselves,
not with the strings that represent them internally in a given Turing Machine. Strings are just sequences of symbols. They don't, for the most part, have any of the mathematical properties which we are interested in computing. For example, it is reasonable to wonder whether a given
natural number is prime, but it makes no sense to ask whether a finite string is prime. They're not the right type of object. When someone constructs a Prime Decider, it is making decisions about *natural
numbers*, not about strings.
The fact that TMs internally represent their inputs and outputs as
finite strings imposes only a single limitation on computation: a computation can only operate over *discrete* mathematical objects, not continuous ones. For example, you cannot construct a TM which performs computations over the reals, because the overwhelming majority of reals cannot be expressed as finite strings. However, it is still possible in
some cases to construct computations which approximate the reals to some arbitrary degree of precision.
But unlike the reals computations *are* discrete mathematical objects.
That means it is perfectly possible to represent them as finite strings, which means it is perfectly legitimate to ask whether the computation HHH(DD) halts. Not the string representing it (that has no halting
behavior whatsoever; it's simply a string), but rather the *actual* computation itself. Or to put it in your terms independent processes or
DD called from main() or all those other things that you perpetually
object to.
You are claiming to have discovered an error in the foundations of
computability while simultaneously redefining its basic terms.
When someone points out that your example is not even a decider in
the standard technical sense, answering:
"irrelevant details"
is rather spectacular.
Definitions ARE the details when your claimed revolution consists of
changing definitions.
And now we have yet another newly introduced term:
"syntactically relevant"
Please define it mathematically.
This is the whole Rice's theorem
Semantic Property versus syntactic property thing.
You can look up the details.
Rice's theorem says nothing remotely related to what you have written. Rice's theorem says that all non-trivial semantic properties are undecidable.
It makes no mention of 'syntactically relevant', whatever
that might mean.
Then prove your claimed theorem:
A decision procedure may consider only
syntactically relevant inference steps.
I didn't say that.
In particular, define "relevant" without circularly meaning:
It has its common meaning.
It's been pointed out to you on numerous occasions that common meanings
are generally not useful when talking about formal topics because they
are generally vaguely defined at best.
There is an irony here. People who have made actual contributions to computational have made a point of rigorously defining their terms, and
yet you accuse them of being vague.
Then you turn around and start
throwing around ill-defined terms as if they somehow clarify things. For instance, in an earlier post today I pointed out that when people talk
about a 'description of a turing machine', they specifically mean the
actual septuplet which defines the machine, something which is formally defined. You instead claim this causes all sorts of problems which can
be solved by instead talking about the 'source code' of the turing
machine, a notion which is absent from computational theory.
André
On 10/23/2026 7:02 PM, André G. Isaak wrote:
On 2026-10-23 17:08, olcott wrote:
On 10/23/2026 4:16 PM, Python wrote:
Nit-picky irrelevant details. The idea was to show
that the decision criteria restricts the steps to
those that are syntactically relevant.
This is a key missing element of the foundations
of computation that prevents computation from being
understood more deeply.
No, Peter.
That is not a "missing element of the foundations of computation."
That is a new restriction you have just invented.
You started with:
computation operates on finite strings
which nobody disputes.
You have now silently strengthened that into:
computation may use only steps that Peter declares
"syntactically relevant" to the decision criterion.
Those propositions are not remotely equivalent.
Of course they aren't otherwise my contribution
would be trivial instead of overturning 90 years
of misconception by filling in the missing gaps
in the foundation of computation that no one even
noticed were missing.
Post's characterization of effective computation does not give you a
magical "relevance" filter that permits a purported decider to
ignore consequences of its own result.
And `strcmp()` proves nothing of the sort.
It merely computes a particular function of two finite strings.
It decides whether or not a pair of finite strings
are equal on the basis of applying inference steps
that are relevant to the decision criteria.
More importantly, André's objection is not "nit-picky."
*This is the simplified essence*
A decider applies finite string transformation
inference steps relevant to the decision criteria
to finite string inputs.
Putting aside, for the moment, what constitutes 'relevance', you have
this strange obsession with 'finite strings' which highlights the fact
that you really have no clue what computational theory is all about.
You object when people introduce the mathematical halting function
into the discussion or talk about deciding whether a given computation
halts and insist that they instead talk about 'finite strings'.
*This is the simplest possible generic essence of all computation*
Axiom 1 --- Paraphrase of Emil Post definition of computation
All computations are equivalent to the application of finite
string transformation rules to finite string inputs to derive
any and all outputs.
Yes, it is true that TMs perform computations on a tape containing a
sequence of symbols and thus operate on finite strings, but the theory
of computation is not really about strings. It is about /mathematical/
functions, and the majority of mathematical functions of interest
don't have finite strings as either their domain or their codomain.
Yet it is
That is why conflating them with computation is incorrect.
these functions that computational theory asks about. It is concerned
with determining which /mathematical/ functions can be computed using
a purely mechanical procedure.
If a function maps natural numbers to natural numbers, it can still be
computable. Yes, you need to encode the integers as finite strings,
but the computation is still concerned with the natural numbers
themselves, not with the strings that represent them internally in a
given Turing Machine. Strings are just sequences of symbols. They
don't, for the most part, have any of the mathematical properties
which we are interested in computing. For example, it is reasonable to
wonder whether a given natural number is prime, but it makes no sense
to ask whether a finite string is prime. They're not the right type of
object. When someone constructs a Prime Decider, it is making
decisions about *natural numbers*, not about strings.
The fact that TMs internally represent their inputs and outputs as
finite strings imposes only a single limitation on computation: a
computation can only operate over *discrete* mathematical objects, not
continuous ones. For example, you cannot construct a TM which performs
computations over the reals, because the overwhelming majority of
reals cannot be expressed as finite strings. However, it is still
possible in some cases to construct computations which approximate the
reals to some arbitrary degree of precision.
But unlike the reals computations *are* discrete mathematical objects.
That means it is perfectly possible to represent them as finite
strings, which means it is perfectly legitimate to ask whether the
computation HHH(DD) halts. Not the string representing it (that has no
halting behavior whatsoever; it's simply a string), but rather the
*actual* computation itself. Or to put it in your terms independent
processes or DD called from main() or all those other things that you
perpetually object to.
You are claiming to have discovered an error in the foundations of
computability while simultaneously redefining its basic terms.
When someone points out that your example is not even a decider in
the standard technical sense, answering:
"irrelevant details"
is rather spectacular.
Definitions ARE the details when your claimed revolution consists of
changing definitions.
And now we have yet another newly introduced term:
"syntactically relevant"
Please define it mathematically.
This is the whole Rice's theorem
Semantic Property versus syntactic property thing.
You can look up the details.
Rice's theorem says nothing remotely related to what you have written.
Rice's theorem says that all non-trivial semantic properties are
undecidable.
Leaving syntactic properties implied.
It makes no mention of 'syntactically relevant', whatever that might
mean.
Sure this is my own unique huge breakthrough.
Then prove your claimed theorem:
A decision procedure may consider only
syntactically relevant inference steps.
I didn't say that.
In particular, define "relevant" without circularly meaning:
It has its common meaning.
It's been pointed out to you on numerous occasions that common
meanings are generally not useful when talking about formal topics
because they are generally vaguely defined at best.
terms-of-the-art that override and supersede common meanings
do more damage to effective communication than anything else.
There is an irony here. People who have made actual contributions to
computational have made a point of rigorously defining their terms,
and yet you accuse them of being vague.
I point out the exact details that they missed:
*This is the simplified essence*
A decider applies finite string transformation
inference steps relevant to the decision criteria
to finite string inputs. Making this a decider:
int strcmp(const char *str1, const char *str2);
That was an example of syntactic relevance.
On 2026-10-23 18:14, olcott wrote:
On 10/23/2026 7:02 PM, André G. Isaak wrote:
On 2026-10-23 17:08, olcott wrote:
On 10/23/2026 4:16 PM, Python wrote:
Nit-picky irrelevant details. The idea was to show
that the decision criteria restricts the steps to
those that are syntactically relevant.
This is a key missing element of the foundations
of computation that prevents computation from being
understood more deeply.
No, Peter.
That is not a "missing element of the foundations of computation."
That is a new restriction you have just invented.
You started with:
computation operates on finite strings
which nobody disputes.
You have now silently strengthened that into:
computation may use only steps that Peter declares
"syntactically relevant" to the decision criterion.
Those propositions are not remotely equivalent.
Of course they aren't otherwise my contribution
would be trivial instead of overturning 90 years
of misconception by filling in the missing gaps
in the foundation of computation that no one even
noticed were missing.
Post's characterization of effective computation does not give you
a magical "relevance" filter that permits a purported decider to
ignore consequences of its own result.
And `strcmp()` proves nothing of the sort.
It merely computes a particular function of two finite strings.
It decides whether or not a pair of finite strings
are equal on the basis of applying inference steps
that are relevant to the decision criteria.
More importantly, André's objection is not "nit-picky."
*This is the simplified essence*
A decider applies finite string transformation
inference steps relevant to the decision criteria
to finite string inputs.
Putting aside, for the moment, what constitutes 'relevance', you have
this strange obsession with 'finite strings' which highlights the
fact that you really have no clue what computational theory is all
about. You object when people introduce the mathematical halting
function into the discussion or talk about deciding whether a given
computation halts and insist that they instead talk about 'finite
strings'.
*This is the simplest possible generic essence of all computation*
Axiom 1 --- Paraphrase of Emil Post definition of computation
All computations are equivalent to the application of finite
string transformation rules to finite string inputs to derive
any and all outputs.
Yes, it is true that TMs perform computations on a tape containing a
sequence of symbols and thus operate on finite strings, but the
theory of computation is not really about strings. It is about /
mathematical/ functions, and the majority of mathematical functions
of interest don't have finite strings as either their domain or their
codomain. Yet it is
That is why conflating them with computation is incorrect.
I'm not conflating mathematical functions with computations. I am
stating the relationship between the two. A mathematical function is a mapping from a domain to a codomain. A computation is a sequence of
steps which takes an element of the domain of a mathematical function
and algorithmically determines which element of the codomain that
function maps to.
The important thing here is that if a mathematical function maps natural numbers to boolean values,
then the associated computation is concerned
with natural numbers and boolean values; it might use finite strings internally, but the mapping it performs is between natural numbers and boolean values (a prime number decider, for example). You want to make
the ridiculous claim that because computations make use of finite
strings they are incapable of making claims about things other than
strings. If this were the case, few people would have developed any sort
of interest in computation in the first place.
these functions that computational theory asks about. It is concerned
with determining which /mathematical/ functions can be computed using
a purely mechanical procedure.
If a function maps natural numbers to natural numbers, it can still
be computable. Yes, you need to encode the integers as finite
strings, but the computation is still concerned with the natural
numbers themselves, not with the strings that represent them
internally in a given Turing Machine. Strings are just sequences of
symbols. They don't, for the most part, have any of the mathematical
properties which we are interested in computing. For example, it is
reasonable to wonder whether a given natural number is prime, but it
makes no sense to ask whether a finite string is prime. They're not
the right type of object. When someone constructs a Prime Decider, it
is making decisions about *natural numbers*, not about strings.
The fact that TMs internally represent their inputs and outputs as
finite strings imposes only a single limitation on computation: a
computation can only operate over *discrete* mathematical objects,
not continuous ones. For example, you cannot construct a TM which
performs computations over the reals, because the overwhelming
majority of reals cannot be expressed as finite strings. However, it
is still possible in some cases to construct computations which
approximate the reals to some arbitrary degree of precision.
But unlike the reals computations *are* discrete mathematical
objects. That means it is perfectly possible to represent them as
finite strings, which means it is perfectly legitimate to ask whether
the computation HHH(DD) halts. Not the string representing it (that
has no halting behavior whatsoever; it's simply a string), but rather
the *actual* computation itself. Or to put it in your terms
independent processes or DD called from main() or all those other
things that you perpetually object to.
You are claiming to have discovered an error in the foundations of
computability while simultaneously redefining its basic terms.
When someone points out that your example is not even a decider in
the standard technical sense, answering:
"irrelevant details"
is rather spectacular.
Definitions ARE the details when your claimed revolution consists
of changing definitions.
And now we have yet another newly introduced term:
"syntactically relevant"
Please define it mathematically.
This is the whole Rice's theorem
Semantic Property versus syntactic property thing.
You can look up the details.
Rice's theorem says nothing remotely related to what you have
written. Rice's theorem says that all non-trivial semantic properties
are undecidable.
Leaving syntactic properties implied.
leaving what about them implied? It doesn't imply anything about
syntactic properties as far as I am aware.
It makes no mention of 'syntactically relevant', whatever that might
mean.
Sure this is my own unique huge breakthrough.
Introducing an undefined expression into the discussion is hardly a huge breakthrough.
Then prove your claimed theorem:
A decision procedure may consider only
syntactically relevant inference steps.
I didn't say that.
In particular, define "relevant" without circularly meaning:
It has its common meaning.
It's been pointed out to you on numerous occasions that common
meanings are generally not useful when talking about formal topics
because they are generally vaguely defined at best.
terms-of-the-art that override and supersede common meanings
do more damage to effective communication than anything else.
You have that exactly backwards. Terms-of-the-art provide precise definitions which eliminate the vagueness of common meanings, and that vagueness is what damages effective communication.
There is an irony here. People who have made actual contributions to
computational have made a point of rigorously defining their terms,
and yet you accuse them of being vague.
I point out the exact details that they missed:
*This is the simplified essence*
A decider applies finite string transformation
inference steps relevant to the decision criteria
to finite string inputs. Making this a decider:
int strcmp(const char *str1, const char *str2);
That was an example of syntactic relevance.
I've already pointed out that that is not a decider at all. And how
exactly does it illustrate 'syntactic relevance'? You've given a
prototype for a C function. You don't make any reference to relevance at all. What exactly about it is 'relevant' and why?
André
On 10/23/2026 7:55 PM, André G. Isaak wrote:
On 2026-10-23 18:14, olcott wrote:
That is why conflating them with computation is incorrect.
I'm not conflating mathematical functions with computations. I am
stating the relationship between the two. A mathematical function is a
mapping from a domain to a codomain. A computation is a sequence of
steps which takes an element of the domain of a mathematical function
and algorithmically determines which element of the codomain that
function maps to.
That is less accurate than this:
Axiom 1 --- Paraphrase of Emil Post definition of computation
All computations are equivalent to the application of finite
string transformation rules to finite string inputs to derive
any and all outputs.
The important thing here is that if a mathematical function maps
natural numbers to boolean values,
That this is not directly relevant to actual computation.
then the associated computation is concerned with natural numbers and
boolean values; it might use finite strings internally, but the
mapping it performs is between natural numbers and boolean values (a
prime number decider, for example). You want to make the ridiculous
claim that because computations make use of finite strings they are
incapable of making claims about things other than strings. If this
were the case, few people would have developed any sort of interest in
computation in the first place.
these functions that computational theory asks about. It is
concerned with determining which /mathematical/ functions can be
computed using a purely mechanical procedure.
If a function maps natural numbers to natural numbers, it can still
be computable. Yes, you need to encode the integers as finite
strings, but the computation is still concerned with the natural
numbers themselves, not with the strings that represent them
internally in a given Turing Machine. Strings are just sequences of
symbols. They don't, for the most part, have any of the mathematical
properties which we are interested in computing. For example, it is
reasonable to wonder whether a given natural number is prime, but it
makes no sense to ask whether a finite string is prime. They're not
the right type of object. When someone constructs a Prime Decider,
it is making decisions about *natural numbers*, not about strings.
The fact that TMs internally represent their inputs and outputs as
finite strings imposes only a single limitation on computation: a
computation can only operate over *discrete* mathematical objects,
not continuous ones. For example, you cannot construct a TM which
performs computations over the reals, because the overwhelming
majority of reals cannot be expressed as finite strings. However, it
is still possible in some cases to construct computations which
approximate the reals to some arbitrary degree of precision.
But unlike the reals computations *are* discrete mathematical
objects. That means it is perfectly possible to represent them as
finite strings, which means it is perfectly legitimate to ask
whether the computation HHH(DD) halts. Not the string representing
it (that has no halting behavior whatsoever; it's simply a string),
but rather the *actual* computation itself. Or to put it in your
terms independent processes or DD called from main() or all those
other things that you perpetually object to.
You are claiming to have discovered an error in the foundations of >>>>>> computability while simultaneously redefining its basic terms.
When someone points out that your example is not even a decider in >>>>>> the standard technical sense, answering:
"irrelevant details"
is rather spectacular.
Definitions ARE the details when your claimed revolution consists >>>>>> of changing definitions.
And now we have yet another newly introduced term:
"syntactically relevant"
Please define it mathematically.
This is the whole Rice's theorem
Semantic Property versus syntactic property thing.
You can look up the details.
Rice's theorem says nothing remotely related to what you have
written. Rice's theorem says that all non-trivial semantic
properties are undecidable.
Leaving syntactic properties implied.
leaving what about them implied? It doesn't imply anything about
syntactic properties as far as I am aware.
When Rice's theorem talks about semantic properties of
finite strings he says this making sure that people
understand that he is not talking about syntactic properties
of finite strings
It makes no mention of 'syntactically relevant', whatever that might
mean.
Sure this is my own unique huge breakthrough.
Introducing an undefined expression into the discussion is hardly a
huge breakthrough.
I don't use terms-of-the-art meanings that override and
supersede common meanings.
I just came up with the idea of:
"relevant to the decision criteria".
This is very clear what that means by the ordinary
meaning of its words.
It is an enormous improvement over "correct" finite
string transformations, that I has a few days ago.
Then prove your claimed theorem:
A decision procedure may consider only
syntactically relevant inference steps.
I didn't say that.
In particular, define "relevant" without circularly meaning:
It has its common meaning.
It's been pointed out to you on numerous occasions that common
meanings are generally not useful when talking about formal topics
because they are generally vaguely defined at best.
terms-of-the-art that override and supersede common meanings
do more damage to effective communication than anything else.
You have that exactly backwards. Terms-of-the-art provide precise
definitions which eliminate the vagueness of common meanings, and that
vagueness is what damages effective communication.
There is an irony here. People who have made actual contributions to
computational have made a point of rigorously defining their terms,
and yet you accuse them of being vague.
I point out the exact details that they missed:
*This is the simplified essence*
A decider applies finite string transformation
inference steps relevant to the decision criteria
to finite string inputs. Making this a decider:
int strcmp(const char *str1, const char *str2);
That was an example of syntactic relevance.
I've already pointed out that that is not a decider at all. And how
exactly does it illustrate 'syntactic relevance'? You've given a
prototype for a C function. You don't make any reference to relevance
at all. What exactly about it is 'relevant' and why?
André
In computability theory, a machine that always halts—also called a
decider (Sipser, 1996) or a total Turing machine (Kozen, 1997)—is a
Turing machine that halts for every input.
A machine that simply stops running and is allowed to ignore its
input is a decider?
int decider(char* s)
{
return 1;
}
When we enrich the details of the actual requirements
of finite string transformation inference steps to be
applied to an input finite string to actually make a
decision according to decision criteria
Then we begin to understand computation at a very much
deeper level. It has been the terms-of-the-art of
computation that have held back all progress towards
this deeper understanding.
On 2026-10-23 19:18, olcott wrote:
On 10/23/2026 7:55 PM, André G. Isaak wrote:
On 2026-10-23 18:14, olcott wrote:
<snip>
That is why conflating them with computation is incorrect.
I'm not conflating mathematical functions with computations. I am
stating the relationship between the two. A mathematical function is
a mapping from a domain to a codomain. A computation is a sequence of
steps which takes an element of the domain of a mathematical function
and algorithmically determines which element of the codomain that
function maps to.
That is less accurate than this:
No. It is not less accurate. My explanation actually indicates what computations are *for* whereas yours does not.
Axiom 1 --- Paraphrase of Emil Post definition of computation
All computations are equivalent to the application of finite
string transformation rules to finite string inputs to derive
any and all outputs.
The important thing here is that if a mathematical function maps
natural numbers to boolean values,
That this is not directly relevant to actual computation.
The above isn't English. If you meant 'Then' rather than 'That', then
you are simply mistaken. An algorithm implements a specific /
mathematical/ function.
A computation is the application of an algorithm
to a specific input.
A Turing Machine uses strings internally but it is
*not* restricted to talking about mathematical functions which involve strings. This is incredibly basic. You don't seem to grasp what it means
for something to be represented by something else.
Reread my explanation
involving a Prime Number decider and explain *specifically* what you
find problematic about it.
When Rice's theorem talks about semantic properties of
finite strings he says this making sure that people
understand that he is not talking about syntactic properties
of finite strings
If he is not talking about syntactic properties then obviously he is not implying anything about syntactic properties, so whatever you were
trying to say is still completely unclear.
It makes no mention of 'syntactically relevant', whatever that
might mean.
Sure this is my own unique huge breakthrough.
Introducing an undefined expression into the discussion is hardly a
huge breakthrough.
I don't use terms-of-the-art meanings that override and
supersede common meanings.
I just came up with the idea of:
"relevant to the decision criteria".
This is very clear what that means by the ordinary
meaning of its words.
It's not even remotely clear to me what you intend this expression to
mean. The 'ordinary meaning of its words' doesn't help.
It is an enormous improvement over "correct" finite
string transformations, that I has a few days ago.
both are equally ill-defined.
In computability theory, a machine that always halts—also called a
decider (Sipser, 1996) or a total Turing machine (Kozen, 1997)—is a
Turing machine that halts for every input.
Deciders are machines that decide sets or languages. They take a
*single* input and accept it if it belongs to the set/language and
reject it otherwise. Yes, they must always halt, but that's not their
entire definition. strcmp() is *not* a decider.
A machine that simply stops running and is allowed to ignore its
input is a decider?
int decider(char* s)
{
return 1;
}
That's a perfectly valid decider.
It decides the universal language,
that is, the language which consists of all possible strings. This might
not be something of interest to you, but it still meets the definition
of 'decider' whether you like it or not.
similarly,
int decider(char *s)
{
return 0;
}
decides the empty language. Both concepts are useful.
When we enrich the details of the actual requirements
of finite string transformation inference steps to be
applied to an input finite string to actually make a
decision according to decision criteria
'Does this string belong to the universal language' is a decision
criterion, and the above implements it perfectly well.
Then we begin to understand computation at a very much
deeper level. It has been the terms-of-the-art of
computation that have held back all progress towards
this deeper understanding.
You haven't provided a deeper understanding of anything. You've taken something which was previously well-defined and propose that we abandon
all those definitions in favour of vague, ill-defined notions.\
André
This is the whole Rice's theorem
Semantic Property versus syntactic property thing.
You can look up the details.
the decision criteria restricts the steps to
those that are syntactically relevant.
A decision procedure may consider only
syntactically relevant inference steps.
I didn't say that.
It has its common meaning.
This is the whole Rice's theorem
Semantic Property versus syntactic property thing.
You can look up the details.
No, Peter.
You don't get to announce that you have discovered:
"a key missing element of the foundations of computation"
and then, when asked to DEFINE that alleged missing element, answer:
"You can look up the details."
Especially because Rice's theorem does NOT supply the definition you need.
Rice's theorem distinguishes nontrivial semantic properties of the
function computed by a program from merely syntactic properties of its representation.
It does NOT say:
a decider applies only inference steps
"relevant to the decision criteria"
and it certainly does not define your word:
relevant
for you.
That concept is YOUR addition.
So YOU have to define it.
Then this exchange is remarkable:
You wrote:
the decision criteria restricts the steps to
those that are syntactically relevant.
I paraphrased that as:
A decision procedure may consider only
syntactically relevant inference steps.
You answered:
I didn't say that.
For fuck's sake.
Compare the two sentences.
If "the decision criteria restricts the steps to those that are syntactically relevant" does NOT mean that the procedure is restricted
to syntactically relevant steps, then explain what the hell it DOES mean.
And now we have this:
It has its common meaning.
No.
You are claiming to have found a missing foundational restriction that overturns:
"90 years of misconception"
You don't get to leave the central term in your revolutionary new
foundation at:
"the common meaning."
Mathematics does not work that way.
Define a predicate, relation, rule, whatever you intend:
Relevant(step, input, decision_criterion)
such that we can objectively determine whether an inference step is "relevant."
Then state your claimed restriction formally.
Then prove it.
And then show how it follows from Rice, Post, Turing, or whatever
existing result you claim supports it.
Because at present your argument is:
1. Computation operates on finite strings.
2. A decider uses "relevant" inference steps.
3. "Relevant" has its common meaning.
4. DD simulated by HHH is relevant.
5. Therefore 90 years of computability theory is wrong.
That is not a foundation.
That is an undefined adjective doing all the work.
And `strcmp()` doesn't rescue you.
`strcmp()` is an algorithm operating on finite strings. Nobody disputes that.
Showing one algorithm whose operations are intuitively "relevant" to
what it computes does not prove the universal theorem you need about
what ALL decision procedures may or may not do.
Most importantly, Rice's theorem is spectacularly unhelpful to your attempted rescue.
Halting is a semantic property of a computation.
That is precisely why examining the syntax of a finite program does not magically make the general problem decidable.
So please don't tell me to "look up the details."
I know what Rice's theorem says.
I am asking for the details of YOUR NEW CLAIM.
You say it fills a gap that everybody else missed for 90 years.
Fine.
Define it.
Formally.
Then prove it.
"Relevant has its common meaning" is not going to overturn computability theory.
Axiom 2
Deciders must apply finite string transformation inference
steps to their finite string inputs that are relevant to the
decision criteria.
Everyone already knows that a computation that returns the strlen(s)
of its input is not a halt decider
DD simulated by HHH according to the operational
semantics of its source code language is the only
relevant way to correctly determine the actual
behavior that input DD actually specifies.
We know that it is the only way because alternatives
are categorically impossible. Try and find one.
Not at all. My system simultaneously refutes Rice.
This is the whole Rice's theorem
Semantic Property versus syntactic property thing.
You can look up the details.
A decider must apply inference steps to make a decision.
A computation that simply stops running does not do this.
Mathematics does not work that way.
Define a predicate, relation, rule, whatever you intend:
Relevant(step, input, decision_criterion)
such that we can objectively determine whether an inference step is
"relevant."
So in other words you have absolutely no idea what:
"relevant to the decision criteria" means.
If you have meat in your refrigerator that is badly
rotting because you were in the hospital for two
months you have no idea of what
"relevant to the decision criteria" of rotten
meat would be?
On 10/24/2026 10:54 AM, olcott wrote:
Mathematics does not work that way.
Define a predicate, relation, rule, whatever you intend:
Relevant(step, input, decision_criterion)
such that we can objectively determine whether an inference step is
"relevant."
So in other words you have absolutely no idea what:
"relevant to the decision criteria" means.
If you have meat in your refrigerator that is badly
rotting because you were in the hospital for two
months you have no idea of what
"relevant to the decision criteria" of rotten
meat would be?
Only liars refuse to define their terms.
Peter, this finally makes the problem with your "Axiom 2" very clear.
You write:
Axiom 2
Deciders must apply finite string transformation inference
steps to their finite string inputs that are relevant to the
decision criteria.
and justify it with:
Everyone already knows that a computation that returns the strlen(s)
of its input is not a halt decider
Yes.
Of course.
But that establishes only the trivial statement:
A halt decider must actually decide halting.
Nobody has disputed that in 90 years.
It does NOT establish your much stronger claim about WHICH inference
steps a halt decider is permitted or required to use.
Those are completely different propositions.
For example, suppose an algorithm deciding some property performs:
useful computation
irrelevant computation
useful computation
return correct answer
The existence of the irrelevant intermediate computation does not
magically make the algorithm cease to decide the property.
A decider is characterized by what function it computes, not by every intermediate operation satisfying some undefined predicate called "relevant."
So your Axiom 2 has two possible interpretations.
If "relevant" merely means:
sufficient to correctly determine the required property
then Axiom 2 reduces to:
A decider must correctly decide what it claims to decide.
Trivially true.
Completely uncontroversial.
And completely useless for refuting the Halting Theorem or Rice's theorem.
But if "relevant" imposes some stronger restriction on which inference
steps may legitimately be used, then THAT is your new mathematical claim.
And you must define and prove it.
Your rotten-meat example does not do that.
Of course I understand the ordinary English word "relevant."
It is only allowed to use inference steps that measure
the behavior specified by its finite string input.
Interpretations are not tolerated. Only the 100%
exact meaning that is precisely specified.
Good then it was only deflection and misdirection when
you asked me to define the term.
In 90 years they never noticed that no such INPUT can
actually exist.
They stupidly conflated the caller
of a function with the INPUT to this same function.
On 10/24/2026 10:54 AM, olcott wrote:
Mathematics does not work that way.
Define a predicate, relation, rule, whatever you intend:
Relevant(step, input, decision_criterion)
such that we can objectively determine whether an inference step is
"relevant."
So in other words you have absolutely no idea what:
"relevant to the decision criteria" means.
If you have meat in your refrigerator that is badly
rotting because you were in the hospital for two
months you have no idea of what
"relevant to the decision criteria" of rotten
meat would be?
Only liars refuse to define their terms.
It is only allowed to use inference steps that measure
the behavior specified by its finite string input.
THANK YOU.
You have finally stated the nontrivial part of your new "Axiom 2."
And no, Peter, that is NOT part of the standard definition of a decider.
It is an additional restriction invented by you.
Now prove it.
Self-evident statements can only be proven by comprehension
that they are self-evident.
It is only allowed to use inference steps that measure
the behavior specified by its finite string input.
Self-evident statements can only be proven by comprehension
that they are self-evident.
Jesus fucking Christ.
No, Peter.
On 10/24/2026 10:08 AM, dbush wrote:
On 10/24/2026 10:54 AM, olcott wrote:
Mathematics does not work that way.
Define a predicate, relation, rule, whatever you intend:
Relevant(step, input, decision_criterion)
such that we can objectively determine whether an inference step is
"relevant."
So in other words you have absolutely no idea what:
"relevant to the decision criteria" means.
If you have meat in your refrigerator that is badly
rotting because you were in the hospital for two
months you have no idea of what
"relevant to the decision criteria" of rotten
meat would be?
Only liars refuse to define their terms.
You didn't define:
"only", "liars", "refuse", "define" or "terms"
So according to your own criteria you are a liar.
One can only build a car by taking steps to
build a car. One can not build a car by only
going outside to break large rocks with a
sledge hammer.
It is only allowed to use inference steps that measure
the behavior specified by its finite string input.
On 10/24/2026 11:28 AM, olcott wrote:
On 10/24/2026 10:08 AM, dbush wrote:
On 10/24/2026 10:54 AM, olcott wrote:
Mathematics does not work that way.
Define a predicate, relation, rule, whatever you intend:
Relevant(step, input, decision_criterion)
such that we can objectively determine whether an inference step is >>>>> "relevant."
So in other words you have absolutely no idea what:
"relevant to the decision criteria" means.
If you have meat in your refrigerator that is badly
rotting because you were in the hospital for two
months you have no idea of what
"relevant to the decision criteria" of rotten
meat would be?
Only liars refuse to define their terms.
You didn't define:
"only", "liars", "refuse", "define" or "terms"
So according to your own criteria you are a liar.
I didn't attempt to use any of those terms mathematically.
You attempted to use "relevant" mathematically without a mathematical definition. That makes you a liar.
The fact that you attempted such a meager refutation shows that you know you're lying.--
On 10/24/2026 10:42 AM, dbush wrote:
On 10/24/2026 11:28 AM, olcott wrote:
On 10/24/2026 10:08 AM, dbush wrote:
On 10/24/2026 10:54 AM, olcott wrote:
Mathematics does not work that way.
Define a predicate, relation, rule, whatever you intend:
Relevant(step, input, decision_criterion)
such that we can objectively determine whether an inference step
is "relevant."
So in other words you have absolutely no idea what:
"relevant to the decision criteria" means.
If you have meat in your refrigerator that is badly
rotting because you were in the hospital for two
months you have no idea of what
"relevant to the decision criteria" of rotten
meat would be?
Only liars refuse to define their terms.
You didn't define:
"only", "liars", "refuse", "define" or "terms"
So according to your own criteria you are a liar.
I didn't attempt to use any of those terms mathematically.
You attempted to use "relevant" mathematically without a mathematical
definition. That makes you a liar.
If you were paying enough attention you would see that
I have disavowed math as directly relevant to computation.
Math only says what they want computation to do not what
computation actually is of how it actually works.
The fact that you attempted such a meager refutation shows that you
know you're lying.
I have disavowed math as directly relevant to computation.
One can only build a car by taking steps to
build a car. One can not build a car by only
going outside to break large rocks with a
sledge hammer.
Yes.
And once again you have proved ONLY THE TRIVIAL VERSION.
To build a car, you must eventually perform steps sufficient to build a
car.
Congratulations.
Nobody disagrees.
But your Axiom 2 says something stronger:
you are ONLY ALLOWED to perform steps
relevant to building the car.
This is just you not paying close enough attention.
Axiom 1 and Axiom 2 are in my signature line now.
I am going to stop reading on the first non-trivial
error.
<snip>
On 10/24/2026 11:50 AM, olcott wrote:
On 10/24/2026 10:42 AM, dbush wrote:
On 10/24/2026 11:28 AM, olcott wrote:
On 10/24/2026 10:08 AM, dbush wrote:
On 10/24/2026 10:54 AM, olcott wrote:
Mathematics does not work that way.
Define a predicate, relation, rule, whatever you intend:
Relevant(step, input, decision_criterion)
such that we can objectively determine whether an inference step >>>>>>> is "relevant."
So in other words you have absolutely no idea what:
"relevant to the decision criteria" means.
If you have meat in your refrigerator that is badly
rotting because you were in the hospital for two
months you have no idea of what
"relevant to the decision criteria" of rotten
meat would be?
Only liars refuse to define their terms.
You didn't define:
"only", "liars", "refuse", "define" or "terms"
So according to your own criteria you are a liar.
I didn't attempt to use any of those terms mathematically.
You attempted to use "relevant" mathematically without a mathematical
definition. That makes you a liar.
If you were paying enough attention you would see that
I have disavowed math as directly relevant to computation.
Math only says what they want computation to do not what
computation actually is of how it actually works.
In other words, you agree with Turing and Linz that no algorithm
satisfies these requirements:
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
INPUT (<X>,Y) to H specifies a sequence of steps
that reach their own final halt state.
That has always been incorrect
On 10/24/2026 10:53 AM, dbush wrote:
On 10/24/2026 11:50 AM, olcott wrote:
On 10/24/2026 10:42 AM, dbush wrote:
On 10/24/2026 11:28 AM, olcott wrote:
On 10/24/2026 10:08 AM, dbush wrote:
On 10/24/2026 10:54 AM, olcott wrote:
Mathematics does not work that way.
Define a predicate, relation, rule, whatever you intend:
Relevant(step, input, decision_criterion)
such that we can objectively determine whether an inference step >>>>>>>> is "relevant."
So in other words you have absolutely no idea what:
"relevant to the decision criteria" means.
If you have meat in your refrigerator that is badly
rotting because you were in the hospital for two
months you have no idea of what
"relevant to the decision criteria" of rotten
meat would be?
Only liars refuse to define their terms.
You didn't define:
"only", "liars", "refuse", "define" or "terms"
So according to your own criteria you are a liar.
I didn't attempt to use any of those terms mathematically.
You attempted to use "relevant" mathematically without a
mathematical definition. That makes you a liar.
If you were paying enough attention you would see that
I have disavowed math as directly relevant to computation.
Math only says what they want computation to do not what
computation actually is of how it actually works.
In other words, you agree with Turing and Linz that no algorithm
satisfies these requirements:
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
That has always been incorrect
On 10/24/2026 12:05 PM, olcott wrote:
On 10/24/2026 10:53 AM, dbush wrote:
On 10/24/2026 11:50 AM, olcott wrote:
On 10/24/2026 10:42 AM, dbush wrote:
On 10/24/2026 11:28 AM, olcott wrote:
On 10/24/2026 10:08 AM, dbush wrote:
On 10/24/2026 10:54 AM, olcott wrote:
Mathematics does not work that way.
Define a predicate, relation, rule, whatever you intend:
Relevant(step, input, decision_criterion)
such that we can objectively determine whether an inference step >>>>>>>>> is "relevant."
So in other words you have absolutely no idea what:
"relevant to the decision criteria" means.
If you have meat in your refrigerator that is badly
rotting because you were in the hospital for two
months you have no idea of what
"relevant to the decision criteria" of rotten
meat would be?
Only liars refuse to define their terms.
You didn't define:
"only", "liars", "refuse", "define" or "terms"
So according to your own criteria you are a liar.
I didn't attempt to use any of those terms mathematically.
You attempted to use "relevant" mathematically without a
mathematical definition. That makes you a liar.
If you were paying enough attention you would see that
I have disavowed math as directly relevant to computation.
Math only says what they want computation to do not what
computation actually is of how it actually works.
In other words, you agree with Turing and Linz that no algorithm
satisfies these requirements:
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
That has always been incorrect
No, that is what everyone wants to know.
I (and everyone else) want to know if any arbitrary algorithm X with
input Y will halt when executed directly. It would be *very* useful to
me if I had an algorithm H that could tell me that in *all* possible cases.
I have disavowed math as directly relevant to computation.
Well, that settles it.
You claim to have:
refuted the Halting Theorem,
refuted Rice's theorem,
corrected the foundations of computability,
and overturned:
"90 years of misconception."
And now, when asked to define the central predicate in your alleged new axiom precisely enough for the claim to be mathematically examined, your answer is:
"I have disavowed math as directly relevant to computation."
Peter, the Halting Theorem and Rice's theorem ARE MATHEMATICAL THEOREMS.
If you have "disavowed math" as the appropriate framework, then you have
not refuted those theorems.
You have simply stopped participating in the subject in which they are theorems.
You are perfectly free to invent some non-mathematical notion of:
computation,
decider,
relevance,
semantic entailment,
halting,
and discuss it using refrigerator meat, cars, rocks, and whatever other analogies you like.
But then conclusions about that private system do not constitute
refutations of Turing or Rice.
You cannot have it both ways:
"I have overturned mathematical computability theory!"
followed by:
"Stop demanding mathematical definitions;
I have disavowed math."
That may be the funniest escape hatch you've tried yet.--
You didn't refute the mathematics.
You just rage-quit mathematics.
Math has always ignored what computations actually
are and how they actually work.
I have proved that math never has been directly related
to what computations actually are or how they actually work.
One can only build a car by taking steps to
build a car. One can not build a car by only
going outside to break large rocks with a
sledge hammer.
Yes.
And once again you have proved ONLY THE TRIVIAL VERSION.
To build a car, you must eventually perform steps sufficient to build a
car.
Congratulations.
Nobody disagrees.
But your Axiom 2 says something stronger:
you are ONLY ALLOWED to perform steps
relevant to building the car.
That is a terribly bad paraphrase of this:
Axiom 2
Deciders must apply finite string transformation inference
steps to their finite string inputs that are relevant to the
decision criteria.
Peter, dbush's definition is not the mistake.
It is the standard, perfectly well-defined Halting Problem:
Does the computation X(Y) halt?
Everyone knows that computations only take finite
strings and not executable processes as input
Math has always ignored what computations actually
are and how they actually work.
Peter, this is becoming spectacular.
Mathematics did not merely specify "goals" for computation.
Restricting this goal to the Emil Post definition of
computation we get
Can H(⟨D⟩,I) always correctly determine whether or not
its input finite string specifies a sequence of configurations
that reach their own final halt state?
On 10/24/2026 11:07 AM, Python wrote:
Peter, dbush's definition is not the mistake.
It is the standard, perfectly well-defined Halting Problem:
Does the computation X(Y) halt?
Everyone knows that computations only take finite
strings and not executable processes as input
after acknowledging this demand that computations
take executable processes as inputs.
On 10/24/2026 11:22 AM, Python wrote:
Math has always ignored what computations actually
are and how they actually work.
Peter, this is becoming spectacular.
Mathematics did not merely specify "goals" for computation.
Can H(⟨D⟩,I) always correctly determine whether or not D(I) halts
is the key one of these incoherent goals.
On 2026-10-24 10:28, olcott wrote:
On 10/24/2026 11:07 AM, Python wrote:
Peter, dbush's definition is not the mistake.
It is the standard, perfectly well-defined Halting Problem:
Does the computation X(Y) halt?
Everyone knows that computations only take finite
strings and not executable processes as input
after acknowledging this demand that computations
take executable processes as inputs.
Computations only take finite strings as inputs. No one has disputed
that. But you can't ask of a finite string whether or not it halts. You
can only ask that question about the computation which that finite
string *represents*.
If you believe otherwise, please demonstrate for me whether or not the following finite string halts:
"qqaaqqaaaaqaqaqaaaaqaaaaaaqaqqqqqaaaq"
Halting is a semantic property of computations, not of finite strings.
Lets go back and restate the halting problem as originally stated:
Given a Turing Machine X (a TM, not a finite string) and a input Y (a
finite string), is it POSSIBLE to construct a Turing Machine H (again,
not a finite string), which takes as input a DESCRIPTION of X, <X>
(a finite string) concatenated with Y (a finite string) and decides
whether X (a Turing Machine, not a finite string) applied to Y (a finite string) halts?
If you truly believe that it is not possible for a TM to answer a
question about another TM rather than a finite string, then you are effectively claiming that the answer to the above question is 'no'.
Instead you are claiming that since TMs can't answer questions about
other TMs, whoever asked the original question probably meant something
else by their question, which is simply absurd. The original formulators
of the halting problem knew *exactly* what they were asking.
And to tie this back to your ill-defined notion of relevance, how
exactly is anything *other* than whether X(Y) halts relevant to the
above question?
André
The behavior of X(Y) has always been outside
of the domain [...] for any and all halt deciders.
Restricting this goal to the Emil Post definition of
computation we get
Can H(⟨D⟩,I) always correctly determine whether or not
its input finite string specifies a sequence of configurations
that reach their own final halt state?
Peter, you have either just restated the Halting Problem or replaced it
with something trivial.
If the finite string ⟨D⟩ together with I specifies, according to the semantics of D, a sequence of configurations
C0 -> C1 -> C2 -> ...
then asking whether that sequence reaches a final halt state is EXACTLY asking whether D(I) halts.
Nobody ever claimed that H receives the actual execution of D(I) as input.
H receives the finite description ⟨D⟩ and I.
So:
Does D(I) halt?
and:
Does ⟨D⟩,I specify a computation whose sequence
of configurations reaches a halt state?
whether or not its input finite string specifies a sequence
of configurations that reach their own final halt state
On 10/24/2026 12:14 PM, André G. Isaak wrote:
On 2026-10-24 10:28, olcott wrote:
On 10/24/2026 11:07 AM, Python wrote:
Peter, dbush's definition is not the mistake.
It is the standard, perfectly well-defined Halting Problem:
Does the computation X(Y) halt?
Everyone knows that computations only take finite
strings and not executable processes as input
after acknowledging this demand that computations
take executable processes as inputs.
Computations only take finite strings as inputs. No one has disputed
that. But you can't ask of a finite string whether or not it halts.
You can only ask that question about the computation which that finite
string *represents*.
If you believe otherwise, please demonstrate for me whether or not the
following finite string halts:
"qqaaqqaaaaqaqaqaaaaqaaaaaaqaqqqqqaaaq"
Halting is a semantic property of computations, not of finite strings.
Lets go back and restate the halting problem as originally stated:
Given a Turing Machine X (a TM, not a finite string) and a input Y (a
finite string), is it POSSIBLE to construct a Turing Machine H (again,
not a finite string), which takes as input a DESCRIPTION of X, <X>
(a finite string) concatenated with Y (a finite string) and decides
whether X (a Turing Machine, not a finite string) applied to Y (a
finite string) halts?
*At this point it seems that you are simply dishonest*
H(⟨X⟩, Y) must apply finite string transformation inference
steps according to the INPUT computation source code of ⟨X⟩ to
determine what behavior this INPUT computation source code
specifies. The behavior of X(Y) has always been outside
of the domain of The Emil Post definition of computation
for any and all halt deciders.
The behavior of X(Y) has always been outside
of the domain [...] for any and all halt deciders.
Wonderful.
So, according to your new foundations,
On 2026-10-24 14:57, olcott wrote:
On 10/24/2026 12:14 PM, André G. Isaak wrote:
On 2026-10-24 10:28, olcott wrote:
On 10/24/2026 11:07 AM, Python wrote:
Peter, dbush's definition is not the mistake.
It is the standard, perfectly well-defined Halting Problem:
Does the computation X(Y) halt?
Everyone knows that computations only take finite
strings and not executable processes as input
after acknowledging this demand that computations
take executable processes as inputs.
Computations only take finite strings as inputs. No one has disputed
that. But you can't ask of a finite string whether or not it halts.
You can only ask that question about the computation which that
finite string *represents*.
If you believe otherwise, please demonstrate for me whether or not
the following finite string halts:
"qqaaqqaaaaqaqaqaaaaqaaaaaaqaqqqqqaaaq"
Halting is a semantic property of computations, not of finite strings.
Lets go back and restate the halting problem as originally stated:
Given a Turing Machine X (a TM, not a finite string) and a input Y (a
finite string), is it POSSIBLE to construct a Turing Machine H
(again, not a finite string), which takes as input a DESCRIPTION of
X, <X>
(a finite string) concatenated with Y (a finite string) and decides
whether X (a Turing Machine, not a finite string) applied to Y (a
finite string) halts?
*At this point it seems that you are simply dishonest*
No. I am stating the QUESTION which the halting problem asks. This
question doesn't make any claims whatsoever about how H(⟨X⟩, Y) works. It neither asserts nor denies that this must apply finite string transformations. It doesn't assert anything whatsoever about how H is to
be implemented. It simply asks a question: "Is an H which does what is
asked for in the question possible?". And what the question asks about
is the behaviour of X(Y).
H(⟨X⟩, Y) must apply finite string transformation inference
steps according to the INPUT computation source code of ⟨X⟩ to
determine what behavior this INPUT computation source code
specifies. The behavior of X(Y) has always been outside
of the domain of The Emil Post definition of computation
for any and all halt deciders.
The behaviour of X(Y) is precisely what the question asks about
so the
answer to this question *must* address that behaviour. If, as you claim, computations can't deal with that behaviour, then the answer to the
question is simply 'no'. Note that ⟨X⟩ doesn't have any behaviour whatsoever; only the X it describes has behaviour, so if you're actually insisting we ask about ⟨X⟩ rather than X it's entirely unclear what question you think you are asking; it's clearly not about halting
behaviour, though, so it it has nothing to do with the halting problem.
André
On 10/24/2026 4:22 PM, André G. Isaak wrote:
On 2026-10-24 14:57, olcott wrote:
On 10/24/2026 12:14 PM, André G. Isaak wrote:
On 2026-10-24 10:28, olcott wrote:
On 10/24/2026 11:07 AM, Python wrote:
Peter, dbush's definition is not the mistake.
It is the standard, perfectly well-defined Halting Problem:
Does the computation X(Y) halt?
Everyone knows that computations only take finite
strings and not executable processes as input
after acknowledging this demand that computations
take executable processes as inputs.
Computations only take finite strings as inputs. No one has disputed
that. But you can't ask of a finite string whether or not it halts.
You can only ask that question about the computation which that
finite string *represents*.
If you believe otherwise, please demonstrate for me whether or not
the following finite string halts:
"qqaaqqaaaaqaqaqaaaaqaaaaaaqaqqqqqaaaq"
Halting is a semantic property of computations, not of finite strings. >>>>
Lets go back and restate the halting problem as originally stated:
Given a Turing Machine X (a TM, not a finite string) and a input Y
(a finite string), is it POSSIBLE to construct a Turing Machine H
(again, not a finite string), which takes as input a DESCRIPTION of
X, <X>
(a finite string) concatenated with Y (a finite string) and decides
whether X (a Turing Machine, not a finite string) applied to Y (a
finite string) halts?
*At this point it seems that you are simply dishonest*
No. I am stating the QUESTION which the halting problem asks. This
question doesn't make any claims whatsoever about how H(⟨X⟩, Y) works. >> It neither asserts nor denies that this must apply finite string
transformations. It doesn't assert anything whatsoever about how H is
to be implemented. It simply asks a question: "Is an H which does what
is asked for in the question possible?". And what the question asks
about is the behaviour of X(Y).
H(⟨X⟩, Y) must apply finite string transformation inference
steps according to the INPUT computation source code of ⟨X⟩ to
determine what behavior this INPUT computation source code
specifies. The behavior of X(Y) has always been outside
of the domain of The Emil Post definition of computation
for any and all halt deciders.
The behaviour of X(Y) is precisely what the question asks about
Emil Post defines this as outside the domain of computation.
Are you not paying attention or are you simply dishonest?
On 2026-10-24 15:32, olcott wrote:
On 10/24/2026 4:22 PM, André G. Isaak wrote:
On 2026-10-24 14:57, olcott wrote:
On 10/24/2026 12:14 PM, André G. Isaak wrote:
On 2026-10-24 10:28, olcott wrote:
On 10/24/2026 11:07 AM, Python wrote:
Peter, dbush's definition is not the mistake.
It is the standard, perfectly well-defined Halting Problem:
Does the computation X(Y) halt?
Everyone knows that computations only take finite
strings and not executable processes as input
after acknowledging this demand that computations
take executable processes as inputs.
Computations only take finite strings as inputs. No one has
disputed that. But you can't ask of a finite string whether or not
it halts. You can only ask that question about the computation
which that finite string *represents*.
If you believe otherwise, please demonstrate for me whether or not
the following finite string halts:
"qqaaqqaaaaqaqaqaaaaqaaaaaaqaqqqqqaaaq"
Halting is a semantic property of computations, not of finite strings. >>>>>
Lets go back and restate the halting problem as originally stated:
Given a Turing Machine X (a TM, not a finite string) and a input Y
(a finite string), is it POSSIBLE to construct a Turing Machine H
(again, not a finite string), which takes as input a DESCRIPTION of >>>>> X, <X>
(a finite string) concatenated with Y (a finite string) and decides >>>>> whether X (a Turing Machine, not a finite string) applied to Y (a
finite string) halts?
*At this point it seems that you are simply dishonest*
No. I am stating the QUESTION which the halting problem asks. This
question doesn't make any claims whatsoever about how H(⟨X⟩, Y)
works. It neither asserts nor denies that this must apply finite
string transformations. It doesn't assert anything whatsoever about
how H is to be implemented. It simply asks a question: "Is an H which
does what is asked for in the question possible?". And what the
question asks about is the behaviour of X(Y).
H(⟨X⟩, Y) must apply finite string transformation inference
steps according to the INPUT computation source code of ⟨X⟩ to
determine what behavior this INPUT computation source code
specifies. The behavior of X(Y) has always been outside
of the domain of The Emil Post definition of computation
for any and all halt deciders.
The behaviour of X(Y) is precisely what the question asks about
Emil Post defines this as outside the domain of computation.
Are you not paying attention or are you simply dishonest?
You seem to be the one not paying attention. The question posed by the halting question asks whether it is possible to compute whether X(Y)
halts.
If that is indeed outside of the domain of computation, then the
answer to the question would be 'no, it's not possible'. It wouldn't be justification for changing the question entirely, which is what you are determined to do.
But, since Post most definitely does not define this as outside the
domain of computation the point is moot. You're reading things into Post which simply aren't there.
André
On 10/24/2026 4:14 PM, Python wrote:
The behavior of X(Y) has always been outside
of the domain [...] for any and all halt deciders.
Wonderful.
So, according to your new foundations,
No that is an incorrect paraphrase.
The behavior of X(Y) has always been outside
of the domain [...] for any and all halt deciders.
OK so we are at dishonest.
The behavior of X(Y) has always been outside
of the domain [...] for any and all halt deciders.
Wonderful.
So, according to your new foundations,
the behavior of X(Y) is outside--
the domain of a machine whose alleged job is to decide the behavior of
X(Y).
Nobody says H takes X(Y) as input. It takes the finite description <X>,Y
and decides whether the computation it describes halts.
If your H does NOT decide that, it is not a halt decider.
You've finally solved the Halting Problem:
Step 1: Remove halting from the problem.
Step 2: Solve what's left.
Step 3: Call everyone else dishonest.
Groundbreaking.
No according to Emil Post. Can you pay attention?
OK so we are at dishonest.
No, Peter.
André just accepted YOUR premise for the sake of argument.
You say determining whether X(Y) halts is outside the domain of
computation.
Fine.
Then the answer to:
Can a computation always determine whether X(Y) halts?
is:
NO.
Congratulations. You have just argued FOR the impossibility asserted by
the Halting Theorem.
What you DON'T get to do is say:
"That question cannot be computed,
therefore I shall replace it with another question--
that can be computed,
and call the original theorem wrong."
André isn't being dishonest.
He's following your premise to its conclusion.
You are changing the question because you don't like the conclusion.
Is the correct answer to the question: What time is it? "yes"?
Is the correct answer to the question: What time is it? "yes"?
Jesus fucking Christ, Peter.
"What time is it?" is not a yes/no question.
"Can a computation always determine whether X(Y) halts?" IS.
Denying my truisms prevents saving the Earth from death.
Denying my truisms prevents saving the Earth from death.
Peter, how on Earth did we get from the Halting Problem to this?
We started with whether H can decide whether X(Y) halts.
On 10/24/2026 5:29 PM, Python wrote:
Denying my truisms prevents saving the Earth from death.
Peter, how on Earth did we get from the Halting Problem to this?
We started with whether H can decide whether X(Y) halts.
The world will not implement my
"true on the basis of meaning expressed in language"
computation until I have proved my point.
This enables damned liars to get way with their damned
lies that are actually killing the whole planet.
My system could put them in their place 10,000
different ways before they finish their first
sentence.
Playing head games pretending to refute my work
is actually killing the whole planet.
Playing head games pretending to refute my work
is actually killing the whole planet.
On 2026-10-24 15:32, olcott wrote:
On 10/24/2026 4:22 PM, André G. Isaak wrote:
On 2026-10-24 14:57, olcott wrote:
On 10/24/2026 12:14 PM, André G. Isaak wrote:
On 2026-10-24 10:28, olcott wrote:
On 10/24/2026 11:07 AM, Python wrote:
Peter, dbush's definition is not the mistake.
It is the standard, perfectly well-defined Halting Problem:
Does the computation X(Y) halt?
Everyone knows that computations only take finite
strings and not executable processes as input
after acknowledging this demand that computations
take executable processes as inputs.
Computations only take finite strings as inputs. No one has
disputed that. But you can't ask of a finite string whether or not
it halts. You can only ask that question about the computation
which that finite string *represents*.
If you believe otherwise, please demonstrate for me whether or not
the following finite string halts:
"qqaaqqaaaaqaqaqaaaaqaaaaaaqaqqqqqaaaq"
Halting is a semantic property of computations, not of finite strings. >>>>>
Lets go back and restate the halting problem as originally stated:
Given a Turing Machine X (a TM, not a finite string) and a input Y
(a finite string), is it POSSIBLE to construct a Turing Machine H
(again, not a finite string), which takes as input a DESCRIPTION of >>>>> X, <X>
(a finite string) concatenated with Y (a finite string) and decides >>>>> whether X (a Turing Machine, not a finite string) applied to Y (a
finite string) halts?
*At this point it seems that you are simply dishonest*
No. I am stating the QUESTION which the halting problem asks. This
question doesn't make any claims whatsoever about how H(⟨X⟩, Y)
works. It neither asserts nor denies that this must apply finite
string transformations. It doesn't assert anything whatsoever about
how H is to be implemented. It simply asks a question: "Is an H which
does what is asked for in the question possible?". And what the
question asks about is the behaviour of X(Y).
H(⟨X⟩, Y) must apply finite string transformation inference
steps according to the INPUT computation source code of ⟨X⟩ to
determine what behavior this INPUT computation source code
specifies. The behavior of X(Y) has always been outside
of the domain of The Emil Post definition of computation
for any and all halt deciders.
The behaviour of X(Y) is precisely what the question asks about
Emil Post defines this as outside the domain of computation.
Are you not paying attention or are you simply dishonest?
You seem to be the one not paying attention. The question posed by the halting question asks whether it is possible to compute whether X(Y)
halts. If that is indeed outside of the domain of computation, then the answer to the question would be 'no, it's not possible'.
It wouldn't be
justification for changing the question entirely, which is what you are determined to do.
But, since Post most definitely does not define this as outside the
domain of computation the point is moot. You're reading things into Post which simply aren't there.
André
On 10/24/2026 5:15 PM, Python wrote:
and always has been stupidly incorrect.Is the correct answer to the question: What time is it? "yes"?
Jesus fucking Christ, Peter.
"What time is it?" is not a yes/no question.
"Can a computation always determine whether X(Y) halts?" IS.
Le 25/10/2026 à 00:35, olcott a écrit :
On 10/24/2026 5:29 PM, Python wrote:
Denying my truisms prevents saving the Earth from death.
Peter, how on Earth did we get from the Halting Problem to this?
We started with whether H can decide whether X(Y) halts.
The world will not implement my
"true on the basis of meaning expressed in language"
computation until I have proved my point.
This enables damned liars to get way with their damned
lies that are actually killing the whole planet.
My system could put them in their place 10,000
different ways before they finish their first
sentence.
Playing head games pretending to refute my work
is actually killing the whole planet.
Playing head games pretending to refute my work
is actually killing the whole planet.
Peter, seriously.
People disagreeing with your argument about the Halting Problem are not "killing the whole planet."
You have established that correct application of the C operational
semantics within HHH produces the recursively simulated sequence:
HHH simulates DD
-> DD calls HHH(DD)
-> HHH simulates DD
-> ...
Agreed.
On 2026-10-24 16:27, olcott wrote:
On 10/24/2026 5:15 PM, Python wrote:
and always has been stupidly incorrect.Is the correct answer to the question: What time is it? "yes"?
Jesus fucking Christ, Peter.
"What time is it?" is not a yes/no question.
"Can a computation always determine whether X(Y) halts?" IS.
No, unlike your question there is no type-mismatch in that question. It
is a simple yes/no question requesting a yes/no answer.
But, if it will make you happy, let's consider a slightly different question: Given an arbitary Turing Machine X and an arbitrary input Y,
is there some foolproof method for determining whether or not X will
halt on input Y?
Notice that in the above formulation of the question, I
don't restrict what kinds of methods you can use. You could use
computation, but I'm also allowing the possibility of some other method
so what you consider to be within the scope of computation according to
Post doesn't play any role here.
What *exactly* do you find wrong with this question? This really *is*
the question that people were interested in when they first posed the halting problem, despite what you may believe. It's a question that has enormous practical implications whereas the question with which you seek
to replace it, as far as I can tell, does not.
André
Agrees that the simulated DD cannot reach past its own line 03
On 10/24/2026 5:52 PM, André G. Isaak wrote:
On 2026-10-24 16:27, olcott wrote:
On 10/24/2026 5:15 PM, Python wrote:
and always has been stupidly incorrect.Is the correct answer to the question: What time is it? "yes"?
Jesus fucking Christ, Peter.
"What time is it?" is not a yes/no question.
"Can a computation always determine whether X(Y) halts?" IS.
No, unlike your question there is no type-mismatch in that question.
It is a simple yes/no question requesting a yes/no answer.
But, if it will make you happy, let's consider a slightly different
question: Given an arbitary Turing Machine X and an arbitrary input Y,
is there some foolproof method for determining whether or not X will
halt on input Y?
That is still outside the scope of Emil Post computation.
That is still outside the scope of Emil Post computation.
Agrees that the simulated DD cannot reach past its own line 03
NO.
Stop adding words to what I agreed to.
I agreed that if the recursive simulation CONTINUES, we get:
HHH -> DD -> HHH -> DD -> ...
I did NOT agree that DD cannot get past line 03 if HHH returns.
In fact, your own HHH is supposed to detect that recursive pattern,
abort it, and return 0.
It ceases to exist.
It was only temporary data within HHH.
Peter, repeating
That is still outside the scope of Emil Post computation.
TWENTY TIMES does not turn it into an answer.
André explicitly removed that restriction:
Is there SOME foolproof method for determining
whether X halts on Y?
On 10/24/2026 5:52 PM, André G. Isaak wrote:
On 2026-10-24 16:27, olcott wrote:
On 10/24/2026 5:15 PM, Python wrote:
and always has been stupidly incorrect.Is the correct answer to the question: What time is it? "yes"?
Jesus fucking Christ, Peter.
"What time is it?" is not a yes/no question.
"Can a computation always determine whether X(Y) halts?" IS.
No, unlike your question there is no type-mismatch in that question.
It is a simple yes/no question requesting a yes/no answer.
But, if it will make you happy, let's consider a slightly different
question: Given an arbitary Turing Machine X and an arbitrary input Y,
is there some foolproof method for determining whether or not X will
halt on input Y?
That is still outside the scope of Emil Post computation.
You really do seem to be a liar at this point.
I am going to stop reading at your very first mistake so
if you say something profoundly brilliant after that I
will never see it.
Maybe you should study axiom 1 below MUCH MORE CLOSELY
X is still an executable process thus out-of-scope
of every computation because they only operate on
finite strings.
Peter, we have ALREADY gone through this exact argument.
You previously described what happens to the HHH called at DD line 03:
It ceases to exist.
It was only temporary data within HHH.
And I already explained the problem.
The simulated HHH does NOT return 0 to DD.
You ABORT the simulation and DISCARD the simulated HHH state.
Those are not the same operation.
So yes:
while the recursive simulation continues,
the simulated HHH does not return.
And when you stop that simulation:
the simulated HHH STILL does not return.
YOU KILL IT.
Then the OUTER, executed HHH returns 0.
That does not establish that DD cannot halt. It establishes that YOUR SIMULATION PROCEDURE chose to stop simulating DD before DD's call at
line 03 returned.
Throwing away a simulated computation is not a transition of the
computation being simulated.
On 10/24/2026 6:02 PM, Python wrote:
Peter, repeating
That is still outside the scope of Emil Post computation.
TWENTY TIMES does not turn it into an answer.
André explicitly removed that restriction:
Is there SOME foolproof method for determining
whether X halts on Y?
X is still an executable process thus out-of-scope
of every computation because they only operate on
finite strings.
OK good so far.
DD cannot possibly reach its own simulated final
state whether HHH aborts this simulation or not.
Once a correct non-halting behavior pattern is
correctly matched the non-halt decision is
correctly made.
On 10/24/2026 6:02 PM, Python wrote:
Peter, repeating
That is still outside the scope of Emil Post computation.
TWENTY TIMES does not turn it into an answer.
André explicitly removed that restriction:
Is there SOME foolproof method for determining
whether X halts on Y?
X is still an executable process thus out-of-scope
of every computation because they only operate on
finite strings.
On 2026-10-24 16:58, olcott wrote:
On 10/24/2026 5:52 PM, André G. Isaak wrote:
On 2026-10-24 16:27, olcott wrote:
On 10/24/2026 5:15 PM, Python wrote:
and always has been stupidly incorrect.Is the correct answer to the question: What time is it? "yes"?
Jesus fucking Christ, Peter.
"What time is it?" is not a yes/no question.
"Can a computation always determine whether X(Y) halts?" IS.
No, unlike your question there is no type-mismatch in that question.
It is a simple yes/no question requesting a yes/no answer.
But, if it will make you happy, let's consider a slightly different
question: Given an arbitary Turing Machine X and an arbitrary input
Y, is there some foolproof method for determining whether or not X
will halt on input Y?
That is still outside the scope of Emil Post computation.
You really do seem to be a liar at this point.
I explicitly stated that I wasn't restricting my question to Emil Post computation.
I asked whether there was *some* method to determine
whether X(Y) would halt and, more importantly, why you think that is a stupid question to want to know the answer to. That last bit deserves a detailed explanation considering the fact that a great many very clever people have been interested in exactly that question.
I am going to stop reading at your very first mistake so
if you say something profoundly brilliant after that I
will never see it.
If everyone adopted that position, none of your posts would even be
read. Note that in many posts people make a claim which might at first glance seem wrong and then go to great lengths to justify that claim. If
you stop reading things whenever you disagree with something you're
going to miss out on a great deal of elucidating arguments.
< juvenile repetition snipped >
Maybe you should study axiom 1 below MUCH MORE CLOSELY
You can propose whatever axioms you want. It doesn't mean anyone is obligated to accept them, that they are correct, or that they are worthy
of study. And your axiom 1 doesn't support your claim that the question posed above is 'outside the scope of computation'. That would require additional argumentation which you've failed to provide.
André
On 10/24/2026 7:23 PM, olcott wrote:
On 10/24/2026 6:02 PM, Python wrote:
Peter, repeating
That is still outside the scope of Emil Post computation.
TWENTY TIMES does not turn it into an answer.
André explicitly removed that restriction:
Is there SOME foolproof method for determining
whether X halts on Y?
X is still an executable process thus out-of-scope
of every computation because they only operate on
finite strings.
Likewise, addition is out-of-scope of every computation because they
only operate on finite strings, not actual numbers.
Agreed?
On 10/24/2026 6:33 PM, dbush wrote:
On 10/24/2026 7:23 PM, olcott wrote:
On 10/24/2026 6:02 PM, Python wrote:
Peter, repeating
That is still outside the scope of Emil Post computation.
TWENTY TIMES does not turn it into an answer.
André explicitly removed that restriction:
Is there SOME foolproof method for determining
whether X halts on Y?
X is still an executable process thus out-of-scope
of every computation because they only operate on
finite strings.
Likewise, addition is out-of-scope of every computation because they
only operate on finite strings, not actual numbers.
Agreed?
Arithmetic can be consistently converted to operations
on finite strings. The behavior of DD() executed in main
cannot be correctly represented as a finite string to HHH.
The behavior of DD() executed in main
cannot be correctly represented as a finite string to HHH.
On 2026-10-24 17:23, olcott wrote:
On 10/24/2026 6:02 PM, Python wrote:
Peter, repeating
That is still outside the scope of Emil Post computation.
TWENTY TIMES does not turn it into an answer.
André explicitly removed that restriction:
Is there SOME foolproof method for determining
whether X halts on Y?
X is still an executable process thus out-of-scope
of every computation because they only operate on
finite strings.
I explicitly stated I wasn't restricting myself to computations. I was asking about *methods*.
And by that same logic, asking whether 13 is a prime number is out-of-
scope of every computation since 13 is a natural number and computations only operated on finite strings.
Are you claiming that we can't compute whether a given natural number is prime? If so, you are in disagreement with essentially the entire world.
André
So you admit that the Halting Theorem is based on an
incorrect question?
I wasn't restricting myself to computations. I was asking about *methods*.
So you admit that the Halting Theorem is based on an incorrect question?
Arithmetic can be consistently converted to operations
on finite strings. The behavior of DD() executed in main
cannot be correctly represented as a finite string to HHH.
So you admit that the Halting Theorem is based on an
incorrect question?
No, Peter.
André admitted NOTHING OF THE SORT.
He explicitly said:
I wasn't restricting myself to computations. I was asking about
*methods*.
And you immediately transformed that into:
So you admit that the Halting Theorem is based on an incorrect question?
That is not a misunderstanding.
You are perfectly familiar with this kind of sophistry, since you accuse everyone else of it constantly.
André broadened the question to remove YOUR objection.
You then pretended that this was an admission that YOUR objection was correct.
It wasn't.
If you're going to call people dishonest every few posts, don't
blatantly put admissions into their mouths that they never made.
OK good so far.
Good. Then the crucial facts are now AGREED:
1. The simulated HHH at DD line 03 never returns 0.
2. You abort that simulation and discard it.
3. Only the OUTER HHH returns 0.
Now you say:
DD cannot possibly reach its own simulated final
state whether HHH aborts this simulation or not.
No.
If you DON'T abort, the simulation recurses forever.
If you DO abort, you have simply STOPPED SIMULATING DD before its line
03 call returned.
A computation failing to reach a final state in a simulation YOU
TERMINATED does not prove that the computation cannot reach a final state.
And this:
Once a correct non-halting behavior pattern is
correctly matched the non-halt decision is
correctly made.
is circular.
The entire dispute is whether your recursive pattern CORRECTLY
establishes that DD does not halt.
You cannot prove that by calling it a "correct non-halting behavior pattern."
Your actual inference is:
My simulation does not return
therefore DD does not halt.
But those are different claims.
In fact, you have now explicitly agreed that your simulated HHH never returns the 0 that your executed HHH returns.
So your simulation does NOT reproduce the behavior of the very HHH whose behavior determines what DD does.
That is the fatal flaw.
IF [...] H CORRECTLY DETERMINES that its simulated D
would never stop running unless aborted THEN [...]
The actual execution traces conclusively prove that I am correct.
On 10/24/2026 7:41 PM, olcott wrote:
On 10/24/2026 6:33 PM, dbush wrote:
On 10/24/2026 7:23 PM, olcott wrote:
On 10/24/2026 6:02 PM, Python wrote:
Peter, repeating
That is still outside the scope of Emil Post computation.
TWENTY TIMES does not turn it into an answer.
André explicitly removed that restriction:
Is there SOME foolproof method for determining
whether X halts on Y?
X is still an executable process thus out-of-scope
of every computation because they only operate on
finite strings.
Likewise, addition is out-of-scope of every computation because they
only operate on finite strings, not actual numbers.
Agreed?
Arithmetic can be consistently converted to operations
on finite strings. The behavior of DD() executed in main
cannot be correctly represented as a finite string to HHH.
Which is another way of saying that the answer to Andre's question above
is "no" and that you agree that Turing and Linz are correct.
the question is incorrect and thus the halting theorem is incorrect
On 2026-10-24 17:41, olcott wrote:
Arithmetic can be consistently converted to operations
on finite strings. The behavior of DD() executed in main
cannot be correctly represented as a finite string to HHH.
That last bit is a really baseless assertion. How do you back up this
claim of yours that DD() called from main() cannot be represented as a finite string? What prevents it from being represented as such?
DD(), after call, can be represented by source code which can be viewed
as a finite string. Are you claiming that calling something from main() somehow causes it to behave *differently* from its source code? That
would call into question the behaviour of basically every computer
program on earth.
André
On 10/24/2026 6:31 PM, André G. Isaak wrote:
On 2026-10-24 17:23, olcott wrote:
On 10/24/2026 6:02 PM, Python wrote:
Peter, repeating
That is still outside the scope of Emil Post computation.
TWENTY TIMES does not turn it into an answer.
André explicitly removed that restriction:
Is there SOME foolproof method for determining
whether X halts on Y?
X is still an executable process thus out-of-scope
of every computation because they only operate on
finite strings.
I explicitly stated I wasn't restricting myself to computations. I was
asking about *methods*.
So you admit that the Halting Theorem is based on an
incorrect question? All but one of my reviewers simply
change the subject as soon as I proved my point.
And by that same logic, asking whether 13 is a prime number is out-of-
scope of every computation since 13 is a natural number and
computations only operated on finite strings.
Are you claiming that we can't compute whether a given natural number
is prime? If so, you are in disagreement with essentially the entire
world.
Provably different execution traces.
So you admit that the Halting Theorem is based on an
incorrect question?
No, Peter.
André admitted NOTHING OF THE SORT.
the question is incorrect and thus the halting theorem is incorrect
No, Peter.
The question is:
Does there exist a method that always determines
whether X(Y) halts?
If, as YOU claim, such a determination is outside the scope of every possible computation, then the answer is:
NO.
Not:
THE QUESTION IS INCORRECT.
"Does there exist an integer whose square is 2?"
No.
Perfectly valid question.
"Does there exist a largest prime?"
No.
Perfectly valid question.
"Does there exist a halt decider satisfying the standard specification?"
No.
Perfectly valid question.
You keep treating a negative answer as evidence that the question was invalid.
That is not a correction to the foundations of computation.
It is a failure to understand what "no" means.
No, Peter.
You are doing the Sipser trick again.
The statement you say Sipser agreed to begins:
IF [...] H CORRECTLY DETERMINES that its simulated D
would never stop running unless aborted THEN [...]
Exactly.
The entire dispute is whether YOUR HHH has CORRECTLY DETERMINED that
about DD.
Sipser agreeing that:
IF the determination is correct,
THEN the conclusion is correct
does not establish that YOUR determination is correct.
That's a tautology, as you just admitted.
You are using Sipser's agreement with
IF P THEN Q
as if Sipser had agreed that
P
holds for your HHH and DD.
He didn't.
And you still haven't answered the fatal objection.
Your own agreed facts are:
simulated HHH(DD): does NOT return 0; you kill it.
executed HHH(DD): DOES return 0.
Yet DD's behavior depends precisely on what HHH(DD) does.
So your alleged "correct simulation" does not reproduce the behavior of
the HHH(DD) whose behavior determines DD's execution.
Saying:
The actual execution traces conclusively prove that I am correct.
is not an answer.
Show the trace in which the HHH called at DD line 03 returns the 0 that
your actual HHH returns.
You can't.
That's the problem.
So you admit that the Halting Theorem is based on an
incorrect question?
No, Peter.
André admitted NOTHING OF THE SORT.
He explicitly said:
I wasn't restricting myself to computations. I was asking about
*methods*.
And you immediately transformed that into:
So you admit that the Halting Theorem is based on an incorrect question?
That is not a misunderstanding.
You are perfectly familiar with this kind of sophistry, since you accuse everyone else of it constantly.
André broadened the question to remove YOUR objection.
You then pretended that this was an admission that YOUR objection was correct.
It wasn't.
If you're going to call people dishonest every few posts, don't
blatantly put admissions into their mouths that they never made.
On 2026-10-24 17:47, olcott wrote:
On 10/24/2026 6:31 PM, André G. Isaak wrote:
On 2026-10-24 17:23, olcott wrote:
On 10/24/2026 6:02 PM, Python wrote:
Peter, repeating
That is still outside the scope of Emil Post computation.
TWENTY TIMES does not turn it into an answer.
André explicitly removed that restriction:
Is there SOME foolproof method for determining
whether X halts on Y?
X is still an executable process thus out-of-scope
of every computation because they only operate on
finite strings.
I explicitly stated I wasn't restricting myself to computations. I
was asking about *methods*.
So you admit that the Halting Theorem is based on an
incorrect question? All but one of my reviewers simply
change the subject as soon as I proved my point.
No. I admit no such thing. And I asked you to explain *why* you think
that is a stupid question to want to know the answer to, which you still haven't addressed. And, as I said, many very intelligent people have
asked this very question, so if you want to claim its a stupid question, you'll need to make a *strong* case for that claim
And just saying it's outside the scrope of 'Emil Post Computation' isn't
a legitimate answer. Even if a question is outside the scope of
computation, that doesn't make it stupid to want to know its answer.
On 10/24/2026 6:57 PM, Python wrote:
No, Peter.
You are doing the Sipser trick again.
The statement you say Sipser agreed to begins:
IF [...] H CORRECTLY DETERMINES that its simulated D
would never stop running unless aborted THEN [...]
Exactly.
The entire dispute is whether YOUR HHH has CORRECTLY DETERMINED that
about DD.
Sipser agreeing that:
IF the determination is correct,
THEN the conclusion is correct
does not establish that YOUR determination is correct.
That's a tautology, as you just admitted.
You are using Sipser's agreement with
IF P THEN Q
as if Sipser had agreed that
P
holds for your HHH and DD.
He didn't.
And you still haven't answered the fatal objection.
Your own agreed facts are:
simulated HHH(DD): does NOT return 0; you kill it.
executed HHH(DD): DOES return 0.
Yet DD's behavior depends precisely on what HHH(DD) does.
So your alleged "correct simulation" does not reproduce the behavior of
the HHH(DD) whose behavior determines DD's execution.
Saying:
The actual execution traces conclusively prove that I am correct.
is not an answer.
Show the trace in which the HHH called at DD line 03 returns the 0 that
your actual HHH returns.
You can't.
That's the problem.
HHH watches the behavior of its simulated input and
as soon as HHH sees that DD calls the same function
with the same argument twice in sequence and there
are no conditional branch instructions from the
beginning of DD until this call this matches the
"infinite recursion" non-halting behavior pattern.
Le 25/10/2026 à 02:07, olcott a écrit :
On 10/24/2026 6:57 PM, Python wrote:
No, Peter.
You are doing the Sipser trick again.
The statement you say Sipser agreed to begins:
IF [...] H CORRECTLY DETERMINES that its simulated D
would never stop running unless aborted THEN [...]
Exactly.
The entire dispute is whether YOUR HHH has CORRECTLY DETERMINED that
about DD.
Sipser agreeing that:
IF the determination is correct,
THEN the conclusion is correct
does not establish that YOUR determination is correct.
That's a tautology, as you just admitted.
You are using Sipser's agreement with
IF P THEN Q
as if Sipser had agreed that
P
holds for your HHH and DD.
He didn't.
And you still haven't answered the fatal objection.
Your own agreed facts are:
simulated HHH(DD): does NOT return 0; you kill it.
executed HHH(DD): DOES return 0.
Yet DD's behavior depends precisely on what HHH(DD) does.
So your alleged "correct simulation" does not reproduce the behavior
of the HHH(DD) whose behavior determines DD's execution.
Saying:
The actual execution traces conclusively prove that I am correct.
is not an answer.
Show the trace in which the HHH called at DD line 03 returns the 0
that your actual HHH returns.
You can't.
That's the problem.
HHH watches the behavior of its simulated input and
as soon as HHH sees that DD calls the same function
with the same argument twice in sequence and there
are no conditional branch instructions from the
beginning of DD until this call this matches the
"infinite recursion" non-halting behavior pattern.
Peter, you have now copy-pasted this same paragraph as an answer to half
a dozen different objections.
I will not tolerate you ignoring it
OK good so far.
Good. Then the crucial facts are now AGREED:
1. The simulated HHH at DD line 03 never returns 0.
2. You abort that simulation and discard it.
3. Only the OUTER HHH returns 0.
Now you say:
DD cannot possibly reach its own simulated final
state whether HHH aborts this simulation or not.
No.
If you DON'T abort, the simulation recurses forever.
If you DO abort, you have simply STOPPED SIMULATING DD before its line
03 call returned.
A computation failing to reach a final state in a simulation YOU
TERMINATED does not prove that the computation cannot reach a final state.
And this:
Once a correct non-halting behavior pattern is
correctly matched the non-halt decision is
correctly made.
is circular.
I will not tolerate you ignoring it
You are hardly in a position to decide what will or will not be
tolerated here.
I did NOT ignore the Sipser quote.
I addressed it explicitly.
The quote is not the problem.
What you falsely claim it establishes is.
Yawn.
Yes, Peter. We know what HHH "watches."
You have now posted this same paragraph repeatedly.
On 10/24/2026 7:32 PM, Python wrote:
Yawn.
Yes, Peter. We know what HHH "watches."
You have now posted this same paragraph repeatedly.
<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
[the correctly simulated] D specifies a non-halting
sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
[the correctly simulated] // inserted for clarity
it can already be inferred from the context.
You cannot possibly show how HHH/DD does not meet that spec.
On 10/24/2026 7:02 PM, André G. Isaak wrote:
On 2026-10-24 17:47, olcott wrote:
On 10/24/2026 6:31 PM, André G. Isaak wrote:
On 2026-10-24 17:23, olcott wrote:
On 10/24/2026 6:02 PM, Python wrote:
Peter, repeating
That is still outside the scope of Emil Post computation.
TWENTY TIMES does not turn it into an answer.
André explicitly removed that restriction:
Is there SOME foolproof method for determining
whether X halts on Y?
X is still an executable process thus out-of-scope
of every computation because they only operate on
finite strings.
I explicitly stated I wasn't restricting myself to computations. I
was asking about *methods*.
So you admit that the Halting Theorem is based on an
incorrect question? All but one of my reviewers simply
change the subject as soon as I proved my point.
No. I admit no such thing. And I asked you to explain *why* you think
that is a stupid question to want to know the answer to, which you
still haven't addressed. And, as I said, many very intelligent people
have asked this very question, so if you want to claim its a stupid
question, you'll need to make a *strong* case for that claim
And just saying it's outside the scrope of 'Emil Post Computation'
isn't a legitimate answer. Even if a question is outside the scope of
computation, that doesn't make it stupid to want to know its answer.
Emil Post computation is Turing equivalent thus outside
the scope of Emil Post computation is outside the scope
of computation. It is too difficult to see that it is
outside the scope of all computation until:
On 2026-10-24 18:14, olcott wrote:
On 10/24/2026 7:02 PM, André G. Isaak wrote:
On 2026-10-24 17:47, olcott wrote:
On 10/24/2026 6:31 PM, André G. Isaak wrote:
On 2026-10-24 17:23, olcott wrote:
On 10/24/2026 6:02 PM, Python wrote:
Peter, repeating
That is still outside the scope of Emil Post computation.
TWENTY TIMES does not turn it into an answer.
André explicitly removed that restriction:
Is there SOME foolproof method for determining
whether X halts on Y?
X is still an executable process thus out-of-scope
of every computation because they only operate on
finite strings.
I explicitly stated I wasn't restricting myself to computations. I
was asking about *methods*.
So you admit that the Halting Theorem is based on an
incorrect question? All but one of my reviewers simply
change the subject as soon as I proved my point.
No. I admit no such thing. And I asked you to explain *why* you think
that is a stupid question to want to know the answer to, which you
still haven't addressed. And, as I said, many very intelligent people
have asked this very question, so if you want to claim its a stupid
question, you'll need to make a *strong* case for that claim
And just saying it's outside the scrope of 'Emil Post Computation'
isn't a legitimate answer. Even if a question is outside the scope of
computation, that doesn't make it stupid to want to know its answer.
Emil Post computation is Turing equivalent thus outside
the scope of Emil Post computation is outside the scope
of computation. It is too difficult to see that it is
outside the scope of all computation until:
Do you even read the posts you respond to? I said I was not restricting
the scope to computation *at all* (Emil Post computation or otherwise).
And I explicitly pointed out that questions which fall outside the scope
of computation could still be perfectly valid questions. And you are
still ignoring the question. Why is stupid to want to know the answer to
the question 'Does X(Y) halt?'?
On 2026-10-24 18:14, olcott wrote:
On 10/24/2026 7:02 PM, André G. Isaak wrote:
On 2026-10-24 17:47, olcott wrote:
On 10/24/2026 6:31 PM, André G. Isaak wrote:
On 2026-10-24 17:23, olcott wrote:
On 10/24/2026 6:02 PM, Python wrote:
Peter, repeating
That is still outside the scope of Emil Post computation.
TWENTY TIMES does not turn it into an answer.
André explicitly removed that restriction:
Is there SOME foolproof method for determining
whether X halts on Y?
X is still an executable process thus out-of-scope
of every computation because they only operate on
finite strings.
I explicitly stated I wasn't restricting myself to computations. I
was asking about *methods*.
So you admit that the Halting Theorem is based on an
incorrect question? All but one of my reviewers simply
change the subject as soon as I proved my point.
No. I admit no such thing. And I asked you to explain *why* you think
that is a stupid question to want to know the answer to, which you
still haven't addressed. And, as I said, many very intelligent people
have asked this very question, so if you want to claim its a stupid
question, you'll need to make a *strong* case for that claim
And just saying it's outside the scrope of 'Emil Post Computation'
isn't a legitimate answer. Even if a question is outside the scope of
computation, that doesn't make it stupid to want to know its answer.
Emil Post computation is Turing equivalent thus outside
the scope of Emil Post computation is outside the scope
of computation. It is too difficult to see that it is
outside the scope of all computation until:
Do you even read the posts you respond to? I said I was not restricting
the scope to computation *at all*
On 10/24/2026 6:44 PM, dbush wrote:i.e. the requirements cannot be satisfied, so you agree with Turing and
On 10/24/2026 7:41 PM, olcott wrote:
On 10/24/2026 6:33 PM, dbush wrote:
On 10/24/2026 7:23 PM, olcott wrote:
On 10/24/2026 6:02 PM, Python wrote:
Peter, repeating
That is still outside the scope of Emil Post computation.
TWENTY TIMES does not turn it into an answer.
André explicitly removed that restriction:
Is there SOME foolproof method for determining
whether X halts on Y?
X is still an executable process thus out-of-scope
of every computation because they only operate on
finite strings.
Likewise, addition is out-of-scope of every computation because they
only operate on finite strings, not actual numbers.
Agreed?
Arithmetic can be consistently converted to operations
on finite strings. The behavior of DD() executed in main
cannot be correctly represented as a finite string to HHH.
Which is another way of saying that the answer to Andre's question
above is "no" and that you agree that Turing and Linz are correct.
the question is incorrect
Peter, please follow this one step at a time, because you are confusing
two completely different things.
The question is:
Can we always determine whether X(Y) halts?
Now suppose, for the sake of argument, that you have proved your claim:
Determining whether X(Y) halts is outside
the scope of all computation.
Fine.
What follows from that?
It follows that NO COMPUTATION can always determine whether X(Y) halts.
That is a NEGATIVE ANSWER to the question.
It does not make the question "incorrect."
For example:
Can an algorithm always determine whether X(Y) halts?
If you prove that this is impossible, the answer is:
No.
The question remains perfectly meaningful.
This distinction is extremely important:
"Can computation do X?"
and
"X is outside the scope of computation."
are not contradictory statements.
The second can be the reason why the answer to the first is NO.
That is exactly what an impossibility theorem does.
André then deliberately made the question even broader:
Is there SOME foolproof METHOD for determining
whether X halts on Y?
He explicitly said that, for this question, he was NOT restricting
"method" to computation.
You replied:
"Changing the subject"
But he told you explicitly that he was broadening the question. He was testing whether your objection was specifically about the limits of computation.
Most importantly, even if we grant your entire premise that the desired result is "outside the scope of all computation," you still have NOT
proved that the Halting Theorem asks an "incorrect question."
You have, at most, given your own reason why its answer must be NO.--
Please distinguish:
INVALID QUESTION
from:
VALID QUESTION WHOSE ANSWER IS NO.
They are not the same thing.
On 10/24/2026 7:59 PM, olcott wrote:
On 10/24/2026 6:44 PM, dbush wrote:i.e. the requirements cannot be satisfied, so you agree with Turing and Linz.
On 10/24/2026 7:41 PM, olcott wrote:
On 10/24/2026 6:33 PM, dbush wrote:
On 10/24/2026 7:23 PM, olcott wrote:
On 10/24/2026 6:02 PM, Python wrote:
Peter, repeating
That is still outside the scope of Emil Post computation.
TWENTY TIMES does not turn it into an answer.
André explicitly removed that restriction:
Is there SOME foolproof method for determining
whether X halts on Y?
X is still an executable process thus out-of-scope
of every computation because they only operate on
finite strings.
Likewise, addition is out-of-scope of every computation because
they only operate on finite strings, not actual numbers.
Agreed?
Arithmetic can be consistently converted to operations
on finite strings. The behavior of DD() executed in main
cannot be correctly represented as a finite string to HHH.
Which is another way of saying that the answer to Andre's question
above is "no" and that you agree that Turing and Linz are correct.
the question is incorrect
Peter, your own examples now demonstrate exactly the distinction I am
trying to explain to you.
On 10/24/2026 7:01 PM, Python wrote:
the question is incorrect and thus the halting theorem is incorrect
No, Peter.
The question is:
Does there exist a method that always determines
whether X(Y) halts?
If, as YOU claim, such a determination is outside the scope of every
possible computation, then the answer is:
NO.
Not:
THE QUESTION IS INCORRECT.
"Does there exist an integer whose square is 2?"
No.
Perfectly valid question.
"Does there exist a largest prime?"
No.
Perfectly valid question.
"Does there exist a halt decider satisfying the standard specification?"
No.
Perfectly valid question.
You keep treating a negative answer as evidence that the question was
invalid.
That is not a correction to the foundations of computation.
It is a failure to understand what "no" means.
HHH watches the behavior of its simulated input and
as soon as HHH sees that DD calls the same function
with the same argument twice in sequence and there
are no conditional branch instructions from the
beginning of DD until this call
this matches the
"infinite recursion" non-halting behavior pattern.
On 10/24/2026 8:08 PM, dbush wrote:
On 10/24/2026 7:59 PM, olcott wrote:
On 10/24/2026 6:44 PM, dbush wrote:i.e. the requirements cannot be satisfied, so you agree with Turing
On 10/24/2026 7:41 PM, olcott wrote:
On 10/24/2026 6:33 PM, dbush wrote:
On 10/24/2026 7:23 PM, olcott wrote:
On 10/24/2026 6:02 PM, Python wrote:
Peter, repeating
That is still outside the scope of Emil Post computation.
TWENTY TIMES does not turn it into an answer.
André explicitly removed that restriction:
Is there SOME foolproof method for determining
whether X halts on Y?
X is still an executable process thus out-of-scope
of every computation because they only operate on
finite strings.
Likewise, addition is out-of-scope of every computation because
they only operate on finite strings, not actual numbers.
Agreed?
Arithmetic can be consistently converted to operations
on finite strings. The behavior of DD() executed in main
cannot be correctly represented as a finite string to HHH.
Which is another way of saying that the answer to Andre's question
above is "no" and that you agree that Turing and Linz are correct.
the question is incorrect
and Linz.
What time is it (yes or no)? is also "undecidable"
No, Peter. It doesn't "show" that.
You have written:
Axiom 2:
Deciders must apply finite string transformation inference
steps to their finite string inputs that are relevant to the
decision criteria.
and then simply asserted:
THEREFORE most undecidable decision problems
were never actual decisions at all.
WHERE IS THE INFERENCE?
Take the Halting Problem.
The decision criterion is:
Does the computation specified by <X>,Y halt?
On 10/24/2026 9:24 PM, olcott wrote:
On 10/24/2026 8:08 PM, dbush wrote:
On 10/24/2026 7:59 PM, olcott wrote:
On 10/24/2026 6:44 PM, dbush wrote:i.e. the requirements cannot be satisfied, so you agree with Turing
On 10/24/2026 7:41 PM, olcott wrote:
On 10/24/2026 6:33 PM, dbush wrote:
On 10/24/2026 7:23 PM, olcott wrote:
On 10/24/2026 6:02 PM, Python wrote:
Peter, repeating
That is still outside the scope of Emil Post computation.
TWENTY TIMES does not turn it into an answer.
André explicitly removed that restriction:
Is there SOME foolproof method for determining
whether X halts on Y?
X is still an executable process thus out-of-scope
of every computation because they only operate on
finite strings.
Likewise, addition is out-of-scope of every computation because >>>>>>> they only operate on finite strings, not actual numbers.
Agreed?
Arithmetic can be consistently converted to operations
on finite strings. The behavior of DD() executed in main
cannot be correctly represented as a finite string to HHH.
Which is another way of saying that the answer to Andre's question
above is "no" and that you agree that Turing and Linz are correct.
the question is incorrect
and Linz.
What time is it (yes or no)? is also "undecidable"
But the question "does algorithm X with input Y halt when executed
directly" always has a correct yes or no answer, and you agreed with
Turing and Linz that no algorithm can compute that.
Peter, I paid attention to EVERY word.
That is precisely why I asked:
WHERE IS THE INFERENCE?
You have not answered.
You say the standard question is based on an "incorrect foundation."
Fine.
Then do this very simple thing.
Write YOUR corrected decision criterion for the Halting Problem.
Not "Axiom 2."
Not "relevant to the decision criteria."
THE ACTUAL DECISION CRITERION.
Complete this sentence:
Given the finite strings <X> and Y,
H must return 1 iff __________________________
and return 0 otherwise.
Fill in the blank.
Then we can compare your "corrected" problem with the standard Halting Problem and see exactly what you changed.--
Until you do that, "my replacement fixes this error" is not an argument.
It is an assertion about an undefined replacement.
And telling me to "pay 100% complete attention" to Axiom 2 cannot help, because Axiom 2 itself refers to:
"the decision criteria"
without specifying what those criteria are.
So specify them.
One sentence.
Fill in the blank.
OK. Let us take your answer LITERALLY, without paraphrasing or adding anything to it.
You wrote:
(<X>, Y) simulated by H reaches its own
simulated final state.
Inserted verbatim into the definition I asked you to complete, that gives:
Given the finite strings <X> and Y,
H must return 1 iff (<X>, Y) simulated by H
reaches its own simulated final state,
and return 0 otherwise.
Is that EXACTLY your definition?
YES or NO.
I am deliberately making no interpretation whatsoever of your words.
If YES, we will apply exactly that definition to HHH and DD next.
Given the finite strings <X> and Y,meets correct non-halting behavior pattern
H return 0 iff (<X>, Y) simulated by H
Given the finite string <X>meets correct non-halting behavior pattern
H return 0 iff <X> simulated by H
Given the finite string DDmeets correct non-halting behavior pattern
HHH return 0 iff DD simulated by HHH
OK. So the definition you gave me before was NOT actually your definition.
Fine.
Let us use this new one LITERALLY:
Given the finite string DD,
HHH returns 0 iff DD simulated by HHH
meets correct non-halting behavior pattern,
else return 1.
Now there is exactly ONE undefined expression left:
correct non-halting behavior pattern
Define "correct".
Specifically, complete this:
A behavior pattern P is a CORRECT
non-halting behavior pattern iff
__________________________________________.
Be very careful here.--
You cannot define it as, in effect,
a pattern which correctly establishes
that DD does not halt
because then your argument becomes:
HHH returns 0 when it finds a pattern
that correctly establishes non-halting.
This pattern correctly establishes non-halting.
Therefore HHH correctly returns 0.
The second statement is precisely what you have to PROVE.
Nor does repeatedly calling
DD -> HHH(DD) -> DD -> HHH(DD) -> ...
a "correct non-halting behavior pattern" prove that it is one.
So now we have finally reduced your entire claim to one question:
What EXACTLY makes that pattern "correct"?
Not what HHH does when it sees one.
Not Axiom 2.
Not Sipser's conditional statement.
Define the word "correct" in your criterion.
That is where your entire argument now lives.
On 10/24/2026 8:48 PM, Python wrote:
Peter, I paid attention to EVERY word.
That is precisely why I asked:
WHERE IS THE INFERENCE?
You have not answered.
You say the standard question is based on an "incorrect foundation."
Fine.
Then do this very simple thing.
Write YOUR corrected decision criterion for the Halting Problem.
Not "Axiom 2."
Not "relevant to the decision criteria."
THE ACTUAL DECISION CRITERION.
Complete this sentence:
Given the finite strings <X> and Y,
H must return 1 iff __________________________
and return 0 otherwise.
Fill in the blank.
I have already done this for you 150 times:
(<X>, Y) simulated by H reaches its own simulated final state.
On 10/24/2026 9:56 PM, olcott wrote:
On 10/24/2026 8:48 PM, Python wrote:
Peter, I paid attention to EVERY word.
That is precisely why I asked:
WHERE IS THE INFERENCE?
You have not answered.
You say the standard question is based on an "incorrect foundation."
Fine.
Then do this very simple thing.
Write YOUR corrected decision criterion for the Halting Problem.
Not "Axiom 2."
Not "relevant to the decision criteria."
THE ACTUAL DECISION CRITERION.
Complete this sentence:
Given the finite strings <X> and Y,
H must return 1 iff __________________________
and return 0 otherwise.
Fill in the blank.
I have already done this for you 150 times:
(<X>, Y) simulated by H reaches its own simulated final state.
That means that "H" is an additional input, and therefore means that H
is DISQUALIFIED from being a halt decider because it does not take the correct number of inputs.
On 10/24/2026 9:56 PM, olcott wrote:
On 10/24/2026 8:48 PM, Python wrote:
Peter, I paid attention to EVERY word.
That is precisely why I asked:
WHERE IS THE INFERENCE?
You have not answered.
You say the standard question is based on an "incorrect foundation."
Fine.
Then do this very simple thing.
Write YOUR corrected decision criterion for the Halting Problem.
Not "Axiom 2."
Not "relevant to the decision criteria."
THE ACTUAL DECISION CRITERION.
Complete this sentence:
Given the finite strings <X> and Y,
H must return 1 iff __________________________
and return 0 otherwise.
Fill in the blank.
I have already done this for you 150 times:
(<X>, Y) simulated by H reaches its own simulated final state.
That means that "H" is an additional input, and therefore means that H
is DISQUALIFIED from being a halt decider because it does not take the correct number of inputs.
On 10/24/2026 9:39 PM, dbush wrote:
On 10/24/2026 9:56 PM, olcott wrote:
On 10/24/2026 8:48 PM, Python wrote:
Peter, I paid attention to EVERY word.
That is precisely why I asked:
WHERE IS THE INFERENCE?
You have not answered.
You say the standard question is based on an "incorrect foundation."
Fine.
Then do this very simple thing.
Write YOUR corrected decision criterion for the Halting Problem.
Not "Axiom 2."
Not "relevant to the decision criteria."
THE ACTUAL DECISION CRITERION.
Complete this sentence:
Given the finite strings <X> and Y,
H must return 1 iff __________________________
and return 0 otherwise.
Fill in the blank.
I have already done this for you 150 times:
(<X>, Y) simulated by H reaches its own simulated final state.
That means that "H" is an additional input, and therefore means that H
is DISQUALIFIED from being a halt decider because it does not take the
correct number of inputs.
My 2022 version had the same number of inputs.
I simplified this because it was more complex
than necessary.
line 818
u32 Sipser_H(ptr2 P, ptr2 I) https://github.com/plolcott/x86utm/blob/master/Halt7.c
Peter, you still did not answer the question.
You have now defined the PATTERN:
DD calls the same function with the same argument
twice in sequence, with no conditional branch
between the beginning of DD and that call.
Fine.
I am not asking you how HHH RECOGNIZES the pattern.
I am asking what makes that pattern CORRECT evidence of non-halting.
Those are two different questions.--
Your missing inference is:
same function + same argument + no intervening branch
THEREFORE
the computation can never reach its final state.
PROVE THAT IMPLICATION.
And DD is precisely where you cannot simply assume it.
The repeatedly called function is HHH itself.
Your actual HHH(DD) recognizes the pattern, ABORTS its simulation, and RETURNS 0.
So you cannot establish that the recursive HHH(DD) will never return
merely by observing that HHH(DD) has been called again.
Whether HHH(DD) RETURNS is the very thing at issue.
In fact, you claim that it DOES return.
So please do not paste this again:
HHH watches...
same function...
same argument...
infinite recursion pattern...
We understand perfectly how you DETECT the pattern.
The unanswered question is:
WHY DOES THAT PATTERN GUARANTEE NON-HALTING
IN THE SPECIAL CASE WHERE THE REPEATED FUNCTION
IS THE VERY HHH THAT ABORTS AND RETURNS 0
WHEN IT DETECTS THAT PATTERN?
That implication — not pattern recognition — is what you need to prove.
Le 25/10/2026 à 02:39, dbush a écrit :
On 10/24/2026 9:56 PM, olcott wrote:
On 10/24/2026 8:48 PM, Python wrote:
Peter, I paid attention to EVERY word.
That is precisely why I asked:
WHERE IS THE INFERENCE?
You have not answered.
You say the standard question is based on an "incorrect foundation."
Fine.
Then do this very simple thing.
Write YOUR corrected decision criterion for the Halting Problem.
Not "Axiom 2."
Not "relevant to the decision criteria."
THE ACTUAL DECISION CRITERION.
Complete this sentence:
Given the finite strings <X> and Y,
H must return 1 iff __________________________
and return 0 otherwise.
Fill in the blank.
I have already done this for you 150 times:
(<X>, Y) simulated by H reaches its own simulated final state.
That means that "H" is an additional input, and therefore means that H
is DISQUALIFIED from being a halt decider because it does not take the
correct number of inputs.
I don't think the number of arguments is the problem here.
Peter can perfectly well write:
H(P, I)
with two arguments. The fact that he subsequently says "P simulated by
H" does not make H a third function argument.
The real problem is WHAT PROPERTY H(P,I) IS CLAIMED TO DECIDE.
Peter has now defined it as essentially:
H(P,I) returns 0 iff the simulation performed by H
matches what H calls a "correct non-halting
behavior pattern."
That is not automatically equivalent to:
P(I) does not halt.
And DD exposes precisely the difference.
For DD, Peter's HHH observes the recursive simulated pattern:
HHH -> DD -> HHH -> DD -> ...
and then the OUTER HHH aborts that simulation and returns 0.
But the HHH being simulated inside DD does not return that 0. Peter has explicitly said that this simulated computation is discarded.
So the problem is not whether his C function has one argument or two.
The problem is whether the property of H's OWN SIMULATION that Peter has defined is actually equivalent to the halting property of P(I).
That is exactly the implication he still has not proved.
Changing from
Sipser_H(P,I)
to
HHH(P)
doesn't touch that problem at all.
My 2022 version had the same number of inputs.
I simplified this because it was more complex
than necessary.
line 818
u32 Sipser_H(ptr2 P, ptr2 I) https://github.com/plolcott/x86utm/blob/master/Halt7.c
It is complete proof of non-halting.
On 10/24/2026 9:15 PM, Python wrote:
OK. So the definition you gave me before was NOT actually your
definition.
Fine.
Let us use this new one LITERALLY:
Given the finite string DD,
HHH returns 0 iff DD simulated by HHH
meets correct non-halting behavior pattern,
else return 1.
Now there is exactly ONE undefined expression left:
correct non-halting behavior pattern
Define "correct".
Specifically, complete this:
A behavior pattern P is a CORRECT
non-halting behavior pattern iff
__________________________________________.
HHH watches the behavior of its simulated input and
as soon as HHH sees that DD calls the same function
with the same argument twice in sequence and there
are no conditional branch instructions from the
beginning of DD until this call this matches the
"infinite recursion" non-halting behavior pattern.
Le 25/10/2026 à 02:47, olcott a écrit :
..
My 2022 version had the same number of inputs.
I simplified this because it was more complex
than necessary.
line 818
u32 Sipser_H(ptr2 P, ptr2 I)
https://github.com/plolcott/x86utm/blob/master/Halt7.c
Peter, I have now checked the actual current Halt7.c, rather than your description of it.
There are TWO separate problems.
First, you repeatedly describe your recursion criterion as:
same function
same argument
no conditional branch
Your code does NOT test that.
Needs_To_Be_Aborted_Trace_HH() tests:
same CALL instruction address
same CALL target
zero intervening JCCs
and immediately reports:
Infinite Recursion Detected Simulation Stopped
It does not compare the arguments.
On 2026-10-24 20:25, olcott wrote:
On 10/24/2026 9:15 PM, Python wrote:
OK. So the definition you gave me before was NOT actually your
definition.
Fine.
Let us use this new one LITERALLY:
Given the finite string DD,
HHH returns 0 iff DD simulated by HHH
meets correct non-halting behavior pattern,
else return 1.
Now there is exactly ONE undefined expression left:
correct non-halting behavior pattern
Define "correct".
Specifically, complete this:
A behavior pattern P is a CORRECT
non-halting behavior pattern iff
__________________________________________.
HHH watches the behavior of its simulated input and
as soon as HHH sees that DD calls the same function
with the same argument twice in sequence and there
are no conditional branch instructions from the
beginning of DD until this call this matches the
"infinite recursion" non-halting behavior pattern.
By that logic, foo is non-halting:
void foo2(int x) {
return;
}
void foo(void) {
int x = 1;
foo2(x);
foo2(x);
return;
}
André
On 10/24/2026 10:07 PM, Python wrote:
Le 25/10/2026 à 02:47, olcott a écrit :
..
My 2022 version had the same number of inputs.
I simplified this because it was more complex
than necessary.
line 818
u32 Sipser_H(ptr2 P, ptr2 I)
https://github.com/plolcott/x86utm/blob/master/Halt7.c
Peter, I have now checked the actual current Halt7.c, rather than your
description of it.
There are TWO separate problems.
First, you repeatedly describe your recursion criterion as:
same function
same argument
no conditional branch
Your code does NOT test that.
Needs_To_Be_Aborted_Trace_HH() tests:
same CALL instruction address
same CALL target
zero intervening JCCs
and immediately reports:
Infinite Recursion Detected Simulation Stopped
It does not compare the arguments.
Dishonest dodge away from this infallible principle:
HHH watches the behavior of its simulated input and
as soon as HHH sees that DD calls the same function
with the same argument twice in sequence and there
are no conditional branch instructions from the
beginning of DD until this call this matches the
"infinite recursion" non-halting behavior pattern.
You really make me want to scream.
Le 25/10/2026 à 02:47, olcott a écrit :
..
My 2022 version had the same number of inputs.
I simplified this because it was more complex
than necessary.
line 818
u32 Sipser_H(ptr2 P, ptr2 I)
https://github.com/plolcott/x86utm/blob/master/Halt7.c
Peter, I have now checked the actual current Halt7.c, rather than your description of it.
Peter, since you provided Halt7.c, here is a simple test I would like
you to run through your actual HHH.
Please do not modify HHH for this test.
typedef void (*fn)(void);
volatile unsigned state = 0;
volatile unsigned sink = 0;
void F(void);
void G(void);
void Done(void);
fn next[2] = { F, Done };
void Done(void)
{
sink++;
}
void G(void)
{
fn p = next[state++];
p();
sink++;
}
void F(void)
{
G();
sink++;
}
Initialize:
state = 0;
sink = 0;
and evaluate:
HHH(F)
using the same compiler, options and x86 simulation environment you use
for your other HHH examples.
Please report:
1. the value returned by HHH(F);
2. if HHH aborts the simulation, the reason/pattern reported;
3. the relevant execution trace produced by HHH.
Please run it as written first, without changing the program or the detection rules.
I'm interested in what your actual implementation reports, not in
predicting the result from either side.
On 10/24/2026 7:49 PM, Python wrote:
[...]
If I remember from some old comments with Kaz, and such. PO thinks that chopping the legs out from an infinite runner and says see, it halted?
Or did it. Sigh. Anyway, it just popped into my head.
On 10/24/2026 8:08 PM, dbush wrote:
On 10/24/2026 7:59 PM, olcott wrote:
On 10/24/2026 6:44 PM, dbush wrote:i.e. the requirements cannot be satisfied, so you agree with Turing
On 10/24/2026 7:41 PM, olcott wrote:
On 10/24/2026 6:33 PM, dbush wrote:
On 10/24/2026 7:23 PM, olcott wrote:
On 10/24/2026 6:02 PM, Python wrote:
Peter, repeating
That is still outside the scope of Emil Post computation.
TWENTY TIMES does not turn it into an answer.
André explicitly removed that restriction:
Is there SOME foolproof method for determining
whether X halts on Y?
X is still an executable process thus out-of-scope
of every computation because they only operate on
finite strings.
Likewise, addition is out-of-scope of every computation because
they only operate on finite strings, not actual numbers.
Agreed?
Arithmetic can be consistently converted to operations
on finite strings. The behavior of DD() executed in main
cannot be correctly represented as a finite string to HHH.
Which is another way of saying that the answer to Andre's question
above is "no" and that you agree that Turing and Linz are correct.
the question is incorrect
and Linz.
What time is it (yes or no)? is also "undecidable"
On 10/24/2026 7:50 PM, André G. Isaak wrote:
On 2026-10-24 18:14, olcott wrote:
On 10/24/2026 7:02 PM, André G. Isaak wrote:
On 2026-10-24 17:47, olcott wrote:Emil Post computation is Turing equivalent thus outside
On 10/24/2026 6:31 PM, André G. Isaak wrote:
On 2026-10-24 17:23, olcott wrote:
On 10/24/2026 6:02 PM, Python wrote:
Peter, repeating
That is still outside the scope of Emil Post computation.
TWENTY TIMES does not turn it into an answer.
André explicitly removed that restriction:
Is there SOME foolproof method for determining
whether X halts on Y?
X is still an executable process thus out-of-scope
of every computation because they only operate on
finite strings.
I explicitly stated I wasn't restricting myself to computations. I >>>>>> was asking about *methods*.
So you admit that the Halting Theorem is based on an
incorrect question? All but one of my reviewers simply
change the subject as soon as I proved my point.
No. I admit no such thing. And I asked you to explain *why* you
think that is a stupid question to want to know the answer to, which
you still haven't addressed. And, as I said, many very intelligent
people have asked this very question, so if you want to claim its a
stupid question, you'll need to make a *strong* case for that claim
And just saying it's outside the scrope of 'Emil Post Computation'
isn't a legitimate answer. Even if a question is outside the scope
of computation, that doesn't make it stupid to want to know its answer. >>>
the scope of Emil Post computation is outside the scope
of computation. It is too difficult to see that it is
outside the scope of all computation until:
Do you even read the posts you respond to? I said I was not
restricting the scope to computation *at all*
Changing the subject as soon as I prove my point.
As soon as I prove the halting theorem is incorrect
because it requires a result outside the scope of
computation YOU CHANGE THE SUBJECT
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,142 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 94:08:24 |
| Calls: | 14,704 |
| Calls today: | 2 |
| Files: | 186,497 |
| D/L today: |
2,665 files (888M bytes) |
| Messages: | 2,551,683 |