On 12/19/2025 4:01 PM, Richard Damon wrote:
On 12/19/25 11:13 AM, olcott wrote:
Computations: Transform finite strings by finite
string transformation rules into values or nontermination.
Deciders: Transform finite strings by finite string
transformation rules into {Accept, Reject}.
But XXX Deciders need to transform there finite string to {Accept,
Reject} in a manner that MATCHES the XXX function.
Not when there is no transformation from the input
to the required value.
https://www.researchgate.net/ publication/398878263_Deciders_Transform_finite_strings_by_finite_string_transformation_rules_into_Accept_Reject
On 12/19/25 6:13 PM, olcott wrote:
On 12/19/2025 4:01 PM, Richard Damon wrote:
On 12/19/25 11:13 AM, olcott wrote:
Computations: Transform finite strings by finite
string transformation rules into values or nontermination.
Deciders: Transform finite strings by finite string
transformation rules into {Accept, Reject}.
But XXX Deciders need to transform there finite string to {Accept,
Reject} in a manner that MATCHES the XXX function.
Not when there is no transformation from the input
to the required value.
In other words, you think UTM don't exist.
On 12/19/2025 5:20 PM, Richard Damon wrote:
On 12/19/25 6:13 PM, olcott wrote:
On 12/19/2025 4:01 PM, Richard Damon wrote:
On 12/19/25 11:13 AM, olcott wrote:
Computations: Transform finite strings by finite
string transformation rules into values or nontermination.
Deciders: Transform finite strings by finite string
transformation rules into {Accept, Reject}.
But XXX Deciders need to transform there finite string to {Accept,
Reject} in a manner that MATCHES the XXX function.
Not when there is no transformation from the input
to the required value.
In other words, you think UTM don't exist.
This boils my whole point down much more succinctly than
ever before and it is derived from standard definitions.
Computations: Transform finite strings by finite
string transformation rules into values or non-termination.
Deciders: Transform finite strings by finite string
transformation rules into {Accept, Reject}.
When UTM(P) and H.UTM(P) vary then it is H.UTM(P)
that rules because H is only required to report on
the behavior that it actual input actually specifies.
On 12/19/25 6:46 PM, olcott wrote:
On 12/19/2025 5:20 PM, Richard Damon wrote:
On 12/19/25 6:13 PM, olcott wrote:
On 12/19/2025 4:01 PM, Richard Damon wrote:
On 12/19/25 11:13 AM, olcott wrote:
Computations: Transform finite strings by finite
string transformation rules into values or nontermination.
Deciders: Transform finite strings by finite string
transformation rules into {Accept, Reject}.
But XXX Deciders need to transform there finite string to {Accept,
Reject} in a manner that MATCHES the XXX function.
Not when there is no transformation from the input
to the required value.
In other words, you think UTM don't exist.
This boils my whole point down much more succinctly than
ever before and it is derived from standard definitions.
Computations: Transform finite strings by finite
string transformation rules into values or non-termination.
Deciders: Transform finite strings by finite string
transformation rules into {Accept, Reject}.
When UTM(P) and H.UTM(P) vary then it is H.UTM(P)
that rules because H is only required to report on
the behavior that it actual input actually specifies.
Nope, because you H.UTM isn't a UTM, and thus you can't use it. You
BROKE the code with your modifications.
There *IS* a transformation from the string of the input to the
behavior, and that is of a real UTM, and that DOES match the behavior of
the direct execution of the machine it describes.
You just don't understand basics, like the meaning of the words you use,--
and that rules matter.
To try to change them is to just make yourself a liar.
On 12/19/2025 8:57 PM, Richard Damon wrote:
On 12/19/25 6:46 PM, olcott wrote:
On 12/19/2025 5:20 PM, Richard Damon wrote:
On 12/19/25 6:13 PM, olcott wrote:
On 12/19/2025 4:01 PM, Richard Damon wrote:
On 12/19/25 11:13 AM, olcott wrote:
Computations: Transform finite strings by finite
string transformation rules into values or nontermination.
Deciders: Transform finite strings by finite string
transformation rules into {Accept, Reject}.
But XXX Deciders need to transform there finite string to {Accept, >>>>>> Reject} in a manner that MATCHES the XXX function.
Not when there is no transformation from the input
to the required value.
In other words, you think UTM don't exist.
This boils my whole point down much more succinctly than
ever before and it is derived from standard definitions.
Computations: Transform finite strings by finite
string transformation rules into values or non-termination.
Deciders: Transform finite strings by finite string
transformation rules into {Accept, Reject}.
When UTM(P) and H.UTM(P) vary then it is H.UTM(P)
that rules because H is only required to report on
the behavior that it actual input actually specifies.
Nope, because you H.UTM isn't a UTM, and thus you can't use it. You
BROKE the code with your modifications.
If H is only a UTM then H(P) never halts.
If H is a UTM that simply stops after one million
steps then H reaches its final halt state and P
never reaches is final halt state.
There *IS* a transformation from the string of the input to the
behavior, and that is of a real UTM, and that DOES match the behavior
of the direct execution of the machine it describes.
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qy // accept state
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn // reject state
H.q0 rf?-nrf- rf?-nrf- reo* H.qy // accept state
H.q0 rf?-nrf- rf?-nrf- reo* H.qn // reject state
The behavior of -n applied to rf?-nrf- and H applied to rf?-nrf-
is not the same.
You just don't understand basics, like the meaning of the words you
use, and that rules matter.
To try to change them is to just make yourself a liar.
On 12/20/25 6:45 PM, olcott wrote:
On 12/20/2025 5:32 PM, Richard Damon wrote:
On 12/20/25 6:25 PM, olcott wrote:
On 12/20/2025 4:57 PM, Tristan Wibberley wrote:
On 20/12/2025 13:12, olcott wrote:
On 12/20/2025 7:01 AM, Tristan Wibberley wrote:
On 19/12/2025 23:01, olcott wrote:
Deciders: Transform finite strings by finite string
transformation rules into {Accept, Reject}.
I continue to Reject your asymmetric and functionally-loaded
labels for
the classes.
That is not any sort of actual rebuttal
it is merely a dogmatic assertion. Actual
rebuttals (even incorrect ones) require reasoning.
I gave it to you before, I think.
It is categorically impossible for this to be
incorrect:
Deciders: Transform finite string inputs by finite
string transformation rules into {Accept, Reject}.
They are not accountable for anything else.
No, you are categorically incorrect. While they may only USE a finite
string transformation, they are accoutable to the function they are
supposed to be computing.
They cannot be held accountable for any behavior
outside the scope of deciders as I have carefully
defined them. They cannot be required to bake
birthday cakes or use any psychic ability.
All that they can be required to do is transform
input finite strings into values.
And the scope of a decider is to attempt to compute the specified
mapping of input to output.
Since the mapping of a description of a Machine to whether that machine halts when run is a fully defined function/mapping, it is in scope for a decider.
It just can't be done, as that mapping is uncomputable, but that doesn't
put it out of scope.
Now, part of your problem is you don't understand that your decider has
a definite algorithm, and thus has a defined output for every input, and that is built on determinism, and not rules like "get the right answer".
Thus, this specific P CAN determine the results your SPECIFIC H will
give with itself as the input, and then do the opposite.
That make that H wrong, it doesn't make the answer a contradiction.--
It only makes the assumption that the decider as a Halt Decider an error.
On 12/20/2025 6:42 PM, Richard Damon wrote:
On 12/20/25 6:45 PM, olcott wrote:
On 12/20/2025 5:32 PM, Richard Damon wrote:
On 12/20/25 6:25 PM, olcott wrote:
On 12/20/2025 4:57 PM, Tristan Wibberley wrote:
On 20/12/2025 13:12, olcott wrote:
On 12/20/2025 7:01 AM, Tristan Wibberley wrote:
On 19/12/2025 23:01, olcott wrote:
Deciders: Transform finite strings by finite string
transformation rules into {Accept, Reject}.
I continue to Reject your asymmetric and functionally-loaded
labels for
the classes.
That is not any sort of actual rebuttal
it is merely a dogmatic assertion. Actual
rebuttals (even incorrect ones) require reasoning.
I gave it to you before, I think.
It is categorically impossible for this to be
incorrect:
Deciders: Transform finite string inputs by finite
string transformation rules into {Accept, Reject}.
They are not accountable for anything else.
No, you are categorically incorrect. While they may only USE a
finite string transformation, they are accoutable to the function
they are supposed to be computing.
They cannot be held accountable for any behavior
outside the scope of deciders as I have carefully
defined them. They cannot be required to bake
birthday cakes or use any psychic ability.
All that they can be required to do is transform
input finite strings into values.
And the scope of a decider is to attempt to compute the specified
mapping of input to output.
Deciders: Transform finite string inputs by finite
string transformation rules into {Accept, Reject}.
The input must somehow encode the value to be computed.
If it does not then the requirement is incorrect.
Since the mapping of a description of a Machine to whether that
machine halts when run is a fully defined function/mapping, it is in
scope for a decider.
You keep dodging this question.
By what correct finite string transformation rule
can HHH(DD) transform its input into the behavior
of DD simulated by HHH1?
It just can't be done, as that mapping is uncomputable, but that
doesn't put it out of scope.
Requiring to compute a mapping that does not exist
puts it out of scope.
Now, part of your problem is you don't understand that your decider
has a definite algorithm, and thus has a defined output for every
input, and that is built on determinism, and not rules like "get the
right answer".
I have had fully operational software for more than three years.
Thus, this specific P CAN determine the results your SPECIFIC H will
give with itself as the input, and then do the opposite.
If there is no mapping from the input to the required
value then the requirement is incorrect because it is
requires behavior that is out-of-scope for computation.
Deciders: Transform finite string inputs by finite
string transformation rules into {Accept, Reject}.
Requiring them to do more than that is an incorrect
requirement.
When-so-ever there are no finite string transformations
from an input into a required value the requirement is
out-of-scope for computation.
That make that H wrong, it doesn't make the answer a contradiction.
It only makes the assumption that the decider as a Halt Decider an error.
On 12/21/25 8:13 PM, olcott wrote:
On 12/21/2025 7:07 PM, Richard Damon wrote:
On 12/21/25 7:59 PM, olcott wrote:
On 12/21/2025 6:54 PM, Richard Damon wrote:
On 12/21/25 7:41 PM, olcott wrote:
On 12/21/2025 6:10 PM, Richard Damon wrote:
On 12/21/25 7:05 PM, olcott wrote:
On 12/21/2025 5:37 PM, Richard Damon wrote:
On 12/21/25 5:39 PM, olcott wrote:
On 12/20/2025 6:00 PM, Richard Damon wrote:
On 12/20/25 6:47 PM, olcott wrote:
On 12/20/2025 5:34 PM, Richard Damon wrote:
On 12/20/25 6:28 PM, olcott wrote:
On 12/20/2025 7:32 AM, Richard Damon wrote:
On 12/20/25 8:01 AM, Tristan Wibberley wrote:
On 19/12/2025 23:01, olcott wrote:
Deciders: Transform finite strings by finite string >>>>>>>>>>>>>>>>> transformation rules into {Accept, Reject}.
I continue to Reject your asymmetric and functionally- >>>>>>>>>>>>>>>> loaded labels for
the classes.
That is just one of the few accurate quotations Olcott >>>>>>>>>>>>>>> makes.
It was not a quotation. I had to piece that together >>>>>>>>>>>>>> myself from numerous sources. It took me 22 years to >>>>>>>>>>>>>> do this.
Gee, that should be something you could have found in just >>>>>>>>>>>>> a few minutes of searching. It is basic material in >>>>>>>>>>>>> Computation Theory in the introductory material on Deciders. >>>>>>>>>>>>>
They never ever phrase it exactly that way.
Look for yourself.
Really? With a very quick search I get to:
https://sites.radford.edu/~nokie/classes/420/Chap3-Langs.html >>>>>>>>>>>
None say: "finite string transformation rules"
None say: "finite string transformation rules"
None say: "finite string transformation rules"
None say: "finite string transformation rules"
Rigth, because that is the part you have wrong.
Deciders don't need to be based on "Finite String
Transformation Rules".
Try to prove this. What counter-example do you have?
As I have said, a Decider built on a RASP machine has no strings >>>>>>> at all, just a list of Numbers.
And even if you have a string based decider, just calling them
"Transformation Rules" leaves too much ambiquity, as we can
verbally describe rules that can not actually be computed, as you >>>>>>> don't limit the "atoms" that make up your transformations.
This, it excludes cases that should be allowed, and allows things >>>>>>> that should be exluded, and thus is a perfectly wrong definition. >>>>>>>
I need the simplest possible essence or I will
never be understood.
You need to start for FACTS or you will never be correct.
It seems you logic says Truth is optional.
Turing machine deciders: Transform finite string
inputs by finite string transformation rules into
{Accept, Reject} values.
Nope. Starting with your error, and you DOOM your logic.
What is the error with that one?
That they are based on some arbitrary finite string transformation
rules. There are very specific requirements to the transformations
that they can do.
I never said arbitrary. I am only wrong
if they are sometimes not based on any
finite string transformation rules at all.
You didn't restrict it, so you left it arbitary.
The "definition" of something needs to actualy define what it is.--
Defining a Playground ball as "A sphere" is incorect, as it allows many things that are not playground balls to be included.
And, Turing Machines are not describe in terms of "String
Transformations" except in very specific terms, so the definition is
just incorrect.
On 12/21/2025 7:45 PM, Richard Damon wrote:
On 12/21/25 8:13 PM, olcott wrote:
On 12/21/2025 7:07 PM, Richard Damon wrote:
On 12/21/25 7:59 PM, olcott wrote:
On 12/21/2025 6:54 PM, Richard Damon wrote:
On 12/21/25 7:41 PM, olcott wrote:
On 12/21/2025 6:10 PM, Richard Damon wrote:
On 12/21/25 7:05 PM, olcott wrote:
On 12/21/2025 5:37 PM, Richard Damon wrote:
On 12/21/25 5:39 PM, olcott wrote:
On 12/20/2025 6:00 PM, Richard Damon wrote:
On 12/20/25 6:47 PM, olcott wrote:
On 12/20/2025 5:34 PM, Richard Damon wrote:
On 12/20/25 6:28 PM, olcott wrote:
On 12/20/2025 7:32 AM, Richard Damon wrote:
On 12/20/25 8:01 AM, Tristan Wibberley wrote: >>>>>>>>>>>>>>>>> On 19/12/2025 23:01, olcott wrote:
Deciders: Transform finite strings by finite string >>>>>>>>>>>>>>>>>> transformation rules into {Accept, Reject}. >>>>>>>>>>>>>>>>>I continue to Reject your asymmetric and functionally- >>>>>>>>>>>>>>>>> loaded labels for
the classes.
That is just one of the few accurate quotations Olcott >>>>>>>>>>>>>>>> makes.
It was not a quotation. I had to piece that together >>>>>>>>>>>>>>> myself from numerous sources. It took me 22 years to >>>>>>>>>>>>>>> do this.
Gee, that should be something you could have found in just >>>>>>>>>>>>>> a few minutes of searching. It is basic material in >>>>>>>>>>>>>> Computation Theory in the introductory material on Deciders. >>>>>>>>>>>>>>
They never ever phrase it exactly that way.
Look for yourself.
Really? With a very quick search I get to:
https://sites.radford.edu/~nokie/classes/420/Chap3-Langs.html >>>>>>>>>>>>
None say: "finite string transformation rules"
None say: "finite string transformation rules"
None say: "finite string transformation rules"
None say: "finite string transformation rules"
Rigth, because that is the part you have wrong.
Deciders don't need to be based on "Finite String
Transformation Rules".
Try to prove this. What counter-example do you have?
As I have said, a Decider built on a RASP machine has no strings >>>>>>>> at all, just a list of Numbers.
And even if you have a string based decider, just calling them >>>>>>>> "Transformation Rules" leaves too much ambiquity, as we can
verbally describe rules that can not actually be computed, as >>>>>>>> you don't limit the "atoms" that make up your transformations. >>>>>>>>
This, it excludes cases that should be allowed, and allows
things that should be exluded, and thus is a perfectly wrong
definition.
I need the simplest possible essence or I will
never be understood.
You need to start for FACTS or you will never be correct.
It seems you logic says Truth is optional.
Turing machine deciders: Transform finite string
inputs by finite string transformation rules into
{Accept, Reject} values.
Nope. Starting with your error, and you DOOM your logic.
What is the error with that one?
That they are based on some arbitrary finite string transformation
rules. There are very specific requirements to the transformations
that they can do.
I never said arbitrary. I am only wrong
if they are sometimes not based on any
finite string transformation rules at all.
You didn't restrict it, so you left it arbitary.
Oh I see what you mean.
I never said anything about their intended purpose.
This was intentional.
If any intended purpose cannot be achieved by
applying finite string transformations to input
finite strings then the intended purpose is
outside of the scope of computation.
This is the entire essence of my 22 years of work
on the halting problem.
The "definition" of something needs to actualy define what it is.
Defining a Playground ball as "A sphere" is incorect, as it allows
many things that are not playground balls to be included.
And, Turing Machines are not describe in terms of "String
Transformations" except in very specific terms, so the definition is
just incorrect.
On 12/21/25 9:38 PM, olcott wrote:
On 12/21/2025 7:45 PM, Richard Damon wrote:
On 12/21/25 8:13 PM, olcott wrote:
On 12/21/2025 7:07 PM, Richard Damon wrote:
On 12/21/25 7:59 PM, olcott wrote:
On 12/21/2025 6:54 PM, Richard Damon wrote:
On 12/21/25 7:41 PM, olcott wrote:
On 12/21/2025 6:10 PM, Richard Damon wrote:
On 12/21/25 7:05 PM, olcott wrote:
On 12/21/2025 5:37 PM, Richard Damon wrote:
On 12/21/25 5:39 PM, olcott wrote:
On 12/20/2025 6:00 PM, Richard Damon wrote:
On 12/20/25 6:47 PM, olcott wrote:
On 12/20/2025 5:34 PM, Richard Damon wrote:
On 12/20/25 6:28 PM, olcott wrote:
On 12/20/2025 7:32 AM, Richard Damon wrote:
On 12/20/25 8:01 AM, Tristan Wibberley wrote: >>>>>>>>>>>>>>>>>> On 19/12/2025 23:01, olcott wrote:
Deciders: Transform finite strings by finite string >>>>>>>>>>>>>>>>>>> transformation rules into {Accept, Reject}. >>>>>>>>>>>>>>>>>>I continue to Reject your asymmetric and functionally- >>>>>>>>>>>>>>>>>> loaded labels for
the classes.
That is just one of the few accurate quotations Olcott >>>>>>>>>>>>>>>>> makes.
It was not a quotation. I had to piece that together >>>>>>>>>>>>>>>> myself from numerous sources. It took me 22 years to >>>>>>>>>>>>>>>> do this.
Gee, that should be something you could have found in >>>>>>>>>>>>>>> just a few minutes of searching. It is basic material in >>>>>>>>>>>>>>> Computation Theory in the introductory material on Deciders. >>>>>>>>>>>>>>>
They never ever phrase it exactly that way.
Look for yourself.
Really? With a very quick search I get to:
https://sites.radford.edu/~nokie/classes/420/Chap3-Langs.html >>>>>>>>>>>>>
None say: "finite string transformation rules"
None say: "finite string transformation rules"
None say: "finite string transformation rules"
None say: "finite string transformation rules"
Rigth, because that is the part you have wrong.
Deciders don't need to be based on "Finite String
Transformation Rules".
Try to prove this. What counter-example do you have?
As I have said, a Decider built on a RASP machine has no
strings at all, just a list of Numbers.
And even if you have a string based decider, just calling them >>>>>>>>> "Transformation Rules" leaves too much ambiquity, as we can >>>>>>>>> verbally describe rules that can not actually be computed, as >>>>>>>>> you don't limit the "atoms" that make up your transformations. >>>>>>>>>
This, it excludes cases that should be allowed, and allows
things that should be exluded, and thus is a perfectly wrong >>>>>>>>> definition.
I need the simplest possible essence or I will
never be understood.
You need to start for FACTS or you will never be correct.
It seems you logic says Truth is optional.
Turing machine deciders: Transform finite string
inputs by finite string transformation rules into
{Accept, Reject} values.
Nope. Starting with your error, and you DOOM your logic.
What is the error with that one?
That they are based on some arbitrary finite string transformation
rules. There are very specific requirements to the transformations
that they can do.
I never said arbitrary. I am only wrong
if they are sometimes not based on any
finite string transformation rules at all.
You didn't restrict it, so you left it arbitary.
Oh I see what you mean.
I never said anything about their intended purpose.
This was intentional.
If any intended purpose cannot be achieved by
applying finite string transformations to input
finite strings then the intended purpose is
outside of the scope of computation.
This is the entire essence of my 22 years of work
on the halting problem.
Which is just a factual error because you don't understand what the
terms mean.
They can only DO what can be done by their computations restrictions.
But the requirements are not limited by their ability, and it is
acknowledge that we can make requirements that can not be meet.
In fact, part of the goal of the field is to try to classify which types
of problems CAN be solved, and which can not.
Not understanding the purpose of the field means you are making fundamentally wrong assumptions.
On 12/21/2025 9:00 PM, Richard Damon wrote:
On 12/21/25 9:38 PM, olcott wrote:
On 12/21/2025 7:45 PM, Richard Damon wrote:
On 12/21/25 8:13 PM, olcott wrote:
On 12/21/2025 7:07 PM, Richard Damon wrote:
On 12/21/25 7:59 PM, olcott wrote:
On 12/21/2025 6:54 PM, Richard Damon wrote:
On 12/21/25 7:41 PM, olcott wrote:
On 12/21/2025 6:10 PM, Richard Damon wrote:
On 12/21/25 7:05 PM, olcott wrote:
On 12/21/2025 5:37 PM, Richard Damon wrote:
On 12/21/25 5:39 PM, olcott wrote:
On 12/20/2025 6:00 PM, Richard Damon wrote:
On 12/20/25 6:47 PM, olcott wrote:
On 12/20/2025 5:34 PM, Richard Damon wrote:
On 12/20/25 6:28 PM, olcott wrote:
On 12/20/2025 7:32 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>> On 12/20/25 8:01 AM, Tristan Wibberley wrote: >>>>>>>>>>>>>>>>>>> On 19/12/2025 23:01, olcott wrote:
Deciders: Transform finite strings by finite string >>>>>>>>>>>>>>>>>>>> transformation rules into {Accept, Reject}. >>>>>>>>>>>>>>>>>>>I continue to Reject your asymmetric and >>>>>>>>>>>>>>>>>>> functionally- loaded labels for
the classes.
That is just one of the few accurate quotations Olcott >>>>>>>>>>>>>>>>>> makes.
It was not a quotation. I had to piece that together >>>>>>>>>>>>>>>>> myself from numerous sources. It took me 22 years to >>>>>>>>>>>>>>>>> do this.
Gee, that should be something you could have found in >>>>>>>>>>>>>>>> just a few minutes of searching. It is basic material in >>>>>>>>>>>>>>>> Computation Theory in the introductory material on >>>>>>>>>>>>>>>> Deciders.
They never ever phrase it exactly that way.
Look for yourself.
Really? With a very quick search I get to:
https://sites.radford.edu/~nokie/classes/420/Chap3-Langs.html >>>>>>>>>>>>>>
None say: "finite string transformation rules"
None say: "finite string transformation rules"
None say: "finite string transformation rules"
None say: "finite string transformation rules"
Rigth, because that is the part you have wrong.
Deciders don't need to be based on "Finite String
Transformation Rules".
Try to prove this. What counter-example do you have?
As I have said, a Decider built on a RASP machine has no
strings at all, just a list of Numbers.
And even if you have a string based decider, just calling them >>>>>>>>>> "Transformation Rules" leaves too much ambiquity, as we can >>>>>>>>>> verbally describe rules that can not actually be computed, as >>>>>>>>>> you don't limit the "atoms" that make up your transformations. >>>>>>>>>>
This, it excludes cases that should be allowed, and allows >>>>>>>>>> things that should be exluded, and thus is a perfectly wrong >>>>>>>>>> definition.
I need the simplest possible essence or I will
never be understood.
You need to start for FACTS or you will never be correct.
It seems you logic says Truth is optional.
Turing machine deciders: Transform finite string
inputs by finite string transformation rules into
{Accept, Reject} values.
Nope. Starting with your error, and you DOOM your logic.
What is the error with that one?
That they are based on some arbitrary finite string transformation >>>>>> rules. There are very specific requirements to the transformations >>>>>> that they can do.
I never said arbitrary. I am only wrong
if they are sometimes not based on any
finite string transformation rules at all.
You didn't restrict it, so you left it arbitary.
Oh I see what you mean.
I never said anything about their intended purpose.
This was intentional.
If any intended purpose cannot be achieved by
applying finite string transformations to input
finite strings then the intended purpose is
outside of the scope of computation.
This is the entire essence of my 22 years of work
on the halting problem.
Which is just a factual error because you don't understand what the
terms mean.
They can only DO what can be done by their computations restrictions.
But the requirements are not limited by their ability, and it is
acknowledge that we can make requirements that can not be meet.
In fact, part of the goal of the field is to try to classify which
types of problems CAN be solved, and which can not.
Not understanding the purpose of the field means you are making
fundamentally wrong assumptions.
I spent 22 years on the notion of undecidability.
Turing machine deciders: Transform finite string
inputs by finite string transformation rules into
{Accept, Reject} values.
What-so-ever result that cannot be derived by
applying finite string transformation rules to
input finite strings <is> outside the scope of
computation.
On 12/21/25 10:19 PM, olcott wrote:No that is simply you not paying 100% complete
On 12/21/2025 9:00 PM, Richard Damon wrote:
On 12/21/25 9:38 PM, olcott wrote:
On 12/21/2025 7:45 PM, Richard Damon wrote:
On 12/21/25 8:13 PM, olcott wrote:
On 12/21/2025 7:07 PM, Richard Damon wrote:
On 12/21/25 7:59 PM, olcott wrote:
On 12/21/2025 6:54 PM, Richard Damon wrote:
On 12/21/25 7:41 PM, olcott wrote:
On 12/21/2025 6:10 PM, Richard Damon wrote:
On 12/21/25 7:05 PM, olcott wrote:
On 12/21/2025 5:37 PM, Richard Damon wrote:
On 12/21/25 5:39 PM, olcott wrote:
On 12/20/2025 6:00 PM, Richard Damon wrote:
On 12/20/25 6:47 PM, olcott wrote:
On 12/20/2025 5:34 PM, Richard Damon wrote:
On 12/20/25 6:28 PM, olcott wrote:
On 12/20/2025 7:32 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>> On 12/20/25 8:01 AM, Tristan Wibberley wrote: >>>>>>>>>>>>>>>>>>>> On 19/12/2025 23:01, olcott wrote:
Deciders: Transform finite strings by finite string >>>>>>>>>>>>>>>>>>>>> transformation rules into {Accept, Reject}. >>>>>>>>>>>>>>>>>>>>I continue to Reject your asymmetric and >>>>>>>>>>>>>>>>>>>> functionally- loaded labels for
the classes.
That is just one of the few accurate quotations >>>>>>>>>>>>>>>>>>> Olcott makes.
It was not a quotation. I had to piece that together >>>>>>>>>>>>>>>>>> myself from numerous sources. It took me 22 years to >>>>>>>>>>>>>>>>>> do this.
Gee, that should be something you could have found in >>>>>>>>>>>>>>>>> just a few minutes of searching. It is basic material >>>>>>>>>>>>>>>>> in Computation Theory in the introductory material on >>>>>>>>>>>>>>>>> Deciders.
They never ever phrase it exactly that way.
Look for yourself.
Really? With a very quick search I get to:
https://sites.radford.edu/~nokie/classes/420/Chap3- >>>>>>>>>>>>>>> Langs.html
None say: "finite string transformation rules"
None say: "finite string transformation rules"
None say: "finite string transformation rules"
None say: "finite string transformation rules"
Rigth, because that is the part you have wrong.
Deciders don't need to be based on "Finite String
Transformation Rules".
Try to prove this. What counter-example do you have?
As I have said, a Decider built on a RASP machine has no >>>>>>>>>>> strings at all, just a list of Numbers.
And even if you have a string based decider, just calling >>>>>>>>>>> them "Transformation Rules" leaves too much ambiquity, as we >>>>>>>>>>> can verbally describe rules that can not actually be
computed, as you don't limit the "atoms" that make up your >>>>>>>>>>> transformations.
This, it excludes cases that should be allowed, and allows >>>>>>>>>>> things that should be exluded, and thus is a perfectly wrong >>>>>>>>>>> definition.
I need the simplest possible essence or I will
never be understood.
You need to start for FACTS or you will never be correct.
It seems you logic says Truth is optional.
Turing machine deciders: Transform finite string
inputs by finite string transformation rules into
{Accept, Reject} values.
Nope. Starting with your error, and you DOOM your logic.
What is the error with that one?
That they are based on some arbitrary finite string
transformation rules. There are very specific requirements to the >>>>>>> transformations that they can do.
I never said arbitrary. I am only wrong
if they are sometimes not based on any
finite string transformation rules at all.
You didn't restrict it, so you left it arbitary.
Oh I see what you mean.
I never said anything about their intended purpose.
This was intentional.
If any intended purpose cannot be achieved by
applying finite string transformations to input
finite strings then the intended purpose is
outside of the scope of computation.
This is the entire essence of my 22 years of work
on the halting problem.
Which is just a factual error because you don't understand what the
terms mean.
They can only DO what can be done by their computations restrictions.
But the requirements are not limited by their ability, and it is
acknowledge that we can make requirements that can not be meet.
In fact, part of the goal of the field is to try to classify which
types of problems CAN be solved, and which can not.
Not understanding the purpose of the field means you are making
fundamentally wrong assumptions.
I spent 22 years on the notion of undecidability.
Turing machine deciders: Transform finite string
inputs by finite string transformation rules into
{Accept, Reject} values.
What-so-ever result that cannot be derived by
applying finite string transformation rules to
input finite strings <is> outside the scope of
computation.
Which, since there *IS* a procedure to get the result from the string
(the real UTM),
On 12/21/2025 10:07 PM, Richard Damon wrote:
On 12/21/25 10:19 PM, olcott wrote:No that is simply you not paying 100% complete
On 12/21/2025 9:00 PM, Richard Damon wrote:
On 12/21/25 9:38 PM, olcott wrote:
On 12/21/2025 7:45 PM, Richard Damon wrote:
On 12/21/25 8:13 PM, olcott wrote:
On 12/21/2025 7:07 PM, Richard Damon wrote:
On 12/21/25 7:59 PM, olcott wrote:
On 12/21/2025 6:54 PM, Richard Damon wrote:
On 12/21/25 7:41 PM, olcott wrote:
On 12/21/2025 6:10 PM, Richard Damon wrote:
On 12/21/25 7:05 PM, olcott wrote:
On 12/21/2025 5:37 PM, Richard Damon wrote:
On 12/21/25 5:39 PM, olcott wrote:
On 12/20/2025 6:00 PM, Richard Damon wrote:
On 12/20/25 6:47 PM, olcott wrote:
On 12/20/2025 5:34 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>> On 12/20/25 6:28 PM, olcott wrote:
On 12/20/2025 7:32 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 12/20/25 8:01 AM, Tristan Wibberley wrote: >>>>>>>>>>>>>>>>>>>>> On 19/12/2025 23:01, olcott wrote:
Deciders: Transform finite strings by finite string >>>>>>>>>>>>>>>>>>>>>> transformation rules into {Accept, Reject}. >>>>>>>>>>>>>>>>>>>>>I continue to Reject your asymmetric and >>>>>>>>>>>>>>>>>>>>> functionally- loaded labels for
the classes.
That is just one of the few accurate quotations >>>>>>>>>>>>>>>>>>>> Olcott makes.
It was not a quotation. I had to piece that together >>>>>>>>>>>>>>>>>>> myself from numerous sources. It took me 22 years to >>>>>>>>>>>>>>>>>>> do this.
Gee, that should be something you could have found in >>>>>>>>>>>>>>>>>> just a few minutes of searching. It is basic material >>>>>>>>>>>>>>>>>> in Computation Theory in the introductory material on >>>>>>>>>>>>>>>>>> Deciders.
They never ever phrase it exactly that way.
Look for yourself.
Really? With a very quick search I get to:
https://sites.radford.edu/~nokie/classes/420/Chap3- >>>>>>>>>>>>>>>> Langs.html
None say: "finite string transformation rules"
None say: "finite string transformation rules"
None say: "finite string transformation rules"
None say: "finite string transformation rules"
Rigth, because that is the part you have wrong.
Deciders don't need to be based on "Finite String >>>>>>>>>>>>>> Transformation Rules".
Try to prove this. What counter-example do you have?
As I have said, a Decider built on a RASP machine has no >>>>>>>>>>>> strings at all, just a list of Numbers.
And even if you have a string based decider, just calling >>>>>>>>>>>> them "Transformation Rules" leaves too much ambiquity, as we >>>>>>>>>>>> can verbally describe rules that can not actually be
computed, as you don't limit the "atoms" that make up your >>>>>>>>>>>> transformations.
This, it excludes cases that should be allowed, and allows >>>>>>>>>>>> things that should be exluded, and thus is a perfectly wrong >>>>>>>>>>>> definition.
I need the simplest possible essence or I will
never be understood.
You need to start for FACTS or you will never be correct.
It seems you logic says Truth is optional.
Turing machine deciders: Transform finite string
inputs by finite string transformation rules into
{Accept, Reject} values.
Nope. Starting with your error, and you DOOM your logic.
What is the error with that one?
That they are based on some arbitrary finite string
transformation rules. There are very specific requirements to >>>>>>>> the transformations that they can do.
I never said arbitrary. I am only wrong
if they are sometimes not based on any
finite string transformation rules at all.
You didn't restrict it, so you left it arbitary.
Oh I see what you mean.
I never said anything about their intended purpose.
This was intentional.
If any intended purpose cannot be achieved by
applying finite string transformations to input
finite strings then the intended purpose is
outside of the scope of computation.
This is the entire essence of my 22 years of work
on the halting problem.
Which is just a factual error because you don't understand what the
terms mean.
They can only DO what can be done by their computations restrictions.
But the requirements are not limited by their ability, and it is
acknowledge that we can make requirements that can not be meet.
In fact, part of the goal of the field is to try to classify which
types of problems CAN be solved, and which can not.
Not understanding the purpose of the field means you are making
fundamentally wrong assumptions.
I spent 22 years on the notion of undecidability.
Turing machine deciders: Transform finite string
inputs by finite string transformation rules into
{Accept, Reject} values.
What-so-ever result that cannot be derived by
applying finite string transformation rules to
input finite strings <is> outside the scope of
computation.
Which, since there *IS* a procedure to get the result from the string
(the real UTM),
attention to the exact meaning of every single word.
When LLMs make this same mistake and I tell them they
did not pay close enough attention they immediately
correct themselves.
On 12/21/25 11:24 PM, olcott wrote:
On 12/21/2025 10:07 PM, Richard Damon wrote:
On 12/21/25 10:19 PM, olcott wrote:No that is simply you not paying 100% complete
On 12/21/2025 9:00 PM, Richard Damon wrote:
On 12/21/25 9:38 PM, olcott wrote:
On 12/21/2025 7:45 PM, Richard Damon wrote:
On 12/21/25 8:13 PM, olcott wrote:
On 12/21/2025 7:07 PM, Richard Damon wrote:
On 12/21/25 7:59 PM, olcott wrote:
On 12/21/2025 6:54 PM, Richard Damon wrote:
On 12/21/25 7:41 PM, olcott wrote:
On 12/21/2025 6:10 PM, Richard Damon wrote:
On 12/21/25 7:05 PM, olcott wrote:
On 12/21/2025 5:37 PM, Richard Damon wrote:As I have said, a Decider built on a RASP machine has no >>>>>>>>>>>>> strings at all, just a list of Numbers.
On 12/21/25 5:39 PM, olcott wrote:
On 12/20/2025 6:00 PM, Richard Damon wrote:
On 12/20/25 6:47 PM, olcott wrote:
On 12/20/2025 5:34 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>> On 12/20/25 6:28 PM, olcott wrote:
On 12/20/2025 7:32 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>> On 12/20/25 8:01 AM, Tristan Wibberley wrote: >>>>>>>>>>>>>>>>>>>>>> On 19/12/2025 23:01, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>> Deciders: Transform finite strings by finite string >>>>>>>>>>>>>>>>>>>>>>> transformation rules into {Accept, Reject}. >>>>>>>>>>>>>>>>>>>>>>
I continue to Reject your asymmetric and >>>>>>>>>>>>>>>>>>>>>> functionally- loaded labels for
the classes.
That is just one of the few accurate quotations >>>>>>>>>>>>>>>>>>>>> Olcott makes.
It was not a quotation. I had to piece that together >>>>>>>>>>>>>>>>>>>> myself from numerous sources. It took me 22 years to >>>>>>>>>>>>>>>>>>>> do this.
Gee, that should be something you could have found in >>>>>>>>>>>>>>>>>>> just a few minutes of searching. It is basic material >>>>>>>>>>>>>>>>>>> in Computation Theory in the introductory material on >>>>>>>>>>>>>>>>>>> Deciders.
They never ever phrase it exactly that way. >>>>>>>>>>>>>>>>>> Look for yourself.
Really? With a very quick search I get to:
https://sites.radford.edu/~nokie/classes/420/Chap3- >>>>>>>>>>>>>>>>> Langs.html
None say: "finite string transformation rules" >>>>>>>>>>>>>>>> None say: "finite string transformation rules" >>>>>>>>>>>>>>>> None say: "finite string transformation rules" >>>>>>>>>>>>>>>> None say: "finite string transformation rules" >>>>>>>>>>>>>>>>
Rigth, because that is the part you have wrong.
Deciders don't need to be based on "Finite String >>>>>>>>>>>>>>> Transformation Rules".
Try to prove this. What counter-example do you have? >>>>>>>>>>>>>
And even if you have a string based decider, just calling >>>>>>>>>>>>> them "Transformation Rules" leaves too much ambiquity, as >>>>>>>>>>>>> we can verbally describe rules that can not actually be >>>>>>>>>>>>> computed, as you don't limit the "atoms" that make up your >>>>>>>>>>>>> transformations.
This, it excludes cases that should be allowed, and allows >>>>>>>>>>>>> things that should be exluded, and thus is a perfectly >>>>>>>>>>>>> wrong definition.
I need the simplest possible essence or I will
never be understood.
You need to start for FACTS or you will never be correct. >>>>>>>>>>>
It seems you logic says Truth is optional.
Turing machine deciders: Transform finite string
inputs by finite string transformation rules into
{Accept, Reject} values.
Nope. Starting with your error, and you DOOM your logic. >>>>>>>>>>>
What is the error with that one?
That they are based on some arbitrary finite string
transformation rules. There are very specific requirements to >>>>>>>>> the transformations that they can do.
I never said arbitrary. I am only wrong
if they are sometimes not based on any
finite string transformation rules at all.
You didn't restrict it, so you left it arbitary.
Oh I see what you mean.
I never said anything about their intended purpose.
This was intentional.
If any intended purpose cannot be achieved by
applying finite string transformations to input
finite strings then the intended purpose is
outside of the scope of computation.
This is the entire essence of my 22 years of work
on the halting problem.
Which is just a factual error because you don't understand what the >>>>> terms mean.
They can only DO what can be done by their computations restrictions. >>>>>
But the requirements are not limited by their ability, and it is
acknowledge that we can make requirements that can not be meet.
In fact, part of the goal of the field is to try to classify which
types of problems CAN be solved, and which can not.
Not understanding the purpose of the field means you are making
fundamentally wrong assumptions.
I spent 22 years on the notion of undecidability.
Turing machine deciders: Transform finite string
inputs by finite string transformation rules into
{Accept, Reject} values.
What-so-ever result that cannot be derived by
applying finite string transformation rules to
input finite strings <is> outside the scope of
computation.
Which, since there *IS* a procedure to get the result from the string
(the real UTM),
attention to the exact meaning of every single word.
Your problem is you don't know the meaning of the words, as defined in
the context you are talking.
When LLMs make this same mistake and I tell them they
did not pay close enough attention they immediately
correct themselves.
Because they are just yes-men, and not sources of truth.
All you have done is gathered liars to your (the LLM) to tell you what--
you want to believe so you don't have to confront the truth.
That just lets you try to live in your world of lies.
On 12/22/2025 9:10 AM, Richard Damon wrote:
On 12/21/25 11:24 PM, olcott wrote:
On 12/21/2025 10:07 PM, Richard Damon wrote:
On 12/21/25 10:19 PM, olcott wrote:No that is simply you not paying 100% complete
On 12/21/2025 9:00 PM, Richard Damon wrote:
On 12/21/25 9:38 PM, olcott wrote:
On 12/21/2025 7:45 PM, Richard Damon wrote:
On 12/21/25 8:13 PM, olcott wrote:
On 12/21/2025 7:07 PM, Richard Damon wrote:
On 12/21/25 7:59 PM, olcott wrote:
On 12/21/2025 6:54 PM, Richard Damon wrote:
On 12/21/25 7:41 PM, olcott wrote:
On 12/21/2025 6:10 PM, Richard Damon wrote:
On 12/21/25 7:05 PM, olcott wrote:
On 12/21/2025 5:37 PM, Richard Damon wrote:As I have said, a Decider built on a RASP machine has no >>>>>>>>>>>>>> strings at all, just a list of Numbers.
On 12/21/25 5:39 PM, olcott wrote:
On 12/20/2025 6:00 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>> On 12/20/25 6:47 PM, olcott wrote:
On 12/20/2025 5:34 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 12/20/25 6:28 PM, olcott wrote:
On 12/20/2025 7:32 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>> On 12/20/25 8:01 AM, Tristan Wibberley wrote: >>>>>>>>>>>>>>>>>>>>>>> On 19/12/2025 23:01, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>> Deciders: Transform finite strings by finite string >>>>>>>>>>>>>>>>>>>>>>>> transformation rules into {Accept, Reject}. >>>>>>>>>>>>>>>>>>>>>>>
I continue to Reject your asymmetric and >>>>>>>>>>>>>>>>>>>>>>> functionally- loaded labels for
the classes.
That is just one of the few accurate quotations >>>>>>>>>>>>>>>>>>>>>> Olcott makes.
It was not a quotation. I had to piece that together >>>>>>>>>>>>>>>>>>>>> myself from numerous sources. It took me 22 years to >>>>>>>>>>>>>>>>>>>>> do this.
Gee, that should be something you could have found >>>>>>>>>>>>>>>>>>>> in just a few minutes of searching. It is basic >>>>>>>>>>>>>>>>>>>> material in Computation Theory in the introductory >>>>>>>>>>>>>>>>>>>> material on Deciders.
They never ever phrase it exactly that way. >>>>>>>>>>>>>>>>>>> Look for yourself.
Really? With a very quick search I get to: >>>>>>>>>>>>>>>>>>
https://sites.radford.edu/~nokie/classes/420/Chap3- >>>>>>>>>>>>>>>>>> Langs.html
None say: "finite string transformation rules" >>>>>>>>>>>>>>>>> None say: "finite string transformation rules" >>>>>>>>>>>>>>>>> None say: "finite string transformation rules" >>>>>>>>>>>>>>>>> None say: "finite string transformation rules" >>>>>>>>>>>>>>>>>
Rigth, because that is the part you have wrong. >>>>>>>>>>>>>>>>
Deciders don't need to be based on "Finite String >>>>>>>>>>>>>>>> Transformation Rules".
Try to prove this. What counter-example do you have? >>>>>>>>>>>>>>
And even if you have a string based decider, just calling >>>>>>>>>>>>>> them "Transformation Rules" leaves too much ambiquity, as >>>>>>>>>>>>>> we can verbally describe rules that can not actually be >>>>>>>>>>>>>> computed, as you don't limit the "atoms" that make up your >>>>>>>>>>>>>> transformations.
This, it excludes cases that should be allowed, and allows >>>>>>>>>>>>>> things that should be exluded, and thus is a perfectly >>>>>>>>>>>>>> wrong definition.
I need the simplest possible essence or I will
never be understood.
You need to start for FACTS or you will never be correct. >>>>>>>>>>>>
It seems you logic says Truth is optional.
Turing machine deciders: Transform finite string
inputs by finite string transformation rules into
{Accept, Reject} values.
Nope. Starting with your error, and you DOOM your logic. >>>>>>>>>>>>
What is the error with that one?
That they are based on some arbitrary finite string
transformation rules. There are very specific requirements to >>>>>>>>>> the transformations that they can do.
I never said arbitrary. I am only wrong
if they are sometimes not based on any
finite string transformation rules at all.
You didn't restrict it, so you left it arbitary.
Oh I see what you mean.
I never said anything about their intended purpose.
This was intentional.
If any intended purpose cannot be achieved by
applying finite string transformations to input
finite strings then the intended purpose is
outside of the scope of computation.
This is the entire essence of my 22 years of work
on the halting problem.
Which is just a factual error because you don't understand what
the terms mean.
They can only DO what can be done by their computations restrictions. >>>>>>
But the requirements are not limited by their ability, and it is
acknowledge that we can make requirements that can not be meet.
In fact, part of the goal of the field is to try to classify which >>>>>> types of problems CAN be solved, and which can not.
Not understanding the purpose of the field means you are making
fundamentally wrong assumptions.
I spent 22 years on the notion of undecidability.
Turing machine deciders: Transform finite string
inputs by finite string transformation rules into
{Accept, Reject} values.
What-so-ever result that cannot be derived by
applying finite string transformation rules to
input finite strings <is> outside the scope of
computation.
Which, since there *IS* a procedure to get the result from the
string (the real UTM),
attention to the exact meaning of every single word.
Your problem is you don't know the meaning of the words, as defined in
the context you are talking.
When LLMs make this same mistake and I tell them they
did not pay close enough attention they immediately
correct themselves.
Because they are just yes-men, and not sources of truth.
Carol's question + my Prolog are a convincing combination https://www.researchgate.net/ publication/398953475_Carol's_question_my_Prolog_are_a_convincing_combination
All you have done is gathered liars to your (the LLM) to tell you what
you want to believe so you don't have to confront the truth.
That just lets you try to live in your world of lies.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 54 |
| Nodes: | 6 (1 / 5) |
| Uptime: | 21:16:11 |
| Calls: | 742 |
| Files: | 1,218 |
| D/L today: |
6 files (8,794K bytes) |
| Messages: | 186,029 |
| Posted today: | 1 |