On 3/18/2025 3:59 AM, Fred. Zwarts wrote:
Op 17.mrt.2025 om 20:45 schreef olcott:
On 3/17/2025 2:41 PM, olcott wrote:
It is impossible for one TM X to determine that another
TM Y has only an infinite loop on the basis of the direct
execution of Y. No TM can in any way monitor the direct
execution of another TM.
NO TM halt decider can possibly exist that
reports on the basis of the direct execution
of another TM.
Is that again a strange way to say 'Yes, I agree'?
It points out that the definition of the halting problem
that requires reporting on the direct execution IS WRONG.
On the other hand there is nothing wrong with having a halt
decider report on the behavior that its finite string input
specifies by simulating this finite string according to its
specified semantics.
On 3/18/2025 3:59 AM, Fred. Zwarts wrote:
Op 17.mrt.2025 om 20:45 schreef olcott:
On 3/17/2025 2:41 PM, olcott wrote:
It is impossible for one TM X to determine that another
TM Y has only an infinite loop on the basis of the direct
execution of Y. No TM can in any way monitor the direct
execution of another TM.
NO TM halt decider can possibly exist that
reports on the basis of the direct execution
of another TM.
Is that again a strange way to say 'Yes, I agree'?
It points out that the definition of the halting problem
that requires reporting on the direct execution IS WRONG.
On the other hand there is nothing wrong with having a halt
decider report on the behavior that its finite string input
specifies by simulating this finite string according to its
specified semantics.
_DDD()
[00002172] 55 push ebp ; housekeeping
[00002173] 8bec mov ebp,esp ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404 add esp,+04
[00002182] 5d pop ebp
[00002183] c3 ret
Size in bytes:(0018) [00002183]
DDD correctly emulated** by HHH that includes HHH
emulating itself emulating DDD cannot possibly
reach the "ret" instruction of DDD and halt.
**Correctly emulated means emulated according to
the semantics of the x86 language.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
DD correctly simulated*** by HHH that includes HHH
emulating itself emulating DD cannot possibly
reach the "ret" instruction of DD and halt. DD
remains stuck on its first line.
***Correctly simulated means simulated according to
the semantics of the C language.
On 3/18/2025 10:36 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 14:48 schreef olcott:
On 3/18/2025 3:59 AM, Fred. Zwarts wrote:
Op 17.mrt.2025 om 20:45 schreef olcott:
On 3/17/2025 2:41 PM, olcott wrote:
It is impossible for one TM X to determine that another
TM Y has only an infinite loop on the basis of the direct
execution of Y. No TM can in any way monitor the direct
execution of another TM.
NO TM halt decider can possibly exist that
reports on the basis of the direct execution
of another TM.
Is that again a strange way to say 'Yes, I agree'?
It points out that the definition of the halting problem
that requires reporting on the direct execution IS WRONG.
On the other hand there is nothing wrong with having a halt
decider report on the behavior that its finite string input
specifies by simulating this finite string according to its
specified semantics.
No 'yes' or 'no' again, but a lot of words again. But I have the
impression that these words mean: 'Yes, I agree that no algorithm can
determine for all possible inputs whether the input describes a
program that halts when directly executed.
Correct?
So you don't understand what I said?
No Halt decider can ever report on the direct execution
of any other TM because it has no access to this direct
execution. At most it only has a finite string machine
code proxy of what the direct execution might be.
On 3/18/2025 3:59 AM, Fred. Zwarts wrote:
Op 17.mrt.2025 om 20:45 schreef olcott:
On 3/17/2025 2:41 PM, olcott wrote:
It is impossible for one TM X to determine that another
TM Y has only an infinite loop on the basis of the direct
execution of Y. No TM can in any way monitor the direct
execution of another TM.
NO TM halt decider can possibly exist that
reports on the basis of the direct execution
of another TM.
Is that again a strange way to say 'Yes, I agree'?
It points out that the definition of the halting problem
that requires reporting on the direct execution IS WRONG.
On 3/18/2025 10:36 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 14:48 schreef olcott:
On 3/18/2025 3:59 AM, Fred. Zwarts wrote:
Op 17.mrt.2025 om 20:45 schreef olcott:
On 3/17/2025 2:41 PM, olcott wrote:
It is impossible for one TM X to determine that another
TM Y has only an infinite loop on the basis of the direct
execution of Y. No TM can in any way monitor the direct
execution of another TM.
NO TM halt decider can possibly exist that
reports on the basis of the direct execution
of another TM.
Is that again a strange way to say 'Yes, I agree'?
It points out that the definition of the halting problem
that requires reporting on the direct execution IS WRONG.
On the other hand there is nothing wrong with having a halt
decider report on the behavior that its finite string input
specifies by simulating this finite string according to its
specified semantics.
No 'yes' or 'no' again, but a lot of words again. But I have the
impression that these words mean: 'Yes, I agree that no algorithm can
determine for all possible inputs whether the input describes a program
that halts when directly executed.
Correct?
So you don't understand what I said?
No Halt decider can ever report on the direct execution
of any other TM because it has no access to this direct
execution. At most it only has a finite string machine
code proxy of what the direct execution might be.
On 3/19/2025 4:20 AM, Fred. Zwarts wrote:Which makes H not a decider at all.
Op 18.mrt.2025 om 16:50 schreef olcott:
On 3/18/2025 10:36 AM, Fred. Zwarts wrote:Again no 'yes' or 'no', but I think it can be interpreted as a 'yes'.
Op 18.mrt.2025 om 14:48 schreef olcott:So you don't understand what I said?
On 3/18/2025 3:59 AM, Fred. Zwarts wrote:No 'yes' or 'no' again, but a lot of words again. But I have the
Op 17.mrt.2025 om 20:45 schreef olcott:
On 3/17/2025 2:41 PM, olcott wrote:Is that again a strange way to say 'Yes, I agree'?
NO TM halt decider can possibly exist that reports on the basis of >>>>>>> the direct execution of another TM.
It is impossible for one TM X to determine that another TM Y has >>>>>>>> only an infinite loop on the basis of the direct execution of Y. >>>>>>>> No TM can in any way monitor the direct execution of another TM. >>>>>>>>
It points out that the definition of the halting problem that
requires reporting on the direct execution IS WRONG.
On the other hand there is nothing wrong with having a halt decider
report on the behavior that its finite string input specifies by
simulating this finite string according to its specified semantics.
impression that these words mean: 'Yes, I agree that no algorithm can
determine for all possible inputs whether the input describes a
program that halts when directly executed.
Correct?
No Halt decider can ever report on the direct execution of any other
TM because it has no access to this direct execution. At most it only
has a finite string machine code proxy of what the direct execution
might be.
Correct?
You are saying There exists an input D to halt decider H such that H
gets the wrong answer.
I am saying That for all inputs D there does not exist a halt decider HWrong as written: for every program D there is another program that
that gets the correct answer:
when halt decider H is required to report on the behavior of the--
directly execute D. No halt decider H can ever report on the behavior
of a directly executed D.
On 3/19/2025 8:38 AM, Mikko wrote:
On 2025-03-18 15:50:22 +0000, olcott said:
On 3/18/2025 10:36 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 14:48 schreef olcott:
On 3/18/2025 3:59 AM, Fred. Zwarts wrote:
Op 17.mrt.2025 om 20:45 schreef olcott:
On 3/17/2025 2:41 PM, olcott wrote:
It is impossible for one TM X to determine that another
TM Y has only an infinite loop on the basis of the direct
execution of Y. No TM can in any way monitor the direct
execution of another TM.
NO TM halt decider can possibly exist that
reports on the basis of the direct execution
of another TM.
Is that again a strange way to say 'Yes, I agree'?
It points out that the definition of the halting problem
that requires reporting on the direct execution IS WRONG.
On the other hand there is nothing wrong with having a halt
decider report on the behavior that its finite string input
specifies by simulating this finite string according to its
specified semantics.
No 'yes' or 'no' again, but a lot of words again. But I have the
impression that these words mean: 'Yes, I agree that no algorithm can
determine for all possible inputs whether the input describes a program >>>> that halts when directly executed.
Correct?
So you don't understand what I said?
He understood. Whether he undestood correctely is less clear but
apparently yes because you don't contradict his understanding.
No Halt decider can ever report on the direct execution
of any other TM because it has no access to this direct
execution. At most it only has a finite string machine
code proxy of what the direct execution might be.
He is not bothered to pay any attention to the entirely
different quantifiers. Maybe has has no idea what
quantification is.
On 3/19/2025 4:20 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 16:50 schreef olcott:
On 3/18/2025 10:36 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 14:48 schreef olcott:
On 3/18/2025 3:59 AM, Fred. Zwarts wrote:
Op 17.mrt.2025 om 20:45 schreef olcott:
On 3/17/2025 2:41 PM, olcott wrote:
It is impossible for one TM X to determine that another
TM Y has only an infinite loop on the basis of the direct
execution of Y. No TM can in any way monitor the direct
execution of another TM.
NO TM halt decider can possibly exist that
reports on the basis of the direct execution
of another TM.
Is that again a strange way to say 'Yes, I agree'?
It points out that the definition of the halting problem
that requires reporting on the direct execution IS WRONG.
On the other hand there is nothing wrong with having a halt
decider report on the behavior that its finite string input
specifies by simulating this finite string according to its
specified semantics.
No 'yes' or 'no' again, but a lot of words again. But I have the
impression that these words mean: 'Yes, I agree that no algorithm can
determine for all possible inputs whether the input describes a program >>>> that halts when directly executed.
Correct?
So you don't understand what I said?
No Halt decider can ever report on the direct execution
of any other TM because it has no access to this direct
execution. At most it only has a finite string machine
code proxy of what the direct execution might be.
Again no 'yes' or 'no', but I think it can be interpreted as a 'yes'.
Correct?
You are saying
There exists an input D to halt decider H such that
H gets the wrong answer.
I am saying
That for all inputs D there does not exist
a halt decider H that gets the correct answer:
when halt decider H is required to report on the
behavior of the directly execute D. No halt decider
H can ever report on the behavior of a directly
executed D.
On 3/19/2025 4:20 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 16:50 schreef olcott:
On 3/18/2025 10:36 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 14:48 schreef olcott:
On 3/18/2025 3:59 AM, Fred. Zwarts wrote:
Op 17.mrt.2025 om 20:45 schreef olcott:
On 3/17/2025 2:41 PM, olcott wrote:
It is impossible for one TM X to determine that another
TM Y has only an infinite loop on the basis of the direct
execution of Y. No TM can in any way monitor the direct
execution of another TM.
NO TM halt decider can possibly exist that
reports on the basis of the direct execution
of another TM.
Is that again a strange way to say 'Yes, I agree'?
It points out that the definition of the halting problem
that requires reporting on the direct execution IS WRONG.
On the other hand there is nothing wrong with having a halt
decider report on the behavior that its finite string input
specifies by simulating this finite string according to its
specified semantics.
No 'yes' or 'no' again, but a lot of words again. But I have the
impression that these words mean: 'Yes, I agree that no algorithm
can determine for all possible inputs whether the input describes a
program that halts when directly executed.
Correct?
So you don't understand what I said?
No Halt decider can ever report on the direct execution
of any other TM because it has no access to this direct
execution. At most it only has a finite string machine
code proxy of what the direct execution might be.
Again no 'yes' or 'no', but I think it can be interpreted as a 'yes'.
Correct?
You are saying
There exists an input D to halt decider H such that
H gets the wrong answer.
I am saying
That for all inputs D there does not exist
a halt decider H that gets the correct answer:
when halt decider H is required to report on the
behavior of the directly execute D. No halt decider
H can ever report on the behavior of a directly
executed D.
On 3/19/2025 6:19 AM, Mikko wrote:
On 2025-03-18 13:48:10 +0000, olcott said:
On 3/18/2025 3:59 AM, Fred. Zwarts wrote:
Op 17.mrt.2025 om 20:45 schreef olcott:
On 3/17/2025 2:41 PM, olcott wrote:
It is impossible for one TM X to determine that another
TM Y has only an infinite loop on the basis of the direct
execution of Y. No TM can in any way monitor the direct
execution of another TM.
NO TM halt decider can possibly exist that
reports on the basis of the direct execution
of another TM.
Is that again a strange way to say 'Yes, I agree'?
It points out that the definition of the halting problem
that requires reporting on the direct execution IS WRONG.
The definition of the halting problem is not wrong. It defines,
which is the only thing a defintion needs to do. It defines
a problem and the problem is about halting so the defined
problem is given a reasonable name. In addition, it is useful
to know whether a Turing machine halts on a particular input,
at least about some Turing machines and inputs.
When it specifies that a halt decider H must report on the
behavior of the direct execution of another Turing Machine M
this requirement is incorrect because no Turing machine
ever has any access to the behavior of any directly executing
Turing machine.
On 3/19/2025 11:16 AM, Mikko wrote:That is not what I say. I did not mention H or D, nor do you see the
On 2025-03-19 15:28:33 +0000, olcott said:
On 3/19/2025 4:20 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 16:50 schreef olcott:
On 3/18/2025 10:36 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 14:48 schreef olcott:
On 3/18/2025 3:59 AM, Fred. Zwarts wrote:
Op 17.mrt.2025 om 20:45 schreef olcott:
On 3/17/2025 2:41 PM, olcott wrote:
It is impossible for one TM X to determine that another
TM Y has only an infinite loop on the basis of the direct
execution of Y. No TM can in any way monitor the direct
execution of another TM.
NO TM halt decider can possibly exist that
reports on the basis of the direct execution
of another TM.
Is that again a strange way to say 'Yes, I agree'?
It points out that the definition of the halting problem
that requires reporting on the direct execution IS WRONG.
On the other hand there is nothing wrong with having a halt
decider report on the behavior that its finite string input
specifies by simulating this finite string according to its
specified semantics.
No 'yes' or 'no' again, but a lot of words again. But I have the
impression that these words mean: 'Yes, I agree that no algorithm
can determine for all possible inputs whether the input describes
a program that halts when directly executed.
Correct?
So you don't understand what I said?
No Halt decider can ever report on the direct execution
of any other TM because it has no access to this direct
execution. At most it only has a finite string machine
code proxy of what the direct execution might be.
Again no 'yes' or 'no', but I think it can be interpreted as a 'yes'.
Correct?
You are saying
There exists an input D to halt decider H such that
H gets the wrong answer.
On 3/19/2025 11:16 AM, Mikko wrote:
On 2025-03-19 15:28:33 +0000, olcott said:
On 3/19/2025 4:20 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 16:50 schreef olcott:
On 3/18/2025 10:36 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 14:48 schreef olcott:
On 3/18/2025 3:59 AM, Fred. Zwarts wrote:
Op 17.mrt.2025 om 20:45 schreef olcott:
On 3/17/2025 2:41 PM, olcott wrote:
It is impossible for one TM X to determine that another
TM Y has only an infinite loop on the basis of the direct
execution of Y. No TM can in any way monitor the direct
execution of another TM.
NO TM halt decider can possibly exist that
reports on the basis of the direct execution
of another TM.
Is that again a strange way to say 'Yes, I agree'?
It points out that the definition of the halting problem
that requires reporting on the direct execution IS WRONG.
On the other hand there is nothing wrong with having a halt
decider report on the behavior that its finite string input
specifies by simulating this finite string according to its
specified semantics.
No 'yes' or 'no' again, but a lot of words again. But I have the
impression that these words mean: 'Yes, I agree that no algorithm can >>>>>> determine for all possible inputs whether the input describes a program >>>>>> that halts when directly executed.
Correct?
So you don't understand what I said?
No Halt decider can ever report on the direct execution
of any other TM because it has no access to this direct
execution. At most it only has a finite string machine
code proxy of what the direct execution might be.
Again no 'yes' or 'no', but I think it can be interpreted as a 'yes'.
Correct?
You are saying
There exists an input D to halt decider H such that
H gets the wrong answer.
I am saying
That for all inputs D there does not exist
a halt decider H that gets the correct answer:
when halt decider H is required to report on the
behavior of the directly execute D. No halt decider
H can ever report on the behavior of a directly
executed D.
I.e., you agree and generalize.
The specification of the halting problem that dbush
kept repeating is common knowledge about what the
halting problem is AND INCORRECT.
The halting problem requires what no TM can ever do.
On 3/19/2025 11:18 AM, Mikko wrote:
On 2025-03-19 15:31:59 +0000, olcott said:
On 3/19/2025 8:38 AM, Mikko wrote:
On 2025-03-18 15:50:22 +0000, olcott said:
On 3/18/2025 10:36 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 14:48 schreef olcott:
On 3/18/2025 3:59 AM, Fred. Zwarts wrote:
Op 17.mrt.2025 om 20:45 schreef olcott:
On 3/17/2025 2:41 PM, olcott wrote:
It is impossible for one TM X to determine that another
TM Y has only an infinite loop on the basis of the direct
execution of Y. No TM can in any way monitor the direct
execution of another TM.
NO TM halt decider can possibly exist that
reports on the basis of the direct execution
of another TM.
Is that again a strange way to say 'Yes, I agree'?
It points out that the definition of the halting problem
that requires reporting on the direct execution IS WRONG.
On the other hand there is nothing wrong with having a halt
decider report on the behavior that its finite string input
specifies by simulating this finite string according to its
specified semantics.
No 'yes' or 'no' again, but a lot of words again. But I have the
impression that these words mean: 'Yes, I agree that no algorithm can >>>>>> determine for all possible inputs whether the input describes a program >>>>>> that halts when directly executed.
Correct?
So you don't understand what I said?
He understood. Whether he undestood correctely is less clear but
apparently yes because you don't contradict his understanding.
No Halt decider can ever report on the direct execution
of any other TM because it has no access to this direct
execution. At most it only has a finite string machine
code proxy of what the direct execution might be.
He is not bothered to pay any attention to the entirely
different quantifiers. Maybe has has no idea what
quantification is.
There are no quantifiers in "yes" and no more in "no".
*His YES and NO is stupidly wrong*
He is saying for all halt deciders H there exists
an input an input D that each H gets incorrectly.
I am saying for all inputs D there does not exist
a halt decider H that reports on the behavior
of the direct execution of input D
On 3/19/2025 6:19 AM, Mikko wrote:
On 2025-03-18 13:48:10 +0000, olcott said:
On 3/18/2025 3:59 AM, Fred. Zwarts wrote:
Op 17.mrt.2025 om 20:45 schreef olcott:
On 3/17/2025 2:41 PM, olcott wrote:
It is impossible for one TM X to determine that another
TM Y has only an infinite loop on the basis of the direct
execution of Y. No TM can in any way monitor the direct
execution of another TM.
NO TM halt decider can possibly exist that
reports on the basis of the direct execution
of another TM.
Is that again a strange way to say 'Yes, I agree'?
It points out that the definition of the halting problem
that requires reporting on the direct execution IS WRONG.
The definition of the halting problem is not wrong. It defines,
which is the only thing a defintion needs to do. It defines
a problem and the problem is about halting so the defined
problem is given a reasonable name. In addition, it is useful
to know whether a Turing machine halts on a particular input,
at least about some Turing machines and inputs.
When it specifies that a halt decider H must report on the
behavior of the direct execution of another Turing Machine M
this requirement is incorrect because no Turing machine
ever has any access to the behavior of any directly executing
Turing machine.
On 3/20/2025 4:33 AM, Mikko wrote:
On 2025-03-19 16:57:05 +0000, olcott said:
On 3/19/2025 6:19 AM, Mikko wrote:
On 2025-03-18 13:48:10 +0000, olcott said:
On 3/18/2025 3:59 AM, Fred. Zwarts wrote:
Op 17.mrt.2025 om 20:45 schreef olcott:
On 3/17/2025 2:41 PM, olcott wrote:
It is impossible for one TM X to determine that another
TM Y has only an infinite loop on the basis of the direct
execution of Y. No TM can in any way monitor the direct
execution of another TM.
NO TM halt decider can possibly exist that
reports on the basis of the direct execution
of another TM.
Is that again a strange way to say 'Yes, I agree'?
It points out that the definition of the halting problem
that requires reporting on the direct execution IS WRONG.
The definition of the halting problem is not wrong. It defines,
which is the only thing a defintion needs to do. It defines
a problem and the problem is about halting so the defined
problem is given a reasonable name. In addition, it is useful
to know whether a Turing machine halts on a particular input,
at least about some Turing machines and inputs.
When it specifies that a halt decider H must report on the
behavior of the direct execution of another Turing Machine M
this requirement is incorrect because no Turing machine
ever has any access to the behavior of any directly executing
Turing machine.
Your "because" is false. What follows that "because" is not relevant
to the false claim that precedes it.
When decide means to examine an input and compute
a mapping from this input to an accept or reject
state then I am correct.
Historically a TM that merely halts accepts its input
by merely halting and totally ignoring this input.
On 3/20/2025 4:31 AM, Mikko wrote:
On 2025-03-20 00:23:32 +0000, olcott said:
On 3/19/2025 11:18 AM, Mikko wrote:
On 2025-03-19 15:31:59 +0000, olcott said:
On 3/19/2025 8:38 AM, Mikko wrote:
On 2025-03-18 15:50:22 +0000, olcott said:
On 3/18/2025 10:36 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 14:48 schreef olcott:
On 3/18/2025 3:59 AM, Fred. Zwarts wrote:
Op 17.mrt.2025 om 20:45 schreef olcott:
On 3/17/2025 2:41 PM, olcott wrote:
It is impossible for one TM X to determine that another >>>>>>>>>>>> TM Y has only an infinite loop on the basis of the direct >>>>>>>>>>>> execution of Y. No TM can in any way monitor the direct >>>>>>>>>>>> execution of another TM.
NO TM halt decider can possibly exist that
reports on the basis of the direct execution
of another TM.
Is that again a strange way to say 'Yes, I agree'?
It points out that the definition of the halting problem
that requires reporting on the direct execution IS WRONG.
On the other hand there is nothing wrong with having a halt
decider report on the behavior that its finite string input
specifies by simulating this finite string according to its
specified semantics.
No 'yes' or 'no' again, but a lot of words again. But I have the >>>>>>>> impression that these words mean: 'Yes, I agree that no algorithm can >>>>>>>> determine for all possible inputs whether the input describes a program
that halts when directly executed.
Correct?
So you don't understand what I said?
He understood. Whether he undestood correctely is less clear but
apparently yes because you don't contradict his understanding.
No Halt decider can ever report on the direct execution
of any other TM because it has no access to this direct
execution. At most it only has a finite string machine
code proxy of what the direct execution might be.
He is not bothered to pay any attention to the entirely
different quantifiers. Maybe has has no idea what
quantification is.
There are no quantifiers in "yes" and no more in "no".
*His YES and NO is stupidly wrong*
He is saying for all halt deciders H there exists
an input an input D that each H gets incorrectly.
No, he said that there is no halt decider that decides every
computation correctly. The "decider" may give a wrong answer
or no answer at all. In the latter case it does not get
anything incorrectly.
I am saying for all inputs D there does not exist
a halt decider H that reports on the behavior
of the direct execution of input D
So you agree with Fred. Zwarts and everyone that undersands the topic.
Every H gets at least one D wrong
is very stupidly misconstrued
to mean every H get every D wrong
On 3/20/2025 4:33 AM, Mikko wrote:
On 2025-03-19 16:57:05 +0000, olcott said:
On 3/19/2025 6:19 AM, Mikko wrote:
On 2025-03-18 13:48:10 +0000, olcott said:
On 3/18/2025 3:59 AM, Fred. Zwarts wrote:
Op 17.mrt.2025 om 20:45 schreef olcott:
On 3/17/2025 2:41 PM, olcott wrote:
It is impossible for one TM X to determine that another
TM Y has only an infinite loop on the basis of the direct
execution of Y. No TM can in any way monitor the direct
execution of another TM.
NO TM halt decider can possibly exist that
reports on the basis of the direct execution
of another TM.
Is that again a strange way to say 'Yes, I agree'?
It points out that the definition of the halting problem
that requires reporting on the direct execution IS WRONG.
The definition of the halting problem is not wrong. It defines,
which is the only thing a defintion needs to do. It defines
a problem and the problem is about halting so the defined
problem is given a reasonable name. In addition, it is useful
to know whether a Turing machine halts on a particular input,
at least about some Turing machines and inputs.
When it specifies that a halt decider H must report on the
behavior of the direct execution of another Turing Machine M
this requirement is incorrect because no Turing machine
ever has any access to the behavior of any directly executing
Turing machine.
Your "because" is false. What follows that "because" is not relevant
to the false claim that precedes it.
When decide means to examine an input and compute
a mapping from this input to an accept or reject
state then I am correct.
Historically a TM that merely halts accepts its input
by merely halting and totally ignoring this input.
On 3/20/2025 4:18 AM, Fred. Zwarts wrote:
Op 20.mrt.2025 om 00:53 schreef olcott:
On 3/19/2025 11:16 AM, Mikko wrote:That is not what I say. I did not mention H or D, nor do you see the
On 2025-03-19 15:28:33 +0000, olcott said:
On 3/19/2025 4:20 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 16:50 schreef olcott:
On 3/18/2025 10:36 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 14:48 schreef olcott:
On 3/18/2025 3:59 AM, Fred. Zwarts wrote:
Op 17.mrt.2025 om 20:45 schreef olcott:
On 3/17/2025 2:41 PM, olcott wrote:
It is impossible for one TM X to determine that another >>>>>>>>>>>> TM Y has only an infinite loop on the basis of the direct >>>>>>>>>>>> execution of Y. No TM can in any way monitor the direct >>>>>>>>>>>> execution of another TM.
NO TM halt decider can possibly exist that
reports on the basis of the direct execution
of another TM.
Is that again a strange way to say 'Yes, I agree'?
It points out that the definition of the halting problem
that requires reporting on the direct execution IS WRONG.
On the other hand there is nothing wrong with having a halt
decider report on the behavior that its finite string input
specifies by simulating this finite string according to its
specified semantics.
No 'yes' or 'no' again, but a lot of words again. But I have the >>>>>>>> impression that these words mean: 'Yes, I agree that no
algorithm can determine for all possible inputs whether the
input describes a program that halts when directly executed.
Correct?
So you don't understand what I said?
No Halt decider can ever report on the direct execution
of any other TM because it has no access to this direct
execution. At most it only has a finite string machine
code proxy of what the direct execution might be.
Again no 'yes' or 'no', but I think it can be interpreted as a 'yes'. >>>>>> Correct?
You are saying
There exists an input D to halt decider H such that
H gets the wrong answer.
words 'wrong answer'.
I said:
We agree that the answer on the question: *"Does an algorithm
exist that for all possible inputs returns whether it describes a
halting program in direct execution"* is 'No'?
Correct?
I AM NOT SAYING ANYTHING LIKE THAT
On 3/20/2025 4:31 AM, Mikko wrote:
On 2025-03-20 00:23:32 +0000, olcott said:
On 3/19/2025 11:18 AM, Mikko wrote:
On 2025-03-19 15:31:59 +0000, olcott said:
On 3/19/2025 8:38 AM, Mikko wrote:
On 2025-03-18 15:50:22 +0000, olcott said:
On 3/18/2025 10:36 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 14:48 schreef olcott:
On 3/18/2025 3:59 AM, Fred. Zwarts wrote:
Op 17.mrt.2025 om 20:45 schreef olcott:
On 3/17/2025 2:41 PM, olcott wrote:
It is impossible for one TM X to determine that another >>>>>>>>>>>> TM Y has only an infinite loop on the basis of the direct >>>>>>>>>>>> execution of Y. No TM can in any way monitor the direct >>>>>>>>>>>> execution of another TM.
NO TM halt decider can possibly exist that
reports on the basis of the direct execution
of another TM.
Is that again a strange way to say 'Yes, I agree'?
It points out that the definition of the halting problem
that requires reporting on the direct execution IS WRONG.
On the other hand there is nothing wrong with having a halt
decider report on the behavior that its finite string input
specifies by simulating this finite string according to its
specified semantics.
No 'yes' or 'no' again, but a lot of words again. But I have the >>>>>>>> impression that these words mean: 'Yes, I agree that no
algorithm can determine for all possible inputs whether the
input describes a program that halts when directly executed.
Correct?
So you don't understand what I said?
He understood. Whether he undestood correctely is less clear but
apparently yes because you don't contradict his understanding.
No Halt decider can ever report on the direct execution
of any other TM because it has no access to this direct
execution. At most it only has a finite string machine
code proxy of what the direct execution might be.
He is not bothered to pay any attention to the entirely
different quantifiers. Maybe has has no idea what
quantification is.
There are no quantifiers in "yes" and no more in "no".
*His YES and NO is stupidly wrong*
He is saying for all halt deciders H there exists
an input an input D that each H gets incorrectly.
No, he said that there is no halt decider that decides every
computation correctly. The "decider" may give a wrong answer
or no answer at all. In the latter case it does not get
anything incorrectly.
I am saying for all inputs D there does not exist
a halt decider H that reports on the behavior
of the direct execution of input D
So you agree with Fred. Zwarts and everyone that undersands the topic.
Every H gets at least one D wrong
is very stupidly misconstrued
to mean every H get every D wrong
On 3/21/2025 3:19 AM, Mikko wrote:Redefinition doesn't make the problem go away, namely, that you can't
On 2025-03-21 03:45:29 +0000, olcott said:
On 3/20/2025 4:31 AM, Mikko wrote:
On 2025-03-20 00:23:32 +0000, olcott said:
On 3/19/2025 11:18 AM, Mikko wrote:
On 2025-03-19 15:31:59 +0000, olcott said:
On 3/19/2025 8:38 AM, Mikko wrote:
On 2025-03-18 15:50:22 +0000, olcott said:
On 3/18/2025 10:36 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 14:48 schreef olcott:So you don't understand what I said?
On 3/18/2025 3:59 AM, Fred. Zwarts wrote:No 'yes' or 'no' again, but a lot of words again. But I have >>>>>>>>>> the impression that these words mean: 'Yes, I agree that no >>>>>>>>>> algorithm can determine for all possible inputs whether the >>>>>>>>>> input describes a program that halts when directly executed. >>>>>>>>>> Correct?
Op 17.mrt.2025 om 20:45 schreef olcott:
On 3/17/2025 2:41 PM, olcott wrote:Is that again a strange way to say 'Yes, I agree'?
NO TM halt decider can possibly exist that reports on the >>>>>>>>>>>>> basis of the direct execution of another TM.
It is impossible for one TM X to determine that another TM >>>>>>>>>>>>>> Y has only an infinite loop on the basis of the direct >>>>>>>>>>>>>> execution of Y. No TM can in any way monitor the direct >>>>>>>>>>>>>> execution of another TM.
It points out that the definition of the halting problem that >>>>>>>>>>> requires reporting on the direct execution IS WRONG.
On the other hand there is nothing wrong with having a halt >>>>>>>>>>> decider report on the behavior that its finite string input >>>>>>>>>>> specifies by simulating this finite string according to its >>>>>>>>>>> specified semantics.
He understood. Whether he undestood correctely is less clear but >>>>>>>> apparently yes because you don't contradict his understanding. >>>>>>>>
*His YES and NO is stupidly wrong*No Halt decider can ever report on the direct execution of any >>>>>>>>> other TM because it has no access to this direct execution. At >>>>>>>>> most it only has a finite string machine code proxy of what the >>>>>>>>> direct execution might be.
He is not bothered to pay any attention to the entirely different >>>>>>> quantifiers. Maybe has has no idea what quantification is.
There are no quantifiers in "yes" and no more in "no".
He is saying for all halt deciders H there exists an input an input
D that each H gets incorrectly.
No, he said that there is no halt decider that decides every
computation correctly. The "decider" may give a wrong answer or no
answer at all. In the latter case it does not get anything
incorrectly.
Every H gets at least one D incorrectly only when the halting problem is defined incoherently.If you know that then you should stop misconstruing it that way. ButEvery H gets at least one D wrong is very stupidly misconstrued toI am saying for all inputs D there does not exist a halt decider HSo you agree with Fred. Zwarts and everyone that undersands the
that reports on the behavior of the direct execution of input D
topic.
mean every H get every D wrong
both statements are someting you could cooment "Yes, that's right" or
"No, I don't think so".
By defining the halting problem as computing the mapping from the input finite string to the behavior that this finite string specifies on the
basis of the semantics of its x86 language HHH is correct to reject DD
as non-halting.
On 3/18/2025 10:36 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 14:48 schreef olcott:
On 3/18/2025 3:59 AM, Fred. Zwarts wrote:
Op 17.mrt.2025 om 20:45 schreef olcott:
On 3/17/2025 2:41 PM, olcott wrote:
It is impossible for one TM X to determine that another
TM Y has only an infinite loop on the basis of the direct
execution of Y. No TM can in any way monitor the direct
execution of another TM.
NO TM halt decider can possibly exist that
reports on the basis of the direct execution
of another TM.
Is that again a strange way to say 'Yes, I agree'?
It points out that the definition of the halting problem
that requires reporting on the direct execution IS WRONG.
On the other hand there is nothing wrong with having a halt
decider report on the behavior that its finite string input
specifies by simulating this finite string according to its
specified semantics.
No 'yes' or 'no' again, but a lot of words again. But I have the
impression that these words mean: 'Yes, I agree that no algorithm can
determine for all possible inputs whether the input describes a
program that halts when directly executed.
Correct?
...
No Halt decider can ever report on the direct execution
of any other TM because it has no access to this direct
execution. At most it only has a finite string machine
code proxy of what the direct execution might be.
On 3/21/2025 4:28 AM, Fred. Zwarts wrote:
Op 20.mrt.2025 om 23:15 schreef olcott:
On 3/20/2025 4:18 AM, Fred. Zwarts wrote:
Op 20.mrt.2025 om 00:53 schreef olcott:
On 3/19/2025 11:16 AM, Mikko wrote:That is not what I say. I did not mention H or D, nor do you see the
On 2025-03-19 15:28:33 +0000, olcott said:
On 3/19/2025 4:20 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 16:50 schreef olcott:
On 3/18/2025 10:36 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 14:48 schreef olcott:
On 3/18/2025 3:59 AM, Fred. Zwarts wrote:
Op 17.mrt.2025 om 20:45 schreef olcott:
On 3/17/2025 2:41 PM, olcott wrote:
It is impossible for one TM X to determine that another >>>>>>>>>>>>>> TM Y has only an infinite loop on the basis of the direct >>>>>>>>>>>>>> execution of Y. No TM can in any way monitor the direct >>>>>>>>>>>>>> execution of another TM.
NO TM halt decider can possibly exist that
reports on the basis of the direct execution
of another TM.
Is that again a strange way to say 'Yes, I agree'?
It points out that the definition of the halting problem >>>>>>>>>>> that requires reporting on the direct execution IS WRONG. >>>>>>>>>>>
On the other hand there is nothing wrong with having a halt >>>>>>>>>>> decider report on the behavior that its finite string input >>>>>>>>>>> specifies by simulating this finite string according to its >>>>>>>>>>> specified semantics.
No 'yes' or 'no' again, but a lot of words again. But I have >>>>>>>>>> the impression that these words mean: 'Yes, I agree that no >>>>>>>>>> algorithm can determine for all possible inputs whether the >>>>>>>>>> input describes a program that halts when directly executed. >>>>>>>>>> Correct?
So you don't understand what I said?
No Halt decider can ever report on the direct execution
of any other TM because it has no access to this direct
execution. At most it only has a finite string machine
code proxy of what the direct execution might be.
Again no 'yes' or 'no', but I think it can be interpreted as a >>>>>>>> 'yes'.
Correct?
You are saying
There exists an input D to halt decider H such that
H gets the wrong answer.
words 'wrong answer'.
I said:
We agree that the answer on the question: *"Does an algorithm
exist that for all possible inputs returns whether it describes a
halting program in direct execution"* is 'No'?
Correct?
I AM NOT SAYING ANYTHING LIKE THAT
Again no clear 'yes' or 'no'.
This time it sounds more like a 'no'.
So, you think an algorithm exists that for all possible inputs returns
whether it describes a halting program in direct execution?
Correct?
When the halting problem is defined incorrectly
thenn for all H there exists a D
such that H gets the wrong answer.
On 3/21/2025 1:44 PM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 16:50 schreef olcott:
On 3/18/2025 10:36 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 14:48 schreef olcott:
On 3/18/2025 3:59 AM, Fred. Zwarts wrote:
Op 17.mrt.2025 om 20:45 schreef olcott:
On 3/17/2025 2:41 PM, olcott wrote:
It is impossible for one TM X to determine that another
TM Y has only an infinite loop on the basis of the direct
execution of Y. No TM can in any way monitor the direct
execution of another TM.
NO TM halt decider can possibly exist that
reports on the basis of the direct execution
of another TM.
Is that again a strange way to say 'Yes, I agree'?
It points out that the definition of the halting problem
that requires reporting on the direct execution IS WRONG.
On the other hand there is nothing wrong with having a halt
decider report on the behavior that its finite string input
specifies by simulating this finite string according to its
specified semantics.
No 'yes' or 'no' again, but a lot of words again. But I have the
impression that these words mean: 'Yes, I agree that no algorithm
can determine for all possible inputs whether the input describes a
program that halts when directly executed.
Correct?
...
No Halt decider can ever report on the direct execution
of any other TM because it has no access to this direct
execution. At most it only has a finite string machine
code proxy of what the direct execution might be.
That sounds like a 'yes, I agree that no algorithm can determine for
all possible inputs whether the input describes a program that halts
when directly executed.'
Correct?
No it is me saying that incorrect problems often have
no correct solution because they are incorrect.
On 3/21/2025 3:19 AM, Mikko wrote:
On 2025-03-21 03:45:29 +0000, olcott said:
On 3/20/2025 4:31 AM, Mikko wrote:
On 2025-03-20 00:23:32 +0000, olcott said:
On 3/19/2025 11:18 AM, Mikko wrote:
On 2025-03-19 15:31:59 +0000, olcott said:
On 3/19/2025 8:38 AM, Mikko wrote:
On 2025-03-18 15:50:22 +0000, olcott said:
On 3/18/2025 10:36 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 14:48 schreef olcott:
On 3/18/2025 3:59 AM, Fred. Zwarts wrote:
Op 17.mrt.2025 om 20:45 schreef olcott:
On 3/17/2025 2:41 PM, olcott wrote:
It is impossible for one TM X to determine that another >>>>>>>>>>>>>> TM Y has only an infinite loop on the basis of the direct >>>>>>>>>>>>>> execution of Y. No TM can in any way monitor the direct >>>>>>>>>>>>>> execution of another TM.
NO TM halt decider can possibly exist that
reports on the basis of the direct execution
of another TM.
Is that again a strange way to say 'Yes, I agree'?
It points out that the definition of the halting problem >>>>>>>>>>> that requires reporting on the direct execution IS WRONG. >>>>>>>>>>>
On the other hand there is nothing wrong with having a halt >>>>>>>>>>> decider report on the behavior that its finite string input >>>>>>>>>>> specifies by simulating this finite string according to its >>>>>>>>>>> specified semantics.
No 'yes' or 'no' again, but a lot of words again. But I have the >>>>>>>>>> impression that these words mean: 'Yes, I agree that no algorithm can
determine for all possible inputs whether the input describes a program
that halts when directly executed.
Correct?
So you don't understand what I said?
He understood. Whether he undestood correctely is less clear but >>>>>>>> apparently yes because you don't contradict his understanding. >>>>>>>>
No Halt decider can ever report on the direct execution
of any other TM because it has no access to this direct
execution. At most it only has a finite string machine
code proxy of what the direct execution might be.
He is not bothered to pay any attention to the entirely
different quantifiers. Maybe has has no idea what
quantification is.
There are no quantifiers in "yes" and no more in "no".
*His YES and NO is stupidly wrong*
He is saying for all halt deciders H there exists
an input an input D that each H gets incorrectly.
No, he said that there is no halt decider that decides every
computation correctly. The "decider" may give a wrong answer
or no answer at all. In the latter case it does not get
anything incorrectly.
I am saying for all inputs D there does not exist
a halt decider H that reports on the behavior
of the direct execution of input D
So you agree with Fred. Zwarts and everyone that undersands the topic.
Every H gets at least one D wrong
is very stupidly misconstrued
to mean every H get every D wrong
If you know that then you should stop misconstruing it that way. But
both statements are someting you could cooment "Yes, that's right"
or "No, I don't think so".
_DD()
[00002133] 55 push ebp ; housekeeping
[00002134] 8bec mov ebp,esp ; housekeeping
[00002136] 51 push ecx ; make space for local
[00002137] 6833210000 push 00002133 ; push DD
[0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
[00002141] 83c404 add esp,+04
[00002144] 8945fc mov [ebp-04],eax
[00002147] 837dfc00 cmp dword [ebp-04],+00
[0000214b] 7402 jz 0000214f
[0000214d] ebfe jmp 0000214d
[0000214f] 8b45fc mov eax,[ebp-04]
[00002152] 8be5 mov esp,ebp
[00002154] 5d pop ebp
[00002155] c3 ret
Size in bytes:(0035) [00002155]
Every H gets at least one D incorrectly only
when the halting problem is defined incoherently.
Op 18.mrt.2025 om 16:50 schreef olcott:
On 3/18/2025 10:36 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 14:48 schreef olcott:
On 3/18/2025 3:59 AM, Fred. Zwarts wrote:
Op 17.mrt.2025 om 20:45 schreef olcott:
On 3/17/2025 2:41 PM, olcott wrote:
It is impossible for one TM X to determine that another
TM Y has only an infinite loop on the basis of the direct
execution of Y. No TM can in any way monitor the direct
execution of another TM.
NO TM halt decider can possibly exist that
reports on the basis of the direct execution
of another TM.
Is that again a strange way to say 'Yes, I agree'?
It points out that the definition of the halting problem
that requires reporting on the direct execution IS WRONG.
On the other hand there is nothing wrong with having a halt
decider report on the behavior that its finite string input
specifies by simulating this finite string according to its
specified semantics.
No 'yes' or 'no' again, but a lot of words again. But I have the
impression that these words mean: 'Yes, I agree that no algorithm can
determine for all possible inputs whether the input describes a program
that halts when directly executed.
Correct?
...
No Halt decider can ever report on the direct execution
of any other TM because it has no access to this direct
execution. At most it only has a finite string machine
code proxy of what the direct execution might be.
That sounds like a 'yes, I agree that no algorithm can determine for
all possible inputs whether the input describes a program that halts
when directly executed.'
Correct?
On 3/20/2025 4:33 AM, Mikko wrote:
On 2025-03-19 16:57:05 +0000, olcott said:
On 3/19/2025 6:19 AM, Mikko wrote:
On 2025-03-18 13:48:10 +0000, olcott said:
On 3/18/2025 3:59 AM, Fred. Zwarts wrote:
Op 17.mrt.2025 om 20:45 schreef olcott:
On 3/17/2025 2:41 PM, olcott wrote:
It is impossible for one TM X to determine that another
TM Y has only an infinite loop on the basis of the direct
execution of Y. No TM can in any way monitor the direct
execution of another TM.
NO TM halt decider can possibly exist that
reports on the basis of the direct execution
of another TM.
Is that again a strange way to say 'Yes, I agree'?
It points out that the definition of the halting problem
that requires reporting on the direct execution IS WRONG.
The definition of the halting problem is not wrong. It defines,
which is the only thing a defintion needs to do. It defines
a problem and the problem is about halting so the defined
problem is given a reasonable name. In addition, it is useful
to know whether a Turing machine halts on a particular input,
at least about some Turing machines and inputs.
When it specifies that a halt decider H must report on the
behavior of the direct execution of another Turing Machine M
this requirement is incorrect because no Turing machine
ever has any access to the behavior of any directly executing
Turing machine.
Your "because" is false. What follows that "because" is not relevant
to the false claim that precedes it.
When decide means to examine an input and compute
a mapping from this input to an accept or reject
state then I am correct.
Historically a TM that merely halts accepts its input
by merely halting and totally ignoring this input.
Op 21.mrt.2025 om 20:10 schreef olcott:
On 3/21/2025 1:44 PM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 16:50 schreef olcott:
On 3/18/2025 10:36 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 14:48 schreef olcott:
On 3/18/2025 3:59 AM, Fred. Zwarts wrote:
Op 17.mrt.2025 om 20:45 schreef olcott:
On 3/17/2025 2:41 PM, olcott wrote:
It is impossible for one TM X to determine that another
TM Y has only an infinite loop on the basis of the direct
execution of Y. No TM can in any way monitor the direct
execution of another TM.
NO TM halt decider can possibly exist that
reports on the basis of the direct execution
of another TM.
Is that again a strange way to say 'Yes, I agree'?
It points out that the definition of the halting problem
that requires reporting on the direct execution IS WRONG.
On the other hand there is nothing wrong with having a halt
decider report on the behavior that its finite string input
specifies by simulating this finite string according to its
specified semantics.
No 'yes' or 'no' again, but a lot of words again. But I have the
impression that these words mean: 'Yes, I agree that no algorithm
can determine for all possible inputs whether the input describes a
program that halts when directly executed.
Correct?
...
No Halt decider can ever report on the direct execution
of any other TM because it has no access to this direct
execution. At most it only has a finite string machine
code proxy of what the direct execution might be.
That sounds like a 'yes, I agree that no algorithm can determine for
all possible inputs whether the input describes a program that halts
when directly executed.'
Correct?
No it is me saying that incorrect problems often have
no correct solution because they are incorrect.
Again no 'yes' or 'no' for my question, but a 'no' to a different question. But it seems Olcott agrees that there is no algorithm that can determine
for all possible inputs whether the input describes a program that halts
when directly executed.'
Because if such an algorithm would exist it would be the solution to
what he calls the 'incorrect problem'.
But Olcott refuses to come with a clear 'yes' or 'no' to the question:
'Does an algorithm exist that can determine for all possible inputs
whether the input describes a program that halts when directly executed.'
I am afraid that he keeps using many irrelevant words because he starts
to understand that he has placed himself in an impossible position.
If he would say 'no', then he agrees with the Halting theorem, but if he would say 'yes', then he has no ground to say that his HHH is correct
even if it differs from the direct execution.
So, he must avoid a clean 'yes' or 'no' and use a lot of words
pretending that he is still honestly contributing to the discussion.
Conclusion: The answer for 'Is there an algorithm that canIt shouldn't be all that difficult to write an Olcott emulator.
determine for all possible inputs whether the input describes
a program that halts when directly executed.' is undecidable
for Olcott.
On 3/22/2025 2:12 PM, Fred. Zwarts wrote:
Op 22.mrt.2025 om 09:41 schreef Fred. Zwarts:
Op 21.mrt.2025 om 20:10 schreef olcott:
On 3/21/2025 1:44 PM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 16:50 schreef olcott:
On 3/18/2025 10:36 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 14:48 schreef olcott:
On 3/18/2025 3:59 AM, Fred. Zwarts wrote:
Op 17.mrt.2025 om 20:45 schreef olcott:
On 3/17/2025 2:41 PM, olcott wrote:
It is impossible for one TM X to determine that another
TM Y has only an infinite loop on the basis of the direct >>>>>>>>>>> execution of Y. No TM can in any way monitor the direct
execution of another TM.
NO TM halt decider can possibly exist that
reports on the basis of the direct execution
of another TM.
Is that again a strange way to say 'Yes, I agree'?
It points out that the definition of the halting problem
that requires reporting on the direct execution IS WRONG.
On the other hand there is nothing wrong with having a halt
decider report on the behavior that its finite string input
specifies by simulating this finite string according to its
specified semantics.
No 'yes' or 'no' again, but a lot of words again. But I have the >>>>>>> impression that these words mean: 'Yes, I agree that no algorithm >>>>>>> can determine for all possible inputs whether the input describes >>>>>>> a program that halts when directly executed.
Correct?
...
No Halt decider can ever report on the direct execution
of any other TM because it has no access to this direct
execution. At most it only has a finite string machine
code proxy of what the direct execution might be.
That sounds like a 'yes, I agree that no algorithm can determine
for all possible inputs whether the input describes a program that
halts when directly executed.'
Correct?
No it is me saying that incorrect problems often have
no correct solution because they are incorrect.
Again no 'yes' or 'no' for my question, but a 'no' to a different
question.
But it seems Olcott agrees that there is no algorithm that can
determine for all possible inputs whether the input describes a
program that halts when directly executed.'
Because if such an algorithm would exist it would be the solution to
what he calls the 'incorrect problem'.
But Olcott refuses to come with a clear 'yes' or 'no' to the question:
'Does an algorithm exist that can determine for all possible inputs
whether the input describes a program that halts when directly
executed.'
I am afraid that he keeps using many irrelevant words because he
starts to understand that he has placed himself in an impossible
position.
If he would say 'no', then he agrees with the Halting theorem, but if
he would say 'yes', then he has no ground to say that his HHH is
correct even if it differs from the direct execution.
So, he must avoid a clean 'yes' or 'no' and use a lot of words
pretending that he is still honestly contributing to the discussion.
Conclusion: The answer for
'Is there an algorithm that can determine for all possible inputs
whether the input describes a program that halts when directly executed.'
is undecidable for Olcott.
"Describes" has always been way too vague.
Machine code that "specifies" behavior according
to the semantics of the machine language has
zero vagueness.
On 3/22/2025 2:12 PM, Fred. Zwarts wrote:
Op 22.mrt.2025 om 09:41 schreef Fred. Zwarts:
Op 21.mrt.2025 om 20:10 schreef olcott:
On 3/21/2025 1:44 PM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 16:50 schreef olcott:
On 3/18/2025 10:36 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 14:48 schreef olcott:
On 3/18/2025 3:59 AM, Fred. Zwarts wrote:
Op 17.mrt.2025 om 20:45 schreef olcott:
On 3/17/2025 2:41 PM, olcott wrote:
It is impossible for one TM X to determine that another
TM Y has only an infinite loop on the basis of the direct >>>>>>>>>>> execution of Y. No TM can in any way monitor the direct
execution of another TM.
NO TM halt decider can possibly exist that
reports on the basis of the direct execution
of another TM.
Is that again a strange way to say 'Yes, I agree'?
It points out that the definition of the halting problem
that requires reporting on the direct execution IS WRONG.
On the other hand there is nothing wrong with having a halt
decider report on the behavior that its finite string input
specifies by simulating this finite string according to its
specified semantics.
No 'yes' or 'no' again, but a lot of words again. But I have the >>>>>>> impression that these words mean: 'Yes, I agree that no algorithm >>>>>>> can determine for all possible inputs whether the input describes >>>>>>> a program that halts when directly executed.
Correct?
...
No Halt decider can ever report on the direct execution
of any other TM because it has no access to this direct
execution. At most it only has a finite string machine
code proxy of what the direct execution might be.
That sounds like a 'yes, I agree that no algorithm can determine
for all possible inputs whether the input describes a program that
halts when directly executed.'
Correct?
No it is me saying that incorrect problems often have
no correct solution because they are incorrect.
Again no 'yes' or 'no' for my question, but a 'no' to a different
question.
But it seems Olcott agrees that there is no algorithm that can
determine for all possible inputs whether the input describes a
program that halts when directly executed.'
Because if such an algorithm would exist it would be the solution to
what he calls the 'incorrect problem'.
But Olcott refuses to come with a clear 'yes' or 'no' to the question:
'Does an algorithm exist that can determine for all possible inputs
whether the input describes a program that halts when directly
executed.'
I am afraid that he keeps using many irrelevant words because he
starts to understand that he has placed himself in an impossible
position.
If he would say 'no', then he agrees with the Halting theorem, but if
he would say 'yes', then he has no ground to say that his HHH is
correct even if it differs from the direct execution.
So, he must avoid a clean 'yes' or 'no' and use a lot of words
pretending that he is still honestly contributing to the discussion.
Conclusion: The answer for
'Is there an algorithm that can determine for all possible inputs
whether the input describes a program that halts when directly executed.'
is undecidable for Olcott.
"Describes" has always been way too vague.
Machine code that "specifies" behavior according
to the semantics of the machine language has
zero vagueness.
On 22/03/2025 19:12, Fred. Zwarts wrote:
Conclusion: The answer for 'Is there an algorithm that canIt shouldn't be all that difficult to write an Olcott emulator.
determine for all possible inputs whether the input describes
a program that halts when directly executed.' is undecidable
for Olcott.
On 3/22/2025 2:12 PM, Fred. Zwarts wrote:
Op 22.mrt.2025 om 09:41 schreef Fred. Zwarts:
Op 21.mrt.2025 om 20:10 schreef olcott:
On 3/21/2025 1:44 PM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 16:50 schreef olcott:
On 3/18/2025 10:36 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 14:48 schreef olcott:
On 3/18/2025 3:59 AM, Fred. Zwarts wrote:
Op 17.mrt.2025 om 20:45 schreef olcott:
On 3/17/2025 2:41 PM, olcott wrote:
It is impossible for one TM X to determine that another
TM Y has only an infinite loop on the basis of the direct >>>>>>>>>>> execution of Y. No TM can in any way monitor the direct
execution of another TM.
NO TM halt decider can possibly exist that
reports on the basis of the direct execution
of another TM.
Is that again a strange way to say 'Yes, I agree'?
It points out that the definition of the halting problem
that requires reporting on the direct execution IS WRONG.
On the other hand there is nothing wrong with having a halt
decider report on the behavior that its finite string input
specifies by simulating this finite string according to its
specified semantics.
No 'yes' or 'no' again, but a lot of words again. But I have the >>>>>>> impression that these words mean: 'Yes, I agree that no algorithm can >>>>>>> determine for all possible inputs whether the input describes a program >>>>>>> that halts when directly executed.
Correct?
...
No Halt decider can ever report on the direct execution
of any other TM because it has no access to this direct
execution. At most it only has a finite string machine
code proxy of what the direct execution might be.
That sounds like a 'yes, I agree that no algorithm can determine for >>>>> all possible inputs whether the input describes a program that halts >>>>> when directly executed.'
Correct?
No it is me saying that incorrect problems often have
no correct solution because they are incorrect.
Again no 'yes' or 'no' for my question, but a 'no' to a different question. >>> But it seems Olcott agrees that there is no algorithm that can
determine for all possible inputs whether the input describes a program
that halts when directly executed.'
Because if such an algorithm would exist it would be the solution to
what he calls the 'incorrect problem'.
But Olcott refuses to come with a clear 'yes' or 'no' to the question:
'Does an algorithm exist that can determine for all possible inputs
whether the input describes a program that halts when directly
executed.'
I am afraid that he keeps using many irrelevant words because he starts
to understand that he has placed himself in an impossible position.
If he would say 'no', then he agrees with the Halting theorem, but if
he would say 'yes', then he has no ground to say that his HHH is
correct even if it differs from the direct execution.
So, he must avoid a clean 'yes' or 'no' and use a lot of words
pretending that he is still honestly contributing to the discussion.
Conclusion: The answer for
'Is there an algorithm that can determine for all possible inputs
whether the input describes a program that halts when directly
executed.'
is undecidable for Olcott.
"Describes" has always been way too vague.
Machine code that "specifies" behavior according
to the semantics of the machine language has
zero vagueness.
On 3/22/2025 11:03 AM, Mikko wrote:
On 2025-03-20 22:19:51 +0000, olcott said:
On 3/20/2025 4:33 AM, Mikko wrote:
On 2025-03-19 16:57:05 +0000, olcott said:
On 3/19/2025 6:19 AM, Mikko wrote:
On 2025-03-18 13:48:10 +0000, olcott said:
On 3/18/2025 3:59 AM, Fred. Zwarts wrote:
Op 17.mrt.2025 om 20:45 schreef olcott:
On 3/17/2025 2:41 PM, olcott wrote:
It is impossible for one TM X to determine that another
TM Y has only an infinite loop on the basis of the direct
execution of Y. No TM can in any way monitor the direct
execution of another TM.
NO TM halt decider can possibly exist that
reports on the basis of the direct execution
of another TM.
Is that again a strange way to say 'Yes, I agree'?
It points out that the definition of the halting problem
that requires reporting on the direct execution IS WRONG.
The definition of the halting problem is not wrong. It defines,
which is the only thing a defintion needs to do. It defines
a problem and the problem is about halting so the defined
problem is given a reasonable name. In addition, it is useful
to know whether a Turing machine halts on a particular input,
at least about some Turing machines and inputs.
When it specifies that a halt decider H must report on the
behavior of the direct execution of another Turing Machine M
this requirement is incorrect because no Turing machine
ever has any access to the behavior of any directly executing
Turing machine.
Your "because" is false. What follows that "because" is not relevant
to the false claim that precedes it.
When decide means to examine an input and compute
a mapping from this input to an accept or reject
state then I am correct.
When you claim something that is false you are wrong. Other
considerations are not relevant.
When X is defined as Y and nothing defines X as ~Y
then X <is> Y within this definition even if everyone
in the universe disagrees.
Historically a TM that merely halts accepts its input
by merely halting and totally ignoring this input.
Irrelevant to the fact that your "because" is false.
It is a truism that no Turing machine has direct access to the
complete details of behavior of any other directly executing Turing Machine.
A UTM has indirect access to the same behavior as the behavior
of a directly executing machine most of the time.
The counter-example is very difficult to understand at the
actual UTM level and requires a UTM that stops simulating
after a finite number of correctly simulated steps.
On 2025-03-22 20:12:37 +0000, Richard Heathfield said:
On 22/03/2025 19:12, Fred. Zwarts wrote:
Conclusion: The answer for 'Is there an algorithm that canIt shouldn't be all that difficult to write an Olcott emulator.
determine for all possible inputs whether the input describes
a program that halts when directly executed.' is undecidable
for Olcott.
But would be hard to compare to direct execution with as many input
as would be required for testing.
On 3/22/2025 9:53 PM, Richard Damon wrote:
On 3/22/25 4:23 PM, olcott wrote:
On 3/22/2025 2:12 PM, Fred. Zwarts wrote:
Op 22.mrt.2025 om 09:41 schreef Fred. Zwarts:
Op 21.mrt.2025 om 20:10 schreef olcott:
On 3/21/2025 1:44 PM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 16:50 schreef olcott:
On 3/18/2025 10:36 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 14:48 schreef olcott:
On 3/18/2025 3:59 AM, Fred. Zwarts wrote:
Op 17.mrt.2025 om 20:45 schreef olcott:
On 3/17/2025 2:41 PM, olcott wrote:
It is impossible for one TM X to determine that another >>>>>>>>>>>>> TM Y has only an infinite loop on the basis of the direct >>>>>>>>>>>>> execution of Y. No TM can in any way monitor the direct >>>>>>>>>>>>> execution of another TM.
NO TM halt decider can possibly exist that
reports on the basis of the direct execution
of another TM.
Is that again a strange way to say 'Yes, I agree'?
It points out that the definition of the halting problem
that requires reporting on the direct execution IS WRONG.
On the other hand there is nothing wrong with having a halt >>>>>>>>>> decider report on the behavior that its finite string input >>>>>>>>>> specifies by simulating this finite string according to its >>>>>>>>>> specified semantics.
No 'yes' or 'no' again, but a lot of words again. But I have >>>>>>>>> the impression that these words mean: 'Yes, I agree that no
algorithm can determine for all possible inputs whether the
input describes a program that halts when directly executed. >>>>>>>>> Correct?
...
No Halt decider can ever report on the direct execution
of any other TM because it has no access to this direct
execution. At most it only has a finite string machine
code proxy of what the direct execution might be.
That sounds like a 'yes, I agree that no algorithm can determine >>>>>>> for all possible inputs whether the input describes a program
that halts when directly executed.'
Correct?
No it is me saying that incorrect problems often have
no correct solution because they are incorrect.
Again no 'yes' or 'no' for my question, but a 'no' to a different
question.
But it seems Olcott agrees that there is no algorithm that can
determine for all possible inputs whether the input describes a
program that halts when directly executed.'
Because if such an algorithm would exist it would be the solution
to what he calls the 'incorrect problem'.
But Olcott refuses to come with a clear 'yes' or 'no' to the question: >>>>> 'Does an algorithm exist that can determine for all possible inputs
whether the input describes a program that halts when directly
executed.'
I am afraid that he keeps using many irrelevant words because he
starts to understand that he has placed himself in an impossible
position.
If he would say 'no', then he agrees with the Halting theorem, but
if he would say 'yes', then he has no ground to say that his HHH is
correct even if it differs from the direct execution.
So, he must avoid a clean 'yes' or 'no' and use a lot of words
pretending that he is still honestly contributing to the discussion. >>>>>
Conclusion: The answer for
'Is there an algorithm that can determine for all possible inputs
whether the input describes a program that halts when directly
executed.'
is undecidable for Olcott.
"Describes" has always been way too vague.
Machine code that "specifies" behavior according
to the semantics of the machine language has
zero vagueness.
And the Machine Code PROVES that your answer is incorrect, as the
machine code for the call to HHH can ONLY be interpreted as going into
HHH and then emulating there.
That proves that I am correct.
And "Correct Emulation" of machine code also requires never stopping.
You are neither stupid enough nor ignorant enough to believe that.
For HHH to determine that its input never halts, we need that exact
same machine code (even what we see of HHH) when FULLY emulated by a
correct emulator, to not halt.
You are neither stupid enough nor ignorant enough to believe that.
If you want to claim that the correct emulation will differ based on
who did the emulation, you need to show the first step actually
correctly emulated, where the difference occurs.
When DDD emulated by HHH calls HHH(DDD) that
call cannot possibly return because DDD remains
stuck in recursive emulation.
When the directly executed DDD calls HHH(DDD) that
call does return because HHH aborts the otherwise
infinite recursive emulation.
You can't do this, because it isn't true, but you are so stupid you
assume it must be as that is the only way to try to prove your lies.
I have done this several times, the above one maybe the best.
Sorry, you are just shown to be a stupid liar and that all your work
is just a fraud based on your lies by using wrong definitions.
You are neither stupid enough nor ignorant enough to believe that.
The real reason is that you care more about rebuttal than truth.
On 3/22/2025 9:53 PM, Richard Damon wrote:Call it what you want.
On 3/22/25 4:23 PM, olcott wrote:
On 3/22/2025 2:12 PM, Fred. Zwarts wrote:
Op 22.mrt.2025 om 09:41 schreef Fred. Zwarts:
Op 21.mrt.2025 om 20:10 schreef olcott:
On 3/21/2025 1:44 PM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 16:50 schreef olcott:
On 3/18/2025 10:36 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 14:48 schreef olcott:
Conclusion: The answer for 'Is there an algorithm that can determine"Describes" has always been way too vague. Machine code that
for all possible inputs whether the input describes a program that
halts when directly executed.' is undecidable for Olcott.
"specifies" behavior according to the semantics of the machine
language has zero vagueness.
Do you believe the machine code can stop the simulation?And the Machine Code PROVES that your answer is incorrect, as theThat proves that I am correct.
machine code for the call to HHH can ONLY be interpreted as going into
HHH and then emulating there.
And "Correct Emulation" of machine code also requires never stopping.You are neither stupid enough nor ignorant enough to believe that.
Ah ok, HHH is not a correct simulator. Knew it.For HHH to determine that its input never halts, we need that exactYou are neither stupid enough nor ignorant enough to believe that.
same machine code (even what we see of HHH) when FULLY emulated by a
correct emulator, to not halt.
Aha! HHH can't simulate itself.If you want to claim that the correct emulation will differ based onWhen DDD emulated by HHH calls HHH(DDD) that call cannot possibly return because DDD remains stuck in recursive emulation.
who did the emulation, you need to show the first step actually
correctly emulated, where the difference occurs.
On 3/23/2025 4:35 AM, Mikko wrote:
On 2025-03-22 20:23:06 +0000, olcott said:
On 3/22/2025 2:12 PM, Fred. Zwarts wrote:
Op 22.mrt.2025 om 09:41 schreef Fred. Zwarts:
Op 21.mrt.2025 om 20:10 schreef olcott:
On 3/21/2025 1:44 PM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 16:50 schreef olcott:
On 3/18/2025 10:36 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 14:48 schreef olcott:
On 3/18/2025 3:59 AM, Fred. Zwarts wrote:
Op 17.mrt.2025 om 20:45 schreef olcott:
On 3/17/2025 2:41 PM, olcott wrote:
It is impossible for one TM X to determine that another >>>>>>>>>>>>> TM Y has only an infinite loop on the basis of the direct >>>>>>>>>>>>> execution of Y. No TM can in any way monitor the direct >>>>>>>>>>>>> execution of another TM.
NO TM halt decider can possibly exist that
reports on the basis of the direct execution
of another TM.
Is that again a strange way to say 'Yes, I agree'?
It points out that the definition of the halting problem
that requires reporting on the direct execution IS WRONG.
On the other hand there is nothing wrong with having a halt >>>>>>>>>> decider report on the behavior that its finite string input >>>>>>>>>> specifies by simulating this finite string according to its >>>>>>>>>> specified semantics.
No 'yes' or 'no' again, but a lot of words again. But I have the >>>>>>>>> impression that these words mean: 'Yes, I agree that no algorithm can >>>>>>>>> determine for all possible inputs whether the input describes a program
that halts when directly executed.
Correct?
...
No Halt decider can ever report on the direct execution
of any other TM because it has no access to this direct
execution. At most it only has a finite string machine
code proxy of what the direct execution might be.
That sounds like a 'yes, I agree that no algorithm can determine for >>>>>>> all possible inputs whether the input describes a program that halts >>>>>>> when directly executed.'
Correct?
No it is me saying that incorrect problems often have
no correct solution because they are incorrect.
Again no 'yes' or 'no' for my question, but a 'no' to a different question.
But it seems Olcott agrees that there is no algorithm that can
determine for all possible inputs whether the input describes a program >>>>> that halts when directly executed.'
Because if such an algorithm would exist it would be the solution to >>>>> what he calls the 'incorrect problem'.
But Olcott refuses to come with a clear 'yes' or 'no' to the question: >>>>> 'Does an algorithm exist that can determine for all possible inputs
whether the input describes a program that halts when directly
executed.'
I am afraid that he keeps using many irrelevant words because he starts >>>>> to understand that he has placed himself in an impossible position.
If he would say 'no', then he agrees with the Halting theorem, but if >>>>> he would say 'yes', then he has no ground to say that his HHH is
correct even if it differs from the direct execution.
So, he must avoid a clean 'yes' or 'no' and use a lot of words
pretending that he is still honestly contributing to the discussion. >>>>>
Conclusion: The answer for
'Is there an algorithm that can determine for all possible inputs
whether the input describes a program that halts when directly
executed.'
is undecidable for Olcott.
"Describes" has always been way too vague.
There would be no universal Turing machine if the word were too vague.
What is good enough for a universal Turing machine is good enough for
a halting decider.
That term was intended to mean something like a virtual
machine language the precisely species every single detail
of the exact behavior according to the semantics of this
virtual machine language.
On 3/23/2025 4:46 PM, Richard Damon wrote:
On 3/23/25 4:47 PM, olcott wrote:
On 3/22/2025 9:53 PM, Richard Damon wrote:
On 3/22/25 4:23 PM, olcott wrote:
On 3/22/2025 2:12 PM, Fred. Zwarts wrote:
Op 22.mrt.2025 om 09:41 schreef Fred. Zwarts:
Op 21.mrt.2025 om 20:10 schreef olcott:
On 3/21/2025 1:44 PM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 16:50 schreef olcott:
On 3/18/2025 10:36 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 14:48 schreef olcott:
On 3/18/2025 3:59 AM, Fred. Zwarts wrote:
Op 17.mrt.2025 om 20:45 schreef olcott:
On 3/17/2025 2:41 PM, olcott wrote:
It is impossible for one TM X to determine that another >>>>>>>>>>>>>>> TM Y has only an infinite loop on the basis of the direct >>>>>>>>>>>>>>> execution of Y. No TM can in any way monitor the direct >>>>>>>>>>>>>>> execution of another TM.
NO TM halt decider can possibly exist that
reports on the basis of the direct execution
of another TM.
Is that again a strange way to say 'Yes, I agree'?
It points out that the definition of the halting problem >>>>>>>>>>>> that requires reporting on the direct execution IS WRONG. >>>>>>>>>>>>
On the other hand there is nothing wrong with having a halt >>>>>>>>>>>> decider report on the behavior that its finite string input >>>>>>>>>>>> specifies by simulating this finite string according to its >>>>>>>>>>>> specified semantics.
No 'yes' or 'no' again, but a lot of words again. But I have >>>>>>>>>>> the impression that these words mean: 'Yes, I agree that no >>>>>>>>>>> algorithm can determine for all possible inputs whether the >>>>>>>>>>> input describes a program that halts when directly executed. >>>>>>>>>>> Correct?
...
No Halt decider can ever report on the direct execution
of any other TM because it has no access to this direct
execution. At most it only has a finite string machine
code proxy of what the direct execution might be.
That sounds like a 'yes, I agree that no algorithm can
determine for all possible inputs whether the input describes a >>>>>>>>> program that halts when directly executed.'
Correct?
No it is me saying that incorrect problems often have
no correct solution because they are incorrect.
Again no 'yes' or 'no' for my question, but a 'no' to a different >>>>>>> question.
But it seems Olcott agrees that there is no algorithm that can
determine for all possible inputs whether the input describes a
program that halts when directly executed.'
Because if such an algorithm would exist it would be the solution >>>>>>> to what he calls the 'incorrect problem'.
But Olcott refuses to come with a clear 'yes' or 'no' to the
question:
'Does an algorithm exist that can determine for all possible
inputs whether the input describes a program that halts when
directly executed.'
I am afraid that he keeps using many irrelevant words because he >>>>>>> starts to understand that he has placed himself in an impossible >>>>>>> position.
If he would say 'no', then he agrees with the Halting theorem,
but if he would say 'yes', then he has no ground to say that his >>>>>>> HHH is correct even if it differs from the direct execution.
So, he must avoid a clean 'yes' or 'no' and use a lot of words
pretending that he is still honestly contributing to the discussion. >>>>>>>
Conclusion: The answer for
'Is there an algorithm that can determine for all possible inputs
whether the input describes a program that halts when directly
executed.'
is undecidable for Olcott.
"Describes" has always been way too vague.
Machine code that "specifies" behavior according
to the semantics of the machine language has
zero vagueness.
And the Machine Code PROVES that your answer is incorrect, as the
machine code for the call to HHH can ONLY be interpreted as going
into HHH and then emulating there.
That proves that I am correct.
Nope, it proves you have a broken definition, and are just committing
FRAUD.
And "Correct Emulation" of machine code also requires never stopping.
You are neither stupid enough nor ignorant enough to believe that.
No, you are too stupid to understand the definition of "correct" in
the context of emulation.
Sorry, but you are just sinking your reputation in that lake of fire.
For HHH to determine that its input never halts, we need that exact
same machine code (even what we see of HHH) when FULLY emulated by a
correct emulator, to not halt.
You are neither stupid enough nor ignorant enough to believe that.
No, you are too stupid to understand the truth of it.
Your "logic" is just based on you claiming the right to LIE, and thus
to commit FRAUD.
If you want to claim that the correct emulation will differ based on
who did the emulation, you need to show the first step actually
correctly emulated, where the difference occurs.
When DDD emulated by HHH calls HHH(DDD) that
call cannot possibly return because DDD remains
stuck in recursive emulation.
Which is irrelevent, since it is a fact that you HHH WILL abort, and
thus there is no infinitely recursive emulation. You just like lying
about what you are talking about by playing shell games.
It is impossible for HHH compute the function from the direct
execution of DDD because DDD is not the finite string input
basis from which all computations must begin. https://en.wikipedia.org/wiki/Computable_function
On 3/24/2025 6:23 AM, Richard Damon wrote:That's the problem of HHH, which should always return.
On 3/23/25 11:09 PM, olcott wrote:
On 3/23/2025 4:46 PM, Richard Damon wrote:
On 3/23/25 4:47 PM, olcott wrote:
On 3/22/2025 9:53 PM, Richard Damon wrote:
On 3/22/25 4:23 PM, olcott wrote:
On 3/22/2025 2:12 PM, Fred. Zwarts wrote:
Op 22.mrt.2025 om 09:41 schreef Fred. Zwarts:
Op 21.mrt.2025 om 20:10 schreef olcott:
On 3/21/2025 1:44 PM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 16:50 schreef olcott:
On 3/18/2025 10:36 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 14:48 schreef olcott:
On 3/18/2025 3:59 AM, Fred. Zwarts wrote:
Op 17.mrt.2025 om 20:45 schreef olcott:
On 3/17/2025 2:41 PM, olcott wrote:
Nope, it proves you have a broken definition, and are just committingThat proves that I am correct.And the Machine Code PROVES that your answer is incorrect, as the
machine code for the call to HHH can ONLY be interpreted as going
into HHH and then emulating there.
FRAUD.
No, you are too stupid to understand the definition of "correct" inAnd "Correct Emulation" of machine code also requires neverYou are neither stupid enough nor ignorant enough to believe that.
stopping.
the context of emulation.
No, you are too stupid to understand the truth of it.For HHH to determine that its input never halts, we need that exact >>>>>> same machine code (even what we see of HHH) when FULLY emulated by >>>>>> a correct emulator, to not halt.You are neither stupid enough nor ignorant enough to believe that.
Your "logic" is just based on you claiming the right to LIE, and thus
to commit FRAUD.
If you want to claim that the correct emulation will differ basedWhen DDD emulated by HHH calls HHH(DDD) that call cannot possibly
on who did the emulation, you need to show the first step actually >>>>>> correctly emulated, where the difference occurs.
return because DDD remains stuck in recursive emulation.
Yes, but how can *the code of DDD* not correspond to its execution?DDD is a semantically and syntactically correct finite stirng of the x86 machine language.WHy isn't DDD made into the correct finite string?Which is irrelevent, since it is a fact that you HHH WILL abort, andIt is impossible for HHH compute the function from the direct
thus there is no infinitely recursive emulation. You just like lying
about what you are talking about by playing shell games.
execution of DDD because DDD is not the finite string input basis from
which all computations must begin.
That doesn't change that DDD halts.That seems to be your own fault.DDD emulated by HHH directly causes recursive emulation because it calls HHH(DDD) to emulate itself again. HHH complies until HHH determines
The problem has always been that you want to use the wrong string for
DDD by excluding the code for HHH from it.
that this cycle cannot possibly reach the final halt state of DDD.
Er no, we want the halting decider to report on the direct executionNote, nobody said that Halting was a computable function, in fact, thatWhen the halting problem requires a halt decider to report on the direct execution of another machine the halting problem is defined incorrectly.
is the meta-question of the problem, *IS* there a machine that can
compute the Halting Mapping.
You said yourself that HHH can't reach DDD's return.You are just showing that you have a fundamental misconception of the
problem you claim to have solved after it was proven to be impossible
as it was unomputable.
Your instance just proves your stupidity and ignorance.
Sorry, but your instance on just using CliffsNotes versions to learn
has made you the failure you are, not understanding what you are trying
to do.
The fact that HHH can't compute the answer
Is a lie not a fact.
And not what that input would do when simulated.was a proven fact, but also its requirement. Halting Decider, by theirof their input
definition, need to try to determine the Halting Behavior of their
input,
Yeah, why lie that the behaviour of DDD were determined by someand that behavior is DEFINED by the behavior of the direct execution,Why lie?
The behavior is SPECIFIED BY THE FINITE STRING OF X86 MACHINE CODE AND
THE SEMANTICS OF THE X86 LANGUAGE.
DISAGREEING WITH THE SEMANTICS OF THE X86 LANGUAGE IS STUPID.
On 3/24/2025 6:23 AM, Richard Damon wrote:
On 3/23/25 11:09 PM, olcott wrote:
On 3/23/2025 4:46 PM, Richard Damon wrote:
On 3/23/25 4:47 PM, olcott wrote:
On 3/22/2025 9:53 PM, Richard Damon wrote:
On 3/22/25 4:23 PM, olcott wrote:
On 3/22/2025 2:12 PM, Fred. Zwarts wrote:
Op 22.mrt.2025 om 09:41 schreef Fred. Zwarts:
Op 21.mrt.2025 om 20:10 schreef olcott:
On 3/21/2025 1:44 PM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 16:50 schreef olcott:
On 3/18/2025 10:36 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 14:48 schreef olcott:
On 3/18/2025 3:59 AM, Fred. Zwarts wrote:
Op 17.mrt.2025 om 20:45 schreef olcott:It points out that the definition of the halting problem >>>>>>>>>>>>>> that requires reporting on the direct execution IS WRONG. >>>>>>>>>>>>>>
On 3/17/2025 2:41 PM, olcott wrote:
It is impossible for one TM X to determine that another >>>>>>>>>>>>>>>>> TM Y has only an infinite loop on the basis of the direct >>>>>>>>>>>>>>>>> execution of Y. No TM can in any way monitor the direct >>>>>>>>>>>>>>>>> execution of another TM.
NO TM halt decider can possibly exist that
reports on the basis of the direct execution
of another TM.
Is that again a strange way to say 'Yes, I agree'? >>>>>>>>>>>>>>
On the other hand there is nothing wrong with having a halt >>>>>>>>>>>>>> decider report on the behavior that its finite string input >>>>>>>>>>>>>> specifies by simulating this finite string according to its >>>>>>>>>>>>>> specified semantics.
No 'yes' or 'no' again, but a lot of words again. But I >>>>>>>>>>>>> have the impression that these words mean: 'Yes, I agree >>>>>>>>>>>>> that no algorithm can determine for all possible inputs >>>>>>>>>>>>> whether the input describes a program that halts when >>>>>>>>>>>>> directly executed.
Correct?
...
No Halt decider can ever report on the direct execution >>>>>>>>>>>> of any other TM because it has no access to this direct >>>>>>>>>>>> execution. At most it only has a finite string machine >>>>>>>>>>>> code proxy of what the direct execution might be.
That sounds like a 'yes, I agree that no algorithm can
determine for all possible inputs whether the input describes >>>>>>>>>>> a program that halts when directly executed.'
Correct?
No it is me saying that incorrect problems often have
no correct solution because they are incorrect.
Again no 'yes' or 'no' for my question, but a 'no' to a
different question.
But it seems Olcott agrees that there is no algorithm that can >>>>>>>>> determine for all possible inputs whether the input describes a >>>>>>>>> program that halts when directly executed.'
Because if such an algorithm would exist it would be the
solution to what he calls the 'incorrect problem'.
But Olcott refuses to come with a clear 'yes' or 'no' to the >>>>>>>>> question:
'Does an algorithm exist that can determine for all possible >>>>>>>>> inputs whether the input describes a program that halts when >>>>>>>>> directly executed.'
I am afraid that he keeps using many irrelevant words because >>>>>>>>> he starts to understand that he has placed himself in an
impossible position.
If he would say 'no', then he agrees with the Halting theorem, >>>>>>>>> but if he would say 'yes', then he has no ground to say that >>>>>>>>> his HHH is correct even if it differs from the direct execution. >>>>>>>>> So, he must avoid a clean 'yes' or 'no' and use a lot of words >>>>>>>>> pretending that he is still honestly contributing to the
discussion.
Conclusion: The answer for
'Is there an algorithm that can determine for all possible
inputs whether the input describes a program that halts when
directly executed.'
is undecidable for Olcott.
"Describes" has always been way too vague.
Machine code that "specifies" behavior according
to the semantics of the machine language has
zero vagueness.
And the Machine Code PROVES that your answer is incorrect, as the
machine code for the call to HHH can ONLY be interpreted as going
into HHH and then emulating there.
That proves that I am correct.
Nope, it proves you have a broken definition, and are just
committing FRAUD.
And "Correct Emulation" of machine code also requires never stopping. >>>>>>
You are neither stupid enough nor ignorant enough to believe that.
No, you are too stupid to understand the definition of "correct" in
the context of emulation.
Sorry, but you are just sinking your reputation in that lake of fire.
For HHH to determine that its input never halts, we need that
exact same machine code (even what we see of HHH) when FULLY
emulated by a correct emulator, to not halt.
You are neither stupid enough nor ignorant enough to believe that.
No, you are too stupid to understand the truth of it.
Your "logic" is just based on you claiming the right to LIE, and
thus to commit FRAUD.
If you want to claim that the correct emulation will differ based
on who did the emulation, you need to show the first step actually >>>>>> correctly emulated, where the difference occurs.
When DDD emulated by HHH calls HHH(DDD) that
call cannot possibly return because DDD remains
stuck in recursive emulation.
Which is irrelevent, since it is a fact that you HHH WILL abort, and
thus there is no infinitely recursive emulation. You just like lying
about what you are talking about by playing shell games.
It is impossible for HHH compute the function from the direct
execution of DDD because DDD is not the finite string input
basis from which all computations must begin.
https://en.wikipedia.org/wiki/Computable_function
WHy isn't DDD made into the correct finite string?i
DDD is a semantically and syntactically correct finite
stirng of the x86 machine language.
That seems to be your own fault.
The problem has always been that you want to use the wrong string for
DDD by excluding the code for HHH from it.
DDD emulated by HHH directly causes recursive emulation
because it calls HHH(DDD) to emulate itself again. HHH
complies until HHH determines that this cycle cannot
possibly reach the final halt state of DDD.
Note, nobody said that Halting was a computable function, in fact,
that is the meta-question of the problem, *IS* there a machine that
can compute the Halting Mapping.
When the halting problem requires a halt decider to
report on the direct execution of another machine the
halting problem is defined incorrectly.
You are just showing that you have a fundamental misconception of the
problem you claim to have solved after it was proven to be impossible
as it was unomputable.
Your instance just proves your stupidity and ignorance.
Sorry, but your instance on just using CliffsNotes versions to learn
has made you the failure you are, not understanding what you are
trying to do.
The fact that HHH can't compute the answer
Is a lie not a fact.
was a proven fact, but also its requirement. Halting Decider, by their
definition, need to try to determine the Halting Behavior of their input,
of their input
of their input
of their input
of their input
of their input
< and that behavior is
DEFINED by the behavior of the direct execution,
Why lie?
The behavior is SPECIFIED BY THE FINITE STRING OF X86 MACHINE CODE
AND THE SEMANTICS OF THE X86 LANGUAGE.
DISAGREEING WITH THE SEMANTICS OF THE X86 LANGUAGE IS STUPID.
for which the decider can get (perhaps only partially) by emulation.
There is nothing wrong is uncomputable problems, it is just a fact of
The computing the square root of a basket of eggs is another
undecidable problem.
logic that they exsit. If you don't like them, that is your problem.
The only way to avoid them is to stay in very simple logic systems
(which seems to be all you can understand anyway).
On 3/24/2025 6:23 AM, Richard Damon wrote:
On 3/23/25 11:09 PM, olcott wrote:
On 3/23/2025 4:46 PM, Richard Damon wrote:
On 3/23/25 4:47 PM, olcott wrote:
On 3/22/2025 9:53 PM, Richard Damon wrote:
On 3/22/25 4:23 PM, olcott wrote:
On 3/22/2025 2:12 PM, Fred. Zwarts wrote:
Op 22.mrt.2025 om 09:41 schreef Fred. Zwarts:
Op 21.mrt.2025 om 20:10 schreef olcott:
On 3/21/2025 1:44 PM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 16:50 schreef olcott:
On 3/18/2025 10:36 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 14:48 schreef olcott:
On 3/18/2025 3:59 AM, Fred. Zwarts wrote:
Op 17.mrt.2025 om 20:45 schreef olcott:It points out that the definition of the halting problem >>>>>>>>>>>>>> that requires reporting on the direct execution IS WRONG. >>>>>>>>>>>>>>
On 3/17/2025 2:41 PM, olcott wrote:
It is impossible for one TM X to determine that another >>>>>>>>>>>>>>>>> TM Y has only an infinite loop on the basis of the direct >>>>>>>>>>>>>>>>> execution of Y. No TM can in any way monitor the direct >>>>>>>>>>>>>>>>> execution of another TM.
NO TM halt decider can possibly exist that
reports on the basis of the direct execution
of another TM.
Is that again a strange way to say 'Yes, I agree'? >>>>>>>>>>>>>>
On the other hand there is nothing wrong with having a halt >>>>>>>>>>>>>> decider report on the behavior that its finite string input >>>>>>>>>>>>>> specifies by simulating this finite string according to its >>>>>>>>>>>>>> specified semantics.
No 'yes' or 'no' again, but a lot of words again. But I have the >>>>>>>>>>>>> impression that these words mean: 'Yes, I agree that no algorithm can
determine for all possible inputs whether the input describes a program
that halts when directly executed.
Correct?
...
No Halt decider can ever report on the direct execution >>>>>>>>>>>> of any other TM because it has no access to this direct >>>>>>>>>>>> execution. At most it only has a finite string machine >>>>>>>>>>>> code proxy of what the direct execution might be.
That sounds like a 'yes, I agree that no algorithm can determine for
all possible inputs whether the input describes a program that halts
when directly executed.'
Correct?
No it is me saying that incorrect problems often have
no correct solution because they are incorrect.
Again no 'yes' or 'no' for my question, but a 'no' to a different question.
But it seems Olcott agrees that there is no algorithm that can >>>>>>>>> determine for all possible inputs whether the input describes a program
that halts when directly executed.'
Because if such an algorithm would exist it would be the solution to >>>>>>>>> what he calls the 'incorrect problem'.
But Olcott refuses to come with a clear 'yes' or 'no' to the question:
'Does an algorithm exist that can determine for all possible inputs >>>>>>>>> whether the input describes a program that halts when directly >>>>>>>>> executed.'
I am afraid that he keeps using many irrelevant words because he starts
to understand that he has placed himself in an impossible position. >>>>>>>>> If he would say 'no', then he agrees with the Halting theorem, but if >>>>>>>>> he would say 'yes', then he has no ground to say that his HHH is >>>>>>>>> correct even if it differs from the direct execution.
So, he must avoid a clean 'yes' or 'no' and use a lot of words >>>>>>>>> pretending that he is still honestly contributing to the discussion. >>>>>>>>>
Conclusion: The answer for
'Is there an algorithm that can determine for all possible inputs >>>>>>>> whether the input describes a program that halts when directly >>>>>>>> executed.'
is undecidable for Olcott.
"Describes" has always been way too vague.
Machine code that "specifies" behavior according
to the semantics of the machine language has
zero vagueness.
And the Machine Code PROVES that your answer is incorrect, as the
machine code for the call to HHH can ONLY be interpreted as going into >>>>>> HHH and then emulating there.
That proves that I am correct.
Nope, it proves you have a broken definition, and are just committing FRAUD.
And "Correct Emulation" of machine code also requires never stopping. >>>>>>
You are neither stupid enough nor ignorant enough to believe that.
No, you are too stupid to understand the definition of "correct" in the >>>> context of emulation.
Sorry, but you are just sinking your reputation in that lake of fire.
For HHH to determine that its input never halts, we need that exact >>>>>> same machine code (even what we see of HHH) when FULLY emulated by a >>>>>> correct emulator, to not halt.
You are neither stupid enough nor ignorant enough to believe that.
No, you are too stupid to understand the truth of it.
Your "logic" is just based on you claiming the right to LIE, and thus
to commit FRAUD.
If you want to claim that the correct emulation will differ based on >>>>>> who did the emulation, you need to show the first step actually
correctly emulated, where the difference occurs.
When DDD emulated by HHH calls HHH(DDD) that
call cannot possibly return because DDD remains
stuck in recursive emulation.
Which is irrelevent, since it is a fact that you HHH WILL abort, and
thus there is no infinitely recursive emulation. You just like lying
about what you are talking about by playing shell games.
It is impossible for HHH compute the function from the direct
execution of DDD because DDD is not the finite string input
basis from which all computations must begin.
https://en.wikipedia.org/wiki/Computable_function
WHy isn't DDD made into the correct finite string?i
DDD is a semantically and syntactically correct finite
stirng of the x86 machine language.
On 3/24/2025 11:03 AM, olcott wrote:
On 3/24/2025 6:23 AM, Richard Damon wrote:
On 3/23/25 11:09 PM, olcott wrote:
On 3/23/2025 4:46 PM, Richard Damon wrote:
On 3/23/25 4:47 PM, olcott wrote:
On 3/22/2025 9:53 PM, Richard Damon wrote:
On 3/22/25 4:23 PM, olcott wrote:
On 3/22/2025 2:12 PM, Fred. Zwarts wrote:
Op 22.mrt.2025 om 09:41 schreef Fred. Zwarts:
Op 21.mrt.2025 om 20:10 schreef olcott:
On 3/21/2025 1:44 PM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 16:50 schreef olcott:
On 3/18/2025 10:36 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 14:48 schreef olcott:
On 3/18/2025 3:59 AM, Fred. Zwarts wrote:
Op 17.mrt.2025 om 20:45 schreef olcott:It points out that the definition of the halting problem >>>>>>>>>>>>>>> that requires reporting on the direct execution IS WRONG. >>>>>>>>>>>>>>>
On 3/17/2025 2:41 PM, olcott wrote:
It is impossible for one TM X to determine that another >>>>>>>>>>>>>>>>>> TM Y has only an infinite loop on the basis of the direct >>>>>>>>>>>>>>>>>> execution of Y. No TM can in any way monitor the direct >>>>>>>>>>>>>>>>>> execution of another TM.
NO TM halt decider can possibly exist that
reports on the basis of the direct execution >>>>>>>>>>>>>>>>> of another TM.
Is that again a strange way to say 'Yes, I agree'? >>>>>>>>>>>>>>>
On the other hand there is nothing wrong with having a halt >>>>>>>>>>>>>>> decider report on the behavior that its finite string input >>>>>>>>>>>>>>> specifies by simulating this finite string according to its >>>>>>>>>>>>>>> specified semantics.
No 'yes' or 'no' again, but a lot of words again. But I >>>>>>>>>>>>>> have the impression that these words mean: 'Yes, I agree >>>>>>>>>>>>>> that no algorithm can determine for all possible inputs >>>>>>>>>>>>>> whether the input describes a program that halts when >>>>>>>>>>>>>> directly executed.
Correct?
...
No Halt decider can ever report on the direct execution >>>>>>>>>>>>> of any other TM because it has no access to this direct >>>>>>>>>>>>> execution. At most it only has a finite string machine >>>>>>>>>>>>> code proxy of what the direct execution might be.
That sounds like a 'yes, I agree that no algorithm can >>>>>>>>>>>> determine for all possible inputs whether the input
describes a program that halts when directly executed.' >>>>>>>>>>>> Correct?
No it is me saying that incorrect problems often have
no correct solution because they are incorrect.
Again no 'yes' or 'no' for my question, but a 'no' to a
different question.
But it seems Olcott agrees that there is no algorithm that can >>>>>>>>>> determine for all possible inputs whether the input describes >>>>>>>>>> a program that halts when directly executed.'
Because if such an algorithm would exist it would be the
solution to what he calls the 'incorrect problem'.
But Olcott refuses to come with a clear 'yes' or 'no' to the >>>>>>>>>> question:
'Does an algorithm exist that can determine for all possible >>>>>>>>>> inputs whether the input describes a program that halts when >>>>>>>>>> directly executed.'
I am afraid that he keeps using many irrelevant words because >>>>>>>>>> he starts to understand that he has placed himself in an
impossible position.
If he would say 'no', then he agrees with the Halting theorem, >>>>>>>>>> but if he would say 'yes', then he has no ground to say that >>>>>>>>>> his HHH is correct even if it differs from the direct execution. >>>>>>>>>> So, he must avoid a clean 'yes' or 'no' and use a lot of words >>>>>>>>>> pretending that he is still honestly contributing to the
discussion.
Conclusion: The answer for
'Is there an algorithm that can determine for all possible
inputs whether the input describes a program that halts when >>>>>>>>> directly executed.'
is undecidable for Olcott.
"Describes" has always been way too vague.
Machine code that "specifies" behavior according
to the semantics of the machine language has
zero vagueness.
And the Machine Code PROVES that your answer is incorrect, as the >>>>>>> machine code for the call to HHH can ONLY be interpreted as going >>>>>>> into HHH and then emulating there.
That proves that I am correct.
Nope, it proves you have a broken definition, and are just
committing FRAUD.
And "Correct Emulation" of machine code also requires never
stopping.
You are neither stupid enough nor ignorant enough to believe that.
No, you are too stupid to understand the definition of "correct" in
the context of emulation.
Sorry, but you are just sinking your reputation in that lake of fire. >>>>>
For HHH to determine that its input never halts, we need that
exact same machine code (even what we see of HHH) when FULLY
emulated by a correct emulator, to not halt.
You are neither stupid enough nor ignorant enough to believe that.
No, you are too stupid to understand the truth of it.
Your "logic" is just based on you claiming the right to LIE, and
thus to commit FRAUD.
If you want to claim that the correct emulation will differ based >>>>>>> on who did the emulation, you need to show the first step
actually correctly emulated, where the difference occurs.
When DDD emulated by HHH calls HHH(DDD) that
call cannot possibly return because DDD remains
stuck in recursive emulation.
Which is irrelevent, since it is a fact that you HHH WILL abort,
and thus there is no infinitely recursive emulation. You just like
lying about what you are talking about by playing shell games.
It is impossible for HHH compute the function from the direct
execution of DDD because DDD is not the finite string input
basis from which all computations must begin.
https://en.wikipedia.org/wiki/Computable_function
WHy isn't DDD made into the correct finite string?i
DDD is a semantically and syntactically correct finite
stirng of the x86 machine language.
Which includes the machine code of DDD, the machine code of HHH, and the machine code of everything it calls down to the OS level.
That seems to be your own fault.
The problem has always been that you want to use the wrong string for
DDD by excluding the code for HHH from it.
DDD emulated by HHH directly causes recursive emulation
because it calls HHH(DDD) to emulate itself again. HHH
complies until HHH determines that this cycle cannot
possibly reach the final halt state of DDD.
Which is another way of saying that HHH can't determine that DDD halts
when executed directly.
Note, nobody said that Halting was a computable function, in fact,
that is the meta-question of the problem, *IS* there a machine that
can compute the Halting Mapping.
When the halting problem requires a halt decider to
report on the direct execution of another machine the
halting problem is defined incorrectly.
False. The question is well defined with a well defined answer in all cases.
I want to know if any arbitrary TM algorithm X with input Y will halt
when executed directly. If I had an H that could tell me that in *all* possible cases, I could solve the Goldbach conjecture, among many other unsolved problems.
Does an H exist that can tell me that or not?
This is now the 8th time I've asked this question, and Fred has asked a similar question many times as well. Why are you so afraid to answer it?
You are just showing that you have a fundamental misconception of the
problem you claim to have solved after it was proven to be impossible
as it was unomputable.
Your instance just proves your stupidity and ignorance.
Sorry, but your instance on just using CliffsNotes versions to learn
has made you the failure you are, not understanding what you are
trying to do.
The fact that HHH can't compute the answer
Is a lie not a fact.
Then why does HHH(DDD) report that DDD doesn't halt when executed
directly when it does?
was a proven fact, but also its requirement. Halting Decider, by
their definition, need to try to determine the Halting Behavior of
their input,
of their input
of their input
of their input
of their input
of their input
Which describes/specifies the algorithm DDD.
< and that behavior is
DEFINED by the behavior of the direct execution,
Why lie?
The behavior is SPECIFIED BY THE FINITE STRING OF X86 MACHINE CODE
AND THE SEMANTICS OF THE X86 LANGUAGE.
And the semantics of the x86 language specify that when the actual x86
code of DDD (and everything it calls) is actually run on an actual x86 process that it will halt.
DISAGREEING WITH THE SEMANTICS OF THE X86 LANGUAGE IS STUPID.
Then why do you disagree that the semantics of the x86 language specify
that DDD halts when executed directly?
for which the decider can get (perhaps only partially) by emulation.
There is nothing wrong is uncomputable problems, it is just a fact of
The computing the square root of a basket of eggs is another
undecidable problem.
Unlike the square root of a basket of eggs, the question of whether or
not an algorithm halts when executed directly has a well-defined correct answer in all cases, but no algorithm exists to compute it.
logic that they exsit. If you don't like them, that is your problem.
The only way to avoid them is to stay in very simple logic systems
(which seems to be all you can understand anyway).
On 3/25/2025 3:49 AM, Mikko wrote:
On 2025-03-24 15:03:05 +0000, olcott said:
On 3/24/2025 6:23 AM, Richard Damon wrote:
On 3/23/25 11:09 PM, olcott wrote:
On 3/23/2025 4:46 PM, Richard Damon wrote:
On 3/23/25 4:47 PM, olcott wrote:
On 3/22/2025 9:53 PM, Richard Damon wrote:
On 3/22/25 4:23 PM, olcott wrote:
On 3/22/2025 2:12 PM, Fred. Zwarts wrote:
Op 22.mrt.2025 om 09:41 schreef Fred. Zwarts:
Op 21.mrt.2025 om 20:10 schreef olcott:
On 3/21/2025 1:44 PM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 16:50 schreef olcott:
On 3/18/2025 10:36 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 14:48 schreef olcott:
On 3/18/2025 3:59 AM, Fred. Zwarts wrote:
Op 17.mrt.2025 om 20:45 schreef olcott:It points out that the definition of the halting problem >>>>>>>>>>>>>>>> that requires reporting on the direct execution IS WRONG. >>>>>>>>>>>>>>>>
On 3/17/2025 2:41 PM, olcott wrote:
It is impossible for one TM X to determine that another >>>>>>>>>>>>>>>>>>> TM Y has only an infinite loop on the basis of the >>>>>>>>>>>>>>>>>>> direct
execution of Y. No TM can in any way monitor the direct >>>>>>>>>>>>>>>>>>> execution of another TM.
NO TM halt decider can possibly exist that >>>>>>>>>>>>>>>>>> reports on the basis of the direct execution >>>>>>>>>>>>>>>>>> of another TM.
Is that again a strange way to say 'Yes, I agree'? >>>>>>>>>>>>>>>>
On the other hand there is nothing wrong with having a halt >>>>>>>>>>>>>>>> decider report on the behavior that its finite string input >>>>>>>>>>>>>>>> specifies by simulating this finite string according to its >>>>>>>>>>>>>>>> specified semantics.
No 'yes' or 'no' again, but a lot of words again. But I >>>>>>>>>>>>>>> have the impression that these words mean: 'Yes, I agree >>>>>>>>>>>>>>> that no algorithm can determine for all possible inputs >>>>>>>>>>>>>>> whether the input describes a program that halts when >>>>>>>>>>>>>>> directly executed.
Correct?
...
No Halt decider can ever report on the direct execution >>>>>>>>>>>>>> of any other TM because it has no access to this direct >>>>>>>>>>>>>> execution. At most it only has a finite string machine >>>>>>>>>>>>>> code proxy of what the direct execution might be.
That sounds like a 'yes, I agree that no algorithm can >>>>>>>>>>>>> determine for all possible inputs whether the input
describes a program that halts when directly executed.' >>>>>>>>>>>>> Correct?
No it is me saying that incorrect problems often have
no correct solution because they are incorrect.
Again no 'yes' or 'no' for my question, but a 'no' to a
different question.
But it seems Olcott agrees that there is no algorithm that >>>>>>>>>>> can determine for all possible inputs whether the input
describes a program that halts when directly executed.'
Because if such an algorithm would exist it would be the >>>>>>>>>>> solution to what he calls the 'incorrect problem'.
But Olcott refuses to come with a clear 'yes' or 'no' to the >>>>>>>>>>> question:
'Does an algorithm exist that can determine for all possible >>>>>>>>>>> inputs whether the input describes a program that halts when >>>>>>>>>>> directly executed.'
I am afraid that he keeps using many irrelevant words because >>>>>>>>>>> he starts to understand that he has placed himself in an >>>>>>>>>>> impossible position.
If he would say 'no', then he agrees with the Halting
theorem, but if he would say 'yes', then he has no ground to >>>>>>>>>>> say that his HHH is correct even if it differs from the
direct execution.
So, he must avoid a clean 'yes' or 'no' and use a lot of >>>>>>>>>>> words pretending that he is still honestly contributing to >>>>>>>>>>> the discussion.
Conclusion: The answer for
'Is there an algorithm that can determine for all possible >>>>>>>>>> inputs whether the input describes a program that halts when >>>>>>>>>> directly executed.'
is undecidable for Olcott.
"Describes" has always been way too vague.
Machine code that "specifies" behavior according
to the semantics of the machine language has
zero vagueness.
And the Machine Code PROVES that your answer is incorrect, as
the machine code for the call to HHH can ONLY be interpreted as >>>>>>>> going into HHH and then emulating there.
That proves that I am correct.
Nope, it proves you have a broken definition, and are just
committing FRAUD.
No, you are too stupid to understand the definition of "correct"
And "Correct Emulation" of machine code also requires never
stopping.
You are neither stupid enough nor ignorant enough to believe that. >>>>>>
in the context of emulation.
Sorry, but you are just sinking your reputation in that lake of fire. >>>>>>
No, you are too stupid to understand the truth of it.
For HHH to determine that its input never halts, we need that
exact same machine code (even what we see of HHH) when FULLY
emulated by a correct emulator, to not halt.
You are neither stupid enough nor ignorant enough to believe that. >>>>>>
Your "logic" is just based on you claiming the right to LIE, and
thus to commit FRAUD.
If you want to claim that the correct emulation will differ
based on who did the emulation, you need to show the first step >>>>>>>> actually correctly emulated, where the difference occurs.
When DDD emulated by HHH calls HHH(DDD) that
call cannot possibly return because DDD remains
stuck in recursive emulation.
Which is irrelevent, since it is a fact that you HHH WILL abort,
and thus there is no infinitely recursive emulation. You just like >>>>>> lying about what you are talking about by playing shell games.
It is impossible for HHH compute the function from the direct
execution of DDD because DDD is not the finite string input
basis from which all computations must begin.
https://en.wikipedia.org/wiki/Computable_function
WHy isn't DDD made into the correct finite string?i
DDD is a semantically and syntactically correct finite
stirng of the x86 machine language.
It is not semantically correct if it does not specify a behaviour.
It does not specify a behavriour if it contains references to
memoro locations outside of itself.
You are stupidly trying to get away
with claiming that C functions cannot call other C functions?
Halt7.obj is the input to x86utm.
On 3/25/2025 3:49 AM, Mikko wrote:
On 2025-03-24 15:03:05 +0000, olcott said:
On 3/24/2025 6:23 AM, Richard Damon wrote:
On 3/23/25 11:09 PM, olcott wrote:
On 3/23/2025 4:46 PM, Richard Damon wrote:
On 3/23/25 4:47 PM, olcott wrote:
On 3/22/2025 9:53 PM, Richard Damon wrote:
On 3/22/25 4:23 PM, olcott wrote:
On 3/22/2025 2:12 PM, Fred. Zwarts wrote:
Op 22.mrt.2025 om 09:41 schreef Fred. Zwarts:
Op 21.mrt.2025 om 20:10 schreef olcott:
On 3/21/2025 1:44 PM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 16:50 schreef olcott:
On 3/18/2025 10:36 AM, Fred. Zwarts wrote:
Op 18.mrt.2025 om 14:48 schreef olcott:
On 3/18/2025 3:59 AM, Fred. Zwarts wrote:
Op 17.mrt.2025 om 20:45 schreef olcott:It points out that the definition of the halting problem >>>>>>>>>>>>>>>> that requires reporting on the direct execution IS WRONG. >>>>>>>>>>>>>>>>
On 3/17/2025 2:41 PM, olcott wrote:
It is impossible for one TM X to determine that another >>>>>>>>>>>>>>>>>>> TM Y has only an infinite loop on the basis of the direct >>>>>>>>>>>>>>>>>>> execution of Y. No TM can in any way monitor the direct >>>>>>>>>>>>>>>>>>> execution of another TM.
NO TM halt decider can possibly exist that >>>>>>>>>>>>>>>>>> reports on the basis of the direct execution >>>>>>>>>>>>>>>>>> of another TM.
Is that again a strange way to say 'Yes, I agree'? >>>>>>>>>>>>>>>>
On the other hand there is nothing wrong with having a halt >>>>>>>>>>>>>>>> decider report on the behavior that its finite string input >>>>>>>>>>>>>>>> specifies by simulating this finite string according to its >>>>>>>>>>>>>>>> specified semantics.
No 'yes' or 'no' again, but a lot of words again. But I have the
impression that these words mean: 'Yes, I agree that no algorithm can
determine for all possible inputs whether the input describes a program
that halts when directly executed.
Correct?
...
No Halt decider can ever report on the direct execution >>>>>>>>>>>>>> of any other TM because it has no access to this direct >>>>>>>>>>>>>> execution. At most it only has a finite string machine >>>>>>>>>>>>>> code proxy of what the direct execution might be.
That sounds like a 'yes, I agree that no algorithm can determine for
all possible inputs whether the input describes a program that halts
when directly executed.'
Correct?
No it is me saying that incorrect problems often have
no correct solution because they are incorrect.
Again no 'yes' or 'no' for my question, but a 'no' to a different question.
But it seems Olcott agrees that there is no algorithm that can >>>>>>>>>>> determine for all possible inputs whether the input describes a program
that halts when directly executed.'
Because if such an algorithm would exist it would be the solution to
what he calls the 'incorrect problem'.
But Olcott refuses to come with a clear 'yes' or 'no' to the question:
'Does an algorithm exist that can determine for all possible inputs >>>>>>>>>>> whether the input describes a program that halts when directly >>>>>>>>>>> executed.'
I am afraid that he keeps using many irrelevant words because he starts
to understand that he has placed himself in an impossible position. >>>>>>>>>>> If he would say 'no', then he agrees with the Halting theorem, but if
he would say 'yes', then he has no ground to say that his HHH is >>>>>>>>>>> correct even if it differs from the direct execution.
So, he must avoid a clean 'yes' or 'no' and use a lot of words >>>>>>>>>>> pretending that he is still honestly contributing to the discussion.
Conclusion: The answer for
'Is there an algorithm that can determine for all possible inputs >>>>>>>>>> whether the input describes a program that halts when directly >>>>>>>>>> executed.'
is undecidable for Olcott.
"Describes" has always been way too vague.
Machine code that "specifies" behavior according
to the semantics of the machine language has
zero vagueness.
And the Machine Code PROVES that your answer is incorrect, as the >>>>>>>> machine code for the call to HHH can ONLY be interpreted as going into >>>>>>>> HHH and then emulating there.
That proves that I am correct.
Nope, it proves you have a broken definition, and are just committing FRAUD.
No, you are too stupid to understand the definition of "correct" in the >>>>>> context of emulation.
And "Correct Emulation" of machine code also requires never stopping. >>>>>>>>
You are neither stupid enough nor ignorant enough to believe that. >>>>>>
Sorry, but you are just sinking your reputation in that lake of fire. >>>>>>
No, you are too stupid to understand the truth of it.
For HHH to determine that its input never halts, we need that exact >>>>>>>> same machine code (even what we see of HHH) when FULLY emulated by a >>>>>>>> correct emulator, to not halt.
You are neither stupid enough nor ignorant enough to believe that. >>>>>>
Your "logic" is just based on you claiming the right to LIE, and thus >>>>>> to commit FRAUD.
If you want to claim that the correct emulation will differ based on >>>>>>>> who did the emulation, you need to show the first step actually >>>>>>>> correctly emulated, where the difference occurs.
When DDD emulated by HHH calls HHH(DDD) that
call cannot possibly return because DDD remains
stuck in recursive emulation.
Which is irrelevent, since it is a fact that you HHH WILL abort, and >>>>>> thus there is no infinitely recursive emulation. You just like lying >>>>>> about what you are talking about by playing shell games.
It is impossible for HHH compute the function from the direct
execution of DDD because DDD is not the finite string input
basis from which all computations must begin.
https://en.wikipedia.org/wiki/Computable_function
WHy isn't DDD made into the correct finite string?i
DDD is a semantically and syntactically correct finite
stirng of the x86 machine language.
It is not semantically correct if it does not specify a behaviour.
It does not specify a behavriour if it contains references to
memoro locations outside of itself.
You are stupidly trying to get away
with claiming that C functions cannot call other C functions?
Halt7.obj is the input to x86utm.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (1 / 15) |
| Uptime: | 160:19:14 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,056 |
| Messages: | 6,416,492 |