All of the textbooks require halt deciders to
report on the behavior of machine M on input w.
This may be easy to understand yet not precisely
accurate.
Since no Turing machine ever takes any Machine
M as an input this <is> a category error even
when this makes no functional difference.
They simply glossed over this key detail because
they thought that it made no difference.
*Defining a halt decider with perfect accuracy*
Turing machine halt deciders compute the mapping
from input finite strings to an {accept, reject}
value on the basis of the behavior that this
input finite string specifies.
On 12/13/2025 3:32 PM, olcott wrote:
All of the textbooks require halt deciders to
report on the behavior of machine M on input w.
This may be easy to understand yet not precisely
accurate.
Since no Turing machine ever takes any Machine
M as an input this <is> a category error even
when this makes no functional difference.
They simply glossed over this key detail because
they thought that it made no difference.
*Defining a halt decider with perfect accuracy*
Turing machine halt deciders compute the mapping
from input finite strings to an {accept, reject}
value on the basis of the behavior that this
input finite string specifies.
By simply adding more detail we can make the
original definition more precise:
A Turing machine based halt decider reports on the
behavior of machine M on input w thorough the
proxy of the finite string machine description of
⟨M⟩ on input w.
The above seems to be more precisely accurate
than any published proof. It includes a key
detail that all of them seem to leave out.
If you know of any published proof that directly
refers to the idea of a proxy, please let me know.
On 12/13/25 5:41 PM, olcott wrote:
On 12/13/2025 3:32 PM, olcott wrote:
All of the textbooks require halt deciders to
report on the behavior of machine M on input w.
This may be easy to understand yet not precisely
accurate.
Since no Turing machine ever takes any Machine
M as an input this <is> a category error even
when this makes no functional difference.
They simply glossed over this key detail because
they thought that it made no difference.
*Defining a halt decider with perfect accuracy*
Turing machine halt deciders compute the mapping
from input finite strings to an {accept, reject}
value on the basis of the behavior that this
input finite string specifies.
By simply adding more detail we can make the
original definition more precise:
A Turing machine based halt decider reports on the
behavior of machine M on input w thorough the
proxy of the finite string machine description of
⟨M⟩ on input w.
The above seems to be more precisely accurate
than any published proof. It includes a key
detail that all of them seem to leave out.
If you know of any published proof that directly
refers to the idea of a proxy, please let me know.
And the use of a string proxy is just normally assumed by the theory, as that is how Turing Machine work.
They almost ALWAYS work by a string representation proxy, as very few--
real questions are based on the "arbitrary" symbol set of the Turing Machines native operation.
If you had bothered to learn the basics of the field, you would have understood that.
Most works assume the basic knowledge of the field.
Note, even the Linz proof you mention explicitly talks about giving the decider a representation of the machine in question, the Wm as the proxy
for giving it M.
So, why did you not understand the use of a proxy.
Sometimes the problem when expressed for lay people will talk about the decider being given a description or representation of the machine.
You just reject those as you think it too vague, when it is a well
defined term, and even the general meaning is applicable, you just need
to remember that it must be a SUFFICIENT description to convey the
needed details of the machine.
On 12/13/2025 5:02 PM, Richard Damon wrote:
On 12/13/25 5:41 PM, olcott wrote:
On 12/13/2025 3:32 PM, olcott wrote:
All of the textbooks require halt deciders to
report on the behavior of machine M on input w.
This may be easy to understand yet not precisely
accurate.
Since no Turing machine ever takes any Machine
M as an input this <is> a category error even
when this makes no functional difference.
They simply glossed over this key detail because
they thought that it made no difference.
*Defining a halt decider with perfect accuracy*
Turing machine halt deciders compute the mapping
from input finite strings to an {accept, reject}
value on the basis of the behavior that this
input finite string specifies.
By simply adding more detail we can make the
original definition more precise:
A Turing machine based halt decider reports on the
behavior of machine M on input w thorough the
proxy of the finite string machine description of
⟨M⟩ on input w.
The above seems to be more precisely accurate
than any published proof. It includes a key
detail that all of them seem to leave out.
If you know of any published proof that directly
refers to the idea of a proxy, please let me know.
And the use of a string proxy is just normally assumed by the theory,
as that is how Turing Machine work.
See that three agreements in one day.
That may be more than we have ever had.
Because none of the textbooks ever directly said
that the finite string input is only a proxy for
the behavior everyone always took the proxy to be
exactly one-and-the-same thing as the actual behavior.
They almost ALWAYS work by a string representation proxy, as very few
real questions are based on the "arbitrary" symbol set of the Turing
Machines native operation.
If you had bothered to learn the basics of the field, you would have
understood that.
Most works assume the basic knowledge of the field.
Note, even the Linz proof you mention explicitly talks about giving
the decider a representation of the machine in question, the Wm as the
proxy for giving it M.
So, why did you not understand the use of a proxy.
Sometimes the problem when expressed for lay people will talk about
the decider being given a description or representation of the machine.
You just reject those as you think it too vague, when it is a well
defined term, and even the general meaning is applicable, you just
need to remember that it must be a SUFFICIENT description to convey
the needed details of the machine.
On 12/13/25 9:30 PM, olcott wrote:
On 12/13/2025 5:02 PM, Richard Damon wrote:
On 12/13/25 5:41 PM, olcott wrote:
On 12/13/2025 3:32 PM, olcott wrote:
All of the textbooks require halt deciders to
report on the behavior of machine M on input w.
This may be easy to understand yet not precisely
accurate.
Since no Turing machine ever takes any Machine
M as an input this <is> a category error even
when this makes no functional difference.
They simply glossed over this key detail because
they thought that it made no difference.
*Defining a halt decider with perfect accuracy*
Turing machine halt deciders compute the mapping
from input finite strings to an {accept, reject}
value on the basis of the behavior that this
input finite string specifies.
By simply adding more detail we can make the
original definition more precise:
A Turing machine based halt decider reports on the
behavior of machine M on input w thorough the
proxy of the finite string machine description of
⟨M⟩ on input w.
The above seems to be more precisely accurate
than any published proof. It includes a key
detail that all of them seem to leave out.
If you know of any published proof that directly
refers to the idea of a proxy, please let me know.
And the use of a string proxy is just normally assumed by the theory,
as that is how Turing Machine work.
See that three agreements in one day.
That may be more than we have ever had.
Because none of the textbooks ever directly said
that the finite string input is only a proxy for
the behavior everyone always took the proxy to be
exactly one-and-the-same thing as the actual behavior.
But the behavior represented by the string *IS* exactly the behavior of
the string, so you attempted point just falls flat.
And, as I said, even your Linz book made that clear, as H took as it
input Wm (the string) not M (the machine).
Also, if you did any real study, you would have learned that the input
to the machine is almost always just a "represemtation" of the input to
the function, as we rarely are really interested in computing a result
on the strings.
The one exception is the very earliest exercises where you learn basic string manipulation with Turing Machines, but you rapidly get to wanting
to do things like "arithmatic" and then learning you need to REPRESENT numbers as something. (and a common method which baffled you as I
remember was unary, you wanted your Turing Machine to use UNICODE as it symbol set.
They almost ALWAYS work by a string representation proxy, as very few
real questions are based on the "arbitrary" symbol set of the Turing
Machines native operation.
If you had bothered to learn the basics of the field, you would have
understood that.
Most works assume the basic knowledge of the field.
Note, even the Linz proof you mention explicitly talks about giving
the decider a representation of the machine in question, the Wm as
the proxy for giving it M.
So, why did you not understand the use of a proxy.
Sometimes the problem when expressed for lay people will talk about
the decider being given a description or representation of the machine.
You just reject those as you think it too vague, when it is a well
defined term, and even the general meaning is applicable, you just
need to remember that it must be a SUFFICIENT description to convey
the needed details of the machine.
On 12/13/2025 8:56 PM, Richard Damon wrote:
On 12/13/25 9:30 PM, olcott wrote:
On 12/13/2025 5:02 PM, Richard Damon wrote:
On 12/13/25 5:41 PM, olcott wrote:
On 12/13/2025 3:32 PM, olcott wrote:
All of the textbooks require halt deciders to
report on the behavior of machine M on input w.
This may be easy to understand yet not precisely
accurate.
Since no Turing machine ever takes any Machine
M as an input this <is> a category error even
when this makes no functional difference.
They simply glossed over this key detail because
they thought that it made no difference.
*Defining a halt decider with perfect accuracy*
Turing machine halt deciders compute the mapping
from input finite strings to an {accept, reject}
value on the basis of the behavior that this
input finite string specifies.
By simply adding more detail we can make the
original definition more precise:
A Turing machine based halt decider reports on the
behavior of machine M on input w thorough the
proxy of the finite string machine description of
⟨M⟩ on input w.
The above seems to be more precisely accurate
than any published proof. It includes a key
detail that all of them seem to leave out.
If you know of any published proof that directly
refers to the idea of a proxy, please let me know.
And the use of a string proxy is just normally assumed by the
theory, as that is how Turing Machine work.
See that three agreements in one day.
That may be more than we have ever had.
Because none of the textbooks ever directly said
that the finite string input is only a proxy for
the behavior everyone always took the proxy to be
exactly one-and-the-same thing as the actual behavior.
But the behavior represented by the string *IS* exactly the behavior
of the string, so you attempted point just falls flat.
Do you really think that I will keep going
on this for 22 years if it just falls flat?
Google Groups has a much better search so
you can see the 40,000 messages that I posted
in comp.theory since 2004.
My very first Halting Problem post Jun 6, 2004, 9:11:19 AM
Alan Turing's Halting Problem is incorrectly formed
It has lots and lots of replies. https://groups.google.com/g/sci.logic/c/V7wzVvx8IMw/m/ggPE6a-60cUJ
And, as I said, even your Linz book made that clear, as H took as it
input Wm (the string) not M (the machine).
That is not the issue. All the textbooks say that.
The issue is that this finite string AS AN INPUT
is the ultimate basis of the halt decision even
when it is not a good proxy for the behavior of
the executed machine.
On 12/13/25 10:39 PM, olcott wrote:
On 12/13/2025 8:56 PM, Richard Damon wrote:
On 12/13/25 9:30 PM, olcott wrote:
On 12/13/2025 5:02 PM, Richard Damon wrote:
On 12/13/25 5:41 PM, olcott wrote:
On 12/13/2025 3:32 PM, olcott wrote:
All of the textbooks require halt deciders to
report on the behavior of machine M on input w.
This may be easy to understand yet not precisely
accurate.
Since no Turing machine ever takes any Machine
M as an input this <is> a category error even
when this makes no functional difference.
They simply glossed over this key detail because
they thought that it made no difference.
*Defining a halt decider with perfect accuracy*
Turing machine halt deciders compute the mapping
from input finite strings to an {accept, reject}
value on the basis of the behavior that this
input finite string specifies.
By simply adding more detail we can make the
original definition more precise:
A Turing machine based halt decider reports on the
behavior of machine M on input w thorough the
proxy of the finite string machine description of
⟨M⟩ on input w.
The above seems to be more precisely accurate
than any published proof. It includes a key
detail that all of them seem to leave out.
If you know of any published proof that directly
refers to the idea of a proxy, please let me know.
And the use of a string proxy is just normally assumed by the
theory, as that is how Turing Machine work.
See that three agreements in one day.
That may be more than we have ever had.
Because none of the textbooks ever directly said
that the finite string input is only a proxy for
the behavior everyone always took the proxy to be
exactly one-and-the-same thing as the actual behavior.
But the behavior represented by the string *IS* exactly the behavior
of the string, so you attempted point just falls flat.
Do you really think that I will keep going
on this for 22 years if it just falls flat?
It seems you have.
Google Groups has a much better search so
you can see the 40,000 messages that I posted
in comp.theory since 2004.
My very first Halting Problem post Jun 6, 2004, 9:11:19 AM
Alan Turing's Halting Problem is incorrectly formed
It has lots and lots of replies.
https://groups.google.com/g/sci.logic/c/V7wzVvx8IMw/m/ggPE6a-60cUJ
But it isn't, and you haven't been able to show it, because you never
knew what you were talking about.
And, as I said, even your Linz book made that clear, as H took as it
input Wm (the string) not M (the machine).
That is not the issue. All the textbooks say that.
No, you just don't know how to read them.
As I pointed out. Your Linz make the detail clear if you actually
understand what you are reading.
Text Books are written assuming the reader has met the prerequisites for
the course, and will be suplemented by the instructor.
Clearly you don't meet that requirement.
Part of your problem is it seems you jumped your understanding level,
and ignored basic Computation Theory and an introduction into Turing Machines, and thus don't understand the material you did read.
This was clear a few years ago when you tried to learn how Turing
Machine worked and just went off the rails and refused to actually learn
the basics.
The issue is that this finite string AS AN INPUT
is the ultimate basis of the halt decision even
when it is not a good proxy for the behavior of
the executed machine.
And why would it not be?
If the user gives it the wrong data, they can't expect the right answer.
If the input isn't a representation of a Halting Program, then the halt decider must reject, as it only accepts inputs that represent Halting Programs.
That is the nature of such a decider. (Perhaps a more--
complicated one could have a third output for input has a syntactic/ grammatical error that makes it not the representation of a program)
If it is a representation of some different program then was intended,
then it is correct to answer about the program that the input represents.
So, your case isn't a refutation.
All you are doing is showing your ignorance of the topic.
... the use of a string proxy is just normally assumed by the theory, as
that is how Turing Machine work.
They almost ALWAYS work by a string representation proxy, as very few
real questions are based on the "arbitrary" symbol set of the Turing
Machines native operation.
If you had bothered to learn the basics of the field, you would have understood that.
Most works assume the basic knowledge of the field.
On 12/13/2025 9:50 PM, Richard Damon wrote:
On 12/13/25 10:39 PM, olcott wrote:
On 12/13/2025 8:56 PM, Richard Damon wrote:
On 12/13/25 9:30 PM, olcott wrote:
On 12/13/2025 5:02 PM, Richard Damon wrote:
On 12/13/25 5:41 PM, olcott wrote:
On 12/13/2025 3:32 PM, olcott wrote:
All of the textbooks require halt deciders to
report on the behavior of machine M on input w.
This may be easy to understand yet not precisely
accurate.
Since no Turing machine ever takes any Machine
M as an input this <is> a category error even
when this makes no functional difference.
They simply glossed over this key detail because
they thought that it made no difference.
*Defining a halt decider with perfect accuracy*
Turing machine halt deciders compute the mapping
from input finite strings to an {accept, reject}
value on the basis of the behavior that this
input finite string specifies.
By simply adding more detail we can make the
original definition more precise:
A Turing machine based halt decider reports on the
behavior of machine M on input w thorough the
proxy of the finite string machine description of
⟨M⟩ on input w.
The above seems to be more precisely accurate
than any published proof. It includes a key
detail that all of them seem to leave out.
If you know of any published proof that directly
refers to the idea of a proxy, please let me know.
And the use of a string proxy is just normally assumed by the
theory, as that is how Turing Machine work.
See that three agreements in one day.
That may be more than we have ever had.
Because none of the textbooks ever directly said
that the finite string input is only a proxy for
the behavior everyone always took the proxy to be
exactly one-and-the-same thing as the actual behavior.
But the behavior represented by the string *IS* exactly the behavior
of the string, so you attempted point just falls flat.
Do you really think that I will keep going
on this for 22 years if it just falls flat?
It seems you have.
Google Groups has a much better search so
you can see the 40,000 messages that I posted
in comp.theory since 2004.
My very first Halting Problem post Jun 6, 2004, 9:11:19 AM
Alan Turing's Halting Problem is incorrectly formed
It has lots and lots of replies.
https://groups.google.com/g/sci.logic/c/V7wzVvx8IMw/m/ggPE6a-60cUJ
But it isn't, and you haven't been able to show it, because you never
knew what you were talking about.
And, as I said, even your Linz book made that clear, as H took as it
input Wm (the string) not M (the machine).
That is not the issue. All the textbooks say that.
No, you just don't know how to read them.
As I pointed out. Your Linz make the detail clear if you actually
understand what you are reading.
Text Books are written assuming the reader has met the prerequisites
for the course, and will be suplemented by the instructor.
Clearly you don't meet that requirement.
Part of your problem is it seems you jumped your understanding level,
and ignored basic Computation Theory and an introduction into Turing
Machines, and thus don't understand the material you did read.
This was clear a few years ago when you tried to learn how Turing
Machine worked and just went off the rails and refused to actually
learn the basics.
The issue is that this finite string AS AN INPUT
is the ultimate basis of the halt decision even
when it is not a good proxy for the behavior of
the executed machine.
And why would it not be?
If the user gives it the wrong data, they can't expect the right answer.
If the input isn't a representation of a Halting Program, then the
halt decider must reject, as it only accepts inputs that represent
Halting Programs.
There is only one correct measure of the behavior
that a finite string AS AN INPUT specifies.
Everyone has missed this because none of the
textbooks EMPHASIZED that the finite string
AS AN INPUT is only a proxy for what the halting
problem asks for.
That is the nature of such a decider. (Perhaps a more complicated one
could have a third output for input has a syntactic/ grammatical error
that makes it not the representation of a program)
If it is a representation of some different program then was intended,
then it is correct to answer about the program that the input represents.
So, your case isn't a refutation.
All you are doing is showing your ignorance of the topic.
On 13/12/2025 23:02, Richard Damon wrote:
... the use of a string proxy is just normally assumed by the theory, as
that is how Turing Machine work.
They almost ALWAYS work by a string representation proxy, as very few
real questions are based on the "arbitrary" symbol set of the Turing
Machines native operation.
If you had bothered to learn the basics of the field, you would have
understood that.
Most works assume the basic knowledge of the field.
I just checked Turings "On computable numbers":
"We may compare a man in the process of computing a real number to a
machine which is only capable of a finite number of conditions q1: q2.
.... qI;
which will be called ' m-configurations '"
He has restricted the problem to those machines that are not real
because real machines are supposed to be capable of an infinite number
of conditions.
However, his definition of "tape" doesn't clearly exclude real ribbons (perhaps that's why he chose the word "tape") but he does say "analogue
of paper" and has establish discrete unreal models as the domain of discussion.
On close inspection I think it's fair to say Turing's machines are
entirely unreal and do not occupy spacetime.
On 12/13/25 11:42 PM, Tristan Wibberley wrote:
On 13/12/2025 22:31, Richard Damon wrote:
... the representation of the machine can be used to determine the
behavior of the machine.
How do you thing a UTM works?
I think it's clear he thinks it doesn't, not /exactly/.
But his proof depends on his decider being "based on" a UTM (with
additions) and thus qualifies to demonstrate the behavior.
On 13/12/2025 23:32, olcott wrote:
All of the textbooks require halt deciders to
report on the behavior of machine M on input w.
This may be easy to understand yet not precisely
accurate.
That is precisely accurate. The problem is exactly what the problem
statement says. You may define your problem differently but then
you just have another problem. The halting problem still is what
it was.
On 12/14/2025 6:15 AM, Richard Damon wrote:
On 12/13/25 11:42 PM, Tristan Wibberley wrote:
On 13/12/2025 22:31, Richard Damon wrote:
... the representation of the machine can be used to determine the
behavior of the machine.
How do you thing a UTM works?
I think it's clear he thinks it doesn't, not /exactly/.
But his proof depends on his decider being "based on" a UTM (with
additions) and thus qualifies to demonstrate the behavior.
The simulation of DD as an input to HHH derives
different behavior than the simulation of DD by
HHH1 because DD calls HHH in recursive simulation
and DD does not call HHH1 at all.
HHH must simulate an instance of itself simulating
an instance of DD that eventually calls yet another
instance of HHH(DD). HHH recognizes that this would
repeat forever if it did not intervene.
HHH1 simulates DD that calls HHH(DD) that returns
0 to this instance of DD.
I have been explaining this to people here for
years and they never get it. Now that I have
formulated first principles they might be able
to finally see.
On 12/14/2025 3:56 AM, Mikko wrote:
On 13/12/2025 23:32, olcott wrote:
All of the textbooks require halt deciders to
report on the behavior of machine M on input w.
This may be easy to understand yet not precisely
accurate.
That is precisely accurate. The problem is exactly what the problem
statement says. You may define your problem differently but then
you just have another problem. The halting problem still is what
it was.
All the textbooks simply ignore that no Turing
machine can possibly compute the mapping from
the behavior from another actual Turing machine.
They can only compute the mapping from a finite
string input that is a mere proxy for this behavior.
They all wrote it up less accurately because it
was easier to understand and they assumed that
it made no difference.
On 12/14/25 11:32 AM, olcott wrote:
On 12/14/2025 3:56 AM, Mikko wrote:
On 13/12/2025 23:32, olcott wrote:
All of the textbooks require halt deciders to
report on the behavior of machine M on input w.
This may be easy to understand yet not precisely
accurate.
That is precisely accurate. The problem is exactly what the problem
statement says. You may define your problem differently but then
you just have another problem. The halting problem still is what
it was.
All the textbooks simply ignore that no Turing
machine can possibly compute the mapping from
the behavior from another actual Turing machine.
Sure it can, from the representation of it.
Just like it can add two numbers by using representatins.
They can only compute the mapping from a finite
string input that is a mere proxy for this behavior.
And the proxy represents that same behavior, so it must get the same
result.
--
They all wrote it up less accurately because it
was easier to understand and they assumed that
it made no difference.
Be4 cause it does make no difference, unless your logic assumes that you
are allowed to lie about things.
On 12/14/2025 1:55 PM, Richard Damon wrote:
On 12/14/25 11:32 AM, olcott wrote:
On 12/14/2025 3:56 AM, Mikko wrote:
On 13/12/2025 23:32, olcott wrote:
All of the textbooks require halt deciders to
report on the behavior of machine M on input w.
This may be easy to understand yet not precisely
accurate.
That is precisely accurate. The problem is exactly what the problem
statement says. You may define your problem differently but then
you just have another problem. The halting problem still is what
it was.
All the textbooks simply ignore that no Turing
machine can possibly compute the mapping from
the behavior from another actual Turing machine.
Sure it can, from the representation of it.
Just like it can add two numbers by using representatins.
They can only compute the mapping from a finite
string input that is a mere proxy for this behavior.
And the proxy represents that same behavior, so it must get the same
result.
As I have conclusively proved many thousands of
times that the behavior of DD AS AN ACTUAL INPUT
to HHH does SPECIFY non-halting behavior.
You only believe otherwise because all of the
textbooks glossed over that halt deciders never
ever directly report on the behavior of Turing
machines. Instead they report on behavior through
the proxy of finite string INPUTS.
Because of this when the proxy specifies behavior
different than the behavior of the machine you
incorrectly assume that the proxy is wrong and
the machine is right.
They all wrote it up less accurately because it
was easier to understand and they assumed that
it made no difference.
Be4 cause it does make no difference, unless your logic assumes that
you are allowed to lie about things.
On 12/14/2025 1:55 PM, Richard Damon wrote:
On 12/14/25 11:32 AM, olcott wrote:
On 12/14/2025 3:56 AM, Mikko wrote:
On 13/12/2025 23:32, olcott wrote:
All of the textbooks require halt deciders to
report on the behavior of machine M on input w.
This may be easy to understand yet not precisely
accurate.
That is precisely accurate. The problem is exactly what the problem
statement says. You may define your problem differently but then
you just have another problem. The halting problem still is what
it was.
All the textbooks simply ignore that no Turing
machine can possibly compute the mapping from
the behavior from another actual Turing machine.
Sure it can, from the representation of it.
Just like it can add two numbers by using representatins.
They can only compute the mapping from a finite
string input that is a mere proxy for this behavior.
And the proxy represents that same behavior, so it must get the same
result.
As I have conclusively proved many thousands of
times that the behavior of DD AS AN ACTUAL INPUT
to HHH does SPECIFY non-halting behavior.
You only believe otherwise because all of the
textbooks glossed over that halt deciders never
ever directly report on the behavior of Turing
machines. Instead they report on behavior through
the proxy of finite string INPUTS.
Because of this when the proxy specifies behavior
different than the behavior of the machine you
incorrectly assume that the proxy is wrong and
the machine is right.
On 12/14/25 3:57 PM, olcott wrote:I say that I have proven this
On 12/14/2025 1:55 PM, Richard Damon wrote:
On 12/14/25 11:32 AM, olcott wrote:
On 12/14/2025 3:56 AM, Mikko wrote:
On 13/12/2025 23:32, olcott wrote:
All of the textbooks require halt deciders to
report on the behavior of machine M on input w.
This may be easy to understand yet not precisely
accurate.
That is precisely accurate. The problem is exactly what the problem
statement says. You may define your problem differently but then
you just have another problem. The halting problem still is what
it was.
All the textbooks simply ignore that no Turing
machine can possibly compute the mapping from
the behavior from another actual Turing machine.
Sure it can, from the representation of it.
Just like it can add two numbers by using representatins.
They can only compute the mapping from a finite
string input that is a mere proxy for this behavior.
And the proxy represents that same behavior, so it must get the same
result.
As I have conclusively proved many thousands of
times that the behavior of DD AS AN ACTUAL INPUT
to HHH does SPECIFY non-halting behavior.
No you haven't,
On 12/14/2025 6:13 PM, Richard Damon wrote:
On 12/14/25 3:57 PM, olcott wrote:I say that I have proven this
On 12/14/2025 1:55 PM, Richard Damon wrote:
On 12/14/25 11:32 AM, olcott wrote:
On 12/14/2025 3:56 AM, Mikko wrote:
On 13/12/2025 23:32, olcott wrote:
All of the textbooks require halt deciders to
report on the behavior of machine M on input w.
This may be easy to understand yet not precisely
accurate.
That is precisely accurate. The problem is exactly what the problem >>>>>> statement says. You may define your problem differently but then
you just have another problem. The halting problem still is what
it was.
All the textbooks simply ignore that no Turing
machine can possibly compute the mapping from
the behavior from another actual Turing machine.
Sure it can, from the representation of it.
Just like it can add two numbers by using representatins.
They can only compute the mapping from a finite
string input that is a mere proxy for this behavior.
And the proxy represents that same behavior, so it must get the same
result.
As I have conclusively proved many thousands of
times that the behavior of DD AS AN ACTUAL INPUT
to HHH does SPECIFY non-halting behavior.
No you haven't,
DD AS AN INPUT TO HHH(DD)
and your rebuttal is ALWAYS I am wrong because
DD NOT AS AN INPUT TO HHH(DD)
has different behavior.
It is like you have no idea that
[NOT TRUE] and [TRUE] are not exactly the same thing
On 12/14/25 7:39 PM, olcott wrote:
On 12/14/2025 6:13 PM, Richard Damon wrote:
On 12/14/25 3:57 PM, olcott wrote:I say that I have proven this
On 12/14/2025 1:55 PM, Richard Damon wrote:
On 12/14/25 11:32 AM, olcott wrote:
On 12/14/2025 3:56 AM, Mikko wrote:
On 13/12/2025 23:32, olcott wrote:
All of the textbooks require halt deciders to
report on the behavior of machine M on input w.
This may be easy to understand yet not precisely
accurate.
That is precisely accurate. The problem is exactly what the problem >>>>>>> statement says. You may define your problem differently but then >>>>>>> you just have another problem. The halting problem still is what >>>>>>> it was.
All the textbooks simply ignore that no Turing
machine can possibly compute the mapping from
the behavior from another actual Turing machine.
Sure it can, from the representation of it.
Just like it can add two numbers by using representatins.
They can only compute the mapping from a finite
string input that is a mere proxy for this behavior.
And the proxy represents that same behavior, so it must get the
same result.
As I have conclusively proved many thousands of
times that the behavior of DD AS AN ACTUAL INPUT
to HHH does SPECIFY non-halting behavior.
No you haven't,
DD AS AN INPUT TO HHH(DD)
Right, which has a specific meaning based on the representation
definition that HHH uses, and that meaning applies everywhere that representation is used.
Does the meaning of an objective statement change based on who you say
it to?
and your rebuttal is ALWAYS I am wrong because
DD NOT AS AN INPUT TO HHH(DD)
has different behavior.
But it is the same DD, in the same context.
It is like you have no idea that
[NOT TRUE] and [TRUE] are not exactly the same thing
But they aren't the same string, so it is just a bad example.
"Apples are normally Red", has that meaning in all spots using the same vocabulary and grammar.
Or, do you claim there is no UTM that uses the same representation as
HHH to use to test it, even though it was built based on one.
On 12/14/2025 6:58 PM, Richard Damon wrote:
On 12/14/25 7:39 PM, olcott wrote:
On 12/14/2025 6:13 PM, Richard Damon wrote:
On 12/14/25 3:57 PM, olcott wrote:I say that I have proven this
On 12/14/2025 1:55 PM, Richard Damon wrote:
On 12/14/25 11:32 AM, olcott wrote:
On 12/14/2025 3:56 AM, Mikko wrote:
On 13/12/2025 23:32, olcott wrote:
All of the textbooks require halt deciders to
report on the behavior of machine M on input w.
This may be easy to understand yet not precisely
accurate.
That is precisely accurate. The problem is exactly what the problem >>>>>>>> statement says. You may define your problem differently but then >>>>>>>> you just have another problem. The halting problem still is what >>>>>>>> it was.
All the textbooks simply ignore that no Turing
machine can possibly compute the mapping from
the behavior from another actual Turing machine.
Sure it can, from the representation of it.
Just like it can add two numbers by using representatins.
They can only compute the mapping from a finite
string input that is a mere proxy for this behavior.
And the proxy represents that same behavior, so it must get the
same result.
As I have conclusively proved many thousands of
times that the behavior of DD AS AN ACTUAL INPUT
to HHH does SPECIFY non-halting behavior.
No you haven't,
DD AS AN INPUT TO HHH(DD)
Right, which has a specific meaning based on the representation
definition that HHH uses, and that meaning applies everywhere that
representation is used.
Does the meaning of an objective statement change based on who you say
it to?
and your rebuttal is ALWAYS I am wrong because
DD NOT AS AN INPUT TO HHH(DD)
has different behavior.
But it is the same DD, in the same context.
It is like you have no idea that
[NOT TRUE] and [TRUE] are not exactly the same thing
But they aren't the same string, so it is just a bad example.
DD as an input to HHH has different
behavior than DD as an input to HHH1.
Halt deciders are only required to map the
behavior that their actual input actually
specifies to a halt status.
On 12/14/2025 6:13 PM, Richard Damon wrote:
On 12/14/25 3:57 PM, olcott wrote:I say that I have proven this
On 12/14/2025 1:55 PM, Richard Damon wrote:
On 12/14/25 11:32 AM, olcott wrote:
On 12/14/2025 3:56 AM, Mikko wrote:
On 13/12/2025 23:32, olcott wrote:
All of the textbooks require halt deciders to
report on the behavior of machine M on input w.
This may be easy to understand yet not precisely
accurate.
That is precisely accurate. The problem is exactly what the problem >>>>>> statement says. You may define your problem differently but then
you just have another problem. The halting problem still is what
it was.
All the textbooks simply ignore that no Turing
machine can possibly compute the mapping from
the behavior from another actual Turing machine.
Sure it can, from the representation of it.
Just like it can add two numbers by using representatins.
They can only compute the mapping from a finite
string input that is a mere proxy for this behavior.
And the proxy represents that same behavior, so it must get the same
result.
As I have conclusively proved many thousands of
times that the behavior of DD AS AN ACTUAL INPUT
to HHH does SPECIFY non-halting behavior.
No you haven't,
DD AS AN INPUT TO HHH(DD)
On 15/12/2025 02:39, olcott wrote:
On 12/14/2025 6:13 PM, Richard Damon wrote:
On 12/14/25 3:57 PM, olcott wrote:I say that I have proven this
On 12/14/2025 1:55 PM, Richard Damon wrote:
On 12/14/25 11:32 AM, olcott wrote:
On 12/14/2025 3:56 AM, Mikko wrote:
On 13/12/2025 23:32, olcott wrote:
All of the textbooks require halt deciders to
report on the behavior of machine M on input w.
This may be easy to understand yet not precisely
accurate.
That is precisely accurate. The problem is exactly what the problem >>>>>>> statement says. You may define your problem differently but then >>>>>>> you just have another problem. The halting problem still is what >>>>>>> it was.
All the textbooks simply ignore that no Turing
machine can possibly compute the mapping from
the behavior from another actual Turing machine.
Sure it can, from the representation of it.
Just like it can add two numbers by using representatins.
They can only compute the mapping from a finite
string input that is a mere proxy for this behavior.
And the proxy represents that same behavior, so it must get the
same result.
As I have conclusively proved many thousands of
times that the behavior of DD AS AN ACTUAL INPUT
to HHH does SPECIFY non-halting behavior.
No you haven't,
DD AS AN INPUT TO HHH(DD)
You keep repeating that the meaning of DD as imput ot HHH is different
from the meaning of DD per se. But you never say what that different
meaning is.
More importantly, you never tell what input to HHH would mean the
same as DD per se so HHH is not a halt decider and is not relevant
to any discossion about halt deciders.
On 12/15/2025 3:10 AM, Mikko wrote:
On 15/12/2025 02:39, olcott wrote:
On 12/14/2025 6:13 PM, Richard Damon wrote:
On 12/14/25 3:57 PM, olcott wrote:I say that I have proven this
On 12/14/2025 1:55 PM, Richard Damon wrote:
On 12/14/25 11:32 AM, olcott wrote:
On 12/14/2025 3:56 AM, Mikko wrote:
On 13/12/2025 23:32, olcott wrote:
All of the textbooks require halt deciders to
report on the behavior of machine M on input w.
This may be easy to understand yet not precisely
accurate.
That is precisely accurate. The problem is exactly what the problem >>>>>>>> statement says. You may define your problem differently but then >>>>>>>> you just have another problem. The halting problem still is what >>>>>>>> it was.
All the textbooks simply ignore that no Turing
machine can possibly compute the mapping from
the behavior from another actual Turing machine.
Sure it can, from the representation of it.
Just like it can add two numbers by using representatins.
They can only compute the mapping from a finite
string input that is a mere proxy for this behavior.
And the proxy represents that same behavior, so it must get the
same result.
As I have conclusively proved many thousands of
times that the behavior of DD AS AN ACTUAL INPUT
to HHH does SPECIFY non-halting behavior.
No you haven't,
DD AS AN INPUT TO HHH(DD)
You keep repeating that the meaning of DD as imput ot HHH is different
from the meaning of DD per se. But you never say what that different
meaning is.
Or I do say it 500 times and you never notice.
DD simulated by HHH according to the semantics of C
cannot possibly reach its own "return" statement
final halt state.
More importantly, you never tell what input to HHH would mean the
same as DD per se so HHH is not a halt decider and is not relevant
to any discossion about halt deciders.
On 12/15/25 9:05 AM, olcott wrote:
On 12/15/2025 3:10 AM, Mikko wrote:
On 15/12/2025 02:39, olcott wrote:
On 12/14/2025 6:13 PM, Richard Damon wrote:
On 12/14/25 3:57 PM, olcott wrote:I say that I have proven this
On 12/14/2025 1:55 PM, Richard Damon wrote:
On 12/14/25 11:32 AM, olcott wrote:
On 12/14/2025 3:56 AM, Mikko wrote:
On 13/12/2025 23:32, olcott wrote:
All of the textbooks require halt deciders to
report on the behavior of machine M on input w.
This may be easy to understand yet not precisely
accurate.
That is precisely accurate. The problem is exactly what the >>>>>>>>> problem
statement says. You may define your problem differently but then >>>>>>>>> you just have another problem. The halting problem still is what >>>>>>>>> it was.
All the textbooks simply ignore that no Turing
machine can possibly compute the mapping from
the behavior from another actual Turing machine.
Sure it can, from the representation of it.
Just like it can add two numbers by using representatins.
They can only compute the mapping from a finite
string input that is a mere proxy for this behavior.
And the proxy represents that same behavior, so it must get the >>>>>>> same result.
As I have conclusively proved many thousands of
times that the behavior of DD AS AN ACTUAL INPUT
to HHH does SPECIFY non-halting behavior.
No you haven't,
DD AS AN INPUT TO HHH(DD)
You keep repeating that the meaning of DD as imput ot HHH is different
from the meaning of DD per se. But you never say what that different
meaning is.
Or I do say it 500 times and you never notice.
DD simulated by HHH according to the semantics of C
cannot possibly reach its own "return" statement
final halt state.
Which is a lie, as HHH doesn't simulate the input by the semantic of C,
as it doesn't correctly simulate the "HHH(DD)" instruction, as it thinks
HHH is something differnt that what it must actually be.
Or, DD doesn't HAVE behavior by the C language, since HHH isn't part of
the input.
More importantly, you never tell what input to HHH would mean the
same as DD per se so HHH is not a halt decider and is not relevant
to any discossion about halt deciders.
On 12/15/2025 6:17 PM, Richard Damon wrote:
On 12/15/25 9:05 AM, olcott wrote:
On 12/15/2025 3:10 AM, Mikko wrote:
On 15/12/2025 02:39, olcott wrote:
On 12/14/2025 6:13 PM, Richard Damon wrote:
On 12/14/25 3:57 PM, olcott wrote:I say that I have proven this
On 12/14/2025 1:55 PM, Richard Damon wrote:
On 12/14/25 11:32 AM, olcott wrote:
On 12/14/2025 3:56 AM, Mikko wrote:
On 13/12/2025 23:32, olcott wrote:
All of the textbooks require halt deciders to
report on the behavior of machine M on input w.
This may be easy to understand yet not precisely
accurate.
That is precisely accurate. The problem is exactly what the >>>>>>>>>> problem
statement says. You may define your problem differently but then >>>>>>>>>> you just have another problem. The halting problem still is what >>>>>>>>>> it was.
All the textbooks simply ignore that no Turing
machine can possibly compute the mapping from
the behavior from another actual Turing machine.
Sure it can, from the representation of it.
Just like it can add two numbers by using representatins.
They can only compute the mapping from a finite
string input that is a mere proxy for this behavior.
And the proxy represents that same behavior, so it must get the >>>>>>>> same result.
As I have conclusively proved many thousands of
times that the behavior of DD AS AN ACTUAL INPUT
to HHH does SPECIFY non-halting behavior.
No you haven't,
DD AS AN INPUT TO HHH(DD)
You keep repeating that the meaning of DD as imput ot HHH is different >>>> from the meaning of DD per se. But you never say what that different
meaning is.
Or I do say it 500 times and you never notice.
DD simulated by HHH according to the semantics of C
cannot possibly reach its own "return" statement
final halt state.
Which is a lie, as HHH doesn't simulate the input by the semantic of
C, as it doesn't correctly simulate the "HHH(DD)" instruction, as it
thinks HHH is something differnt that what it must actually be.
So you you think that HHH thinks that the call
from DD to HHH(DD) is a bowl of spaghetti?
Or, DD doesn't HAVE behavior by the C language, since HHH isn't part
of the input.
More importantly, you never tell what input to HHH would mean the
same as DD per se so HHH is not a halt decider and is not relevant
to any discossion about halt deciders.
On 12/15/25 8:31 PM, olcott wrote:
On 12/15/2025 6:17 PM, Richard Damon wrote:
On 12/15/25 9:05 AM, olcott wrote:
On 12/15/2025 3:10 AM, Mikko wrote:
On 15/12/2025 02:39, olcott wrote:
On 12/14/2025 6:13 PM, Richard Damon wrote:
On 12/14/25 3:57 PM, olcott wrote:I say that I have proven this
On 12/14/2025 1:55 PM, Richard Damon wrote:
On 12/14/25 11:32 AM, olcott wrote:
On 12/14/2025 3:56 AM, Mikko wrote:
On 13/12/2025 23:32, olcott wrote:
All of the textbooks require halt deciders to
report on the behavior of machine M on input w.
This may be easy to understand yet not precisely
accurate.
That is precisely accurate. The problem is exactly what the >>>>>>>>>>> problem
statement says. You may define your problem differently but then >>>>>>>>>>> you just have another problem. The halting problem still is what >>>>>>>>>>> it was.
All the textbooks simply ignore that no Turing
machine can possibly compute the mapping from
the behavior from another actual Turing machine.
Sure it can, from the representation of it.
Just like it can add two numbers by using representatins.
They can only compute the mapping from a finite
string input that is a mere proxy for this behavior.
And the proxy represents that same behavior, so it must get the >>>>>>>>> same result.
As I have conclusively proved many thousands of
times that the behavior of DD AS AN ACTUAL INPUT
to HHH does SPECIFY non-halting behavior.
No you haven't,
DD AS AN INPUT TO HHH(DD)
You keep repeating that the meaning of DD as imput ot HHH is different >>>>> from the meaning of DD per se. But you never say what that different >>>>> meaning is.
Or I do say it 500 times and you never notice.
DD simulated by HHH according to the semantics of C
cannot possibly reach its own "return" statement
final halt state.
Which is a lie, as HHH doesn't simulate the input by the semantic of
C, as it doesn't correctly simulate the "HHH(DD)" instruction, as it
thinks HHH is something differnt that what it must actually be.
So you you think that HHH thinks that the call
from DD to HHH(DD) is a bowl of spaghetti?
No, because HHH doesn't "Think", but it clearly simulates it wrong, as
it doesn't make it act like the real HHH.
It is clear that YOU think
that HHH doesn't actually mean that HHH, as you keep on changing what
your think HHH is, just showing your don't know the meaning of your words.
Your problem is you can't define what HHH actually does and then have it follow that to get your answer, as your world is just based on lying.
You don't seem to understand a fundamental principle of a program, that
it actually only does what it has been programmed for. Since the only
real code for HHH has the abort in it, that IS what HHH does, and your reasoning about HHH must include that behavior, or you are just lying to yourself, and then beleiving your own lies.
Or, DD doesn't HAVE behavior by the C language, since HHH isn't part
of the input.
More importantly, you never tell what input to HHH would mean the
same as DD per se so HHH is not a halt decider and is not relevant
to any discossion about halt deciders.
On 12/15/2025 9:22 PM, Richard Damon wrote:
On 12/15/25 8:31 PM, olcott wrote:
On 12/15/2025 6:17 PM, Richard Damon wrote:
On 12/15/25 9:05 AM, olcott wrote:
On 12/15/2025 3:10 AM, Mikko wrote:
On 15/12/2025 02:39, olcott wrote:
On 12/14/2025 6:13 PM, Richard Damon wrote:
On 12/14/25 3:57 PM, olcott wrote:I say that I have proven this
On 12/14/2025 1:55 PM, Richard Damon wrote:
On 12/14/25 11:32 AM, olcott wrote:
On 12/14/2025 3:56 AM, Mikko wrote:
On 13/12/2025 23:32, olcott wrote:
All of the textbooks require halt deciders to
report on the behavior of machine M on input w.
This may be easy to understand yet not precisely
accurate.
That is precisely accurate. The problem is exactly what the >>>>>>>>>>>> problem
statement says. You may define your problem differently but >>>>>>>>>>>> then
you just have another problem. The halting problem still is >>>>>>>>>>>> what
it was.
All the textbooks simply ignore that no Turing
machine can possibly compute the mapping from
the behavior from another actual Turing machine.
Sure it can, from the representation of it.
Just like it can add two numbers by using representatins.
They can only compute the mapping from a finite
string input that is a mere proxy for this behavior.
And the proxy represents that same behavior, so it must get >>>>>>>>>> the same result.
As I have conclusively proved many thousands of
times that the behavior of DD AS AN ACTUAL INPUT
to HHH does SPECIFY non-halting behavior.
No you haven't,
DD AS AN INPUT TO HHH(DD)
You keep repeating that the meaning of DD as imput ot HHH is
different
from the meaning of DD per se. But you never say what that different >>>>>> meaning is.
Or I do say it 500 times and you never notice.
DD simulated by HHH according to the semantics of C
cannot possibly reach its own "return" statement
final halt state.
Which is a lie, as HHH doesn't simulate the input by the semantic of
C, as it doesn't correctly simulate the "HHH(DD)" instruction, as it
thinks HHH is something differnt that what it must actually be.
So you you think that HHH thinks that the call
from DD to HHH(DD) is a bowl of spaghetti?
No, because HHH doesn't "Think", but it clearly simulates it wrong, as
it doesn't make it act like the real HHH.
I am just going to have to rewrite this as a
C interpreter.
HHH.exe *is* a (not yet implemented) C interpreter.
It can correctly interpret a source file test.c
that only contains DD.
It knows that HHH is itself and it understands that
the argument to HHH(DD) refers to the text of DD.
It is clear that YOU think that HHH doesn't actually mean that HHH, as
you keep on changing what your think HHH is, just showing your don't
know the meaning of your words.
Your problem is you can't define what HHH actually does and then have
it follow that to get your answer, as your world is just based on lying.
You don't seem to understand a fundamental principle of a program,
that it actually only does what it has been programmed for. Since the
only real code for HHH has the abort in it, that IS what HHH does, and
your reasoning about HHH must include that behavior, or you are just
lying to yourself, and then beleiving your own lies.
Or, DD doesn't HAVE behavior by the C language, since HHH isn't part
of the input.
More importantly, you never tell what input to HHH would mean the
same as DD per se so HHH is not a halt decider and is not relevant >>>>>> to any discossion about halt deciders.
On 12/15/2025 9:10 PM, Richard Damon wrote:
[...]
Is a C compiler a real program? ;^)
On 12/15/2025 3:10 AM, Mikko wrote:
On 15/12/2025 02:39, olcott wrote:
On 12/14/2025 6:13 PM, Richard Damon wrote:
On 12/14/25 3:57 PM, olcott wrote:I say that I have proven this
On 12/14/2025 1:55 PM, Richard Damon wrote:
On 12/14/25 11:32 AM, olcott wrote:
On 12/14/2025 3:56 AM, Mikko wrote:
On 13/12/2025 23:32, olcott wrote:
All of the textbooks require halt deciders to
report on the behavior of machine M on input w.
This may be easy to understand yet not precisely
accurate.
That is precisely accurate. The problem is exactly what the problem >>>>>>>> statement says. You may define your problem differently but then >>>>>>>> you just have another problem. The halting problem still is what >>>>>>>> it was.
All the textbooks simply ignore that no Turing
machine can possibly compute the mapping from
the behavior from another actual Turing machine.
Sure it can, from the representation of it.
Just like it can add two numbers by using representatins.
They can only compute the mapping from a finite
string input that is a mere proxy for this behavior.
And the proxy represents that same behavior, so it must get the
same result.
As I have conclusively proved many thousands of
times that the behavior of DD AS AN ACTUAL INPUT
to HHH does SPECIFY non-halting behavior.
No you haven't,
DD AS AN INPUT TO HHH(DD)
You keep repeating that the meaning of DD as imput ot HHH is different
from the meaning of DD per se. But you never say what that different
meaning is.
Or I do say it 500 times and you never notice.
DD simulated by HHH according to the semantics of C
cannot possibly reach its own "return" statement
final halt state.
On 15/12/2025 16:05, olcott wrote:
On 12/15/2025 3:10 AM, Mikko wrote:
On 15/12/2025 02:39, olcott wrote:
On 12/14/2025 6:13 PM, Richard Damon wrote:
On 12/14/25 3:57 PM, olcott wrote:I say that I have proven this
On 12/14/2025 1:55 PM, Richard Damon wrote:
On 12/14/25 11:32 AM, olcott wrote:
On 12/14/2025 3:56 AM, Mikko wrote:
On 13/12/2025 23:32, olcott wrote:
All of the textbooks require halt deciders to
report on the behavior of machine M on input w.
This may be easy to understand yet not precisely
accurate.
That is precisely accurate. The problem is exactly what the >>>>>>>>> problem
statement says. You may define your problem differently but then >>>>>>>>> you just have another problem. The halting problem still is what >>>>>>>>> it was.
All the textbooks simply ignore that no Turing
machine can possibly compute the mapping from
the behavior from another actual Turing machine.
Sure it can, from the representation of it.
Just like it can add two numbers by using representatins.
They can only compute the mapping from a finite
string input that is a mere proxy for this behavior.
And the proxy represents that same behavior, so it must get the >>>>>>> same result.
As I have conclusively proved many thousands of
times that the behavior of DD AS AN ACTUAL INPUT
to HHH does SPECIFY non-halting behavior.
No you haven't,
DD AS AN INPUT TO HHH(DD)
You keep repeating that the meaning of DD as imput ot HHH is different
from the meaning of DD per se. But you never say what that different
meaning is.
Or I do say it 500 times and you never notice.
You are right, i have never noticed a pointer to any of those 500.
DD simulated by HHH according to the semantics of C
cannot possibly reach its own "return" statement
final halt state.
And you still don't say.
On 12/16/25 12:47 AM, Chris M. Thomasson wrote:
On 12/15/2025 9:10 PM, Richard Damon wrote:
[...]
Is a C compiler a real program? ;^)
It likely would be.
But a not-yet implemented C compiler isn't, nor a source file that
depends on calling, and thus including the code of such a thing.
On 12/17/2025 4:07 AM, Mikko wrote:
On 15/12/2025 16:05, olcott wrote:
On 12/15/2025 3:10 AM, Mikko wrote:
On 15/12/2025 02:39, olcott wrote:
On 12/14/2025 6:13 PM, Richard Damon wrote:
On 12/14/25 3:57 PM, olcott wrote:I say that I have proven this
On 12/14/2025 1:55 PM, Richard Damon wrote:
On 12/14/25 11:32 AM, olcott wrote:
On 12/14/2025 3:56 AM, Mikko wrote:
On 13/12/2025 23:32, olcott wrote:
All of the textbooks require halt deciders to
report on the behavior of machine M on input w.
This may be easy to understand yet not precisely
accurate.
That is precisely accurate. The problem is exactly what the >>>>>>>>>> problem
statement says. You may define your problem differently but then >>>>>>>>>> you just have another problem. The halting problem still is what >>>>>>>>>> it was.
All the textbooks simply ignore that no Turing
machine can possibly compute the mapping from
the behavior from another actual Turing machine.
Sure it can, from the representation of it.
Just like it can add two numbers by using representatins.
They can only compute the mapping from a finite
string input that is a mere proxy for this behavior.
And the proxy represents that same behavior, so it must get the >>>>>>>> same result.
As I have conclusively proved many thousands of
times that the behavior of DD AS AN ACTUAL INPUT
to HHH does SPECIFY non-halting behavior.
No you haven't,
DD AS AN INPUT TO HHH(DD)
You keep repeating that the meaning of DD as imput ot HHH is different >>>> from the meaning of DD per se. But you never say what that different
meaning is.
Or I do say it 500 times and you never notice.
You are right, i have never noticed a pointer to any of those 500.
DD simulated by HHH according to the semantics of C
cannot possibly reach its own "return" statement
final halt state.
And you still don't say.
(a) TMs only transform input finite strings to values
using finite string transformation rules.
(b) There exists no alternative more definitive measure
of the behavior that the input to H(P) specifies (within
finite string transformation rules) than P simulated by H.
On 17/12/2025 16:06, olcott wrote:
On 12/17/2025 4:07 AM, Mikko wrote:
On 15/12/2025 16:05, olcott wrote:
On 12/15/2025 3:10 AM, Mikko wrote:
On 15/12/2025 02:39, olcott wrote:
On 12/14/2025 6:13 PM, Richard Damon wrote:
On 12/14/25 3:57 PM, olcott wrote:I say that I have proven this
On 12/14/2025 1:55 PM, Richard Damon wrote:
On 12/14/25 11:32 AM, olcott wrote:
On 12/14/2025 3:56 AM, Mikko wrote:
On 13/12/2025 23:32, olcott wrote:
All of the textbooks require halt deciders to
report on the behavior of machine M on input w.
This may be easy to understand yet not precisely
accurate.
That is precisely accurate. The problem is exactly what the >>>>>>>>>>> problem
statement says. You may define your problem differently but then >>>>>>>>>>> you just have another problem. The halting problem still is what >>>>>>>>>>> it was.
All the textbooks simply ignore that no Turing
machine can possibly compute the mapping from
the behavior from another actual Turing machine.
Sure it can, from the representation of it.
Just like it can add two numbers by using representatins.
They can only compute the mapping from a finite
string input that is a mere proxy for this behavior.
And the proxy represents that same behavior, so it must get the >>>>>>>>> same result.
As I have conclusively proved many thousands of
times that the behavior of DD AS AN ACTUAL INPUT
to HHH does SPECIFY non-halting behavior.
No you haven't,
DD AS AN INPUT TO HHH(DD)
You keep repeating that the meaning of DD as imput ot HHH is different >>>>> from the meaning of DD per se. But you never say what that different >>>>> meaning is.
Or I do say it 500 times and you never notice.
You are right, i have never noticed a pointer to any of those 500.
DD simulated by HHH according to the semantics of C
cannot possibly reach its own "return" statement
final halt state.
And you still don't say.
(a) TMs only transform input finite strings to values
using finite string transformation rules.
(b) There exists no alternative more definitive measure
of the behavior that the input to H(P) specifies (within
finite string transformation rules) than P simulated by H.
Nothing new there.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,090 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 63:14:23 |
| Calls: | 13,949 |
| Calls today: | 2 |
| Files: | 187,035 |
| D/L today: |
3,464 files (1,014M bytes) |
| Messages: | 2,461,403 |