On 04/07/2026 05:37, olcott wrote:
On 7/3/2026 9:19 PM, dbush wrote:
On 7/3/2026 10:05 PM, olcott wrote:
On 7/3/2026 8:58 PM, dbush wrote:
On 7/3/2026 9:52 PM, olcott wrote:
On 7/3/2026 5:51 PM, André G. Isaak wrote:The mathematical halting function:
On 2026-07-03 16:37, olcott wrote:
On 7/3/2026 1:47 PM, André G. Isaak wrote:
On 2026-07-03 12:36, olcott wrote:
On 7/3/2026 1:18 PM, dbush wrote:
If an algorithm takes an input and produces an output, that >>>>>>>>>>> is by definition a mapping.That only proves that the definition is incoherent.
The coherent way that it actually works is that
inputs are transformed into outputs by applying
finite string transformation rules to inputs to
derive outputs.
Apparently you don't understand the difference between a
mapping and an algorithm. They are two different things.
André
A function that ignores its input and only returns 0
is not any sort of halt function.
He was defining 'mapping', not 'halt function'.
André
A actual halt function must compute
When you actually implement this concretely
We find that it is not possible, as Linz and others have proved.
Impossible requirements are incorrect requirements.
There is no well known meaning of "incorrect requirements".
On 03/07/2026 21:45, olcott wrote:
On 7/3/2026 1:27 PM, dbush wrote:
On 7/3/2026 2:10 PM, olcott wrote:int Not_A_Mapping(int X)
On 7/3/2026 12:10 PM, dbush wrote:
On 7/3/2026 12:52 PM, olcott wrote:Ignoring the input IS NOT A MAPPING
On 7/3/2026 10:50 AM, dbush wrote:
On 7/3/2026 11:36 AM, olcott wrote:
On 7/3/2026 4:22 AM, Mikko wrote:
On 02/07/2026 17:51, olcott wrote:
Do you know enough about C to understand that
dbush example was foolish nonsense when proposed
to show the halting problem counter-example?
It is a valid example of a C program. It was present as a part >>>>>>>>> of a
claim about you, and your response was the false claim that "That >>>>>>>>> is just nonsense". Later in the discussion you offer more evidence >>>>>>>>> to support his claim.
His halt decider did not look at its input.
Nor is it required to. All it needs to do is map inputs to outputs. >>>>>>>
So a piece of metal sitting on the ground is an automobile.
Does algorithm H map machine description X and machine input Y to
an output of either 0 or 1?
A mapping is nothing more than an association of inputs to outputs,
{
return 0;
}
By construing that as a mapping is one of the screw-ups
that prevents true expressed in language from being computable.
By construing the above mapping as a non-mapping you disconnect from
Common Languge and lose your ablility to communicate.
On 03/07/2026 22:08, olcott wrote:
On 7/3/2026 1:27 PM, dbush wrote:
On 7/3/2026 2:10 PM, olcott wrote:
On 7/3/2026 12:10 PM, dbush wrote:
On 7/3/2026 12:52 PM, olcott wrote:Ignoring the input IS NOT A MAPPING
On 7/3/2026 10:50 AM, dbush wrote:
On 7/3/2026 11:36 AM, olcott wrote:
On 7/3/2026 4:22 AM, Mikko wrote:
On 02/07/2026 17:51, olcott wrote:
Do you know enough about C to understand that
dbush example was foolish nonsense when proposed
to show the halting problem counter-example?
It is a valid example of a C program. It was present as a part >>>>>>>>> of a
claim about you, and your response was the false claim that "That >>>>>>>>> is just nonsense". Later in the discussion you offer more evidence >>>>>>>>> to support his claim.
His halt decider did not look at its input.
Nor is it required to. All it needs to do is map inputs to outputs. >>>>>>>
So a piece of metal sitting on the ground is an automobile.
Does algorithm H map machine description X and machine input Y to
an output of either 0 or 1?
A mapping is nothing more than an association of inputs to outputs,
so there is nothing to ignore. What an algorithm might do to
*compute* the mapping has nothing to do with the mapping.
It is conventionally construed as a mapping.
More importantly, it satisfies the definition of "mapping".
It is not even conventionally construed as a halt
function, not even a halt function that gets the
wrong answer.
Irrelevant, as the claim was that H does not implement the halt
function.
On 7/4/2026 2:43 AM, Mikko wrote:
On 03/07/2026 21:36, olcott wrote:
On 7/3/2026 1:18 PM, dbush wrote:
On 7/3/2026 2:10 PM, olcott wrote:
On 7/3/2026 12:10 PM, dbush wrote:
On 7/3/2026 12:52 PM, olcott wrote:Ignoring the input IS NOT A MAPPING
On 7/3/2026 10:50 AM, dbush wrote:
On 7/3/2026 11:36 AM, olcott wrote:
On 7/3/2026 4:22 AM, Mikko wrote:
On 02/07/2026 17:51, olcott wrote:
Do you know enough about C to understand that
dbush example was foolish nonsense when proposed
to show the halting problem counter-example?
It is a valid example of a C program. It was present as a part >>>>>>>>>> of a
claim about you, and your response was the false claim that "That >>>>>>>>>> is just nonsense". Later in the discussion you offer more >>>>>>>>>> evidence
to support his claim.
His halt decider did not look at its input.
Nor is it required to. All it needs to do is map inputs to
outputs.
So a piece of metal sitting on the ground is an automobile.
Does algorithm H map machine description X and machine input Y to >>>>>> an output of either 0 or 1?
If an algorithm takes an input and produces an output, that is by
definition a mapping.
That only proves that the definition is incoherent.
Your definitions often are. But the well known definition of "mapping"
is not.
The output really should be based on the input
because computing the mapping from an input to
an output requires some kind of correspondence
between the two.
On 7/4/2026 2:48 AM, Mikko wrote:
On 04/07/2026 05:37, olcott wrote:
On 7/3/2026 9:19 PM, dbush wrote:
On 7/3/2026 10:05 PM, olcott wrote:
On 7/3/2026 8:58 PM, dbush wrote:
On 7/3/2026 9:52 PM, olcott wrote:
On 7/3/2026 5:51 PM, André G. Isaak wrote:The mathematical halting function:
On 2026-07-03 16:37, olcott wrote:
On 7/3/2026 1:47 PM, André G. Isaak wrote:
On 2026-07-03 12:36, olcott wrote:
On 7/3/2026 1:18 PM, dbush wrote:
If an algorithm takes an input and produces an output, that >>>>>>>>>>>> is by definition a mapping.That only proves that the definition is incoherent.
The coherent way that it actually works is that
inputs are transformed into outputs by applying
finite string transformation rules to inputs to
derive outputs.
Apparently you don't understand the difference between a
mapping and an algorithm. They are two different things.
André
A function that ignores its input and only returns 0
is not any sort of halt function.
He was defining 'mapping', not 'halt function'.
André
A actual halt function must compute
When you actually implement this concretely
We find that it is not possible, as Linz and others have proved.
Impossible requirements are incorrect requirements.
There is no well known meaning of "incorrect requirements".
I just established the meaning of incorrect requirements
as any requirement that requires the logically impossible.
The halting problem requires a decider that correctly
reports the halt status of an input that does the opposite
of whatever it reports.
I already established that an incorrect polar question
is any yes/no question lacking a correct yes/no answer.
On 7/4/2026 2:55 AM, Mikko wrote:
On 03/07/2026 21:45, olcott wrote:
On 7/3/2026 1:27 PM, dbush wrote:
On 7/3/2026 2:10 PM, olcott wrote:int Not_A_Mapping(int X)
On 7/3/2026 12:10 PM, dbush wrote:
On 7/3/2026 12:52 PM, olcott wrote:Ignoring the input IS NOT A MAPPING
On 7/3/2026 10:50 AM, dbush wrote:
On 7/3/2026 11:36 AM, olcott wrote:
On 7/3/2026 4:22 AM, Mikko wrote:
On 02/07/2026 17:51, olcott wrote:
Do you know enough about C to understand that
dbush example was foolish nonsense when proposed
to show the halting problem counter-example?
It is a valid example of a C program. It was present as a part >>>>>>>>>> of a
claim about you, and your response was the false claim that "That >>>>>>>>>> is just nonsense". Later in the discussion you offer more >>>>>>>>>> evidence
to support his claim.
His halt decider did not look at its input.
Nor is it required to. All it needs to do is map inputs to
outputs.
So a piece of metal sitting on the ground is an automobile.
Does algorithm H map machine description X and machine input Y to >>>>>> an output of either 0 or 1?
A mapping is nothing more than an association of inputs to outputs,
{
return 0;
}
By construing that as a mapping is one of the screw-ups
that prevents true expressed in language from being computable.
By construing the above mapping as a non-mapping you disconnect from
Common Languge and lose your ablility to communicate.
I will not tolerate that math hijacks the term
"mapping" to ignore requirement that there must
be some actual correspondence between inputs and
outputs.
A actual halt function must computeThe mathematical halting function:
On 03/07/2026 21:38, olcott wrote:
On 7/3/2026 1:21 PM, André G. Isaak wrote:
On 2026-07-03 12:12, olcott wrote:
On 7/3/2026 12:17 PM, André G. Isaak wrote:
On 2026-07-03 10:48, olcott wrote:Model theory has been expressly off-topic for
On 7/3/2026 9:45 AM, André G. Isaak wrote:
On 2026-07-02 23:02, olcott wrote:
On 7/1/2026 9:03 PM, olcott wrote:
Q cannot do the ∀x without an infinite sequence of steps.
So your phrasing is good: Q would need something like an
infinite sequence of steps (or a single principle that
summarizes them) to get the ∀x. Since formal proofs must be >>>>>>>> finite, and Q lacks the tool (induction) that would allow a
finite proof of the infinite claim, the universal statement
remains unprovable.
I'm not sure why you are responding to yourself nor who 'your
phrasing' refers to since you don't quote anyone. But, assuming >>>>>>> we're still talking about ∀ x, S(x) ≠ x in Q, your reasoning is >>>>>>> simply off.
You *can* prove universally quantified claims in Q, just not that >>>>>>> particular claim.
What is the reason that (∀x, S(x) ≠ x) cannot be proved in Q?
Because it isn't true in all models of Q,
many weeks in every thread. Whenever you ignore
this the rest of your reply will be ignored.
The rest of my post which you snipped and (presumably) ignored
explained *why* you are wrong about this. PTS does not reject models
or model theory. It simply doesn't rely on model-theoretic semantics.
Q *requires* a model.
It replaces Model theory With PTS.
That you do not understand this is your mistake.
"Is x true" is replaced with something like "Is x provable".
"Is x provable" is there already. Why would one want to lose
"Is x true"? If one dosn't need "Is x true" one needn't use
it.
On 7/4/2026 3:49 AM, Mikko wrote:
On 03/07/2026 21:38, olcott wrote:
On 7/3/2026 1:21 PM, André G. Isaak wrote:
On 2026-07-03 12:12, olcott wrote:
On 7/3/2026 12:17 PM, André G. Isaak wrote:
On 2026-07-03 10:48, olcott wrote:Model theory has been expressly off-topic for
On 7/3/2026 9:45 AM, André G. Isaak wrote:Because it isn't true in all models of Q,
On 2026-07-02 23:02, olcott wrote:
On 7/1/2026 9:03 PM, olcott wrote:
Q cannot do the ∀x without an infinite sequence of steps. >>>>>>>>>So your phrasing is good: Q would need something like an
infinite sequence of steps (or a single principle that
summarizes them) to get the ∀x. Since formal proofs must be >>>>>>>>> finite, and Q lacks the tool (induction) that would allow a >>>>>>>>> finite proof of the infinite claim, the universal statement >>>>>>>>> remains unprovable.
I'm not sure why you are responding to yourself nor who 'your >>>>>>>> phrasing' refers to since you don't quote anyone. But, assuming >>>>>>>> we're still talking about ∀ x, S(x) ≠ x in Q, your reasoning is >>>>>>>> simply off.
You *can* prove universally quantified claims in Q, just not
that particular claim.
What is the reason that (∀x, S(x) ≠ x) cannot be proved in Q? >>>>>>
many weeks in every thread. Whenever you ignore
this the rest of your reply will be ignored.
The rest of my post which you snipped and (presumably) ignored
explained *why* you are wrong about this. PTS does not reject models
or model theory. It simply doesn't rely on model-theoretic
semantics. Q *requires* a model.
It replaces Model theory With PTS.
That you do not understand this is your mistake.
"Is x true" is replaced with something like "Is x provable".
"Is x provable" is there already. Why would one want to lose
"Is x true"? If one dosn't need "Is x true" one needn't use
it.
The whole focus of most PTS "Is x provable".
Model theory looks at true in a model and ignores
the connection between true and provable.
On 7/4/2026 2:48 AM, Mikko wrote:
On 04/07/2026 05:37, olcott wrote:
On 7/3/2026 9:19 PM, dbush wrote:
On 7/3/2026 10:05 PM, olcott wrote:
On 7/3/2026 8:58 PM, dbush wrote:
On 7/3/2026 9:52 PM, olcott wrote:
On 7/3/2026 5:51 PM, André G. Isaak wrote:The mathematical halting function:
On 2026-07-03 16:37, olcott wrote:
On 7/3/2026 1:47 PM, André G. Isaak wrote:
On 2026-07-03 12:36, olcott wrote:
On 7/3/2026 1:18 PM, dbush wrote:
If an algorithm takes an input and produces an output, that >>>>>>>>>>>> is by definition a mapping.That only proves that the definition is incoherent.
The coherent way that it actually works is that
inputs are transformed into outputs by applying
finite string transformation rules to inputs to
derive outputs.
Apparently you don't understand the difference between a
mapping and an algorithm. They are two different things.
André
A function that ignores its input and only returns 0
is not any sort of halt function.
He was defining 'mapping', not 'halt function'.
André
A actual halt function must compute
When you actually implement this concretely
We find that it is not possible, as Linz and others have proved.
Impossible requirements are incorrect requirements.
There is no well known meaning of "incorrect requirements".
I just established the meaning of incorrect requirements
as any requirement that requires the logically impossible.
On 7/4/2026 2:46 AM, Mikko wrote:The halting problem does not require anything unless the input
On 04/07/2026 04:52, olcott wrote:
On 7/3/2026 5:51 PM, André G. Isaak wrote:
On 2026-07-03 16:37, olcott wrote:
On 7/3/2026 1:47 PM, André G. Isaak wrote:
On 2026-07-03 12:36, olcott wrote:
On 7/3/2026 1:18 PM, dbush wrote:
If an algorithm takes an input and produces an output, that is >>>>>>>> by definition a mapping.That only proves that the definition is incoherent.
The coherent way that it actually works is that
inputs are transformed into outputs by applying
finite string transformation rules to inputs to
derive outputs.
Apparently you don't understand the difference between a mapping
and an algorithm. They are two different things.
André
A function that ignores its input and only returns 0
is not any sort of halt function.
He was defining 'mapping', not 'halt function'.
André
A actual halt function must compute the mapping from
its actual input according to the operational semantics
of this input to the behavior that this input actually
specifies. No function can report on the behavior of
its caller because it has no idea who its caller is.
A function does not compute. An algrothm may compute a function.
However, no algrithm computes the halt function.
The halt functions maps a computation to a truth value
but so do many other functions, too.
When implemented as C functions
typedef int (*ptr)();
int HHH(ptr P);
01 int DD()
02 {
03 int Halt_Status = HHH(DD);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 void main()
10 {
11 DD();
12 HHH(DD);
13 }
The HP requires HHH to report on the DD() invoked
in main(). This is impossible because HHH has no
idea who its caller is and deciders are functions
that only operate on their arguments.
On 7/4/2026 2:43 AM, Mikko wrote:
On 03/07/2026 21:36, olcott wrote:
On 7/3/2026 1:18 PM, dbush wrote:
On 7/3/2026 2:10 PM, olcott wrote:
On 7/3/2026 12:10 PM, dbush wrote:
On 7/3/2026 12:52 PM, olcott wrote:Ignoring the input IS NOT A MAPPING
On 7/3/2026 10:50 AM, dbush wrote:
On 7/3/2026 11:36 AM, olcott wrote:
On 7/3/2026 4:22 AM, Mikko wrote:
On 02/07/2026 17:51, olcott wrote:
Do you know enough about C to understand that
dbush example was foolish nonsense when proposed
to show the halting problem counter-example?
It is a valid example of a C program. It was present as a part >>>>>>>>>> of a
claim about you, and your response was the false claim that "That >>>>>>>>>> is just nonsense". Later in the discussion you offer more >>>>>>>>>> evidence
to support his claim.
His halt decider did not look at its input.
Nor is it required to. All it needs to do is map inputs to
outputs.
So a piece of metal sitting on the ground is an automobile.
Does algorithm H map machine description X and machine input Y to >>>>>> an output of either 0 or 1?
If an algorithm takes an input and produces an output, that is by
definition a mapping.
That only proves that the definition is incoherent.
Your definitions often are. But the well known definition of "mapping"
is not.
The output really should be based on the input
because computing the mapping from an input to
an output requires some kind of correspondence
between the two.
On 7/4/2026 2:55 AM, Mikko wrote:
On 03/07/2026 21:45, olcott wrote:
On 7/3/2026 1:27 PM, dbush wrote:
On 7/3/2026 2:10 PM, olcott wrote:int Not_A_Mapping(int X)
On 7/3/2026 12:10 PM, dbush wrote:
On 7/3/2026 12:52 PM, olcott wrote:Ignoring the input IS NOT A MAPPING
On 7/3/2026 10:50 AM, dbush wrote:
On 7/3/2026 11:36 AM, olcott wrote:
On 7/3/2026 4:22 AM, Mikko wrote:
On 02/07/2026 17:51, olcott wrote:
Do you know enough about C to understand that
dbush example was foolish nonsense when proposed
to show the halting problem counter-example?
It is a valid example of a C program. It was present as a part >>>>>>>>>> of a
claim about you, and your response was the false claim that "That >>>>>>>>>> is just nonsense". Later in the discussion you offer more >>>>>>>>>> evidence
to support his claim.
His halt decider did not look at its input.
Nor is it required to. All it needs to do is map inputs to
outputs.
So a piece of metal sitting on the ground is an automobile.
Does algorithm H map machine description X and machine input Y to >>>>>> an output of either 0 or 1?
A mapping is nothing more than an association of inputs to outputs,
{
return 0;
}
By construing that as a mapping is one of the screw-ups
that prevents true expressed in language from being computable.
By construing the above mapping as a non-mapping you disconnect from
Common Languge and lose your ablility to communicate.
I will not tolerate that math hijacks the term
"mapping" to ignore requirement that there must
be some actual correspondence between inputs and
outputs.
A actual halt function must compute the mapping fromA function does not compute. It just is. It can be said to "report"
its actual input according to the operational semantics
of this input to the behavior that this input actually
specifies. No function can report on the behavior of
its caller because it has no idea who its caller is.
On 7/4/2026 3:00 AM, Mikko wrote:
On 03/07/2026 22:08, olcott wrote:
On 7/3/2026 1:27 PM, dbush wrote:
On 7/3/2026 2:10 PM, olcott wrote:
On 7/3/2026 12:10 PM, dbush wrote:
On 7/3/2026 12:52 PM, olcott wrote:Ignoring the input IS NOT A MAPPING
On 7/3/2026 10:50 AM, dbush wrote:
On 7/3/2026 11:36 AM, olcott wrote:
On 7/3/2026 4:22 AM, Mikko wrote:
On 02/07/2026 17:51, olcott wrote:
Do you know enough about C to understand that
dbush example was foolish nonsense when proposed
to show the halting problem counter-example?
It is a valid example of a C program. It was present as a part >>>>>>>>>> of a
claim about you, and your response was the false claim that "That >>>>>>>>>> is just nonsense". Later in the discussion you offer more >>>>>>>>>> evidence
to support his claim.
His halt decider did not look at its input.
Nor is it required to. All it needs to do is map inputs to
outputs.
So a piece of metal sitting on the ground is an automobile.
Does algorithm H map machine description X and machine input Y to >>>>>> an output of either 0 or 1?
A mapping is nothing more than an association of inputs to outputs,
so there is nothing to ignore. What an algorithm might do to
*compute* the mapping has nothing to do with the mapping.
It is conventionally construed as a mapping.
More importantly, it satisfies the definition of "mapping".
It is not even conventionally construed as a halt
function, not even a halt function that gets the
wrong answer.
Irrelevant, as the claim was that H does not implement the halt
function.
If it ignores input it is no function of this input.
On 7/4/2026 2:41 AM, Mikko wrote:
On 03/07/2026 21:10, olcott wrote:
On 7/3/2026 12:10 PM, dbush wrote:
On 7/3/2026 12:52 PM, olcott wrote:Ignoring the input IS NOT A MAPPING
On 7/3/2026 10:50 AM, dbush wrote:
On 7/3/2026 11:36 AM, olcott wrote:
On 7/3/2026 4:22 AM, Mikko wrote:
On 02/07/2026 17:51, olcott wrote:
Do you know enough about C to understand that
dbush example was foolish nonsense when proposed
to show the halting problem counter-example?
It is a valid example of a C program. It was present as a part of a >>>>>>>> claim about you, and your response was the false claim that "That >>>>>>>> is just nonsense". Later in the discussion you offer more evidence >>>>>>>> to support his claim.
His halt decider did not look at its input.
Nor is it required to. All it needs to do is map inputs to outputs. >>>>>>
So a piece of metal sitting on the ground is an automobile.
Does algorithm H map machine description X and machine input Y to an
output of either 0 or 1?
No, but dbush's program H implements a mapping anyway. It just is
a different mapping from the one a halt decider is required to do.
Making it complete nonsense.
On 7/4/2026 2:37 AM, Mikko wrote:
On 2026-07-02 dbush wrote:
The halting problem doesn't actually have self reference, as
algorithms can be copied as in the below example of algorithm D:
void D(ptr *I)
{
// algorithm D; input: I
ptr *X = D;
ptr *Y = I;
int result;
{
// algorithm H; inputs: X,Y
result = 0;
}
if (result == 1) {
while (1);
}
}
Which is the counter example input to algorithm H:
int H(ptr *X, ptr *Y)
{
int result;
{
// algorithm H; inputs: X,Y
result = 0;
}
return result;
}
On 03/07/2026 18:36, olcott wrote:
On 7/3/2026 4:22 AM, Mikko wrote:
On 02/07/2026 17:51, olcott wrote:
Do you know enough about C to understand that
dbush example was foolish nonsense when proposed
to show the halting problem counter-example?
It is a valid example of a C program. It was present as a part of a
claim about you, and your response was the false claim that "That
is just nonsense". Later in the discussion you offer more evidence
to support his claim.
His halt decider did not look at its input.
For every possible input his H halts and returns either 0 for false
or 1 for true. Therefore his H is a decider. It return 0 for D
although D halts so the decider H is not a halt decider.
counter-factual H always returns 0.
On 7/4/2026 9:32 AM, olcott wrote:
On 7/4/2026 2:37 AM, Mikko wrote:
On 2026-07-02 dbush wrote:
The halting problem doesn't actually have self reference, as
algorithms can be copied as in the below example of algorithm D:
void D(ptr *I)
{
// algorithm D; input: I
ptr *X = D;
ptr *Y = I;
int result;
{
// algorithm H; inputs: X,Y
result = 0;
}
if (result == 1) {
while (1);
}
}
Which is the counter example input to algorithm H:
int H(ptr *X, ptr *Y)
{
int result;
{
// algorithm H; inputs: X,Y
result = 0;
}
return result;
}
On 03/07/2026 18:36, olcott wrote:
On 7/3/2026 4:22 AM, Mikko wrote:
On 02/07/2026 17:51, olcott wrote:
Do you know enough about C to understand that
dbush example was foolish nonsense when proposed
to show the halting problem counter-example?
It is a valid example of a C program. It was present as a part of a
claim about you, and your response was the false claim that "That
is just nonsense". Later in the discussion you offer more evidence
to support his claim.
His halt decider did not look at its input.
For every possible input his H halts and returns either 0 for false
or 1 for true. Therefore his H is a decider. It return 0 for D
although D halts so the decider H is not a halt decider.
counter-factual H always returns 0.
Which means the condition "either 0 or 1" is satisfied.
It seems we need to add "or" to the list of basic high school level
logic topics you don't understand.
On 04/07/2026 20:13, olcott wrote:
On 7/4/2026 3:49 AM, Mikko wrote:
On 03/07/2026 21:38, olcott wrote:
On 7/3/2026 1:21 PM, André G. Isaak wrote:
On 2026-07-03 12:12, olcott wrote:
On 7/3/2026 12:17 PM, André G. Isaak wrote:
On 2026-07-03 10:48, olcott wrote:Model theory has been expressly off-topic for
On 7/3/2026 9:45 AM, André G. Isaak wrote:Because it isn't true in all models of Q,
On 2026-07-02 23:02, olcott wrote:
On 7/1/2026 9:03 PM, olcott wrote:
Q cannot do the ∀x without an infinite sequence of steps. >>>>>>>>>>So your phrasing is good: Q would need something like an
infinite sequence of steps (or a single principle that
summarizes them) to get the ∀x. Since formal proofs must be >>>>>>>>>> finite, and Q lacks the tool (induction) that would allow a >>>>>>>>>> finite proof of the infinite claim, the universal statement >>>>>>>>>> remains unprovable.
I'm not sure why you are responding to yourself nor who 'your >>>>>>>>> phrasing' refers to since you don't quote anyone. But, assuming >>>>>>>>> we're still talking about ∀ x, S(x) ≠ x in Q, your reasoning is >>>>>>>>> simply off.
You *can* prove universally quantified claims in Q, just not >>>>>>>>> that particular claim.
What is the reason that (∀x, S(x) ≠ x) cannot be proved in Q? >>>>>>>
many weeks in every thread. Whenever you ignore
this the rest of your reply will be ignored.
The rest of my post which you snipped and (presumably) ignored
explained *why* you are wrong about this. PTS does not reject
models or model theory. It simply doesn't rely on model-theoretic
semantics. Q *requires* a model.
It replaces Model theory With PTS.
That you do not understand this is your mistake.
"Is x true" is replaced with something like "Is x provable".
"Is x provable" is there already. Why would one want to lose
"Is x true"? If one dosn't need "Is x true" one needn't use
it.
The whole focus of most PTS "Is x provable".
Model theory looks at true in a model and ignores
the connection between true and provable.
People rarely care about PTS or model theory. More often they careabout
what is or is not true about someting they consider important.
On 04/07/2026 19:58, olcott wrote:
On 7/4/2026 2:48 AM, Mikko wrote:
On 04/07/2026 05:37, olcott wrote:
On 7/3/2026 9:19 PM, dbush wrote:
On 7/3/2026 10:05 PM, olcott wrote:
On 7/3/2026 8:58 PM, dbush wrote:
On 7/3/2026 9:52 PM, olcott wrote:
On 7/3/2026 5:51 PM, André G. Isaak wrote:The mathematical halting function:
On 2026-07-03 16:37, olcott wrote:
On 7/3/2026 1:47 PM, André G. Isaak wrote:
On 2026-07-03 12:36, olcott wrote:
On 7/3/2026 1:18 PM, dbush wrote:
If an algorithm takes an input and produces an output, that >>>>>>>>>>>>> is by definition a mapping.That only proves that the definition is incoherent.
The coherent way that it actually works is that
inputs are transformed into outputs by applying
finite string transformation rules to inputs to
derive outputs.
Apparently you don't understand the difference between a >>>>>>>>>>> mapping and an algorithm. They are two different things. >>>>>>>>>>>
André
A function that ignores its input and only returns 0
is not any sort of halt function.
He was defining 'mapping', not 'halt function'.
André
A actual halt function must compute
When you actually implement this concretely
We find that it is not possible, as Linz and others have proved.
Impossible requirements are incorrect requirements.
There is no well known meaning of "incorrect requirements".
I just established the meaning of incorrect requirements
as any requirement that requires the logically impossible.
That is insufficient to make the expression "incorrect requirements" meaningful in Common Language or well known.
On 04/07/2026 19:55, olcott wrote:
On 7/4/2026 2:46 AM, Mikko wrote:The halting problem does not require anything unless the input
On 04/07/2026 04:52, olcott wrote:
On 7/3/2026 5:51 PM, André G. Isaak wrote:
On 2026-07-03 16:37, olcott wrote:
On 7/3/2026 1:47 PM, André G. Isaak wrote:
On 2026-07-03 12:36, olcott wrote:
On 7/3/2026 1:18 PM, dbush wrote:
If an algorithm takes an input and produces an output, that is >>>>>>>>> by definition a mapping.That only proves that the definition is incoherent.
The coherent way that it actually works is that
inputs are transformed into outputs by applying
finite string transformation rules to inputs to
derive outputs.
Apparently you don't understand the difference between a mapping >>>>>>> and an algorithm. They are two different things.
André
A function that ignores its input and only returns 0
is not any sort of halt function.
He was defining 'mapping', not 'halt function'.
André
A actual halt function must compute the mapping from
its actual input according to the operational semantics
of this input to the behavior that this input actually
specifies. No function can report on the behavior of
its caller because it has no idea who its caller is.
A function does not compute. An algrothm may compute a function.
However, no algrithm computes the halt function.
The halt functions maps a computation to a truth value
but so do many other functions, too.
When implemented as C functions
typedef int (*ptr)();
int HHH(ptr P);
01 int DD()
02 {
03 int Halt_Status = HHH(DD);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 void main()
10 {
11 DD();
12 HHH(DD);
13 }
The HP requires HHH to report on the DD() invoked
in main(). This is impossible because HHH has no
idea who its caller is and deciders are functions
that only operate on their arguments.
fully specifies a computation.
The above DD calls HHH, which must be the same HHH as main calls if
DD halts. Therefore the bhaviour of HHH is a part of the computation
that the HHH would answer about if it were a halt decider.
The requirements of a halt decider don't require that then input
be presented to the decider the way it is done above. For exmample,
a text file would be acceptable.
On 04/07/2026 20:01, olcott wrote:
On 7/4/2026 2:55 AM, Mikko wrote:
On 03/07/2026 21:45, olcott wrote:
On 7/3/2026 1:27 PM, dbush wrote:
On 7/3/2026 2:10 PM, olcott wrote:int Not_A_Mapping(int X)
On 7/3/2026 12:10 PM, dbush wrote:
On 7/3/2026 12:52 PM, olcott wrote:Ignoring the input IS NOT A MAPPING
On 7/3/2026 10:50 AM, dbush wrote:
On 7/3/2026 11:36 AM, olcott wrote:
On 7/3/2026 4:22 AM, Mikko wrote:
On 02/07/2026 17:51, olcott wrote:
Do you know enough about C to understand that
dbush example was foolish nonsense when proposed
to show the halting problem counter-example?
It is a valid example of a C program. It was present as a >>>>>>>>>>> part of a
claim about you, and your response was the false claim that >>>>>>>>>>> "That
is just nonsense". Later in the discussion you offer more >>>>>>>>>>> evidence
to support his claim.
His halt decider did not look at its input.
Nor is it required to. All it needs to do is map inputs to >>>>>>>>> outputs.
So a piece of metal sitting on the ground is an automobile.
Does algorithm H map machine description X and machine input Y to >>>>>>> an output of either 0 or 1?
A mapping is nothing more than an association of inputs to outputs,
{
return 0;
}
By construing that as a mapping is one of the screw-ups
that prevents true expressed in language from being computable.
By construing the above mapping as a non-mapping you disconnect from
Common Languge and lose your ablility to communicate.
I will not tolerate that math hijacks the term
"mapping" to ignore requirement that there must
be some actual correspondence between inputs and
outputs.
Your exceesive intolerance is irrelevant.
In mathematical context the
cartogrphical meaning is so obviously nonsense that no confusion is
possible. Besides it is well known that in a mathematical context many
words have meanings that are unrelated or only distantly related to
their usual meanings.
A actual halt function must compute the mapping fromA function does not compute. It just is. It can be said to "report"
its actual input according to the operational semantics
of this input to the behavior that this input actually
specifies. No function can report on the behavior of
its caller because it has no idea who its caller is.
but that must not be interpreted too literally.
On 04/07/2026 20:03, olcott wrote:
On 7/4/2026 3:00 AM, Mikko wrote:
On 03/07/2026 22:08, olcott wrote:
On 7/3/2026 1:27 PM, dbush wrote:
On 7/3/2026 2:10 PM, olcott wrote:
On 7/3/2026 12:10 PM, dbush wrote:
On 7/3/2026 12:52 PM, olcott wrote:Ignoring the input IS NOT A MAPPING
On 7/3/2026 10:50 AM, dbush wrote:
On 7/3/2026 11:36 AM, olcott wrote:
On 7/3/2026 4:22 AM, Mikko wrote:
On 02/07/2026 17:51, olcott wrote:
Do you know enough about C to understand that
dbush example was foolish nonsense when proposed
to show the halting problem counter-example?
It is a valid example of a C program. It was present as a >>>>>>>>>>> part of a
claim about you, and your response was the false claim that >>>>>>>>>>> "That
is just nonsense". Later in the discussion you offer more >>>>>>>>>>> evidence
to support his claim.
His halt decider did not look at its input.
Nor is it required to. All it needs to do is map inputs to >>>>>>>>> outputs.
So a piece of metal sitting on the ground is an automobile.
Does algorithm H map machine description X and machine input Y to >>>>>>> an output of either 0 or 1?
A mapping is nothing more than an association of inputs to outputs, >>>>> so there is nothing to ignore. What an algorithm might do to
*compute* the mapping has nothing to do with the mapping.
It is conventionally construed as a mapping.
More importantly, it satisfies the definition of "mapping".
It is not even conventionally construed as a halt
function, not even a halt function that gets the
wrong answer.
Irrelevant, as the claim was that H does not implement the halt
function.
If it ignores input it is no function of this input.
Everything that is required to be in the argument list of a function
is an argument to that function, even when the function "ignores" it.
On 04/07/2026 16:38, olcott wrote:
On 7/4/2026 2:41 AM, Mikko wrote:
On 03/07/2026 21:10, olcott wrote:
On 7/3/2026 12:10 PM, dbush wrote:
On 7/3/2026 12:52 PM, olcott wrote:Ignoring the input IS NOT A MAPPING
On 7/3/2026 10:50 AM, dbush wrote:
On 7/3/2026 11:36 AM, olcott wrote:
On 7/3/2026 4:22 AM, Mikko wrote:
On 02/07/2026 17:51, olcott wrote:
Do you know enough about C to understand that
dbush example was foolish nonsense when proposed
to show the halting problem counter-example?
It is a valid example of a C program. It was present as a part >>>>>>>>> of a
claim about you, and your response was the false claim that "That >>>>>>>>> is just nonsense". Later in the discussion you offer more evidence >>>>>>>>> to support his claim.
His halt decider did not look at its input.
Nor is it required to. All it needs to do is map inputs to outputs. >>>>>>>
So a piece of metal sitting on the ground is an automobile.
Does algorithm H map machine description X and machine input Y to
an output of either 0 or 1?
No, but dbush's program H implements a mapping anyway. It just is
a different mapping from the one a halt decider is required to do.
Making it complete nonsense.
The program has a well defined meaning so it is not non-sense.
That it may be too big or complex for you is irrelevant.
On 7/6/2026 3:24 AM, Mikko wrote:
On 04/07/2026 19:55, olcott wrote:
On 7/4/2026 2:46 AM, Mikko wrote:The halting problem does not require anything unless the input
On 04/07/2026 04:52, olcott wrote:
On 7/3/2026 5:51 PM, André G. Isaak wrote:
On 2026-07-03 16:37, olcott wrote:
On 7/3/2026 1:47 PM, André G. Isaak wrote:
On 2026-07-03 12:36, olcott wrote:
On 7/3/2026 1:18 PM, dbush wrote:
If an algorithm takes an input and produces an output, that is >>>>>>>>>> by definition a mapping.That only proves that the definition is incoherent.
The coherent way that it actually works is that
inputs are transformed into outputs by applying
finite string transformation rules to inputs to
derive outputs.
Apparently you don't understand the difference between a mapping >>>>>>>> and an algorithm. They are two different things.
André
A function that ignores its input and only returns 0
is not any sort of halt function.
He was defining 'mapping', not 'halt function'.
André
A actual halt function must compute the mapping from
its actual input according to the operational semantics
of this input to the behavior that this input actually
specifies. No function can report on the behavior of
its caller because it has no idea who its caller is.
A function does not compute. An algrothm may compute a function.
However, no algrithm computes the halt function.
The halt functions maps a computation to a truth value
but so do many other functions, too.
When implemented as C functions
typedef int (*ptr)();
int HHH(ptr P);
01 int DD()
02 {
03 int Halt_Status = HHH(DD);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 void main()
10 {
11 DD();
12 HHH(DD);
13 }
The HP requires HHH to report on the DD() invoked
in main(). This is impossible because HHH has no
idea who its caller is and deciders are functions
that only operate on their arguments.
fully specifies a computation.
The above DD calls HHH, which must be the same HHH as main calls if
DD halts. Therefore the bhaviour of HHH is a part of the computation
that the HHH would answer about if it were a halt decider.
HHH(DD) can and does correctly report on its input.
I just can get why it is taking so long for people
to understand that DD executed in main is out-of-scope
for HHH. It is like someone took actual brains apart
and welded in short-circuits.
The requirements of a halt decider don't require that then input
be presented to the decider the way it is done above. For exmample,
a text file would be acceptable.
On 07/06/2026 08:30 AM, olcott wrote:
On 7/6/2026 3:24 AM, Mikko wrote:
On 04/07/2026 19:55, olcott wrote:
On 7/4/2026 2:46 AM, Mikko wrote:The halting problem does not require anything unless the input
On 04/07/2026 04:52, olcott wrote:
On 7/3/2026 5:51 PM, André G. Isaak wrote:
On 2026-07-03 16:37, olcott wrote:
On 7/3/2026 1:47 PM, André G. Isaak wrote:
On 2026-07-03 12:36, olcott wrote:
On 7/3/2026 1:18 PM, dbush wrote:
If an algorithm takes an input and produces an output, that is >>>>>>>>>>> by definition a mapping.That only proves that the definition is incoherent.
The coherent way that it actually works is that
inputs are transformed into outputs by applying
finite string transformation rules to inputs to
derive outputs.
Apparently you don't understand the difference between a mapping >>>>>>>>> and an algorithm. They are two different things.
André
A function that ignores its input and only returns 0
is not any sort of halt function.
He was defining 'mapping', not 'halt function'.
André
A actual halt function must compute the mapping from
its actual input according to the operational semantics
of this input to the behavior that this input actually
specifies. No function can report on the behavior of
its caller because it has no idea who its caller is.
A function does not compute. An algrothm may compute a function.
However, no algrithm computes the halt function.
The halt functions maps a computation to a truth value
but so do many other functions, too.
When implemented as C functions
typedef int (*ptr)();
int HHH(ptr P);
01 int DD()
02 {
03 int Halt_Status = HHH(DD);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 void main()
10 {
11 DD();
12 HHH(DD);
13 }
The HP requires HHH to report on the DD() invoked
in main(). This is impossible because HHH has no
idea who its caller is and deciders are functions
that only operate on their arguments.
fully specifies a computation.
The above DD calls HHH, which must be the same HHH as main calls if
DD halts. Therefore the bhaviour of HHH is a part of the computation
that the HHH would answer about if it were a halt decider.
HHH(DD) can and does correctly report on its input.
I just can get why it is taking so long for people
to understand that DD executed in main is out-of-scope
for HHH. It is like someone took actual brains apart
and welded in short-circuits.
The requirements of a halt decider don't require that then input
be presented to the decider the way it is done above. For exmample,
a text file would be acceptable.
It's well known that each finite input to a finite program
has a finite static-analysis that determines whether it halts,
furthermore for each language of finite input it can be determined
via a finite-static-analysis a partition of the language into what
halts and what doesn't.
Infinite tapes or with infinite programs are different,
see "Zeno machines" since super-tasks have accounts of
mathematical independence (whether a model of integers
is a fragment and finite, an extension and with infinite
members, or "in the middle", since the usual idea is that
a standard model of integers doesn't exist).
So, there are accounts of halting or "completions" in
the infinitary that are independent usual finitist
accounts, whose Law of Large Numbers is only the
Law of Small Numbers, since there is a "Law of Larger Numbers"
and a "Law of Largest Numbers", about models of arithmetic.
Otherwise that's just barking about "V = L" and so on.
On 7/6/2026 2:59 AM, Mikko wrote:
On 04/07/2026 20:13, olcott wrote:
On 7/4/2026 3:49 AM, Mikko wrote:
On 03/07/2026 21:38, olcott wrote:
On 7/3/2026 1:21 PM, André G. Isaak wrote:
On 2026-07-03 12:12, olcott wrote:
On 7/3/2026 12:17 PM, André G. Isaak wrote:
On 2026-07-03 10:48, olcott wrote:Model theory has been expressly off-topic for
On 7/3/2026 9:45 AM, André G. Isaak wrote:Because it isn't true in all models of Q,
On 2026-07-02 23:02, olcott wrote:
On 7/1/2026 9:03 PM, olcott wrote:
Q cannot do the ∀x without an infinite sequence of steps. >>>>>>>>>>>So your phrasing is good: Q would need something like an >>>>>>>>>>> infinite sequence of steps (or a single principle that
summarizes them) to get the ∀x. Since formal proofs must be >>>>>>>>>>> finite, and Q lacks the tool (induction) that would allow a >>>>>>>>>>> finite proof of the infinite claim, the universal statement >>>>>>>>>>> remains unprovable.
I'm not sure why you are responding to yourself nor who 'your >>>>>>>>>> phrasing' refers to since you don't quote anyone. But,
assuming we're still talking about ∀ x, S(x) ≠ x in Q, your >>>>>>>>>> reasoning is simply off.
You *can* prove universally quantified claims in Q, just not >>>>>>>>>> that particular claim.
What is the reason that (∀x, S(x) ≠ x) cannot be proved in Q? >>>>>>>>
many weeks in every thread. Whenever you ignore
this the rest of your reply will be ignored.
The rest of my post which you snipped and (presumably) ignored
explained *why* you are wrong about this. PTS does not reject
models or model theory. It simply doesn't rely on model-theoretic >>>>>> semantics. Q *requires* a model.
It replaces Model theory With PTS.
That you do not understand this is your mistake.
"Is x true" is replaced with something like "Is x provable".
"Is x provable" is there already. Why would one want to lose
"Is x true"? If one dosn't need "Is x true" one needn't use
it.
The whole focus of most PTS "Is x provable".
Model theory looks at true in a model and ignores
the connection between true and provable.
People rarely care about PTS or model theory. More often they
careabout what is or is not true about someting they consider important.
Hence we must correct the divergence of logic
from correct reasoning if we are to automate
correct reasoning.
On 7/6/2026 3:11 AM, Mikko wrote:
On 04/07/2026 19:58, olcott wrote:
On 7/4/2026 2:48 AM, Mikko wrote:
On 04/07/2026 05:37, olcott wrote:
On 7/3/2026 9:19 PM, dbush wrote:
On 7/3/2026 10:05 PM, olcott wrote:
On 7/3/2026 8:58 PM, dbush wrote:
On 7/3/2026 9:52 PM, olcott wrote:
On 7/3/2026 5:51 PM, André G. Isaak wrote:The mathematical halting function:
On 2026-07-03 16:37, olcott wrote:
On 7/3/2026 1:47 PM, André G. Isaak wrote:
On 2026-07-03 12:36, olcott wrote:
On 7/3/2026 1:18 PM, dbush wrote:
If an algorithm takes an input and produces an output, >>>>>>>>>>>>>> that is by definition a mapping.That only proves that the definition is incoherent.
The coherent way that it actually works is that
inputs are transformed into outputs by applying
finite string transformation rules to inputs to
derive outputs.
Apparently you don't understand the difference between a >>>>>>>>>>>> mapping and an algorithm. They are two different things. >>>>>>>>>>>>
André
A function that ignores its input and only returns 0
is not any sort of halt function.
He was defining 'mapping', not 'halt function'.
André
A actual halt function must compute
When you actually implement this concretely
We find that it is not possible, as Linz and others have proved.
Impossible requirements are incorrect requirements.
There is no well known meaning of "incorrect requirements".
I just established the meaning of incorrect requirements
as any requirement that requires the logically impossible.
That is insufficient to make the expression "incorrect requirements"
meaningful in Common Language or well known.
In other words if the requirement is to compute the square
root of the actual dead flesh of a dead chicken you would
not reject this out-of hand?
On 7/6/2026 3:24 AM, Mikko wrote:
On 04/07/2026 19:55, olcott wrote:
On 7/4/2026 2:46 AM, Mikko wrote:The halting problem does not require anything unless the input
On 04/07/2026 04:52, olcott wrote:
On 7/3/2026 5:51 PM, André G. Isaak wrote:
On 2026-07-03 16:37, olcott wrote:
On 7/3/2026 1:47 PM, André G. Isaak wrote:
On 2026-07-03 12:36, olcott wrote:
On 7/3/2026 1:18 PM, dbush wrote:
If an algorithm takes an input and produces an output, that is >>>>>>>>>> by definition a mapping.That only proves that the definition is incoherent.
The coherent way that it actually works is that
inputs are transformed into outputs by applying
finite string transformation rules to inputs to
derive outputs.
Apparently you don't understand the difference between a mapping >>>>>>>> and an algorithm. They are two different things.
André
A function that ignores its input and only returns 0
is not any sort of halt function.
He was defining 'mapping', not 'halt function'.
André
A actual halt function must compute the mapping from
its actual input according to the operational semantics
of this input to the behavior that this input actually
specifies. No function can report on the behavior of
its caller because it has no idea who its caller is.
A function does not compute. An algrothm may compute a function.
However, no algrithm computes the halt function.
The halt functions maps a computation to a truth value
but so do many other functions, too.
When implemented as C functions
typedef int (*ptr)();
int HHH(ptr P);
01 int DD()
02 {
03 int Halt_Status = HHH(DD);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 void main()
10 {
11 DD();
12 HHH(DD);
13 }
The HP requires HHH to report on the DD() invoked
in main(). This is impossible because HHH has no
idea who its caller is and deciders are functions
that only operate on their arguments.
fully specifies a computation.
The above DD calls HHH, which must be the same HHH as main calls if
DD halts. Therefore the bhaviour of HHH is a part of the computation
that the HHH would answer about if it were a halt decider.
HHH(DD) can and does correctly report on its input.
I just can get why it is taking so long for people
to understand that DD executed in main is out-of-scope
for HHH. It is like someone took actual brains apart
and welded in short-circuits.
On 7/6/2026 3:37 AM, Mikko wrote:
On 04/07/2026 20:01, olcott wrote:
On 7/4/2026 2:55 AM, Mikko wrote:
On 03/07/2026 21:45, olcott wrote:
On 7/3/2026 1:27 PM, dbush wrote:
On 7/3/2026 2:10 PM, olcott wrote:{
On 7/3/2026 12:10 PM, dbush wrote:
On 7/3/2026 12:52 PM, olcott wrote:Ignoring the input IS NOT A MAPPING
On 7/3/2026 10:50 AM, dbush wrote:
On 7/3/2026 11:36 AM, olcott wrote:
On 7/3/2026 4:22 AM, Mikko wrote:
On 02/07/2026 17:51, olcott wrote:
Do you know enough about C to understand that
dbush example was foolish nonsense when proposed
to show the halting problem counter-example?
It is a valid example of a C program. It was present as a >>>>>>>>>>>> part of a
claim about you, and your response was the false claim that >>>>>>>>>>>> "That
is just nonsense". Later in the discussion you offer more >>>>>>>>>>>> evidence
to support his claim.
His halt decider did not look at its input.
Nor is it required to. All it needs to do is map inputs to >>>>>>>>>> outputs.
So a piece of metal sitting on the ground is an automobile.
Does algorithm H map machine description X and machine input Y >>>>>>>> to an output of either 0 or 1?
A mapping is nothing more than an association of inputs to outputs, >>>>> int Not_A_Mapping(int X)
return 0;
}
By construing that as a mapping is one of the screw-ups
that prevents true expressed in language from being computable.
By construing the above mapping as a non-mapping you disconnect from
Common Languge and lose your ablility to communicate.
I will not tolerate that math hijacks the term
"mapping" to ignore requirement that there must
be some actual correspondence between inputs and
outputs.
Your exceesive intolerance is irrelevant.
It makes terms-of-the-art into damned liars.
On 7/6/2026 3:55 AM, Mikko wrote:
On 04/07/2026 20:03, olcott wrote:
On 7/4/2026 3:00 AM, Mikko wrote:
On 03/07/2026 22:08, olcott wrote:
On 7/3/2026 1:27 PM, dbush wrote:
On 7/3/2026 2:10 PM, olcott wrote:
On 7/3/2026 12:10 PM, dbush wrote:
On 7/3/2026 12:52 PM, olcott wrote:Ignoring the input IS NOT A MAPPING
On 7/3/2026 10:50 AM, dbush wrote:
On 7/3/2026 11:36 AM, olcott wrote:
On 7/3/2026 4:22 AM, Mikko wrote:
On 02/07/2026 17:51, olcott wrote:
Do you know enough about C to understand that
dbush example was foolish nonsense when proposed
to show the halting problem counter-example?
It is a valid example of a C program. It was present as a >>>>>>>>>>>> part of a
claim about you, and your response was the false claim that >>>>>>>>>>>> "That
is just nonsense". Later in the discussion you offer more >>>>>>>>>>>> evidence
to support his claim.
His halt decider did not look at its input.
Nor is it required to. All it needs to do is map inputs to >>>>>>>>>> outputs.
So a piece of metal sitting on the ground is an automobile.
Does algorithm H map machine description X and machine input Y >>>>>>>> to an output of either 0 or 1?
A mapping is nothing more than an association of inputs to
outputs, so there is nothing to ignore. What an algorithm might >>>>>> do to *compute* the mapping has nothing to do with the mapping.
It is conventionally construed as a mapping.
More importantly, it satisfies the definition of "mapping".
It is not even conventionally construed as a halt
function, not even a halt function that gets the
wrong answer.
Irrelevant, as the claim was that H does not implement the halt
function.
If it ignores input it is no function of this input.
Everything that is required to be in the argument list of a function
is an argument to that function, even when the function "ignores" it.
You are entirely right on the linguistic front. If we look strictly at
the compositional meaning of the words in everyday language, calling something a "function of an input" when it ignores that input is, at
best, a paradox and, at worst, a semantic lie.
On 7/6/2026 4:00 AM, Mikko wrote:
On 04/07/2026 16:38, olcott wrote:
On 7/4/2026 2:41 AM, Mikko wrote:
On 03/07/2026 21:10, olcott wrote:
On 7/3/2026 12:10 PM, dbush wrote:
On 7/3/2026 12:52 PM, olcott wrote:Ignoring the input IS NOT A MAPPING
On 7/3/2026 10:50 AM, dbush wrote:
On 7/3/2026 11:36 AM, olcott wrote:
On 7/3/2026 4:22 AM, Mikko wrote:
On 02/07/2026 17:51, olcott wrote:
Do you know enough about C to understand that
dbush example was foolish nonsense when proposed
to show the halting problem counter-example?
It is a valid example of a C program. It was present as a part >>>>>>>>>> of a
claim about you, and your response was the false claim that "That >>>>>>>>>> is just nonsense". Later in the discussion you offer more >>>>>>>>>> evidence
to support his claim.
His halt decider did not look at its input.
Nor is it required to. All it needs to do is map inputs to
outputs.
So a piece of metal sitting on the ground is an automobile.
Does algorithm H map machine description X and machine input Y to >>>>>> an output of either 0 or 1?
No, but dbush's program H implements a mapping anyway. It just is
a different mapping from the one a halt decider is required to do.
Making it complete nonsense.
The program has a well defined meaning so it is not non-sense.
That it may be too big or complex for you is irrelevant.
It has zero correspondence to the HP counter-example
input thus the claim that is does is a damned lie.
On 06/07/2026 17:36, olcott wrote:
On 7/6/2026 2:59 AM, Mikko wrote:
On 04/07/2026 20:13, olcott wrote:
On 7/4/2026 3:49 AM, Mikko wrote:
On 03/07/2026 21:38, olcott wrote:
On 7/3/2026 1:21 PM, André G. Isaak wrote:
On 2026-07-03 12:12, olcott wrote:
On 7/3/2026 12:17 PM, André G. Isaak wrote:
On 2026-07-03 10:48, olcott wrote:Model theory has been expressly off-topic for
On 7/3/2026 9:45 AM, André G. Isaak wrote:Because it isn't true in all models of Q,
On 2026-07-02 23:02, olcott wrote:
On 7/1/2026 9:03 PM, olcott wrote:
Q cannot do the ∀x without an infinite sequence of steps. >>>>>>>>>>>>So your phrasing is good: Q would need something like an >>>>>>>>>>>> infinite sequence of steps (or a single principle that >>>>>>>>>>>> summarizes them) to get the ∀x. Since formal proofs must be >>>>>>>>>>>> finite, and Q lacks the tool (induction) that would allow a >>>>>>>>>>>> finite proof of the infinite claim, the universal statement >>>>>>>>>>>> remains unprovable.
I'm not sure why you are responding to yourself nor who 'your >>>>>>>>>>> phrasing' refers to since you don't quote anyone. But,
assuming we're still talking about ∀ x, S(x) ≠ x in Q, your >>>>>>>>>>> reasoning is simply off.
You *can* prove universally quantified claims in Q, just not >>>>>>>>>>> that particular claim.
What is the reason that (∀x, S(x) ≠ x) cannot be proved in Q? >>>>>>>>>
many weeks in every thread. Whenever you ignore
this the rest of your reply will be ignored.
The rest of my post which you snipped and (presumably) ignored
explained *why* you are wrong about this. PTS does not reject
models or model theory. It simply doesn't rely on model-theoretic >>>>>>> semantics. Q *requires* a model.
It replaces Model theory With PTS.
That you do not understand this is your mistake.
"Is x true" is replaced with something like "Is x provable".
"Is x provable" is there already. Why would one want to lose
"Is x true"? If one dosn't need "Is x true" one needn't use
it.
The whole focus of most PTS "Is x provable".
Model theory looks at true in a model and ignores
the connection between true and provable.
People rarely care about PTS or model theory. More often they
careabout what is or is not true about someting they consider important. >>>
Hence we must correct the divergence of logic
from correct reasoning if we are to automate
correct reasoning.
Most people would accept as correct any reasoning that produce true conclusions from true premises.
If the conclusions are not relevant
to any real needs they might call the reasoning useless or a waste
of time but not incorrect. If some of the premises are false or
obscure someone might call the reasoning incorrect.
On 06/07/2026 18:27, olcott wrote:
On 7/6/2026 3:11 AM, Mikko wrote:
On 04/07/2026 19:58, olcott wrote:
On 7/4/2026 2:48 AM, Mikko wrote:
On 04/07/2026 05:37, olcott wrote:
On 7/3/2026 9:19 PM, dbush wrote:
On 7/3/2026 10:05 PM, olcott wrote:
On 7/3/2026 8:58 PM, dbush wrote:
On 7/3/2026 9:52 PM, olcott wrote:
On 7/3/2026 5:51 PM, André G. Isaak wrote:The mathematical halting function:
On 2026-07-03 16:37, olcott wrote:
On 7/3/2026 1:47 PM, André G. Isaak wrote:
On 2026-07-03 12:36, olcott wrote:
On 7/3/2026 1:18 PM, dbush wrote:
If an algorithm takes an input and produces an output, >>>>>>>>>>>>>>> that is by definition a mapping.That only proves that the definition is incoherent. >>>>>>>>>>>>>> The coherent way that it actually works is that
inputs are transformed into outputs by applying
finite string transformation rules to inputs to
derive outputs.
Apparently you don't understand the difference between a >>>>>>>>>>>>> mapping and an algorithm. They are two different things. >>>>>>>>>>>>>
André
A function that ignores its input and only returns 0
is not any sort of halt function.
He was defining 'mapping', not 'halt function'.
André
A actual halt function must compute
When you actually implement this concretely
We find that it is not possible, as Linz and others have proved.
Impossible requirements are incorrect requirements.
There is no well known meaning of "incorrect requirements".
I just established the meaning of incorrect requirements
as any requirement that requires the logically impossible.
That is insufficient to make the expression "incorrect requirements"
meaningful in Common Language or well known.
In other words if the requirement is to compute the square
root of the actual dead flesh of a dead chicken you would
not reject this out-of hand?
Depends on what yuo count as rejection. I don't think I would
try to meet that requirement.
On 06/07/2026 18:30, olcott wrote:
On 7/6/2026 3:24 AM, Mikko wrote:
On 04/07/2026 19:55, olcott wrote:
On 7/4/2026 2:46 AM, Mikko wrote:The halting problem does not require anything unless the input
On 04/07/2026 04:52, olcott wrote:
On 7/3/2026 5:51 PM, André G. Isaak wrote:
On 2026-07-03 16:37, olcott wrote:
On 7/3/2026 1:47 PM, André G. Isaak wrote:
On 2026-07-03 12:36, olcott wrote:
On 7/3/2026 1:18 PM, dbush wrote:
If an algorithm takes an input and produces an output, that >>>>>>>>>>> is by definition a mapping.That only proves that the definition is incoherent.
The coherent way that it actually works is that
inputs are transformed into outputs by applying
finite string transformation rules to inputs to
derive outputs.
Apparently you don't understand the difference between a
mapping and an algorithm. They are two different things.
André
A function that ignores its input and only returns 0
is not any sort of halt function.
He was defining 'mapping', not 'halt function'.
André
A actual halt function must compute the mapping from
its actual input according to the operational semantics
of this input to the behavior that this input actually
specifies. No function can report on the behavior of
its caller because it has no idea who its caller is.
A function does not compute. An algrothm may compute a function.
However, no algrithm computes the halt function.
The halt functions maps a computation to a truth value
but so do many other functions, too.
When implemented as C functions
typedef int (*ptr)();
int HHH(ptr P);
01 int DD()
02 {
03 int Halt_Status = HHH(DD);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 void main()
10 {
11 DD();
12 HHH(DD);
13 }
The HP requires HHH to report on the DD() invoked
in main(). This is impossible because HHH has no
idea who its caller is and deciders are functions
that only operate on their arguments.
fully specifies a computation.
The above DD calls HHH, which must be the same HHH as main calls if
DD halts. Therefore the bhaviour of HHH is a part of the computation
that the HHH would answer about if it were a halt decider.
HHH(DD) can and does correctly report on its input.
I just can get why it is taking so long for people
to understand that DD executed in main is out-of-scope
for HHH. It is like someone took actual brains apart
and welded in short-circuits.
It does not really matter. HHH and DD are not interesting and you
have never said anyting interesting about them.
On 06/07/2026 18:33, olcott wrote:
On 7/6/2026 3:37 AM, Mikko wrote:
On 04/07/2026 20:01, olcott wrote:
On 7/4/2026 2:55 AM, Mikko wrote:
On 03/07/2026 21:45, olcott wrote:
On 7/3/2026 1:27 PM, dbush wrote:
On 7/3/2026 2:10 PM, olcott wrote:{
On 7/3/2026 12:10 PM, dbush wrote:
On 7/3/2026 12:52 PM, olcott wrote:Ignoring the input IS NOT A MAPPING
On 7/3/2026 10:50 AM, dbush wrote:Does algorithm H map machine description X and machine input Y >>>>>>>>> to an output of either 0 or 1?
On 7/3/2026 11:36 AM, olcott wrote:
On 7/3/2026 4:22 AM, Mikko wrote:
On 02/07/2026 17:51, olcott wrote:
Do you know enough about C to understand that
dbush example was foolish nonsense when proposed
to show the halting problem counter-example?
It is a valid example of a C program. It was present as a >>>>>>>>>>>>> part of a
claim about you, and your response was the false claim that >>>>>>>>>>>>> "That
is just nonsense". Later in the discussion you offer more >>>>>>>>>>>>> evidence
to support his claim.
His halt decider did not look at its input.
Nor is it required to. All it needs to do is map inputs to >>>>>>>>>>> outputs.
So a piece of metal sitting on the ground is an automobile. >>>>>>>>>
A mapping is nothing more than an association of inputs to outputs, >>>>>> int Not_A_Mapping(int X)
return 0;
}
By construing that as a mapping is one of the screw-ups
that prevents true expressed in language from being computable.
By construing the above mapping as a non-mapping you disconnect from >>>>> Common Languge and lose your ablility to communicate.
I will not tolerate that math hijacks the term
"mapping" to ignore requirement that there must
be some actual correspondence between inputs and
outputs.
Your exceesive intolerance is irrelevant.
It makes terms-of-the-art into damned liars.
No, your excessive intolerance does not do that.
On 06/07/2026 18:38, olcott wrote:
On 7/6/2026 3:55 AM, Mikko wrote:
On 04/07/2026 20:03, olcott wrote:
On 7/4/2026 3:00 AM, Mikko wrote:
On 03/07/2026 22:08, olcott wrote:
On 7/3/2026 1:27 PM, dbush wrote:
On 7/3/2026 2:10 PM, olcott wrote:
On 7/3/2026 12:10 PM, dbush wrote:
On 7/3/2026 12:52 PM, olcott wrote:Ignoring the input IS NOT A MAPPING
On 7/3/2026 10:50 AM, dbush wrote:Does algorithm H map machine description X and machine input Y >>>>>>>>> to an output of either 0 or 1?
On 7/3/2026 11:36 AM, olcott wrote:
On 7/3/2026 4:22 AM, Mikko wrote:
On 02/07/2026 17:51, olcott wrote:
Do you know enough about C to understand that
dbush example was foolish nonsense when proposed
to show the halting problem counter-example?
It is a valid example of a C program. It was present as a >>>>>>>>>>>>> part of a
claim about you, and your response was the false claim that >>>>>>>>>>>>> "That
is just nonsense". Later in the discussion you offer more >>>>>>>>>>>>> evidence
to support his claim.
His halt decider did not look at its input.
Nor is it required to. All it needs to do is map inputs to >>>>>>>>>>> outputs.
So a piece of metal sitting on the ground is an automobile. >>>>>>>>>
A mapping is nothing more than an association of inputs to
outputs, so there is nothing to ignore. What an algorithm might >>>>>>> do to *compute* the mapping has nothing to do with the mapping.
It is conventionally construed as a mapping.
More importantly, it satisfies the definition of "mapping".
It is not even conventionally construed as a halt
function, not even a halt function that gets the
wrong answer.
Irrelevant, as the claim was that H does not implement the halt
function.
If it ignores input it is no function of this input.
Everything that is required to be in the argument list of a function
is an argument to that function, even when the function "ignores" it.
You are entirely right on the linguistic front. If we look strictly at
the compositional meaning of the words in everyday language, calling
something a "function of an input" when it ignores that input is, at
best, a paradox and, at worst, a semantic lie.
The word "function" is has many meanings in everday language anyway.
Sometimes it means what someone does, sometimes what one does not do
although should do. The interpretation depends on the context. In
some contexts the correct interpretation is the mathematical meaning.
On 7/8/2026 2:42 AM, Mikko wrote:
On 06/07/2026 17:36, olcott wrote:
On 7/6/2026 2:59 AM, Mikko wrote:
On 04/07/2026 20:13, olcott wrote:
On 7/4/2026 3:49 AM, Mikko wrote:
On 03/07/2026 21:38, olcott wrote:
On 7/3/2026 1:21 PM, André G. Isaak wrote:
On 2026-07-03 12:12, olcott wrote:
On 7/3/2026 12:17 PM, André G. Isaak wrote:
On 2026-07-03 10:48, olcott wrote:Model theory has been expressly off-topic for
On 7/3/2026 9:45 AM, André G. Isaak wrote:Because it isn't true in all models of Q,
On 2026-07-02 23:02, olcott wrote:
On 7/1/2026 9:03 PM, olcott wrote:
Q cannot do the ∀x without an infinite sequence of steps. >>>>>>>>>>>>>So your phrasing is good: Q would need something like an >>>>>>>>>>>>> infinite sequence of steps (or a single principle that >>>>>>>>>>>>> summarizes them) to get the ∀x. Since formal proofs must be >>>>>>>>>>>>> finite, and Q lacks the tool (induction) that would allow a >>>>>>>>>>>>> finite proof of the infinite claim, the universal statement >>>>>>>>>>>>> remains unprovable.
I'm not sure why you are responding to yourself nor who >>>>>>>>>>>> 'your phrasing' refers to since you don't quote anyone. But, >>>>>>>>>>>> assuming we're still talking about ∀ x, S(x) ≠ x in Q, your >>>>>>>>>>>> reasoning is simply off.
You *can* prove universally quantified claims in Q, just not >>>>>>>>>>>> that particular claim.
What is the reason that (∀x, S(x) ≠ x) cannot be proved in Q? >>>>>>>>>>
many weeks in every thread. Whenever you ignore
this the rest of your reply will be ignored.
The rest of my post which you snipped and (presumably) ignored >>>>>>>> explained *why* you are wrong about this. PTS does not reject >>>>>>>> models or model theory. It simply doesn't rely on model-
theoretic semantics. Q *requires* a model.
It replaces Model theory With PTS.
That you do not understand this is your mistake.
"Is x true" is replaced with something like "Is x provable".
"Is x provable" is there already. Why would one want to lose
"Is x true"? If one dosn't need "Is x true" one needn't use
it.
The whole focus of most PTS "Is x provable".
Model theory looks at true in a model and ignores
the connection between true and provable.
People rarely care about PTS or model theory. More often they
careabout what is or is not true about someting they consider
important.
Hence we must correct the divergence of logic
from correct reasoning if we are to automate
correct reasoning.
Most people would accept as correct any reasoning that produce true
conclusions from true premises.
I need a system that is good enough to make disinformation
systems funded by many billions per year look like ridiculous
fools even to themselves.
On 7/8/2026 2:48 AM, Mikko wrote:
On 06/07/2026 18:27, olcott wrote:
On 7/6/2026 3:11 AM, Mikko wrote:
On 04/07/2026 19:58, olcott wrote:
On 7/4/2026 2:48 AM, Mikko wrote:
On 04/07/2026 05:37, olcott wrote:
On 7/3/2026 9:19 PM, dbush wrote:
On 7/3/2026 10:05 PM, olcott wrote:Impossible requirements are incorrect requirements.
On 7/3/2026 8:58 PM, dbush wrote:
On 7/3/2026 9:52 PM, olcott wrote:
On 7/3/2026 5:51 PM, André G. Isaak wrote:The mathematical halting function:
On 2026-07-03 16:37, olcott wrote:
On 7/3/2026 1:47 PM, André G. Isaak wrote:
On 2026-07-03 12:36, olcott wrote:
On 7/3/2026 1:18 PM, dbush wrote:
If an algorithm takes an input and produces an output, >>>>>>>>>>>>>>>> that is by definition a mapping.That only proves that the definition is incoherent. >>>>>>>>>>>>>>> The coherent way that it actually works is that
inputs are transformed into outputs by applying
finite string transformation rules to inputs to
derive outputs.
Apparently you don't understand the difference between a >>>>>>>>>>>>>> mapping and an algorithm. They are two different things. >>>>>>>>>>>>>>
André
A function that ignores its input and only returns 0 >>>>>>>>>>>>> is not any sort of halt function.
He was defining 'mapping', not 'halt function'.
André
A actual halt function must compute
When you actually implement this concretely
We find that it is not possible, as Linz and others have proved. >>>>>>>
There is no well known meaning of "incorrect requirements".
I just established the meaning of incorrect requirements
as any requirement that requires the logically impossible.
That is insufficient to make the expression "incorrect requirements"
meaningful in Common Language or well known.
In other words if the requirement is to compute the square
root of the actual dead flesh of a dead chicken you would
not reject this out-of hand?
Depends on what yuo count as rejection. I don't think I would
try to meet that requirement.
Incorrect decision problem requirements.
On 7/8/2026 2:55 AM, Mikko wrote:
On 06/07/2026 18:30, olcott wrote:
On 7/6/2026 3:24 AM, Mikko wrote:
On 04/07/2026 19:55, olcott wrote:
On 7/4/2026 2:46 AM, Mikko wrote:The halting problem does not require anything unless the input
On 04/07/2026 04:52, olcott wrote:
On 7/3/2026 5:51 PM, André G. Isaak wrote:
On 2026-07-03 16:37, olcott wrote:
On 7/3/2026 1:47 PM, André G. Isaak wrote:
On 2026-07-03 12:36, olcott wrote:
On 7/3/2026 1:18 PM, dbush wrote:
If an algorithm takes an input and produces an output, that >>>>>>>>>>>> is by definition a mapping.That only proves that the definition is incoherent.
The coherent way that it actually works is that
inputs are transformed into outputs by applying
finite string transformation rules to inputs to
derive outputs.
Apparently you don't understand the difference between a
mapping and an algorithm. They are two different things.
André
A function that ignores its input and only returns 0
is not any sort of halt function.
He was defining 'mapping', not 'halt function'.
André
A actual halt function must compute the mapping from
its actual input according to the operational semantics
of this input to the behavior that this input actually
specifies. No function can report on the behavior of
its caller because it has no idea who its caller is.
A function does not compute. An algrothm may compute a function.
However, no algrithm computes the halt function.
The halt functions maps a computation to a truth value
but so do many other functions, too.
When implemented as C functions
typedef int (*ptr)();
int HHH(ptr P);
01 int DD()
02 {
03 int Halt_Status = HHH(DD);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 void main()
10 {
11 DD();
12 HHH(DD);
13 }
The HP requires HHH to report on the DD() invoked
in main(). This is impossible because HHH has no
idea who its caller is and deciders are functions
that only operate on their arguments.
fully specifies a computation.
The above DD calls HHH, which must be the same HHH as main calls if
DD halts. Therefore the bhaviour of HHH is a part of the computation
that the HHH would answer about if it were a halt decider.
HHH(DD) can and does correctly report on its input.
I just can get why it is taking so long for people
to understand that DD executed in main is out-of-scope
for HHH. It is like someone took actual brains apart
and welded in short-circuits.
It does not really matter. HHH and DD are not interesting and you
have never said anyting interesting about them.
HHH/DD conclusively proves that the halting problem
proof has always been incorrect.
On 7/8/2026 2:59 AM, Mikko wrote:
On 06/07/2026 18:33, olcott wrote:
On 7/6/2026 3:37 AM, Mikko wrote:
On 04/07/2026 20:01, olcott wrote:
On 7/4/2026 2:55 AM, Mikko wrote:
On 03/07/2026 21:45, olcott wrote:
On 7/3/2026 1:27 PM, dbush wrote:
On 7/3/2026 2:10 PM, olcott wrote:{
On 7/3/2026 12:10 PM, dbush wrote:
On 7/3/2026 12:52 PM, olcott wrote:Ignoring the input IS NOT A MAPPING
On 7/3/2026 10:50 AM, dbush wrote:Does algorithm H map machine description X and machine input Y >>>>>>>>>> to an output of either 0 or 1?
On 7/3/2026 11:36 AM, olcott wrote:
On 7/3/2026 4:22 AM, Mikko wrote:
On 02/07/2026 17:51, olcott wrote:
Do you know enough about C to understand that
dbush example was foolish nonsense when proposed >>>>>>>>>>>>>>> to show the halting problem counter-example?
It is a valid example of a C program. It was present as a >>>>>>>>>>>>>> part of a
claim about you, and your response was the false claim >>>>>>>>>>>>>> that "That
is just nonsense". Later in the discussion you offer more >>>>>>>>>>>>>> evidence
to support his claim.
His halt decider did not look at its input.
Nor is it required to. All it needs to do is map inputs to >>>>>>>>>>>> outputs.
So a piece of metal sitting on the ground is an automobile. >>>>>>>>>>
A mapping is nothing more than an association of inputs to outputs, >>>>>>> int Not_A_Mapping(int X)
return 0;
}
By construing that as a mapping is one of the screw-ups
that prevents true expressed in language from being computable.
By construing the above mapping as a non-mapping you disconnect from >>>>>> Common Languge and lose your ablility to communicate.
I will not tolerate that math hijacks the term
"mapping" to ignore requirement that there must
be some actual correspondence between inputs and
outputs.
Your exceesive intolerance is irrelevant.
It makes terms-of-the-art into damned liars.
No, your excessive intolerance does not do that.
All knowledge has its own natural type hierarchy.
On 7/8/2026 3:09 AM, Mikko wrote:
On 06/07/2026 18:38, olcott wrote:
On 7/6/2026 3:55 AM, Mikko wrote:
On 04/07/2026 20:03, olcott wrote:
On 7/4/2026 3:00 AM, Mikko wrote:
On 03/07/2026 22:08, olcott wrote:
On 7/3/2026 1:27 PM, dbush wrote:
On 7/3/2026 2:10 PM, olcott wrote:It is conventionally construed as a mapping.
On 7/3/2026 12:10 PM, dbush wrote:
On 7/3/2026 12:52 PM, olcott wrote:Ignoring the input IS NOT A MAPPING
On 7/3/2026 10:50 AM, dbush wrote:Does algorithm H map machine description X and machine input Y >>>>>>>>>> to an output of either 0 or 1?
On 7/3/2026 11:36 AM, olcott wrote:
On 7/3/2026 4:22 AM, Mikko wrote:
On 02/07/2026 17:51, olcott wrote:
Do you know enough about C to understand that
dbush example was foolish nonsense when proposed >>>>>>>>>>>>>>> to show the halting problem counter-example?
It is a valid example of a C program. It was present as a >>>>>>>>>>>>>> part of a
claim about you, and your response was the false claim >>>>>>>>>>>>>> that "That
is just nonsense". Later in the discussion you offer more >>>>>>>>>>>>>> evidence
to support his claim.
His halt decider did not look at its input.
Nor is it required to. All it needs to do is map inputs to >>>>>>>>>>>> outputs.
So a piece of metal sitting on the ground is an automobile. >>>>>>>>>>
A mapping is nothing more than an association of inputs to
outputs, so there is nothing to ignore. What an algorithm might >>>>>>>> do to *compute* the mapping has nothing to do with the mapping. >>>>>>>
More importantly, it satisfies the definition of "mapping".
It is not even conventionally construed as a halt
function, not even a halt function that gets the
wrong answer.
Irrelevant, as the claim was that H does not implement the halt
function.
If it ignores input it is no function of this input.
Everything that is required to be in the argument list of a function
is an argument to that function, even when the function "ignores" it.
You are entirely right on the linguistic front. If we look strictly
at the compositional meaning of the words in everyday language,
calling something a "function of an input" when it ignores that input
is, at best, a paradox and, at worst, a semantic lie.
The word "function" is has many meanings in everday language anyway.
A function of its inputs cannot fucking ignore these
fucking inputs and not be a damned liar.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,142 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 91:07:56 |
| Calls: | 14,704 |
| Calls today: | 2 |
| Files: | 186,497 |
| D/L today: |
1,900 files (564M bytes) |
| Messages: | 2,551,613 |