On 7/1/2025 11:37 AM, Mr Flibble wrote:
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote:
On 6/30/25 2:30 PM, Mr Flibble wrote:
PO just works off the lie that a correct simulation of the input is
different than the direct execution, even though he can't show the
instruction actually correctly simulated where they differ, and thus
proves he is lying.
The closest he comes is claiming that the simulation of the "Call HHH"
must be different when simulated then when executed, as for "some
reason" it must be just because otherwise HHH can't do the simulation.
Sorry, not being able to do something doesn't mean you get to redefine
it,
You ar4e just showing you are as stupid as he is.
No. A simulator does not have to run a simulation to completion if it can
determine that the input, A PROGRAM, never halts.
/Flibble
The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and
DDD does not call HHH1(DDD) in recursive simulation.
*I can't imagine how Mike does not get this*
*Context of above dialogue*
*Context of above dialogue*
*Context of above dialogue*
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
}
Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0. (HHH1 has identical code)
On 7/1/2025 11:37 AM, Mr Flibble wrote:
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote:
On 6/30/25 2:30 PM, Mr Flibble wrote:
PO just works off the lie that a correct simulation of the input is
different than the direct execution, even though he can't show the
instruction actually correctly simulated where they differ, and thus
proves he is lying.
The closest he comes is claiming that the simulation of the "Call HHH"
must be different when simulated then when executed, as for "some
reason" it must be just because otherwise HHH can't do the simulation.
Sorry, not being able to do something doesn't mean you get to redefine
it,
You ar4e just showing you are as stupid as he is.
No. A simulator does not have to run a simulation to completion if it can
determine that the input, A PROGRAM, never halts.
/Flibble
The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and
DDD does not call HHH1(DDD) in recursive simulation.
*I can't imagine how Mike does not get this*
*Context of above dialogue*
*Context of above dialogue*
*Context of above dialogue*
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
}
Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0. (HHH1 has identical code)
On 7/3/2025 3:57 AM, Mikko wrote:
On 2025-07-03 02:50:40 +0000, olcott said:
On 7/1/2025 11:37 AM, Mr Flibble wrote:
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote:
On 6/30/25 2:30 PM, Mr Flibble wrote:
PO just works off the lie that a correct simulation of the input is
different than the direct execution, even though he can't show the
instruction actually correctly simulated where they differ, and thus >>>>> proves he is lying.
The closest he comes is claiming that the simulation of the "Call HHH" >>>>> must be different when simulated then when executed, as for "some
reason" it must be just because otherwise HHH can't do the simulation. >>>>>
Sorry, not being able to do something doesn't mean you get to redefine >>>>> it,
You ar4e just showing you are as stupid as he is.
No. A simulator does not have to run a simulation to completion if
it can
determine that the input, A PROGRAM, never halts.
/Flibble
The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and
DDD does not call HHH1(DDD) in recursive simulation.
Either "no" (encoded as 0) or "yes" (encoded as any other number) is the
wrong asnwer to the quesstion "does DDD specify a halting computation?".
That is *not* the actual question.
HHH(DDD) is asked: Does your input specify a computation that halts?
DDD correctly simulated by HHH cannot possibly reach its own "return" statement final halt state, so NO.
HHH1(DDD) is asked: Does your input specify a computation that halts?
DDD correctly simulated by HHH1 reaches its own "return" statement final
halt state, so YES.
HHH says "no" and HHH1 says "yes" so one of them gives the wrong answer.
*I can't imagine how Mike does not get this*
*Context of above dialogue*
*Context of above dialogue*
*Context of above dialogue*
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
}
Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0. (HHH1 has identical code)
That the HHH and HHH1 give different reusults for the same input
means that their codes are not functionally equvalent and this
meas that they are not identical.
The subject line does not make sense as the message does not mean what
"correct" means in this context. What is correct and what is not depends
on what requirements are specified, and that message specifies none.
For example, to drive a car on the right side of a road is incorrect in
some situations and correct in others, depending on laws applicable to
the road and and on the facts the laws specify as relevant.
On 7/3/2025 9:16 AM, Richard Damon wrote:
On 7/2/25 10:50 PM, olcott wrote:
On 7/1/2025 11:37 AM, Mr Flibble wrote:
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote:
On 6/30/25 2:30 PM, Mr Flibble wrote:
PO just works off the lie that a correct simulation of the input is
different than the direct execution, even though he can't show the
instruction actually correctly simulated where they differ, and thus >>>>> proves he is lying.
The closest he comes is claiming that the simulation of the "Call HHH" >>>>> must be different when simulated then when executed, as for "some
reason" it must be just because otherwise HHH can't do the simulation. >>>>>
Sorry, not being able to do something doesn't mean you get to redefine >>>>> it,
You ar4e just showing you are as stupid as he is.
No. A simulator does not have to run a simulation to completion if
it can
determine that the input, A PROGRAM, never halts.
/Flibble
The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and
DDD does not call HHH1(DDD) in recursive simulation.
Nope. It seems you don't understand what the question actually IS
because you have just lied to yourself so much that you lost the
understanding of the queiston.
*I can't imagine how Mike does not get this*
I can't understand
*Context of above dialogue*
*Context of above dialogue*
*Context of above dialogue*
Context of your context:
A Halt Decider is supposed to decide if the program given to it (via
some correct representation) will halt when run.
Thus, "the input" needs to represent a program
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
}
Which, by itself, isn't a valid input, or program. as HHH is undefined.
Each different definition of HHH, gives a different problem.
Your "logic" seems to be based on trying to re-define what a program
is, which just makes it a lie.
"Programs" must be complete and self-contained in the field of
computability theory, something you don't seem to understand.
Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0. (HHH1 has identical code)
But it CAN'T simulate the above input. as it isn't valid.
You need to add the code of HHH to the input to let HHH simulate "the
input" to get anything.
No I do not. The above paragraph has every detail that is needed.
And at that point, you have different inputs for different HHHs, and
possibly different behaviors, which you logic forgets to take into
account, which just breaks it.
Wrong.
It is because the what I specified does take this
into account that HHH(DDD)==0 and HHH1(DDD)==1 are correct.
Sorry, but you sre just showing your own stupidity, and ignorance of
what you are talking about.
You never point out any actual mistake.
You only point out what you fail to understand.
*Every chatbot totally understands this correctly*
Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0.
That you do not understand is your own limitation.
On 7/3/2025 9:50 AM, Richard Damon wrote:
On 7/3/25 10:39 AM, olcott wrote:
On 7/3/2025 9:16 AM, Richard Damon wrote:
On 7/2/25 10:50 PM, olcott wrote:
On 7/1/2025 11:37 AM, Mr Flibble wrote:
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote:
On 6/30/25 2:30 PM, Mr Flibble wrote:
PO just works off the lie that a correct simulation of the input is >>>>>>> different than the direct execution, even though he can't show the >>>>>>> instruction actually correctly simulated where they differ, and thus >>>>>>> proves he is lying.
The closest he comes is claiming that the simulation of the "Call >>>>>>> HHH"
must be different when simulated then when executed, as for "some >>>>>>> reason" it must be just because otherwise HHH can't do the
simulation.
Sorry, not being able to do something doesn't mean you get to
redefine
it,
You ar4e just showing you are as stupid as he is.
No. A simulator does not have to run a simulation to completion if >>>>>> it can
determine that the input, A PROGRAM, never halts.
/Flibble
The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and
DDD does not call HHH1(DDD) in recursive simulation.
Nope. It seems you don't understand what the question actually IS
because you have just lied to yourself so much that you lost the
understanding of the queiston.
*I can't imagine how Mike does not get this*
I can't understand
*Context of above dialogue*
*Context of above dialogue*
*Context of above dialogue*
Context of your context:
A Halt Decider is supposed to decide if the program given to it (via
some correct representation) will halt when run.
Thus, "the input" needs to represent a program
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
}
Which, by itself, isn't a valid input, or program. as HHH is undefined. >>>>
Each different definition of HHH, gives a different problem.
Your "logic" seems to be based on trying to re-define what a program
is, which just makes it a lie.
"Programs" must be complete and self-contained in the field of
computability theory, something you don't seem to understand.
Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0. (HHH1 has identical code)
But it CAN'T simulate the above input. as it isn't valid.
You need to add the code of HHH to the input to let HHH simulate
"the input" to get anything.
No I do not. The above paragraph has every detail that is needed.
Then how do you correctly simulate something you do not have.
Note, your "description" of HHH is just incorrect, as it is also
incomplete.
Simulating a LIE just gives you a lie.
And at that point, you have different inputs for different HHHs, and
possibly different behaviors, which you logic forgets to take into
account, which just breaks it.
Wrong.
It is because the what I specified does take this
into account that HHH(DDD)==0 and HHH1(DDD)==1 are correct.
Nope, becausee it violates the DEFINITION of what it means to simulate
something.
*You don't even know what you mean by this*
What I mean is the execution trace that is derived
within the semantics of the C programming language.
HHH1 simulates DDD that calls HHH(DDD) that
simulates DDD and then simulates itself simulating DDD.
Then HHH(DDD) aborts its simulation and returns to the
DDD simulated by HHH1. Then this DDD returns to HHH1.
*Claude (smarter than ChatGPT) figured this out on its own* https://claude.ai/share/da9b8e3f-eb16-42ca-a9e8-913f4b88202c
On 7/3/2025 5:59 PM, Richard Damon wrote:
On 7/3/25 11:17 AM, olcott wrote:
On 7/3/2025 9:50 AM, Richard Damon wrote:
On 7/3/25 10:39 AM, olcott wrote:
On 7/3/2025 9:16 AM, Richard Damon wrote:
On 7/2/25 10:50 PM, olcott wrote:
On 7/1/2025 11:37 AM, Mr Flibble wrote:
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote:
On 6/30/25 2:30 PM, Mr Flibble wrote:
PO just works off the lie that a correct simulation of the
input is
different than the direct execution, even though he can't show the >>>>>>>>> instruction actually correctly simulated where they differ, and >>>>>>>>> thus
proves he is lying.
The closest he comes is claiming that the simulation of the
"Call HHH"
must be different when simulated then when executed, as for "some >>>>>>>>> reason" it must be just because otherwise HHH can't do the
simulation.
Sorry, not being able to do something doesn't mean you get to >>>>>>>>> redefine
it,
You ar4e just showing you are as stupid as he is.
No. A simulator does not have to run a simulation to completion >>>>>>>> if it can
determine that the input, A PROGRAM, never halts.
/Flibble
The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and
DDD does not call HHH1(DDD) in recursive simulation.
Nope. It seems you don't understand what the question actually IS
because you have just lied to yourself so much that you lost the
understanding of the queiston.
*I can't imagine how Mike does not get this*
I can't understand
*Context of above dialogue*
*Context of above dialogue*
*Context of above dialogue*
Context of your context:
A Halt Decider is supposed to decide if the program given to it
(via some correct representation) will halt when run.
Thus, "the input" needs to represent a program
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
}
Which, by itself, isn't a valid input, or program. as HHH is
undefined.
Each different definition of HHH, gives a different problem.
Your "logic" seems to be based on trying to re-define what a
program is, which just makes it a lie.
"Programs" must be complete and self-contained in the field of
computability theory, something you don't seem to understand.
Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0. (HHH1 has identical code)
But it CAN'T simulate the above input. as it isn't valid.
You need to add the code of HHH to the input to let HHH simulate
"the input" to get anything.
No I do not. The above paragraph has every detail that is needed.
Then how do you correctly simulate something you do not have.
Note, your "description" of HHH is just incorrect, as it is also
incomplete.
Simulating a LIE just gives you a lie.
And at that point, you have different inputs for different HHHs,
and possibly different behaviors, which you logic forgets to take
into account, which just breaks it.
Wrong.
It is because the what I specified does take this
into account that HHH(DDD)==0 and HHH1(DDD)==1 are correct.
Nope, becausee it violates the DEFINITION of what it means to
simulate something.
*You don't even know what you mean by this*
What I mean is the execution trace that is derived
within the semantics of the C programming language.
Right, which means that the input needs to include the code of HHH.
And when you do so, there is only one possible HHH for that input, as
it has been specified in the input, and any other HHH trying to be
defined breaks the one-definition rule.
HHH1 simulates DDD that calls HHH(DDD) that
simulates DDD and then simulates itself simulating DDD.
Then HHH(DDD) aborts its simulation and returns to the
DDD simulated by HHH1. Then this DDD returns to HHH1.
Right, it aborts it, but the CORRECT simulation of that input would be
to see that
DDD calls HHH that simulates DDD that calls HHH and then the first HHH
aborts its simulation and returns to DDD which then halts.
Thus, the input is HALTING, as shown by the CORRECT simulation.
*Claude (smarter than ChatGPT) figured this out on its own*
https://claude.ai/share/da9b8e3f-eb16-42ca-a9e8-913f4b88202c
Since your input includes your LIE:
Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern.
Since the pattern you claim to be a "non-terminating" pattern can not
actually be one, as it exists in the correct simulation that halt, say
your arguement is just UNSOUND.
As you are just proving that you yourself are (that is unsound), as
you believe your own lies.
*I am NOT the liar here*
On 7/3/2025 3:57 AM, Mikko wrote:
On 2025-07-03 02:50:40 +0000, olcott said:
On 7/1/2025 11:37 AM, Mr Flibble wrote:
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote:
On 6/30/25 2:30 PM, Mr Flibble wrote:
PO just works off the lie that a correct simulation of the input is
different than the direct execution, even though he can't show the
instruction actually correctly simulated where they differ, and thus >>>>> proves he is lying.
The closest he comes is claiming that the simulation of the "Call HHH" >>>>> must be different when simulated then when executed, as for "some
reason" it must be just because otherwise HHH can't do the simulation. >>>>>
Sorry, not being able to do something doesn't mean you get to redefine >>>>> it,
You ar4e just showing you are as stupid as he is.
No. A simulator does not have to run a simulation to completion if it can >>>> determine that the input, A PROGRAM, never halts.
/Flibble
The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and
DDD does not call HHH1(DDD) in recursive simulation.
Either "no" (encoded as 0) or "yes" (encoded as any other number) is the
wrong asnwer to the quesstion "does DDD specify a halting computation?".
That is *not* the actual question.
HHH(DDD) is asked: Does your input specify a computation that halts?
DDD correctly simulated by HHH cannot possibly reach its own "return" statement final halt state, so NO.
HHH1(DDD) is asked: Does your input specify a computation that halts?
DDD correctly simulated by HHH1 reaches its own "return" statement
final halt state, so YES.
On 7/3/2025 9:50 AM, Richard Damon wrote:
On 7/3/25 10:39 AM, olcott wrote:
On 7/3/2025 9:16 AM, Richard Damon wrote:
On 7/2/25 10:50 PM, olcott wrote:
On 7/1/2025 11:37 AM, Mr Flibble wrote:
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote:
On 6/30/25 2:30 PM, Mr Flibble wrote:
PO just works off the lie that a correct simulation of the input is >>>>>>> different than the direct execution, even though he can't show the >>>>>>> instruction actually correctly simulated where they differ, and thus >>>>>>> proves he is lying.
The closest he comes is claiming that the simulation of the "Call HHH" >>>>>>> must be different when simulated then when executed, as for "some >>>>>>> reason" it must be just because otherwise HHH can't do the simulation. >>>>>>>
Sorry, not being able to do something doesn't mean you get to redefine >>>>>>> it,
You ar4e just showing you are as stupid as he is.
No. A simulator does not have to run a simulation to completion if it can
determine that the input, A PROGRAM, never halts.
/Flibble
The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and
DDD does not call HHH1(DDD) in recursive simulation.
Nope. It seems you don't understand what the question actually IS
because you have just lied to yourself so much that you lost the
understanding of the queiston.
*I can't imagine how Mike does not get this*
I can't understand
*Context of above dialogue*
*Context of above dialogue*
*Context of above dialogue*
Context of your context:
A Halt Decider is supposed to decide if the program given to it (via
some correct representation) will halt when run.
Thus, "the input" needs to represent a program
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
}
Which, by itself, isn't a valid input, or program. as HHH is undefined. >>>>
Each different definition of HHH, gives a different problem.
Your "logic" seems to be based on trying to re-define what a program
is, which just makes it a lie.
"Programs" must be complete and self-contained in the field of
computability theory, something you don't seem to understand.
Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0. (HHH1 has identical code)
But it CAN'T simulate the above input. as it isn't valid.
You need to add the code of HHH to the input to let HHH simulate "the
input" to get anything.
No I do not. The above paragraph has every detail that is needed.
Then how do you correctly simulate something you do not have.
Note, your "description" of HHH is just incorrect, as it is also incomplete. >>
Simulating a LIE just gives you a lie.
And at that point, you have different inputs for different HHHs, and
possibly different behaviors, which you logic forgets to take into
account, which just breaks it.
Wrong.
It is because the what I specified does take this
into account that HHH(DDD)==0 and HHH1(DDD)==1 are correct.
Nope, becausee it violates the DEFINITION of what it means to simulate
something.
*You don't even know what you mean by this*
What I mean is the execution trace that is derived
within the semantics of the C programming language.
On 7/4/2025 2:35 AM, Mikko wrote:If. But here it confuses that with not being able to simulate past the recursive call.
On 2025-07-03 12:56:42 +0000, olcott said:
On 7/3/2025 3:57 AM, Mikko wrote:
On 2025-07-03 02:50:40 +0000, olcott said:
On 7/1/2025 11:37 AM, Mr Flibble wrote:
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote:
On 6/30/25 2:30 PM, Mr Flibble wrote:
No. A simulator does not have to run a simulation to completion if >>>>>> it can determine that the input, A PROGRAM, never halts.
DDD halts.What is the area of a square circle with a radius of 2?That is *not* the actual question.THe actual question is whatever someone asks.
*when executed directly, which is what should be simulated. HHH can't.HHH(DDD) is asked: Does your input specify a computation that halts*?
DDD correctly simulated by HHH cannot possibly reach its own "return"
statement final halt state, so NO.
Uh, the traces both show a call to HHH.THat is the same question if the input specifies the computation as
DDD. If it does not then HHH(DDD) is irrelevant and either the user's
manual of HHH species another input for the purpose or HHH is not
relevant to the halting problem.
The full execution trace of the input to HHH1(DDD) is different than TheHHH1(DDD) is asked: Does your input specify a computation that halts?The user's manual of HHH1 apparently dpecifies different encoding
DDD correctly simulated by HHH1 reaches its own "return" statement
final halt state, so YES.
rules.
full execution trace of the input to HHH(DDD)
because DDD calls HHH in recursive simulation and does not call HHH1 in recursive simulation.
On 7/4/2025 2:35 AM, Mikko wrote:
On 2025-07-03 12:56:42 +0000, olcott said:
On 7/3/2025 3:57 AM, Mikko wrote:
On 2025-07-03 02:50:40 +0000, olcott said:
On 7/1/2025 11:37 AM, Mr Flibble wrote:
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote:
On 6/30/25 2:30 PM, Mr Flibble wrote:
PO just works off the lie that a correct simulation of the input is >>>>>>> different than the direct execution, even though he can't show the >>>>>>> instruction actually correctly simulated where they differ, and thus >>>>>>> proves he is lying.
The closest he comes is claiming that the simulation of the "Call >>>>>>> HHH"
must be different when simulated then when executed, as for "some >>>>>>> reason" it must be just because otherwise HHH can't do the
simulation.
Sorry, not being able to do something doesn't mean you get to
redefine
it,
You ar4e just showing you are as stupid as he is.
No. A simulator does not have to run a simulation to completion if >>>>>> it can
determine that the input, A PROGRAM, never halts.
/Flibble
The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and
DDD does not call HHH1(DDD) in recursive simulation.
Either "no" (encoded as 0) or "yes" (encoded as any other number) is
the
wrong asnwer to the quesstion "does DDD specify a halting
computation?".
That is *not* the actual question.
THe actual question is whatever someone asks.
What is the area of a square circle with a radius of 2?
However, if the question is
not "does DDD specify a halting computation?" or the same about some
other computation then it is not in the scope of the halting problem
or the termination problem.
The halting problem has always been flatly incorrect
by making that the question. So I am reframing the
question the same way that ZFC reframed Russell's Paradox.
HHH computes the mapping from its actual inputs to the
behavior specifies by these inputs by correctly simulating
them.
HHH(DDD) is asked: Does your input specify a computation that halts?
DDD correctly simulated by HHH cannot possibly reach its own "return"
statement final halt state, so NO.
int sum(int x, int y) { return x + y; }
sum(3,4) derives 7 only from its actual inputs.
When we make a rule that sum(3,4) must derive
the sum of 5 + 6, then this requirement is wrong.
int main()
{
DD(); // calls HHH(DD)
}
Likewise for HHH(DD) to report on the behavior of its caller.
THat is the same question if the input specifies the computation as
DDD. If it does not then HHH(DDD) is irrelevant and either the user's
manual of HHH species another input for the purpose or HHH is not
relevant to the halting problem.
HHH1(DDD) is asked: Does your input specify a computation that halts?
DDD correctly simulated by HHH1 reaches its own "return" statement
final halt state, so YES.
The user's manual of HHH1 apparently dpecifies different encoding rules.
The full execution trace of the input to HHH1(DDD) is
different than The full execution trace of the input to HHH(DDD)
because DDD calls HHH in recursive simulation and does not
call HHH1 in recursive simulation.
Claude.ai figured this out on its own
proving that it is smarter than ChatGPT https://claude.ai/share/da9b8e3f-eb16-42ca-a9e8-913f4b88202c
On 7/3/2025 7:22 PM, Richard Damon wrote:
On 7/3/25 7:15 PM, olcott wrote:
On 7/3/2025 5:59 PM, Richard Damon wrote:
On 7/3/25 11:17 AM, olcott wrote:
On 7/3/2025 9:50 AM, Richard Damon wrote:
On 7/3/25 10:39 AM, olcott wrote:
On 7/3/2025 9:16 AM, Richard Damon wrote:Then how do you correctly simulate something you do not have.
On 7/2/25 10:50 PM, olcott wrote:
On 7/1/2025 11:37 AM, Mr Flibble wrote:
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote:
On 6/30/25 2:30 PM, Mr Flibble wrote:
PO just works off the lie that a correct simulation of the >>>>>>>>>>> input is
different than the direct execution, even though he can't >>>>>>>>>>> show the
instruction actually correctly simulated where they differ, >>>>>>>>>>> and thus
proves he is lying.
The closest he comes is claiming that the simulation of the >>>>>>>>>>> "Call HHH"
must be different when simulated then when executed, as for >>>>>>>>>>> "some
reason" it must be just because otherwise HHH can't do the >>>>>>>>>>> simulation.
Sorry, not being able to do something doesn't mean you get to >>>>>>>>>>> redefine
it,
You ar4e just showing you are as stupid as he is.
No. A simulator does not have to run a simulation to
completion if it can
determine that the input, A PROGRAM, never halts.
/Flibble
The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and
DDD does not call HHH1(DDD) in recursive simulation.
Nope. It seems you don't understand what the question actually >>>>>>>> IS because you have just lied to yourself so much that you lost >>>>>>>> the understanding of the queiston.
*I can't imagine how Mike does not get this*
I can't understand
*Context of above dialogue*
*Context of above dialogue*
*Context of above dialogue*
Context of your context:
A Halt Decider is supposed to decide if the program given to it >>>>>>>> (via some correct representation) will halt when run.
Thus, "the input" needs to represent a program
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
}
Which, by itself, isn't a valid input, or program. as HHH is
undefined.
Each different definition of HHH, gives a different problem.
Your "logic" seems to be based on trying to re-define what a
program is, which just makes it a lie.
"Programs" must be complete and self-contained in the field of >>>>>>>> computability theory, something you don't seem to understand.
Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0. (HHH1 has identical code)
But it CAN'T simulate the above input. as it isn't valid.
You need to add the code of HHH to the input to let HHH simulate >>>>>>>> "the input" to get anything.
No I do not. The above paragraph has every detail that is needed. >>>>>>
Note, your "description" of HHH is just incorrect, as it is also
incomplete.
Simulating a LIE just gives you a lie.
And at that point, you have different inputs for different HHHs, >>>>>>>> and possibly different behaviors, which you logic forgets to
take into account, which just breaks it.
Wrong.
It is because the what I specified does take this
into account that HHH(DDD)==0 and HHH1(DDD)==1 are correct.
Nope, becausee it violates the DEFINITION of what it means to
simulate something.
*You don't even know what you mean by this*
What I mean is the execution trace that is derived
within the semantics of the C programming language.
Right, which means that the input needs to include the code of HHH.
And when you do so, there is only one possible HHH for that input,
as it has been specified in the input, and any other HHH trying to
be defined breaks the one-definition rule.
HHH1 simulates DDD that calls HHH(DDD) that
simulates DDD and then simulates itself simulating DDD.
Then HHH(DDD) aborts its simulation and returns to the
DDD simulated by HHH1. Then this DDD returns to HHH1.
Right, it aborts it, but the CORRECT simulation of that input would
be to see that
DDD calls HHH that simulates DDD that calls HHH and then the first
HHH aborts its simulation and returns to DDD which then halts.
Thus, the input is HALTING, as shown by the CORRECT simulation.
*Claude (smarter than ChatGPT) figured this out on its own*
https://claude.ai/share/da9b8e3f-eb16-42ca-a9e8-913f4b88202c
Since your input includes your LIE:
Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern.
Since the pattern you claim to be a "non-terminating" pattern can
not actually be one, as it exists in the correct simulation that
halt, say your arguement is just UNSOUND.
As you are just proving that you yourself are (that is unsound), as
you believe your own lies.
*I am NOT the liar here*
Sure you are. WHy isn't it a lie, since it is wrong.
You cannot possibly show one single
actual mistake in the execution trace.
This is just like Trump denying that there
are any cuts to Medicaid in his bill.
On 7/4/2025 8:22 AM, joes wrote:
Am Fri, 04 Jul 2025 07:50:23 -0500 schrieb olcott:
On 7/4/2025 2:35 AM, Mikko wrote:
On 2025-07-03 12:56:42 +0000, olcott said:
On 7/3/2025 3:57 AM, Mikko wrote:
On 2025-07-03 02:50:40 +0000, olcott said:
On 7/1/2025 11:37 AM, Mr Flibble wrote:
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote:
On 6/30/25 2:30 PM, Mr Flibble wrote:
No. A simulator does not have to run a simulation to completion if >>>>>>>> it can determine that the input, A PROGRAM, never halts.
If. But here it confuses that with not being able to simulate past the
recursive call.
It is the correct simulation of the input that
specifies the actual behavior of this input.
If this simulation cannot simulate past the recursive
call then this correctly simulated input cannot possibly
reach its own correctly simulated final halt state.
int main()
{
DDD(); // Calls HHH(DDD) which is not accountable
} // for the behavior of its caller
DDD halts.What is the area of a square circle with a radius of 2?That is *not* the actual question.THe actual question is whatever someone asks.
HHH(DDD) is asked: Does your input specify a computation that halts*? >>>>> DDD correctly simulated by HHH cannot possibly reach its own "return" >>>>> statement final halt state, so NO.
*when executed directly, which is what should be simulated. HHH can't.
HHH1(DDD) has the same behavior as the directly executed DDD()
THat is the same question if the input specifies the computation as
DDD. If it does not then HHH(DDD) is irrelevant and either the user's
manual of HHH species another input for the purpose or HHH is not
relevant to the halting problem.
The full execution trace of the input to HHH1(DDD) is different than The >>> full execution trace of the input to HHH(DDD)HHH1(DDD) is asked: Does your input specify a computation that halts? >>>>> DDD correctly simulated by HHH1 reaches its own "return" statementThe user's manual of HHH1 apparently dpecifies different encoding
final halt state, so YES.
rules.
because DDD calls HHH in recursive simulation and does not call HHH1 in
recursive simulation.
Uh, the traces both show a call to HHH.
*This one page analysis by Clause.ai sum its up nicely* https://claude.ai/share/da9b8e3f-eb16-42ca-a9e8-913f4b88202c
On 7/4/2025 8:23 AM, Richard Damon wrote:
On 7/4/25 8:50 AM, olcott wrote:
On 7/4/2025 2:35 AM, Mikko wrote:
On 2025-07-03 12:56:42 +0000, olcott said:
On 7/3/2025 3:57 AM, Mikko wrote:
On 2025-07-03 02:50:40 +0000, olcott said:
On 7/1/2025 11:37 AM, Mr Flibble wrote:
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote:
On 6/30/25 2:30 PM, Mr Flibble wrote:
PO just works off the lie that a correct simulation of the
input is
different than the direct execution, even though he can't show the >>>>>>>>> instruction actually correctly simulated where they differ, and >>>>>>>>> thus
proves he is lying.
The closest he comes is claiming that the simulation of the
"Call HHH"
must be different when simulated then when executed, as for "some >>>>>>>>> reason" it must be just because otherwise HHH can't do the
simulation.
Sorry, not being able to do something doesn't mean you get to >>>>>>>>> redefine
it,
You ar4e just showing you are as stupid as he is.
No. A simulator does not have to run a simulation to completion >>>>>>>> if it can
determine that the input, A PROGRAM, never halts.
/Flibble
The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and
DDD does not call HHH1(DDD) in recursive simulation.
Either "no" (encoded as 0) or "yes" (encoded as any other number)
is the
wrong asnwer to the quesstion "does DDD specify a halting
computation?".
That is *not* the actual question.
THe actual question is whatever someone asks.
What is the area of a square circle with a radius of 2?
However, if the question is
not "does DDD specify a halting computation?" or the same about some
other computation then it is not in the scope of the halting problem
or the termination problem.
The halting problem has always been flatly incorrect
by making that the question. So I am reframing the
question the same way that ZFC reframed Russell's Paradox.
Nope, just shows you are too stupid to understand it.
Then tell me where I go wrong on this explanation:
ZFC conquered Russell's Paradox by redefining how
sets are defined such that a set that is a member
of itself can no longer be defined.
"ZFC avoids this paradox by using axioms that restrict set formation."
HHH computes the mapping from its actual inputs to the
behavior specifies by these inputs by correctly simulating
them.
No it doesn't, as you "input" which you say doesn't include the code
of HHH, can't be simulated.
I have always told you that
HHH simulates DDD that calls HHH(DDD)
then HHH simulates itself simulating DDD
*You must have no idea what those words mean*
HHH(DDD) is asked: Does your input specify a computation that halts? >>>>> DDD correctly simulated by HHH cannot possibly reach its own "return" >>>>> statement final halt state, so NO.
int sum(int x, int y) { return x + y; }
sum(3,4) derives 7 only from its actual inputs.
Right, and for HHH(DDD) the input is the PROGRAM DDD,
No this has never been the case as I have told you hundreds
and hundreds of times. The input to HHH has always been a
pointer to the machine code of DDD in a single block of memory
that includes all of Halt7.obj.
What you are referring to as a program never has been
an actual program that begins in main(). What you have
been referring to as a program is the machine code of
DDD and the machine code of everything that DDD calls.
That has always been there in the single block of memory
of Hlat7.obj.
which must include the code for HHH, and for any HHH that returns an
answer, the correct answer will be Halting (1).
The actual execution trace of DDD correctly simulated
by HHH is different than the actual execution trace of
DDD correctly simulated by HHH1.
*I am shocked that Mike cannot see this*
To me this seems like a guy with a computer
science degree that never heard of recursion.
When we make a rule that sum(3,4) must derive
the sum of 5 + 6, then this requirement is wrong.
Right, so we don't, just as it is wrong to derive the answer about the
correct simulation of DDD by looking at anything but THAT SPECIFIC DDD
and its correct simulation, which also means we need to pass as "the
input" all of the code that DDD uses, which included HHH.
and everything that HHH calls as I have been telling
you many many times and you keep forgetting from one
post to the next.
What the F did you think that I mean by HHH simulates
DDD and then simulates itself simulating DDD if itself
is inaccessible to HHH?
*Maybe you never had any idea what any of those words mean*
Since DDD() will halt, the correct simulation of it will reach the
final state (but your HHH can't do that) and thus the only correct
answer that HHH can return is Halting (1)
A partial halt decider must compute the mapping
*FROM ITS ACTUAL INPUT* (not one damn thing else)
*FROM ITS ACTUAL INPUT* (not one damn thing else)
*FROM ITS ACTUAL INPUT* (not one damn thing else)
to the actual behavior that this input specifies
not any damn thing else.
int main()
{
DD(); // calls HHH(DD)
}
Likewise for HHH(DD) to report on the behavior of its caller.
But it isn't being asked about "its caller", its being asked about
DDD, which just happens to be its its caller.
When functions are computed by Turing Machines directly
executed Turing machines are not in the domain.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
When DDD is correctly emulated by HHH the ultimate
measure of the correctness of this emulation is the
semantics of the x86 language.
I don't understand why I ever had to say that more
than once if my reviewers are engaging in an honest
dialogue so I concluded that my reviewers are dishonest.
The problem is you don't understand what a "program" actually is.
Termination analyzers are applied to C functions that
are not programs that always begin their execution in main().
THat is the same question if the input specifies the computation as
DDD. If it does not then HHH(DDD) is irrelevant and either the user's
manual of HHH species another input for the purpose or HHH is not
relevant to the halting problem.
HHH1(DDD) is asked: Does your input specify a computation that halts? >>>>> DDD correctly simulated by HHH1 reaches its own "return" statement
final halt state, so YES.
The user's manual of HHH1 apparently dpecifies different encoding
rules.
The full execution trace of the input to HHH1(DDD) is
different than The full execution trace of the input to HHH(DDD)
because DDD calls HHH in recursive simulation and does not
call HHH1 in recursive simulation.
But no actual instruction actually correctly simulated differs until
HHH aborts its simulation.
*That has always been counter-factual*
When we compare DDD emulated by HHH and DDD emulated
by HHH1 SIDE-BY-SIDE. (Mike didn't do it this way).
The difference is when
HHH begins to simulate itself simulating DDD and
HHH1 NEVER begins to simulate itself simulating DDD.
HHH doesn't actually abort its simulation of DDD until
after has simulated many hundreds of simulated instructions
later. HHH simulates itself simulating DDD until DDD calls
HHH(DDD) again.
WHen you look at the actual x86 simulation of all the code executed,
this is what you see, as you yourself have proven with the very long
traces.
We only need to understand that when HHH simulates DDD
and this DDD calls HHH(DDD) that the outer HHH is
simulating itself simulated DDD.
By doing this we capture the essence of 5266 pages of
execution trace in about one half of one page of text.
When you abreviate them, to make your arguemnt, you LIE about what HHH
does and "simplify" it behavior by ignoring the fact that it WILL
abort is simulation, since that is what you have actually defined your
HHH to do, and thus your "recursive" simulation is bounded, not infinite.
But of course, you are just too stupid to understand that.
Claude.ai figured this out on its own
proving that it is smarter than ChatGPT
https://claude.ai/share/da9b8e3f-eb16-42ca-a9e8-913f4b88202c
Because you LIE to it.
When you can't even point out any actual mistake
then your claim that I am intentionally telling
lies is quite nutty.
Sorry, it seems that you have lost contact with the idea that only
actually true things are true, and not things that we want to be true.
You are worse then the climate deniers you claim to be fighting, at
least they can point to actual raw evidence, and it becomes arguments
over interpretation, you just claim stuff without any proof,
https://www.researchgate.net/ publication/336568434_Severe_anthropogenic_climate_change_proven_entirely_with_verifiable_facts
My paper proves that even billion dollar disinformation teams
cannot possibly explain away the 98 PPM spike in atmospheric
CO2 in the last 70 years. The next fastest 98 PPM spike in the
last 800,000 years took 7537 years, 126-fold slower.
That puts you more in the class of a flat-earther.
On 7/4/2025 12:48 PM, Richard Damon wrote:
On 7/4/25 9:32 AM, olcott wrote:
On 7/4/2025 8:22 AM, joes wrote:
Am Fri, 04 Jul 2025 07:50:23 -0500 schrieb olcott:
On 7/4/2025 2:35 AM, Mikko wrote:
On 2025-07-03 12:56:42 +0000, olcott said:
On 7/3/2025 3:57 AM, Mikko wrote:
On 2025-07-03 02:50:40 +0000, olcott said:
On 7/1/2025 11:37 AM, Mr Flibble wrote:
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote:
On 6/30/25 2:30 PM, Mr Flibble wrote:
No. A simulator does not have to run a simulation to
completion if
it can determine that the input, A PROGRAM, never halts.
If. But here it confuses that with not being able to simulate past the >>>> recursive call.
It is the correct simulation of the input that
specifies the actual behavior of this input.
Right, and that means correctly simulating EVERY instruction that
makes up the PROGRAM, which must include the code of *THE* HHH, or you
can't "correctly simulate" the call instruction.
SIn
If this simulation cannot simulate past the recursive
call then this correctly simulated input cannot possibly
reach its own correctly simulated final halt state.
But it can, as the call goes into HHH, and you then just simulate the
code of HHH.
Do you mean like this? (as I have been telling you for three years) https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
I ignore the rest of your points because you
prove that it is almost impossible for you
to handle a single point.
When I go over the exact same point 500 times
you never notice that I ever mentioned this point.
On 7/4/2025 1:14 PM, Richard Damon wrote:
On 7/4/25 10:43 AM, olcott wrote:
On 7/4/2025 8:23 AM, Richard Damon wrote:
On 7/4/25 8:50 AM, olcott wrote:
On 7/4/2025 2:35 AM, Mikko wrote:
On 2025-07-03 12:56:42 +0000, olcott said:
On 7/3/2025 3:57 AM, Mikko wrote:
On 2025-07-03 02:50:40 +0000, olcott said:
On 7/1/2025 11:37 AM, Mr Flibble wrote:
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote:
On 6/30/25 2:30 PM, Mr Flibble wrote:
PO just works off the lie that a correct simulation of the >>>>>>>>>>> input is
different than the direct execution, even though he can't >>>>>>>>>>> show the
instruction actually correctly simulated where they differ, >>>>>>>>>>> and thus
proves he is lying.
The closest he comes is claiming that the simulation of the >>>>>>>>>>> "Call HHH"
must be different when simulated then when executed, as for >>>>>>>>>>> "some
reason" it must be just because otherwise HHH can't do the >>>>>>>>>>> simulation.
Sorry, not being able to do something doesn't mean you get to >>>>>>>>>>> redefine
it,
You ar4e just showing you are as stupid as he is.
No. A simulator does not have to run a simulation to
completion if it can
determine that the input, A PROGRAM, never halts.
/Flibble
The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and
DDD does not call HHH1(DDD) in recursive simulation.
Either "no" (encoded as 0) or "yes" (encoded as any other
number) is the
wrong asnwer to the quesstion "does DDD specify a halting
computation?".
That is *not* the actual question.
THe actual question is whatever someone asks.
What is the area of a square circle with a radius of 2?
However, if the question is
not "does DDD specify a halting computation?" or the same about some >>>>>> other computation then it is not in the scope of the halting problem >>>>>> or the termination problem.
The halting problem has always been flatly incorrect
by making that the question. So I am reframing the
question the same way that ZFC reframed Russell's Paradox.
Nope, just shows you are too stupid to understand it.
Then tell me where I go wrong on this explanation:
ZFC conquered Russell's Paradox by redefining how
sets are defined such that a set that is a member
of itself can no longer be defined.
"ZFC avoids this paradox by using axioms that restrict set formation."
And what does that distraction have to do with halting problem?
*Changing the definition of the problem is a way to solve it*
On 7/4/2025 3:40 PM, Richard Damon wrote:
On 7/4/25 2:25 PM, olcott wrote:
On 7/4/2025 1:14 PM, Richard Damon wrote:
On 7/4/25 10:43 AM, olcott wrote:
On 7/4/2025 8:23 AM, Richard Damon wrote:And what does that distraction have to do with halting problem?
On 7/4/25 8:50 AM, olcott wrote:
On 7/4/2025 2:35 AM, Mikko wrote:
On 2025-07-03 12:56:42 +0000, olcott said:
On 7/3/2025 3:57 AM, Mikko wrote:
On 2025-07-03 02:50:40 +0000, olcott said:
On 7/1/2025 11:37 AM, Mr Flibble wrote:
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote: >>>>>>>>>>>>
On 6/30/25 2:30 PM, Mr Flibble wrote:
PO just works off the lie that a correct simulation of the >>>>>>>>>>>>> input is
different than the direct execution, even though he can't >>>>>>>>>>>>> show the
instruction actually correctly simulated where they differ, >>>>>>>>>>>>> and thus
proves he is lying.
The closest he comes is claiming that the simulation of the >>>>>>>>>>>>> "Call HHH"
must be different when simulated then when executed, as for >>>>>>>>>>>>> "some
reason" it must be just because otherwise HHH can't do the >>>>>>>>>>>>> simulation.
Sorry, not being able to do something doesn't mean you get >>>>>>>>>>>>> to redefine
it,
You ar4e just showing you are as stupid as he is.
No. A simulator does not have to run a simulation to
completion if it can
determine that the input, A PROGRAM, never halts.
/Flibble
The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and
DDD does not call HHH1(DDD) in recursive simulation.
Either "no" (encoded as 0) or "yes" (encoded as any other
number) is the
wrong asnwer to the quesstion "does DDD specify a halting
computation?".
That is *not* the actual question.
THe actual question is whatever someone asks.
What is the area of a square circle with a radius of 2?
However, if the question is
not "does DDD specify a halting computation?" or the same about >>>>>>>> some
other computation then it is not in the scope of the halting
problem
or the termination problem.
The halting problem has always been flatly incorrect
by making that the question. So I am reframing the
question the same way that ZFC reframed Russell's Paradox.
Nope, just shows you are too stupid to understand it.
Then tell me where I go wrong on this explanation:
ZFC conquered Russell's Paradox by redefining how
sets are defined such that a set that is a member
of itself can no longer be defined.
"ZFC avoids this paradox by using axioms that restrict set formation." >>>>
*Changing the definition of the problem is a way to solve it*
But you aren't allowed to do that.
Note, ZFC doesn't solve the problem of Russell's Paradox in Naive Set
Theory, as it doesn't do anything to Naive Set Theory.
It replaced the erroneous naive set theory thus
conquering the misconception of Russell's Paradox.
Likewise I am conquering the misconception that
partial halt deciders must report on the behavior
of directly executed Turing machines.
On 7/4/2025 3:33 PM, Richard Damon wrote:
On 7/4/25 2:24 PM, olcott wrote:
On 7/4/2025 12:48 PM, Richard Damon wrote:
On 7/4/25 9:32 AM, olcott wrote:
On 7/4/2025 8:22 AM, joes wrote:
Am Fri, 04 Jul 2025 07:50:23 -0500 schrieb olcott:
On 7/4/2025 2:35 AM, Mikko wrote:
On 2025-07-03 12:56:42 +0000, olcott said:
On 7/3/2025 3:57 AM, Mikko wrote:
On 2025-07-03 02:50:40 +0000, olcott said:
On 7/1/2025 11:37 AM, Mr Flibble wrote:
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote: >>>>>>>>>>>>> On 6/30/25 2:30 PM, Mr Flibble wrote:
No. A simulator does not have to run a simulation to
completion if
it can determine that the input, A PROGRAM, never halts.
If. But here it confuses that with not being able to simulate past >>>>>> the
recursive call.
It is the correct simulation of the input that
specifies the actual behavior of this input.
Right, and that means correctly simulating EVERY instruction that
makes up the PROGRAM, which must include the code of *THE* HHH, or
you can't "correctly simulate" the call instruction.
SIn
If this simulation cannot simulate past the recursive
call then this correctly simulated input cannot possibly
reach its own correctly simulated final halt state.
But it can, as the call goes into HHH, and you then just simulate
the code of HHH.
Do you mean like this? (as I have been telling you for three years)
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Yes, so where in that trace does HHH's "correct simulation" differ
from the exact same simulation generated by HHH1 before HHH aborts?
When we compare DDD emulated by HHH and DDD emulated
by HHH1 SIDE-BY-SIDE. (Mike didn't do it this way).
*The difference is when*
HHH begins to simulate itself simulating DDD and
HHH1 NEVER begins to simulate itself simulating DDD.
On 7/4/2025 2:42 AM, Mikko wrote:
On 2025-07-03 15:17:53 +0000, olcott said:
On 7/3/2025 9:50 AM, Richard Damon wrote:
On 7/3/25 10:39 AM, olcott wrote:
On 7/3/2025 9:16 AM, Richard Damon wrote:
On 7/2/25 10:50 PM, olcott wrote:
On 7/1/2025 11:37 AM, Mr Flibble wrote:
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote:
On 6/30/25 2:30 PM, Mr Flibble wrote:
PO just works off the lie that a correct simulation of the
input is
different than the direct execution, even though he can't show the >>>>>>>>> instruction actually correctly simulated where they differ, and >>>>>>>>> thus
proves he is lying.
The closest he comes is claiming that the simulation of the
"Call HHH"
must be different when simulated then when executed, as for "some >>>>>>>>> reason" it must be just because otherwise HHH can't do the
simulation.
Sorry, not being able to do something doesn't mean you get to >>>>>>>>> redefine
it,
You ar4e just showing you are as stupid as he is.
No. A simulator does not have to run a simulation to completion >>>>>>>> if it can
determine that the input, A PROGRAM, never halts.
/Flibble
The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and
DDD does not call HHH1(DDD) in recursive simulation.
Nope. It seems you don't understand what the question actually IS
because you have just lied to yourself so much that you lost the
understanding of the queiston.
*I can't imagine how Mike does not get this*
I can't understand
*Context of above dialogue*
*Context of above dialogue*
*Context of above dialogue*
Context of your context:
A Halt Decider is supposed to decide if the program given to it
(via some correct representation) will halt when run.
Thus, "the input" needs to represent a program
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
}
Which, by itself, isn't a valid input, or program. as HHH is
undefined.
Each different definition of HHH, gives a different problem.
Your "logic" seems to be based on trying to re-define what a
program is, which just makes it a lie.
"Programs" must be complete and self-contained in the field of
computability theory, something you don't seem to understand.
Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0. (HHH1 has identical code)
But it CAN'T simulate the above input. as it isn't valid.
You need to add the code of HHH to the input to let HHH simulate
"the input" to get anything.
No I do not. The above paragraph has every detail that is needed.
Then how do you correctly simulate something you do not have.
Note, your "description" of HHH is just incorrect, as it is also
incomplete.
Simulating a LIE just gives you a lie.
And at that point, you have different inputs for different HHHs,
and possibly different behaviors, which you logic forgets to take
into account, which just breaks it.
Wrong.
It is because the what I specified does take this
into account that HHH(DDD)==0 and HHH1(DDD)==1 are correct.
Nope, becausee it violates the DEFINITION of what it means to
simulate something.
*You don't even know what you mean by this*
What I mean is the execution trace that is derived
within the semantics of the C programming language.
C lanbuage definition does not specifiy the senatics of the non-standard
lanugage extension that your HHH and HHH1 use.
*This is the ONLY specification of HHH that chatbots see*
Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0.
On 7/4/2025 2:35 AM, Mikko wrote:
On 2025-07-03 12:56:42 +0000, olcott said:
On 7/3/2025 3:57 AM, Mikko wrote:
On 2025-07-03 02:50:40 +0000, olcott said:That is *not* the actual question.
On 7/1/2025 11:37 AM, Mr Flibble wrote:
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote:
On 6/30/25 2:30 PM, Mr Flibble wrote:
PO just works off the lie that a correct simulation of the input is >>>>>>> different than the direct execution, even though he can't show the >>>>>>> instruction actually correctly simulated where they differ, and thus >>>>>>> proves he is lying.
The closest he comes is claiming that the simulation of the "Call HHH" >>>>>>> must be different when simulated then when executed, as for "some >>>>>>> reason" it must be just because otherwise HHH can't do the simulation. >>>>>>>
Sorry, not being able to do something doesn't mean you get to redefine >>>>>>> it,
You ar4e just showing you are as stupid as he is.
No. A simulator does not have to run a simulation to completion if it can
determine that the input, A PROGRAM, never halts.
/Flibble
The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and
DDD does not call HHH1(DDD) in recursive simulation.
Either "no" (encoded as 0) or "yes" (encoded as any other number) is the >>>> wrong asnwer to the quesstion "does DDD specify a halting computation?". >>>
THe actual question is whatever someone asks.
What is the area of a square circle with a radius of 2?
On 7/4/2025 2:42 AM, Mikko wrote:
On 2025-07-03 15:17:53 +0000, olcott said:
On 7/3/2025 9:50 AM, Richard Damon wrote:
On 7/3/25 10:39 AM, olcott wrote:
On 7/3/2025 9:16 AM, Richard Damon wrote:
On 7/2/25 10:50 PM, olcott wrote:
On 7/1/2025 11:37 AM, Mr Flibble wrote:
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote:
On 6/30/25 2:30 PM, Mr Flibble wrote:
PO just works off the lie that a correct simulation of the input is >>>>>>>>> different than the direct execution, even though he can't show the >>>>>>>>> instruction actually correctly simulated where they differ, and thus >>>>>>>>> proves he is lying.
The closest he comes is claiming that the simulation of the "Call HHH"
must be different when simulated then when executed, as for "some >>>>>>>>> reason" it must be just because otherwise HHH can't do the simulation.
Sorry, not being able to do something doesn't mean you get to redefine
it,
You ar4e just showing you are as stupid as he is.
No. A simulator does not have to run a simulation to completion if it can
determine that the input, A PROGRAM, never halts.
/Flibble
The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and
DDD does not call HHH1(DDD) in recursive simulation.
Nope. It seems you don't understand what the question actually IS
because you have just lied to yourself so much that you lost the
understanding of the queiston.
*I can't imagine how Mike does not get this*
I can't understand
*Context of above dialogue*
*Context of above dialogue*
*Context of above dialogue*
Context of your context:
A Halt Decider is supposed to decide if the program given to it (via >>>>>> some correct representation) will halt when run.
Thus, "the input" needs to represent a program
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
}
Which, by itself, isn't a valid input, or program. as HHH is undefined. >>>>>>
Each different definition of HHH, gives a different problem.
Your "logic" seems to be based on trying to re-define what a program >>>>>> is, which just makes it a lie.
"Programs" must be complete and self-contained in the field of
computability theory, something you don't seem to understand.
Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0. (HHH1 has identical code)
But it CAN'T simulate the above input. as it isn't valid.
You need to add the code of HHH to the input to let HHH simulate "the >>>>>> input" to get anything.
No I do not. The above paragraph has every detail that is needed.
Then how do you correctly simulate something you do not have.
Note, your "description" of HHH is just incorrect, as it is also incomplete.
Simulating a LIE just gives you a lie.
And at that point, you have different inputs for different HHHs, and >>>>>> possibly different behaviors, which you logic forgets to take into >>>>>> account, which just breaks it.
Wrong.
It is because the what I specified does take this
into account that HHH(DDD)==0 and HHH1(DDD)==1 are correct.
Nope, becausee it violates the DEFINITION of what it means to simulate >>>> something.
*You don't even know what you mean by this*
What I mean is the execution trace that is derived
within the semantics of the C programming language.
C lanbuage definition does not specifiy the senatics of the non-standard
lanugage extension that your HHH and HHH1 use.
*This is the ONLY specification of HHH that chatbots see*
On 7/4/2025 3:33 PM, Richard Damon wrote:
On 7/4/25 2:24 PM, olcott wrote:
On 7/4/2025 12:48 PM, Richard Damon wrote:
On 7/4/25 9:32 AM, olcott wrote:
On 7/4/2025 8:22 AM, joes wrote:
Am Fri, 04 Jul 2025 07:50:23 -0500 schrieb olcott:
On 7/4/2025 2:35 AM, Mikko wrote:
On 2025-07-03 12:56:42 +0000, olcott said:
On 7/3/2025 3:57 AM, Mikko wrote:
On 2025-07-03 02:50:40 +0000, olcott said:
On 7/1/2025 11:37 AM, Mr Flibble wrote:
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote: >>>>>>>>>>>>> On 6/30/25 2:30 PM, Mr Flibble wrote:
No. A simulator does not have to run a simulation to
completion if
it can determine that the input, A PROGRAM, never halts.
If. But here it confuses that with not being able to simulate past >>>>>> the
recursive call.
It is the correct simulation of the input that
specifies the actual behavior of this input.
Right, and that means correctly simulating EVERY instruction that
makes up the PROGRAM, which must include the code of *THE* HHH, or
you can't "correctly simulate" the call instruction.
SIn
If this simulation cannot simulate past the recursive
call then this correctly simulated input cannot possibly
reach its own correctly simulated final halt state.
But it can, as the call goes into HHH, and you then just simulate
the code of HHH.
Do you mean like this? (as I have been telling you for three years)
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Yes, so where in that trace does HHH's "correct simulation" differ
from the exact same simulation generated by HHH1 before HHH aborts?
When we compare DDD emulated by HHH and DDD emulated
by HHH1 SIDE-BY-SIDE. (Mike didn't do it this way).
*The difference is when*
HHH begins to simulate itself simulating DDD and
HHH1 NEVER begins to simulate itself simulating DDD.
HHH doesn't actually abort its simulation of DDD until
after has simulated many hundreds of simulated instructions
later. HHH simulates itself simulating DDD until DDD calls
HHH(DDD) again.
I only address one point at a time because you
find that one single point to be impossibly too
difficult for you. When I tell you something
500 times you never notice that I even said it once.
On 7/4/2025 3:40 PM, Richard Damon wrote:
On 7/4/25 2:25 PM, olcott wrote:
On 7/4/2025 1:14 PM, Richard Damon wrote:
On 7/4/25 10:43 AM, olcott wrote:
On 7/4/2025 8:23 AM, Richard Damon wrote:And what does that distraction have to do with halting problem?
On 7/4/25 8:50 AM, olcott wrote:
On 7/4/2025 2:35 AM, Mikko wrote:
On 2025-07-03 12:56:42 +0000, olcott said:
On 7/3/2025 3:57 AM, Mikko wrote:
On 2025-07-03 02:50:40 +0000, olcott said:
On 7/1/2025 11:37 AM, Mr Flibble wrote:
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote: >>>>>>>>>>>>
On 6/30/25 2:30 PM, Mr Flibble wrote:
PO just works off the lie that a correct simulation of the >>>>>>>>>>>>> input is
different than the direct execution, even though he can't >>>>>>>>>>>>> show the
instruction actually correctly simulated where they differ, >>>>>>>>>>>>> and thus
proves he is lying.
The closest he comes is claiming that the simulation of the >>>>>>>>>>>>> "Call HHH"
must be different when simulated then when executed, as for >>>>>>>>>>>>> "some
reason" it must be just because otherwise HHH can't do the >>>>>>>>>>>>> simulation.
Sorry, not being able to do something doesn't mean you get >>>>>>>>>>>>> to redefine
it,
You ar4e just showing you are as stupid as he is.
No. A simulator does not have to run a simulation to
completion if it can
determine that the input, A PROGRAM, never halts.
/Flibble
The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and
DDD does not call HHH1(DDD) in recursive simulation.
Either "no" (encoded as 0) or "yes" (encoded as any other
number) is the
wrong asnwer to the quesstion "does DDD specify a halting
computation?".
That is *not* the actual question.
THe actual question is whatever someone asks.
What is the area of a square circle with a radius of 2?
However, if the question is
not "does DDD specify a halting computation?" or the same about >>>>>>>> some
other computation then it is not in the scope of the halting
problem
or the termination problem.
The halting problem has always been flatly incorrect
by making that the question. So I am reframing the
question the same way that ZFC reframed Russell's Paradox.
Nope, just shows you are too stupid to understand it.
Then tell me where I go wrong on this explanation:
ZFC conquered Russell's Paradox by redefining how
sets are defined such that a set that is a member
of itself can no longer be defined.
"ZFC avoids this paradox by using axioms that restrict set formation." >>>>
*Changing the definition of the problem is a way to solve it*
But you aren't allowed to do that.
Note, ZFC doesn't solve the problem of Russell's Paradox in Naive Set
Theory, as it doesn't do anything to Naive Set Theory.
It replaced the erroneous naive set theory thus
conquering the misconception of Russell's Paradox.
Likewise I am conquering the misconception that
partial halt deciders must report on the behavior
of directly executed Turing machines.
On 7/5/2025 8:01 AM, Richard Damon wrote:
On 7/4/25 6:17 PM, olcott wrote:
On 7/4/2025 3:33 PM, Richard Damon wrote:
On 7/4/25 2:24 PM, olcott wrote:
On 7/4/2025 12:48 PM, Richard Damon wrote:
On 7/4/25 9:32 AM, olcott wrote:
On 7/4/2025 8:22 AM, joes wrote:
Am Fri, 04 Jul 2025 07:50:23 -0500 schrieb olcott:
On 7/4/2025 2:35 AM, Mikko wrote:
On 2025-07-03 12:56:42 +0000, olcott said:
On 7/3/2025 3:57 AM, Mikko wrote:
On 2025-07-03 02:50:40 +0000, olcott said:
On 7/1/2025 11:37 AM, Mr Flibble wrote:
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote: >>>>>>>>>>>>>>> On 6/30/25 2:30 PM, Mr Flibble wrote:
No. A simulator does not have to run a simulation to >>>>>>>>>>>>>> completion if
it can determine that the input, A PROGRAM, never halts.
If. But here it confuses that with not being able to simulate
past the
recursive call.
It is the correct simulation of the input that
specifies the actual behavior of this input.
Right, and that means correctly simulating EVERY instruction that
makes up the PROGRAM, which must include the code of *THE* HHH, or >>>>>> you can't "correctly simulate" the call instruction.
SIn
If this simulation cannot simulate past the recursive
call then this correctly simulated input cannot possibly
reach its own correctly simulated final halt state.
But it can, as the call goes into HHH, and you then just simulate
the code of HHH.
Do you mean like this? (as I have been telling you for three years)
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Yes, so where in that trace does HHH's "correct simulation" differ
from the exact same simulation generated by HHH1 before HHH aborts?
When we compare DDD emulated by HHH and DDD emulated
by HHH1 SIDE-BY-SIDE. (Mike didn't do it this way).
*The difference is when*
HHH begins to simulate itself simulating DDD and
HHH1 NEVER begins to simulate itself simulating DDD.
And where does that show as a difference in the trace?
"itself" isn't something in the code/
Yes there aren't any machine addresses in x86 code.
x86 code always only works on the basis of its psychic ability.
We can't possibly see that DDD calls the machine address
of HHH because in x86 code there is no such thing as machine
addresses.
On 7/5/2025 8:07 AM, Richard Damon wrote:
On 7/4/25 6:24 PM, olcott wrote:
On 7/4/2025 3:40 PM, Richard Damon wrote:
On 7/4/25 2:25 PM, olcott wrote:
On 7/4/2025 1:14 PM, Richard Damon wrote:
On 7/4/25 10:43 AM, olcott wrote:
On 7/4/2025 8:23 AM, Richard Damon wrote:
On 7/4/25 8:50 AM, olcott wrote:
On 7/4/2025 2:35 AM, Mikko wrote:
On 2025-07-03 12:56:42 +0000, olcott said:
On 7/3/2025 3:57 AM, Mikko wrote:
On 2025-07-03 02:50:40 +0000, olcott said:
On 7/1/2025 11:37 AM, Mr Flibble wrote:
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote: >>>>>>>>>>>>>>
On 6/30/25 2:30 PM, Mr Flibble wrote:No. A simulator does not have to run a simulation to >>>>>>>>>>>>>> completion if it can
PO just works off the lie that a correct simulation of >>>>>>>>>>>>>>> the input is
different than the direct execution, even though he can't >>>>>>>>>>>>>>> show the
instruction actually correctly simulated where they >>>>>>>>>>>>>>> differ, and thus
proves he is lying.
The closest he comes is claiming that the simulation of >>>>>>>>>>>>>>> the "Call HHH"
must be different when simulated then when executed, as >>>>>>>>>>>>>>> for "some
reason" it must be just because otherwise HHH can't do >>>>>>>>>>>>>>> the simulation.
Sorry, not being able to do something doesn't mean you >>>>>>>>>>>>>>> get to redefine
it,
You ar4e just showing you are as stupid as he is. >>>>>>>>>>>>>>
determine that the input, A PROGRAM, never halts.
/Flibble
The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and >>>>>>>>>>>>> DDD does not call HHH1(DDD) in recursive simulation.
Either "no" (encoded as 0) or "yes" (encoded as any other >>>>>>>>>>>> number) is the
wrong asnwer to the quesstion "does DDD specify a halting >>>>>>>>>>>> computation?".
That is *not* the actual question.
THe actual question is whatever someone asks.
What is the area of a square circle with a radius of 2?
However, if the question is
not "does DDD specify a halting computation?" or the same
about some
other computation then it is not in the scope of the halting >>>>>>>>>> problem
or the termination problem.
The halting problem has always been flatly incorrect
by making that the question. So I am reframing the
question the same way that ZFC reframed Russell's Paradox.
Nope, just shows you are too stupid to understand it.
Then tell me where I go wrong on this explanation:
ZFC conquered Russell's Paradox by redefining how
sets are defined such that a set that is a member
of itself can no longer be defined.
"ZFC avoids this paradox by using axioms that restrict set
formation."
And what does that distraction have to do with halting problem?
*Changing the definition of the problem is a way to solve it*
But you aren't allowed to do that.
Note, ZFC doesn't solve the problem of Russell's Paradox in Naive
Set Theory, as it doesn't do anything to Naive Set Theory.
It replaced the erroneous naive set theory thus
conquering the misconception of Russell's Paradox.
Yes, by creating a totally new system.
Note, The don't say that Russell's Paradox no longer exists in Naive
Set Theory, they
It proves that Russell's Paradox was always a misconception
anchored in incoherence.
Likewise I am conquering the misconception that
partial halt deciders must report on the behavior
of directly executed Turing machines.
But you aren't making a totally new system, just lying about the
existing system. In Computability Theory, reporting on the behavior of
the direct execution of a Turing Machine is a valid operation. To say
it isn't is just a lie.
The key correction that I am making to the halting problem
is the requirement that halt deciders report on the behavior
of a directly executed Turing machine when these have always
been outside of the domain of every Turing machine based decider.
On 7/5/2025 7:36 PM, Richard Damon wrote:
On 7/5/25 12:21 PM, olcott wrote:
On 7/5/2025 8:07 AM, Richard Damon wrote:
On 7/4/25 6:24 PM, olcott wrote:
On 7/4/2025 3:40 PM, Richard Damon wrote:
On 7/4/25 2:25 PM, olcott wrote:
On 7/4/2025 1:14 PM, Richard Damon wrote:
On 7/4/25 10:43 AM, olcott wrote:
On 7/4/2025 8:23 AM, Richard Damon wrote:
On 7/4/25 8:50 AM, olcott wrote:
On 7/4/2025 2:35 AM, Mikko wrote:Nope, just shows you are too stupid to understand it.
On 2025-07-03 12:56:42 +0000, olcott said:
On 7/3/2025 3:57 AM, Mikko wrote:
On 2025-07-03 02:50:40 +0000, olcott said:
On 7/1/2025 11:37 AM, Mr Flibble wrote:Either "no" (encoded as 0) or "yes" (encoded as any other >>>>>>>>>>>>>> number) is the
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote: >>>>>>>>>>>>>>>>
On 6/30/25 2:30 PM, Mr Flibble wrote:No. A simulator does not have to run a simulation to >>>>>>>>>>>>>>>> completion if it can
PO just works off the lie that a correct simulation of >>>>>>>>>>>>>>>>> the input is
different than the direct execution, even though he >>>>>>>>>>>>>>>>> can't show the
instruction actually correctly simulated where they >>>>>>>>>>>>>>>>> differ, and thus
proves he is lying.
The closest he comes is claiming that the simulation of >>>>>>>>>>>>>>>>> the "Call HHH"
must be different when simulated then when executed, as >>>>>>>>>>>>>>>>> for "some
reason" it must be just because otherwise HHH can't do >>>>>>>>>>>>>>>>> the simulation.
Sorry, not being able to do something doesn't mean you >>>>>>>>>>>>>>>>> get to redefine
it,
You ar4e just showing you are as stupid as he is. >>>>>>>>>>>>>>>>
determine that the input, A PROGRAM, never halts. >>>>>>>>>>>>>>>>
/Flibble
The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and >>>>>>>>>>>>>>> DDD does not call HHH1(DDD) in recursive simulation. >>>>>>>>>>>>>>
wrong asnwer to the quesstion "does DDD specify a halting >>>>>>>>>>>>>> computation?".
That is *not* the actual question.
THe actual question is whatever someone asks.
What is the area of a square circle with a radius of 2?
However, if the question is
not "does DDD specify a halting computation?" or the same >>>>>>>>>>>> about some
other computation then it is not in the scope of the halting >>>>>>>>>>>> problem
or the termination problem.
The halting problem has always been flatly incorrect
by making that the question. So I am reframing the
question the same way that ZFC reframed Russell's Paradox. >>>>>>>>>>
Then tell me where I go wrong on this explanation:
ZFC conquered Russell's Paradox by redefining how
sets are defined such that a set that is a member
of itself can no longer be defined.
"ZFC avoids this paradox by using axioms that restrict set
formation."
And what does that distraction have to do with halting problem? >>>>>>>>
*Changing the definition of the problem is a way to solve it*
But you aren't allowed to do that.
Note, ZFC doesn't solve the problem of Russell's Paradox in Naive
Set Theory, as it doesn't do anything to Naive Set Theory.
It replaced the erroneous naive set theory thus
conquering the misconception of Russell's Paradox.
Yes, by creating a totally new system.
Note, The don't say that Russell's Paradox no longer exists in Naive
Set Theory, they
It proves that Russell's Paradox was always a misconception
anchored in incoherence.
No, it was anchored in the existing theory of the time.
It showed that the theory had a major problem that needed to be fixed,
by finding a better system.
Likewise I am conquering the misconception that
partial halt deciders must report on the behavior
of directly executed Turing machines.
But you aren't making a totally new system, just lying about the
existing system. In Computability Theory, reporting on the behavior
of the direct execution of a Turing Machine is a valid operation. To
say it isn't is just a lie.
The key correction that I am making to the halting problem
is the requirement that halt deciders report on the behavior
of a directly executed Turing machine when these have always
been outside of the domain of every Turing machine based decider.
But that isn't a "base" criteria in the system. That is like saying
you are keeping standard addition, but you want 5 + 7 to be 57 instead
of 12, as that doesn't make sense.
Your problem is you just don't understand how logic systems work at
all, and thus you are trying to tackle a problem without knowing what
you are doing.
Sort of like taking a car with a minor knocking probem, and trying to
beat the engine with a big wrench.
If you want to change that criteria, you need to work on reformulating
from the original axiom level.
Note, ZFC didn't just ban sets from containing themselves, but defined
actual rules of how to build sets from previously created sets, with a
notation that the set being created isn't part of the set of
previously created sets. This RESULTS in the inability to define a set
containing itself.
Thus, you need to do the same to achieve your results, the problem
being that the idea that you can define what a "Halt Decider" would be
is something that just comes out of the general principles of
Computations.
The Halting of Computations is just a natural property of them.
Computations are encodable into finite strings (in a way that allows
the full recreation of the behavior of that computation)
And thus, asking if the computation a will halt given a finite string
representation of it just naturally follows.
All the Halting Problem proofs depend on the ability
of an *ACTUAL INPUT* to do the opposite of whatever its
decider decides and *THIS HAS ALWAYS BEEN IMPOSSIBLE*
On 7/5/2025 2:30 AM, Fred. Zwarts wrote:
Op 04.jul.2025 om 14:57 schreef olcott:
On 7/4/2025 2:42 AM, Mikko wrote:
On 2025-07-03 15:17:53 +0000, olcott said:
On 7/3/2025 9:50 AM, Richard Damon wrote:
On 7/3/25 10:39 AM, olcott wrote:
On 7/3/2025 9:16 AM, Richard Damon wrote:Then how do you correctly simulate something you do not have.
On 7/2/25 10:50 PM, olcott wrote:
On 7/1/2025 11:37 AM, Mr Flibble wrote:
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote:
On 6/30/25 2:30 PM, Mr Flibble wrote:
PO just works off the lie that a correct simulation of the input is >>>>>>>>>>> different than the direct execution, even though he can't show the >>>>>>>>>>> instruction actually correctly simulated where they differ, and thus
proves he is lying.
The closest he comes is claiming that the simulation of the "Call HHH"
must be different when simulated then when executed, as for "some >>>>>>>>>>> reason" it must be just because otherwise HHH can't do the simulation.
Sorry, not being able to do something doesn't mean you get to redefine
it,
You ar4e just showing you are as stupid as he is.
No. A simulator does not have to run a simulation to completion if it can
determine that the input, A PROGRAM, never halts.
/Flibble
The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and
DDD does not call HHH1(DDD) in recursive simulation.
Nope. It seems you don't understand what the question actually IS >>>>>>>> because you have just lied to yourself so much that you lost the >>>>>>>> understanding of the queiston.
*I can't imagine how Mike does not get this*
I can't understand
*Context of above dialogue*
*Context of above dialogue*
*Context of above dialogue*
Context of your context:
A Halt Decider is supposed to decide if the program given to it (via >>>>>>>> some correct representation) will halt when run.
Thus, "the input" needs to represent a program
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
}
Which, by itself, isn't a valid input, or program. as HHH is undefined.
Each different definition of HHH, gives a different problem.
Your "logic" seems to be based on trying to re-define what a program >>>>>>>> is, which just makes it a lie.
"Programs" must be complete and self-contained in the field of >>>>>>>> computability theory, something you don't seem to understand.
Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0. (HHH1 has identical code)
But it CAN'T simulate the above input. as it isn't valid.
You need to add the code of HHH to the input to let HHH simulate "the >>>>>>>> input" to get anything.
No I do not. The above paragraph has every detail that is needed. >>>>>>
Note, your "description" of HHH is just incorrect, as it is also incomplete.
Simulating a LIE just gives you a lie.
And at that point, you have different inputs for different HHHs, and >>>>>>>> possibly different behaviors, which you logic forgets to take into >>>>>>>> account, which just breaks it.
Wrong.
It is because the what I specified does take this
into account that HHH(DDD)==0 and HHH1(DDD)==1 are correct.
Nope, becausee it violates the DEFINITION of what it means to simulate >>>>>> something.
*You don't even know what you mean by this*
What I mean is the execution trace that is derived
within the semantics of the C programming language.
C lanbuage definition does not specifiy the senatics of the non-standard >>>> lanugage extension that your HHH and HHH1 use.
*This is the ONLY specification of HHH that chatbots see*
Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0.
There is no non-termination behaviour to detect, because the input
specifies only a *finite* recursion.
When DDD is infinitely simulated by HHH it never reaches
On 7/5/2025 3:44 AM, Mikko wrote:But is incorrect when there is no non-termination pattern and it still
On 2025-07-04 12:57:47 +0000, olcott said:
On 7/4/2025 2:42 AM, Mikko wrote:
On 2025-07-03 15:17:53 +0000, olcott said:
On 7/3/2025 9:50 AM, Richard Damon wrote:
On 7/3/25 10:39 AM, olcott wrote:
On 7/3/2025 9:16 AM, Richard Damon wrote:Then how do you correctly simulate something you do not have.
On 7/2/25 10:50 PM, olcott wrote:
On 7/1/2025 11:37 AM, Mr Flibble wrote:
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote:
On 6/30/25 2:30 PM, Mr Flibble wrote:
PO just works off the lie that a correct simulation of the >>>>>>>>>>> input is
different than the direct execution, even though he can't >>>>>>>>>>> show the
instruction actually correctly simulated where they differ, >>>>>>>>>>> and thus
proves he is lying.
The closest he comes is claiming that the simulation of the >>>>>>>>>>> "Call HHH"
must be different when simulated then when executed, as for >>>>>>>>>>> "some
reason" it must be just because otherwise HHH can't do the >>>>>>>>>>> simulation.
Sorry, not being able to do something doesn't mean you get to >>>>>>>>>>> redefine
it,
You ar4e just showing you are as stupid as he is.
No. A simulator does not have to run a simulation to
completion if it can
determine that the input, A PROGRAM, never halts.
/Flibble
The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and
DDD does not call HHH1(DDD) in recursive simulation.
Nope. It seems you don't understand what the question actually >>>>>>>> IS because you have just lied to yourself so much that you lost >>>>>>>> the understanding of the queiston.
*I can't imagine how Mike does not get this*
I can't understand
*Context of above dialogue*
*Context of above dialogue*
*Context of above dialogue*
Context of your context:
A Halt Decider is supposed to decide if the program given to it >>>>>>>> (via some correct representation) will halt when run.
Thus, "the input" needs to represent a program
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
}
Which, by itself, isn't a valid input, or program. as HHH is
undefined.
Each different definition of HHH, gives a different problem.
Your "logic" seems to be based on trying to re-define what a
program is, which just makes it a lie.
"Programs" must be complete and self-contained in the field of >>>>>>>> computability theory, something you don't seem to understand.
Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0. (HHH1 has identical code)
But it CAN'T simulate the above input. as it isn't valid.
You need to add the code of HHH to the input to let HHH simulate >>>>>>>> "the input" to get anything.
No I do not. The above paragraph has every detail that is needed. >>>>>>
Note, your "description" of HHH is just incorrect, as it is also
incomplete.
Simulating a LIE just gives you a lie.
And at that point, you have different inputs for different HHHs, >>>>>>>> and possibly different behaviors, which you logic forgets to
take into account, which just breaks it.
Wrong.
It is because the what I specified does take this
into account that HHH(DDD)==0 and HHH1(DDD)==1 are correct.
Nope, becausee it violates the DEFINITION of what it means to
simulate something.
*You don't even know what you mean by this*
What I mean is the execution trace that is derived
within the semantics of the C programming language.
C lanbuage definition does not specifiy the senatics of the non-
standard
lanugage extension that your HHH and HHH1 use.
*This is the ONLY specification of HHH that chatbots see*
That is irrelevant. What is relevant is the specification or lack of
that readers of comp.theory see.
Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0.
On 7/5/2025 2:33 AM, Fred. Zwarts wrote:The input for HHH specifies a halting program according to the semantics
Op 05.jul.2025 om 00:24 schreef olcott:
On 7/4/2025 3:40 PM, Richard Damon wrote:
On 7/4/25 2:25 PM, olcott wrote:
On 7/4/2025 1:14 PM, Richard Damon wrote:
On 7/4/25 10:43 AM, olcott wrote:
On 7/4/2025 8:23 AM, Richard Damon wrote:
On 7/4/25 8:50 AM, olcott wrote:
On 7/4/2025 2:35 AM, Mikko wrote:
On 2025-07-03 12:56:42 +0000, olcott said:
On 7/3/2025 3:57 AM, Mikko wrote:
On 2025-07-03 02:50:40 +0000, olcott said:
On 7/1/2025 11:37 AM, Mr Flibble wrote:
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote: >>>>>>>>>>>>>>
On 6/30/25 2:30 PM, Mr Flibble wrote:No. A simulator does not have to run a simulation to >>>>>>>>>>>>>> completion if it can
PO just works off the lie that a correct simulation of >>>>>>>>>>>>>>> the input is
different than the direct execution, even though he can't >>>>>>>>>>>>>>> show the
instruction actually correctly simulated where they >>>>>>>>>>>>>>> differ, and thus
proves he is lying.
The closest he comes is claiming that the simulation of >>>>>>>>>>>>>>> the "Call HHH"
must be different when simulated then when executed, as >>>>>>>>>>>>>>> for "some
reason" it must be just because otherwise HHH can't do >>>>>>>>>>>>>>> the simulation.
Sorry, not being able to do something doesn't mean you >>>>>>>>>>>>>>> get to redefine
it,
You ar4e just showing you are as stupid as he is. >>>>>>>>>>>>>>
determine that the input, A PROGRAM, never halts.
/Flibble
The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and >>>>>>>>>>>>> DDD does not call HHH1(DDD) in recursive simulation.
Either "no" (encoded as 0) or "yes" (encoded as any other >>>>>>>>>>>> number) is the
wrong asnwer to the quesstion "does DDD specify a halting >>>>>>>>>>>> computation?".
That is *not* the actual question.
THe actual question is whatever someone asks.
What is the area of a square circle with a radius of 2?
However, if the question is
not "does DDD specify a halting computation?" or the same
about some
other computation then it is not in the scope of the halting >>>>>>>>>> problem
or the termination problem.
The halting problem has always been flatly incorrect
by making that the question. So I am reframing the
question the same way that ZFC reframed Russell's Paradox.
Nope, just shows you are too stupid to understand it.
Then tell me where I go wrong on this explanation:
ZFC conquered Russell's Paradox by redefining how
sets are defined such that a set that is a member
of itself can no longer be defined.
"ZFC avoids this paradox by using axioms that restrict set
formation."
And what does that distraction have to do with halting problem?
*Changing the definition of the problem is a way to solve it*
But you aren't allowed to do that.
Note, ZFC doesn't solve the problem of Russell's Paradox in Naive
Set Theory, as it doesn't do anything to Naive Set Theory.
It replaced the erroneous naive set theory thus
conquering the misconception of Russell's Paradox.
Likewise I am conquering the misconception that
partial halt deciders must report on the behavior
of directly executed Turing machines.
Your misconception is that the decider must report on hypothetical
Turing machines, where in fact the decider must report on its input.
DDD simulated by HHH according to the semantics of the
C programming language cannot possibly reach its own
simulated "return" statement final halt state even if
an infinite number of steps are simulated.
On 7/5/2025 9:59 PM, Richard Damon wrote:
On 7/5/25 10:23 PM, olcott wrote:
On 7/5/2025 7:36 PM, Richard Damon wrote:
On 7/5/25 12:21 PM, olcott wrote:
On 7/5/2025 8:07 AM, Richard Damon wrote:
On 7/4/25 6:24 PM, olcott wrote:
On 7/4/2025 3:40 PM, Richard Damon wrote:
On 7/4/25 2:25 PM, olcott wrote:
On 7/4/2025 1:14 PM, Richard Damon wrote:
On 7/4/25 10:43 AM, olcott wrote:
On 7/4/2025 8:23 AM, Richard Damon wrote:
On 7/4/25 8:50 AM, olcott wrote:
On 7/4/2025 2:35 AM, Mikko wrote:Nope, just shows you are too stupid to understand it.
On 2025-07-03 12:56:42 +0000, olcott said:
On 7/3/2025 3:57 AM, Mikko wrote:
On 2025-07-03 02:50:40 +0000, olcott said:
On 7/1/2025 11:37 AM, Mr Flibble wrote:Either "no" (encoded as 0) or "yes" (encoded as any >>>>>>>>>>>>>>>> other number) is the
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote: >>>>>>>>>>>>>>>>>>
On 6/30/25 2:30 PM, Mr Flibble wrote:No. A simulator does not have to run a simulation to >>>>>>>>>>>>>>>>>> completion if it can
PO just works off the lie that a correct simulation >>>>>>>>>>>>>>>>>>> of the input is
different than the direct execution, even though he >>>>>>>>>>>>>>>>>>> can't show the
instruction actually correctly simulated where they >>>>>>>>>>>>>>>>>>> differ, and thus
proves he is lying.
The closest he comes is claiming that the simulation >>>>>>>>>>>>>>>>>>> of the "Call HHH"
must be different when simulated then when executed, >>>>>>>>>>>>>>>>>>> as for "some
reason" it must be just because otherwise HHH can't >>>>>>>>>>>>>>>>>>> do the simulation.
Sorry, not being able to do something doesn't mean >>>>>>>>>>>>>>>>>>> you get to redefine
it,
You ar4e just showing you are as stupid as he is. >>>>>>>>>>>>>>>>>>
determine that the input, A PROGRAM, never halts. >>>>>>>>>>>>>>>>>>
/Flibble
The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct >>>>>>>>>>>>>>>>> because DDD calls HHH(DDD) in recursive simulation and >>>>>>>>>>>>>>>>> DDD does not call HHH1(DDD) in recursive simulation. >>>>>>>>>>>>>>>>
wrong asnwer to the quesstion "does DDD specify a >>>>>>>>>>>>>>>> halting computation?".
That is *not* the actual question.
THe actual question is whatever someone asks.
What is the area of a square circle with a radius of 2? >>>>>>>>>>>>>
However, if the question is
not "does DDD specify a halting computation?" or the same >>>>>>>>>>>>>> about some
other computation then it is not in the scope of the >>>>>>>>>>>>>> halting problem
or the termination problem.
The halting problem has always been flatly incorrect >>>>>>>>>>>>> by making that the question. So I am reframing the
question the same way that ZFC reframed Russell's Paradox. >>>>>>>>>>>>
Then tell me where I go wrong on this explanation:
ZFC conquered Russell's Paradox by redefining how
sets are defined such that a set that is a member
of itself can no longer be defined.
"ZFC avoids this paradox by using axioms that restrict set >>>>>>>>>>> formation."
And what does that distraction have to do with halting problem? >>>>>>>>>>
*Changing the definition of the problem is a way to solve it* >>>>>>>>>
But you aren't allowed to do that.
Note, ZFC doesn't solve the problem of Russell's Paradox in
Naive Set Theory, as it doesn't do anything to Naive Set Theory. >>>>>>>>
It replaced the erroneous naive set theory thus
conquering the misconception of Russell's Paradox.
Yes, by creating a totally new system.
Note, The don't say that Russell's Paradox no longer exists in
Naive Set Theory, they
It proves that Russell's Paradox was always a misconception
anchored in incoherence.
No, it was anchored in the existing theory of the time.
It showed that the theory had a major problem that needed to be
fixed, by finding a better system.
Likewise I am conquering the misconception that
partial halt deciders must report on the behavior
of directly executed Turing machines.
But you aren't making a totally new system, just lying about the
existing system. In Computability Theory, reporting on the
behavior of the direct execution of a Turing Machine is a valid
operation. To say it isn't is just a lie.
The key correction that I am making to the halting problem
is the requirement that halt deciders report on the behavior
of a directly executed Turing machine when these have always
been outside of the domain of every Turing machine based decider.
But that isn't a "base" criteria in the system. That is like saying
you are keeping standard addition, but you want 5 + 7 to be 57
instead of 12, as that doesn't make sense.
Your problem is you just don't understand how logic systems work at
all, and thus you are trying to tackle a problem without knowing
what you are doing.
Sort of like taking a car with a minor knocking probem, and trying
to beat the engine with a big wrench.
If you want to change that criteria, you need to work on
reformulating from the original axiom level.
Note, ZFC didn't just ban sets from containing themselves, but
defined actual rules of how to build sets from previously created
sets, with a notation that the set being created isn't part of the
set of previously created sets. This RESULTS in the inability to
define a set containing itself.
Thus, you need to do the same to achieve your results, the problem
being that the idea that you can define what a "Halt Decider" would
be is something that just comes out of the general principles of
Computations.
The Halting of Computations is just a natural property of them.
Computations are encodable into finite strings (in a way that allows
the full recreation of the behavior of that computation)
And thus, asking if the computation a will halt given a finite
string representation of it just naturally follows.
All the Halting Problem proofs depend on the ability
of an *ACTUAL INPUT* to do the opposite of whatever its
decider decides and *THIS HAS ALWAYS BEEN IMPOSSIBLE*
No, they depend on the ability of being able to make a program that
does the opposite of what the decider says when given a proper
representation of that program.
Yet no Turing machine decider can take an executing
Turing machine as an input thus not in the domain/scope of
any Turing machine decider. Halt deciders NEVER report
on the behavior of executing programs.
On 7/5/2025 9:59 PM, Richard Damon wrote:
On 7/5/25 10:23 PM, olcott wrote:
On 7/5/2025 7:36 PM, Richard Damon wrote:
On 7/5/25 12:21 PM, olcott wrote:
On 7/5/2025 8:07 AM, Richard Damon wrote:
On 7/4/25 6:24 PM, olcott wrote:
On 7/4/2025 3:40 PM, Richard Damon wrote:
On 7/4/25 2:25 PM, olcott wrote:
On 7/4/2025 1:14 PM, Richard Damon wrote:
On 7/4/25 10:43 AM, olcott wrote:
On 7/4/2025 8:23 AM, Richard Damon wrote:
On 7/4/25 8:50 AM, olcott wrote:
On 7/4/2025 2:35 AM, Mikko wrote:Nope, just shows you are too stupid to understand it.
On 2025-07-03 12:56:42 +0000, olcott said:
On 7/3/2025 3:57 AM, Mikko wrote:
On 2025-07-03 02:50:40 +0000, olcott said:
On 7/1/2025 11:37 AM, Mr Flibble wrote:Either "no" (encoded as 0) or "yes" (encoded as any >>>>>>>>>>>>>>>> other number) is the
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote: >>>>>>>>>>>>>>>>>>
On 6/30/25 2:30 PM, Mr Flibble wrote:No. A simulator does not have to run a simulation to >>>>>>>>>>>>>>>>>> completion if it can
PO just works off the lie that a correct simulation >>>>>>>>>>>>>>>>>>> of the input is
different than the direct execution, even though he >>>>>>>>>>>>>>>>>>> can't show the
instruction actually correctly simulated where they >>>>>>>>>>>>>>>>>>> differ, and thus
proves he is lying.
The closest he comes is claiming that the simulation >>>>>>>>>>>>>>>>>>> of the "Call HHH"
must be different when simulated then when executed, >>>>>>>>>>>>>>>>>>> as for "some
reason" it must be just because otherwise HHH can't >>>>>>>>>>>>>>>>>>> do the simulation.
Sorry, not being able to do something doesn't mean >>>>>>>>>>>>>>>>>>> you get to redefine
it,
You ar4e just showing you are as stupid as he is. >>>>>>>>>>>>>>>>>>
determine that the input, A PROGRAM, never halts. >>>>>>>>>>>>>>>>>>
/Flibble
The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct >>>>>>>>>>>>>>>>> because DDD calls HHH(DDD) in recursive simulation and >>>>>>>>>>>>>>>>> DDD does not call HHH1(DDD) in recursive simulation. >>>>>>>>>>>>>>>>
wrong asnwer to the quesstion "does DDD specify a >>>>>>>>>>>>>>>> halting computation?".
That is *not* the actual question.
THe actual question is whatever someone asks.
What is the area of a square circle with a radius of 2? >>>>>>>>>>>>>
However, if the question is
not "does DDD specify a halting computation?" or the same >>>>>>>>>>>>>> about some
other computation then it is not in the scope of the >>>>>>>>>>>>>> halting problem
or the termination problem.
The halting problem has always been flatly incorrect >>>>>>>>>>>>> by making that the question. So I am reframing the
question the same way that ZFC reframed Russell's Paradox. >>>>>>>>>>>>
Then tell me where I go wrong on this explanation:
ZFC conquered Russell's Paradox by redefining how
sets are defined such that a set that is a member
of itself can no longer be defined.
"ZFC avoids this paradox by using axioms that restrict set >>>>>>>>>>> formation."
And what does that distraction have to do with halting problem? >>>>>>>>>>
*Changing the definition of the problem is a way to solve it* >>>>>>>>>
But you aren't allowed to do that.
Note, ZFC doesn't solve the problem of Russell's Paradox in
Naive Set Theory, as it doesn't do anything to Naive Set Theory. >>>>>>>>
It replaced the erroneous naive set theory thus
conquering the misconception of Russell's Paradox.
Yes, by creating a totally new system.
Note, The don't say that Russell's Paradox no longer exists in
Naive Set Theory, they
It proves that Russell's Paradox was always a misconception
anchored in incoherence.
No, it was anchored in the existing theory of the time.
It showed that the theory had a major problem that needed to be
fixed, by finding a better system.
Likewise I am conquering the misconception that
partial halt deciders must report on the behavior
of directly executed Turing machines.
But you aren't making a totally new system, just lying about the
existing system. In Computability Theory, reporting on the
behavior of the direct execution of a Turing Machine is a valid
operation. To say it isn't is just a lie.
The key correction that I am making to the halting problem
is the requirement that halt deciders report on the behavior
of a directly executed Turing machine when these have always
been outside of the domain of every Turing machine based decider.
But that isn't a "base" criteria in the system. That is like saying
you are keeping standard addition, but you want 5 + 7 to be 57
instead of 12, as that doesn't make sense.
Your problem is you just don't understand how logic systems work at
all, and thus you are trying to tackle a problem without knowing
what you are doing.
Sort of like taking a car with a minor knocking probem, and trying
to beat the engine with a big wrench.
If you want to change that criteria, you need to work on
reformulating from the original axiom level.
Note, ZFC didn't just ban sets from containing themselves, but
defined actual rules of how to build sets from previously created
sets, with a notation that the set being created isn't part of the
set of previously created sets. This RESULTS in the inability to
define a set containing itself.
Thus, you need to do the same to achieve your results, the problem
being that the idea that you can define what a "Halt Decider" would
be is something that just comes out of the general principles of
Computations.
The Halting of Computations is just a natural property of them.
Computations are encodable into finite strings (in a way that allows
the full recreation of the behavior of that computation)
And thus, asking if the computation a will halt given a finite
string representation of it just naturally follows.
All the Halting Problem proofs depend on the ability
of an *ACTUAL INPUT* to do the opposite of whatever its
decider decides and *THIS HAS ALWAYS BEEN IMPOSSIBLE*
No, they depend on the ability of being able to make a program that
does the opposite of what the decider says when given a proper
representation of that program.
Yet no Turing machine decider can take an executing
Turing machine as an input thus not in the domain/scope of
any Turing machine decider. Halt deciders NEVER report
on the behavior of executing programs.
On 7/6/2025 4:19 AM, Mikko wrote:
On 2025-07-05 15:59:50 +0000, olcott said:
On 7/5/2025 2:30 AM, Fred. Zwarts wrote:
Op 04.jul.2025 om 14:57 schreef olcott:
On 7/4/2025 2:42 AM, Mikko wrote:
On 2025-07-03 15:17:53 +0000, olcott said:
On 7/3/2025 9:50 AM, Richard Damon wrote:
On 7/3/25 10:39 AM, olcott wrote:
On 7/3/2025 9:16 AM, Richard Damon wrote:Then how do you correctly simulate something you do not have.
On 7/2/25 10:50 PM, olcott wrote:
On 7/1/2025 11:37 AM, Mr Flibble wrote:
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote: >>>>>>>>>>>>
On 6/30/25 2:30 PM, Mr Flibble wrote:
PO just works off the lie that a correct simulation of the >>>>>>>>>>>>> input is
different than the direct execution, even though he can't >>>>>>>>>>>>> show the
instruction actually correctly simulated where they differ, >>>>>>>>>>>>> and thus
proves he is lying.
The closest he comes is claiming that the simulation of the >>>>>>>>>>>>> "Call HHH"
must be different when simulated then when executed, as for >>>>>>>>>>>>> "some
reason" it must be just because otherwise HHH can't do the >>>>>>>>>>>>> simulation.
Sorry, not being able to do something doesn't mean you get >>>>>>>>>>>>> to redefine
it,
You ar4e just showing you are as stupid as he is.
No. A simulator does not have to run a simulation to
completion if it can
determine that the input, A PROGRAM, never halts.
/Flibble
The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and
DDD does not call HHH1(DDD) in recursive simulation.
Nope. It seems you don't understand what the question actually >>>>>>>>>> IS because you have just lied to yourself so much that you >>>>>>>>>> lost the understanding of the queiston.
*I can't imagine how Mike does not get this*
I can't understand
*Context of above dialogue*
*Context of above dialogue*
*Context of above dialogue*
Context of your context:
A Halt Decider is supposed to decide if the program given to >>>>>>>>>> it (via some correct representation) will halt when run.
Thus, "the input" needs to represent a program
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
}
Which, by itself, isn't a valid input, or program. as HHH is >>>>>>>>>> undefined.
Each different definition of HHH, gives a different problem. >>>>>>>>>>
Your "logic" seems to be based on trying to re-define what a >>>>>>>>>> program is, which just makes it a lie.
"Programs" must be complete and self-contained in the field of >>>>>>>>>> computability theory, something you don't seem to understand. >>>>>>>>>>
Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0. (HHH1 has identical code)
But it CAN'T simulate the above input. as it isn't valid.
You need to add the code of HHH to the input to let HHH
simulate "the input" to get anything.
No I do not. The above paragraph has every detail that is needed. >>>>>>>>
Note, your "description" of HHH is just incorrect, as it is also >>>>>>>> incomplete.
Simulating a LIE just gives you a lie.
And at that point, you have different inputs for different >>>>>>>>>> HHHs, and possibly different behaviors, which you logic
forgets to take into account, which just breaks it.
Wrong.
It is because the what I specified does take this
into account that HHH(DDD)==0 and HHH1(DDD)==1 are correct.
Nope, becausee it violates the DEFINITION of what it means to
simulate something.
*You don't even know what you mean by this*
What I mean is the execution trace that is derived
within the semantics of the C programming language.
C lanbuage definition does not specifiy the senatics of the non-
standard
lanugage extension that your HHH and HHH1 use.
*This is the ONLY specification of HHH that chatbots see*
Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0.
There is no non-termination behaviour to detect, because the input
specifies only a *finite* recursion.
When DDD is infinitely simulated by HHH it never reaches
When DDD is infinitely simulated by HHH that HHH never answers correctly
(or otherwise) and therefore is not a halting decider.
So by a kind of mathematical induction HHH correctly
predicts that DDD simulated by HHH (according to the
semantics of the C programming language) cannot possibly
reach its own simulated "return" statement final halt
state then HHH is correct to reject DDD as non-halting.
On 7/6/2025 6:48 AM, Richard Damon wrote:
On 7/6/25 12:06 AM, olcott wrote:
On 7/5/2025 9:59 PM, Richard Damon wrote:
On 7/5/25 10:23 PM, olcott wrote:
On 7/5/2025 7:36 PM, Richard Damon wrote:
On 7/5/25 12:21 PM, olcott wrote:
On 7/5/2025 8:07 AM, Richard Damon wrote:
On 7/4/25 6:24 PM, olcott wrote:
On 7/4/2025 3:40 PM, Richard Damon wrote:
On 7/4/25 2:25 PM, olcott wrote:
On 7/4/2025 1:14 PM, Richard Damon wrote:
On 7/4/25 10:43 AM, olcott wrote:
On 7/4/2025 8:23 AM, Richard Damon wrote:
On 7/4/25 8:50 AM, olcott wrote:
On 7/4/2025 2:35 AM, Mikko wrote:Nope, just shows you are too stupid to understand it. >>>>>>>>>>>>>>
On 2025-07-03 12:56:42 +0000, olcott said:
On 7/3/2025 3:57 AM, Mikko wrote:
On 2025-07-03 02:50:40 +0000, olcott said: >>>>>>>>>>>>>>>>>>
On 7/1/2025 11:37 AM, Mr Flibble wrote: >>>>>>>>>>>>>>>>>>>> On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon >>>>>>>>>>>>>>>>>>>> wrote:Either "no" (encoded as 0) or "yes" (encoded as any >>>>>>>>>>>>>>>>>> other number) is the
On 6/30/25 2:30 PM, Mr Flibble wrote: >>>>>>>>>>>>>>>>>>>>>No. A simulator does not have to run a simulation to >>>>>>>>>>>>>>>>>>>> completion if it can
PO just works off the lie that a correct simulation >>>>>>>>>>>>>>>>>>>>> of the input is
different than the direct execution, even though he >>>>>>>>>>>>>>>>>>>>> can't show the
instruction actually correctly simulated where they >>>>>>>>>>>>>>>>>>>>> differ, and thus
proves he is lying.
The closest he comes is claiming that the >>>>>>>>>>>>>>>>>>>>> simulation of the "Call HHH"
must be different when simulated then when >>>>>>>>>>>>>>>>>>>>> executed, as for "some
reason" it must be just because otherwise HHH can't >>>>>>>>>>>>>>>>>>>>> do the simulation.
Sorry, not being able to do something doesn't mean >>>>>>>>>>>>>>>>>>>>> you get to redefine
it,
You ar4e just showing you are as stupid as he is. >>>>>>>>>>>>>>>>>>>>
determine that the input, A PROGRAM, never halts. >>>>>>>>>>>>>>>>>>>>
/Flibble
The most direct way to analyze this is that >>>>>>>>>>>>>>>>>>> HHH(DDD)==0 and HHH1(DDD)==1 are both correct >>>>>>>>>>>>>>>>>>> because DDD calls HHH(DDD) in recursive simulation and >>>>>>>>>>>>>>>>>>> DDD does not call HHH1(DDD) in recursive simulation. >>>>>>>>>>>>>>>>>>
wrong asnwer to the quesstion "does DDD specify a >>>>>>>>>>>>>>>>>> halting computation?".
That is *not* the actual question.
THe actual question is whatever someone asks.
What is the area of a square circle with a radius of 2? >>>>>>>>>>>>>>>
However, if the question is
not "does DDD specify a halting computation?" or the >>>>>>>>>>>>>>>> same about some
other computation then it is not in the scope of the >>>>>>>>>>>>>>>> halting problem
or the termination problem.
The halting problem has always been flatly incorrect >>>>>>>>>>>>>>> by making that the question. So I am reframing the >>>>>>>>>>>>>>> question the same way that ZFC reframed Russell's Paradox. >>>>>>>>>>>>>>
Then tell me where I go wrong on this explanation:
ZFC conquered Russell's Paradox by redefining how
sets are defined such that a set that is a member
of itself can no longer be defined.
"ZFC avoids this paradox by using axioms that restrict set >>>>>>>>>>>>> formation."
And what does that distraction have to do with halting problem? >>>>>>>>>>>>
*Changing the definition of the problem is a way to solve it* >>>>>>>>>>>
But you aren't allowed to do that.
Note, ZFC doesn't solve the problem of Russell's Paradox in >>>>>>>>>> Naive Set Theory, as it doesn't do anything to Naive Set Theory. >>>>>>>>>>
It replaced the erroneous naive set theory thus
conquering the misconception of Russell's Paradox.
Yes, by creating a totally new system.
Note, The don't say that Russell's Paradox no longer exists in >>>>>>>> Naive Set Theory, they
It proves that Russell's Paradox was always a misconception
anchored in incoherence.
No, it was anchored in the existing theory of the time.
It showed that the theory had a major problem that needed to be
fixed, by finding a better system.
Likewise I am conquering the misconception that
partial halt deciders must report on the behavior
of directly executed Turing machines.
But you aren't making a totally new system, just lying about the >>>>>>>> existing system. In Computability Theory, reporting on the
behavior of the direct execution of a Turing Machine is a valid >>>>>>>> operation. To say it isn't is just a lie.
The key correction that I am making to the halting problem
is the requirement that halt deciders report on the behavior
of a directly executed Turing machine when these have always
been outside of the domain of every Turing machine based decider. >>>>>>>
But that isn't a "base" criteria in the system. That is like
saying you are keeping standard addition, but you want 5 + 7 to be >>>>>> 57 instead of 12, as that doesn't make sense.
Your problem is you just don't understand how logic systems work
at all, and thus you are trying to tackle a problem without
knowing what you are doing.
Sort of like taking a car with a minor knocking probem, and trying >>>>>> to beat the engine with a big wrench.
If you want to change that criteria, you need to work on
reformulating from the original axiom level.
Note, ZFC didn't just ban sets from containing themselves, but
defined actual rules of how to build sets from previously created
sets, with a notation that the set being created isn't part of the >>>>>> set of previously created sets. This RESULTS in the inability to
define a set containing itself.
Thus, you need to do the same to achieve your results, the problem >>>>>> being that the idea that you can define what a "Halt Decider"
would be is something that just comes out of the general
principles of Computations.
The Halting of Computations is just a natural property of them.
Computations are encodable into finite strings (in a way that
allows the full recreation of the behavior of that computation)
And thus, asking if the computation a will halt given a finite
string representation of it just naturally follows.
All the Halting Problem proofs depend on the ability
of an *ACTUAL INPUT* to do the opposite of whatever its
decider decides and *THIS HAS ALWAYS BEEN IMPOSSIBLE*
No, they depend on the ability of being able to make a program that
does the opposite of what the decider says when given a proper
representation of that program.
Yet no Turing machine decider can take an executing
Turing machine as an input thus not in the domain/scope of
any Turing machine decider. Halt deciders NEVER report
on the behavior of executing programs.
But it doesn't need to,
*The standard halting problem proof cannot even be constructed*
*There is no input to any halt decider that does the opposite*
*of what its decider decides*
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD); // DD cannot do the opposite of HHH
DD(); // The caller of HHH(DD) is not its input
}
On 7/6/2025 4:19 AM, Mikko wrote:
On 2025-07-05 15:59:50 +0000, olcott said:
On 7/5/2025 2:30 AM, Fred. Zwarts wrote:
Op 04.jul.2025 om 14:57 schreef olcott:
On 7/4/2025 2:42 AM, Mikko wrote:
On 2025-07-03 15:17:53 +0000, olcott said:
On 7/3/2025 9:50 AM, Richard Damon wrote:
On 7/3/25 10:39 AM, olcott wrote:
On 7/3/2025 9:16 AM, Richard Damon wrote:Then how do you correctly simulate something you do not have.
On 7/2/25 10:50 PM, olcott wrote:
On 7/1/2025 11:37 AM, Mr Flibble wrote:
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote: >>>>>>>>>>>>
On 6/30/25 2:30 PM, Mr Flibble wrote:
PO just works off the lie that a correct simulation of the input is
different than the direct execution, even though he can't show the
instruction actually correctly simulated where they differ, and thus
proves he is lying.
The closest he comes is claiming that the simulation of the "Call HHH"
must be different when simulated then when executed, as for "some >>>>>>>>>>>>> reason" it must be just because otherwise HHH can't do the simulation.
Sorry, not being able to do something doesn't mean you get to redefine
it,
You ar4e just showing you are as stupid as he is.
No. A simulator does not have to run a simulation to completion if it can
determine that the input, A PROGRAM, never halts.
/Flibble
The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and
DDD does not call HHH1(DDD) in recursive simulation.
Nope. It seems you don't understand what the question actually IS >>>>>>>>>> because you have just lied to yourself so much that you lost the >>>>>>>>>> understanding of the queiston.
*I can't imagine how Mike does not get this*
I can't understand
*Context of above dialogue*
*Context of above dialogue*
*Context of above dialogue*
Context of your context:
A Halt Decider is supposed to decide if the program given to it (via >>>>>>>>>> some correct representation) will halt when run.
Thus, "the input" needs to represent a program
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
}
Which, by itself, isn't a valid input, or program. as HHH is undefined.
Each different definition of HHH, gives a different problem. >>>>>>>>>>
Your "logic" seems to be based on trying to re-define what a program >>>>>>>>>> is, which just makes it a lie.
"Programs" must be complete and self-contained in the field of >>>>>>>>>> computability theory, something you don't seem to understand. >>>>>>>>>>
Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0. (HHH1 has identical code)
But it CAN'T simulate the above input. as it isn't valid.
You need to add the code of HHH to the input to let HHH simulate "the
input" to get anything.
No I do not. The above paragraph has every detail that is needed. >>>>>>>>
Note, your "description" of HHH is just incorrect, as it is also incomplete.
Simulating a LIE just gives you a lie.
And at that point, you have different inputs for different HHHs, and >>>>>>>>>> possibly different behaviors, which you logic forgets to take into >>>>>>>>>> account, which just breaks it.
Wrong.
It is because the what I specified does take this
into account that HHH(DDD)==0 and HHH1(DDD)==1 are correct.
Nope, becausee it violates the DEFINITION of what it means to simulate >>>>>>>> something.
*You don't even know what you mean by this*
What I mean is the execution trace that is derived
within the semantics of the C programming language.
C lanbuage definition does not specifiy the senatics of the non- standard
lanugage extension that your HHH and HHH1 use.
*This is the ONLY specification of HHH that chatbots see*
Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0.
There is no non-termination behaviour to detect, because the input
specifies only a *finite* recursion.
When DDD is infinitely simulated by HHH it never reaches
When DDD is infinitely simulated by HHH that HHH never answers correctly
(or otherwise) and therefore is not a halting decider.
So by a kind of mathematical induction HHH correctly
predicts that DDD simulated by HHH (according to the
semantics of the C programming language) cannot possibly
reach its own simulated "return" statement final halt
state then HHH is correct to reject DDD as non-halting.
On 7/7/2025 3:25 AM, Mikko wrote:
On 2025-07-06 15:00:25 +0000, olcott said:
On 7/6/2025 4:19 AM, Mikko wrote:
On 2025-07-05 15:59:50 +0000, olcott said:
On 7/5/2025 2:30 AM, Fred. Zwarts wrote:
Op 04.jul.2025 om 14:57 schreef olcott:
On 7/4/2025 2:42 AM, Mikko wrote:
On 2025-07-03 15:17:53 +0000, olcott said:
On 7/3/2025 9:50 AM, Richard Damon wrote:
On 7/3/25 10:39 AM, olcott wrote:
On 7/3/2025 9:16 AM, Richard Damon wrote:
On 7/2/25 10:50 PM, olcott wrote:
On 7/1/2025 11:37 AM, Mr Flibble wrote:
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote: >>>>>>>>>>>>>>
On 6/30/25 2:30 PM, Mr Flibble wrote:No. A simulator does not have to run a simulation to >>>>>>>>>>>>>> completion if it can
PO just works off the lie that a correct simulation of >>>>>>>>>>>>>>> the input is
different than the direct execution, even though he can't >>>>>>>>>>>>>>> show the
instruction actually correctly simulated where they >>>>>>>>>>>>>>> differ, and thus
proves he is lying.
The closest he comes is claiming that the simulation of >>>>>>>>>>>>>>> the "Call HHH"
must be different when simulated then when executed, as >>>>>>>>>>>>>>> for "some
reason" it must be just because otherwise HHH can't do >>>>>>>>>>>>>>> the simulation.
Sorry, not being able to do something doesn't mean you >>>>>>>>>>>>>>> get to redefine
it,
You ar4e just showing you are as stupid as he is. >>>>>>>>>>>>>>
determine that the input, A PROGRAM, never halts.
/Flibble
The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and >>>>>>>>>>>>> DDD does not call HHH1(DDD) in recursive simulation.
Nope. It seems you don't understand what the question
actually IS because you have just lied to yourself so much >>>>>>>>>>>> that you lost the understanding of the queiston.
*I can't imagine how Mike does not get this*
I can't understand
*Context of above dialogue*
*Context of above dialogue*
*Context of above dialogue*
Context of your context:
A Halt Decider is supposed to decide if the program given to >>>>>>>>>>>> it (via some correct representation) will halt when run. >>>>>>>>>>>>
Thus, "the input" needs to represent a program
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
}
Which, by itself, isn't a valid input, or program. as HHH is >>>>>>>>>>>> undefined.
Each different definition of HHH, gives a different problem. >>>>>>>>>>>>
Your "logic" seems to be based on trying to re-define what a >>>>>>>>>>>> program is, which just makes it a lie.
"Programs" must be complete and self-contained in the field >>>>>>>>>>>> of computability theory, something you don't seem to
understand.
Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0. (HHH1 has identical code)
But it CAN'T simulate the above input. as it isn't valid. >>>>>>>>>>>>
You need to add the code of HHH to the input to let HHH >>>>>>>>>>>> simulate "the input" to get anything.
No I do not. The above paragraph has every detail that is >>>>>>>>>>> needed.
Then how do you correctly simulate something you do not have. >>>>>>>>>>
Note, your "description" of HHH is just incorrect, as it is >>>>>>>>>> also incomplete.
Simulating a LIE just gives you a lie.
Nope, becausee it violates the DEFINITION of what it means to >>>>>>>>>> simulate something.
And at that point, you have different inputs for different >>>>>>>>>>>> HHHs, and possibly different behaviors, which you logic >>>>>>>>>>>> forgets to take into account, which just breaks it.
Wrong.
It is because the what I specified does take this
into account that HHH(DDD)==0 and HHH1(DDD)==1 are correct. >>>>>>>>>>
*You don't even know what you mean by this*
What I mean is the execution trace that is derived
within the semantics of the C programming language.
C lanbuage definition does not specifiy the senatics of the non- >>>>>>>> standard
lanugage extension that your HHH and HHH1 use.
*This is the ONLY specification of HHH that chatbots see*
Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0.
There is no non-termination behaviour to detect, because the input >>>>>> specifies only a *finite* recursion.
When DDD is infinitely simulated by HHH it never reaches
When DDD is infinitely simulated by HHH that HHH never answers
correctly
(or otherwise) and therefore is not a halting decider.
So by a kind of mathematical induction HHH correctly
predicts that DDD simulated by HHH (according to the
semantics of the C programming language) cannot possibly
reach its own simulated "return" statement final halt
state then HHH is correct to reject DDD as non-halting.
"By a kind of mathematical induction" is not a valid basis for inference.
void DDD()
{
HHH(DDD);
return;
}
DDD simulated by HHH according to the semantics
of the C programming language specifies
HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)...
It is so simple that I really can't believe that
my reviewers are not dishonest when they disagree.
There are very specific induction rules that apply to very specific
types of mathematical objects, for example the induction axiom of Peano
arithmetics.
But you cannot use the above before you have proven that HHH correctly
predicts and after that you needn't.
I just did that 500 times now.
On 7/7/2025 3:25 AM, Mikko wrote:
On 2025-07-06 15:00:25 +0000, olcott said:
On 7/6/2025 4:19 AM, Mikko wrote:
On 2025-07-05 15:59:50 +0000, olcott said:
On 7/5/2025 2:30 AM, Fred. Zwarts wrote:
Op 04.jul.2025 om 14:57 schreef olcott:
On 7/4/2025 2:42 AM, Mikko wrote:
On 2025-07-03 15:17:53 +0000, olcott said:
On 7/3/2025 9:50 AM, Richard Damon wrote:
On 7/3/25 10:39 AM, olcott wrote:
On 7/3/2025 9:16 AM, Richard Damon wrote:Then how do you correctly simulate something you do not have. >>>>>>>>>>
On 7/2/25 10:50 PM, olcott wrote:
On 7/1/2025 11:37 AM, Mr Flibble wrote:
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote: >>>>>>>>>>>>>>
On 6/30/25 2:30 PM, Mr Flibble wrote:No. A simulator does not have to run a simulation to completion if it can
PO just works off the lie that a correct simulation of the input is
different than the direct execution, even though he can't show the
instruction actually correctly simulated where they differ, and thus
proves he is lying.
The closest he comes is claiming that the simulation of the "Call HHH"
must be different when simulated then when executed, as for "some
reason" it must be just because otherwise HHH can't do the simulation.
Sorry, not being able to do something doesn't mean you get to redefine
it,
You ar4e just showing you are as stupid as he is. >>>>>>>>>>>>>>
determine that the input, A PROGRAM, never halts.
/Flibble
The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and >>>>>>>>>>>>> DDD does not call HHH1(DDD) in recursive simulation.
Nope. It seems you don't understand what the question actually IS >>>>>>>>>>>> because you have just lied to yourself so much that you lost the >>>>>>>>>>>> understanding of the queiston.
*I can't imagine how Mike does not get this*
I can't understand
*Context of above dialogue*
*Context of above dialogue*
*Context of above dialogue*
Context of your context:
A Halt Decider is supposed to decide if the program given to it (via
some correct representation) will halt when run.
Thus, "the input" needs to represent a program
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
}
Which, by itself, isn't a valid input, or program. as HHH is undefined.
Each different definition of HHH, gives a different problem. >>>>>>>>>>>>
Your "logic" seems to be based on trying to re-define what a program
is, which just makes it a lie.
"Programs" must be complete and self-contained in the field of >>>>>>>>>>>> computability theory, something you don't seem to understand. >>>>>>>>>>>>
Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0. (HHH1 has identical code)
But it CAN'T simulate the above input. as it isn't valid. >>>>>>>>>>>>
You need to add the code of HHH to the input to let HHH simulate "the
input" to get anything.
No I do not. The above paragraph has every detail that is needed. >>>>>>>>>>
Note, your "description" of HHH is just incorrect, as it is also incomplete.
Simulating a LIE just gives you a lie.
Nope, becausee it violates the DEFINITION of what it means to simulate
And at that point, you have different inputs for different HHHs, and
possibly different behaviors, which you logic forgets to take into >>>>>>>>>>>> account, which just breaks it.
Wrong.
It is because the what I specified does take this
into account that HHH(DDD)==0 and HHH1(DDD)==1 are correct. >>>>>>>>>>
something.
*You don't even know what you mean by this*
What I mean is the execution trace that is derived
within the semantics of the C programming language.
C lanbuage definition does not specifiy the senatics of the non- standard
lanugage extension that your HHH and HHH1 use.
*This is the ONLY specification of HHH that chatbots see*
Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0.
There is no non-termination behaviour to detect, because the input >>>>>> specifies only a *finite* recursion.
When DDD is infinitely simulated by HHH it never reaches
When DDD is infinitely simulated by HHH that HHH never answers correctly >>>> (or otherwise) and therefore is not a halting decider.
So by a kind of mathematical induction HHH correctly
predicts that DDD simulated by HHH (according to the
semantics of the C programming language) cannot possibly
reach its own simulated "return" statement final halt
state then HHH is correct to reject DDD as non-halting.
"By a kind of mathematical induction" is not a valid basis for inference.
void DDD()
{
HHH(DDD);
return;
}
DDD simulated by HHH according to the semantics
of the C programming language specifies
HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)...
On 7/8/2025 2:35 AM, Mikko wrote:
On 2025-07-07 14:02:49 +0000, olcott said:
On 7/7/2025 3:25 AM, Mikko wrote:
On 2025-07-06 15:00:25 +0000, olcott said:void DDD()
On 7/6/2025 4:19 AM, Mikko wrote:
On 2025-07-05 15:59:50 +0000, olcott said:
On 7/5/2025 2:30 AM, Fred. Zwarts wrote:
Op 04.jul.2025 om 14:57 schreef olcott:
On 7/4/2025 2:42 AM, Mikko wrote:
On 2025-07-03 15:17:53 +0000, olcott said:
On 7/3/2025 9:50 AM, Richard Damon wrote:
On 7/3/25 10:39 AM, olcott wrote:
On 7/3/2025 9:16 AM, Richard Damon wrote:Then how do you correctly simulate something you do not have. >>>>>>>>>>>>
On 7/2/25 10:50 PM, olcott wrote:
On 7/1/2025 11:37 AM, Mr Flibble wrote:Nope. It seems you don't understand what the question actually IS
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote: >>>>>>>>>>>>>>>>
On 6/30/25 2:30 PM, Mr Flibble wrote:No. A simulator does not have to run a simulation to completion if it can
PO just works off the lie that a correct simulation of the input is
different than the direct execution, even though he can't show the
instruction actually correctly simulated where they differ, and thus
proves he is lying.
The closest he comes is claiming that the simulation of the "Call HHH"
must be different when simulated then when executed, as for "some
reason" it must be just because otherwise HHH can't do the simulation.
Sorry, not being able to do something doesn't mean you get to redefine
it,
You ar4e just showing you are as stupid as he is. >>>>>>>>>>>>>>>>
determine that the input, A PROGRAM, never halts. >>>>>>>>>>>>>>>>
/Flibble
The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and >>>>>>>>>>>>>>> DDD does not call HHH1(DDD) in recursive simulation. >>>>>>>>>>>>>>
because you have just lied to yourself so much that you lost the >>>>>>>>>>>>>> understanding of the queiston.
*I can't imagine how Mike does not get this*
I can't understand
*Context of above dialogue*
*Context of above dialogue*
*Context of above dialogue*
Context of your context:
A Halt Decider is supposed to decide if the program given to it (via
some correct representation) will halt when run.
Thus, "the input" needs to represent a program
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
}
Which, by itself, isn't a valid input, or program. as HHH is undefined.
Each different definition of HHH, gives a different problem. >>>>>>>>>>>>>>
Your "logic" seems to be based on trying to re-define what a program
is, which just makes it a lie.
"Programs" must be complete and self-contained in the field of >>>>>>>>>>>>>> computability theory, something you don't seem to understand. >>>>>>>>>>>>>>
Termination Analyzer HHH simulates its input until >>>>>>>>>>>>>>> it detects a non-terminating behavior pattern. When >>>>>>>>>>>>>>> HHH detects such a pattern it aborts its simulation >>>>>>>>>>>>>>> and returns 0. (HHH1 has identical code)
But it CAN'T simulate the above input. as it isn't valid. >>>>>>>>>>>>>>
You need to add the code of HHH to the input to let HHH simulate "the
input" to get anything.
No I do not. The above paragraph has every detail that is needed. >>>>>>>>>>>>
Note, your "description" of HHH is just incorrect, as it is also incomplete.
Simulating a LIE just gives you a lie.
Nope, becausee it violates the DEFINITION of what it means to simulate
And at that point, you have different inputs for different HHHs, and
possibly different behaviors, which you logic forgets to take into
account, which just breaks it.
Wrong.
It is because the what I specified does take this
into account that HHH(DDD)==0 and HHH1(DDD)==1 are correct. >>>>>>>>>>>>
something.
*You don't even know what you mean by this*
What I mean is the execution trace that is derived
within the semantics of the C programming language.
C lanbuage definition does not specifiy the senatics of the non- standard
lanugage extension that your HHH and HHH1 use.
*This is the ONLY specification of HHH that chatbots see*
Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0.
There is no non-termination behaviour to detect, because the input >>>>>>>> specifies only a *finite* recursion.
When DDD is infinitely simulated by HHH it never reaches
When DDD is infinitely simulated by HHH that HHH never answers correctly >>>>>> (or otherwise) and therefore is not a halting decider.
So by a kind of mathematical induction HHH correctly
predicts that DDD simulated by HHH (according to the
semantics of the C programming language) cannot possibly
reach its own simulated "return" statement final halt
state then HHH is correct to reject DDD as non-halting.
"By a kind of mathematical induction" is not a valid basis for inference. >>>
{
HHH(DDD);
return;
}
DDD simulated by HHH according to the semantics
of the C programming language specifies
HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)...
Simply reading the code of your HHH shows that that is not what happens.
Your HHH does not simulate that many levels of recorsion.
I was showing the pattern of behavior that HHH recognizes.
On 7/8/2025 2:35 AM, Mikko wrote:
On 2025-07-07 14:02:49 +0000, olcott said:
On 7/7/2025 3:25 AM, Mikko wrote:
On 2025-07-06 15:00:25 +0000, olcott said:
On 7/6/2025 4:19 AM, Mikko wrote:
On 2025-07-05 15:59:50 +0000, olcott said:
On 7/5/2025 2:30 AM, Fred. Zwarts wrote:
Op 04.jul.2025 om 14:57 schreef olcott:
On 7/4/2025 2:42 AM, Mikko wrote:
On 2025-07-03 15:17:53 +0000, olcott said:
On 7/3/2025 9:50 AM, Richard Damon wrote:
On 7/3/25 10:39 AM, olcott wrote:
On 7/3/2025 9:16 AM, Richard Damon wrote:
On 7/2/25 10:50 PM, olcott wrote:
On 7/1/2025 11:37 AM, Mr Flibble wrote:Nope. It seems you don't understand what the question >>>>>>>>>>>>>> actually IS because you have just lied to yourself so much >>>>>>>>>>>>>> that you lost the understanding of the queiston.
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote: >>>>>>>>>>>>>>>>
On 6/30/25 2:30 PM, Mr Flibble wrote:No. A simulator does not have to run a simulation to >>>>>>>>>>>>>>>> completion if it can
PO just works off the lie that a correct simulation of >>>>>>>>>>>>>>>>> the input is
different than the direct execution, even though he >>>>>>>>>>>>>>>>> can't show the
instruction actually correctly simulated where they >>>>>>>>>>>>>>>>> differ, and thus
proves he is lying.
The closest he comes is claiming that the simulation of >>>>>>>>>>>>>>>>> the "Call HHH"
must be different when simulated then when executed, as >>>>>>>>>>>>>>>>> for "some
reason" it must be just because otherwise HHH can't do >>>>>>>>>>>>>>>>> the simulation.
Sorry, not being able to do something doesn't mean you >>>>>>>>>>>>>>>>> get to redefine
it,
You ar4e just showing you are as stupid as he is. >>>>>>>>>>>>>>>>
determine that the input, A PROGRAM, never halts. >>>>>>>>>>>>>>>>
/Flibble
The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct
because DDD calls HHH(DDD) in recursive simulation and >>>>>>>>>>>>>>> DDD does not call HHH1(DDD) in recursive simulation. >>>>>>>>>>>>>>
*I can't imagine how Mike does not get this*
I can't understand
*Context of above dialogue*
*Context of above dialogue*
*Context of above dialogue*
Context of your context:
A Halt Decider is supposed to decide if the program given >>>>>>>>>>>>>> to it (via some correct representation) will halt when run. >>>>>>>>>>>>>>
Thus, "the input" needs to represent a program
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
}
Which, by itself, isn't a valid input, or program. as HHH >>>>>>>>>>>>>> is undefined.
Each different definition of HHH, gives a different problem. >>>>>>>>>>>>>>
Your "logic" seems to be based on trying to re-define what >>>>>>>>>>>>>> a program is, which just makes it a lie.
"Programs" must be complete and self-contained in the >>>>>>>>>>>>>> field of computability theory, something you don't seem to >>>>>>>>>>>>>> understand.
Termination Analyzer HHH simulates its input until >>>>>>>>>>>>>>> it detects a non-terminating behavior pattern. When >>>>>>>>>>>>>>> HHH detects such a pattern it aborts its simulation >>>>>>>>>>>>>>> and returns 0. (HHH1 has identical code)
But it CAN'T simulate the above input. as it isn't valid. >>>>>>>>>>>>>>
You need to add the code of HHH to the input to let HHH >>>>>>>>>>>>>> simulate "the input" to get anything.
No I do not. The above paragraph has every detail that is >>>>>>>>>>>>> needed.
Then how do you correctly simulate something you do not have. >>>>>>>>>>>>
Note, your "description" of HHH is just incorrect, as it is >>>>>>>>>>>> also incomplete.
Simulating a LIE just gives you a lie.
Nope, becausee it violates the DEFINITION of what it means >>>>>>>>>>>> to simulate something.
And at that point, you have different inputs for different >>>>>>>>>>>>>> HHHs, and possibly different behaviors, which you logic >>>>>>>>>>>>>> forgets to take into account, which just breaks it. >>>>>>>>>>>>>>
Wrong.
It is because the what I specified does take this
into account that HHH(DDD)==0 and HHH1(DDD)==1 are correct. >>>>>>>>>>>>
*You don't even know what you mean by this*
What I mean is the execution trace that is derived
within the semantics of the C programming language.
C lanbuage definition does not specifiy the senatics of the >>>>>>>>>> non- standard
lanugage extension that your HHH and HHH1 use.
*This is the ONLY specification of HHH that chatbots see*
Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0.
There is no non-termination behaviour to detect, because the
input specifies only a *finite* recursion.
When DDD is infinitely simulated by HHH it never reaches
When DDD is infinitely simulated by HHH that HHH never answers
correctly
(or otherwise) and therefore is not a halting decider.
So by a kind of mathematical induction HHH correctly
predicts that DDD simulated by HHH (according to the
semantics of the C programming language) cannot possibly
reach its own simulated "return" statement final halt
state then HHH is correct to reject DDD as non-halting.
"By a kind of mathematical induction" is not a valid basis for
inference.
void DDD()
{
HHH(DDD);
return;
}
DDD simulated by HHH according to the semantics
of the C programming language specifies
HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)...
Simply reading the code of your HHH shows that that is not what happens.
Your HHH does not simulate that many levels of recorsion.
I was showing the pattern of behavior that HHH recognizes.
On 7/9/2025 3:32 AM, Mikko wrote:
On 2025-07-08 14:16:13 +0000, olcott said:
On 7/8/2025 2:35 AM, Mikko wrote:
On 2025-07-07 14:02:49 +0000, olcott said:
On 7/7/2025 3:25 AM, Mikko wrote:
On 2025-07-06 15:00:25 +0000, olcott said:
On 7/6/2025 4:19 AM, Mikko wrote:
On 2025-07-05 15:59:50 +0000, olcott said:
On 7/5/2025 2:30 AM, Fred. Zwarts wrote:
Op 04.jul.2025 om 14:57 schreef olcott:
On 7/4/2025 2:42 AM, Mikko wrote:
On 2025-07-03 15:17:53 +0000, olcott said:
On 7/3/2025 9:50 AM, Richard Damon wrote:
On 7/3/25 10:39 AM, olcott wrote:
On 7/3/2025 9:16 AM, Richard Damon wrote:
On 7/2/25 10:50 PM, olcott wrote:
On 7/1/2025 11:37 AM, Mr Flibble wrote:Nope. It seems you don't understand what the question >>>>>>>>>>>>>>>> actually IS because you have just lied to yourself so >>>>>>>>>>>>>>>> much that you lost the understanding of the queiston. >>>>>>>>>>>>>>>>
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote: >>>>>>>>>>>>>>>>>>
On 6/30/25 2:30 PM, Mr Flibble wrote:No. A simulator does not have to run a simulation to >>>>>>>>>>>>>>>>>> completion if it can
PO just works off the lie that a correct simulation >>>>>>>>>>>>>>>>>>> of the input is
different than the direct execution, even though he >>>>>>>>>>>>>>>>>>> can't show the
instruction actually correctly simulated where they >>>>>>>>>>>>>>>>>>> differ, and thus
proves he is lying.
The closest he comes is claiming that the simulation >>>>>>>>>>>>>>>>>>> of the "Call HHH"
must be different when simulated then when executed, >>>>>>>>>>>>>>>>>>> as for "some
reason" it must be just because otherwise HHH can't >>>>>>>>>>>>>>>>>>> do the simulation.
Sorry, not being able to do something doesn't mean >>>>>>>>>>>>>>>>>>> you get to redefine
it,
You ar4e just showing you are as stupid as he is. >>>>>>>>>>>>>>>>>>
determine that the input, A PROGRAM, never halts. >>>>>>>>>>>>>>>>>>
/Flibble
The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct >>>>>>>>>>>>>>>>> because DDD calls HHH(DDD) in recursive simulation and >>>>>>>>>>>>>>>>> DDD does not call HHH1(DDD) in recursive simulation. >>>>>>>>>>>>>>>>
*I can't imagine how Mike does not get this*
I can't understand
*Context of above dialogue*
*Context of above dialogue*
*Context of above dialogue*
Context of your context:
A Halt Decider is supposed to decide if the program >>>>>>>>>>>>>>>> given to it (via some correct representation) will halt >>>>>>>>>>>>>>>> when run.
Thus, "the input" needs to represent a program >>>>>>>>>>>>>>>>
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
}
Which, by itself, isn't a valid input, or program. as >>>>>>>>>>>>>>>> HHH is undefined.
Each different definition of HHH, gives a different >>>>>>>>>>>>>>>> problem.
Your "logic" seems to be based on trying to re-define >>>>>>>>>>>>>>>> what a program is, which just makes it a lie.
"Programs" must be complete and self-contained in the >>>>>>>>>>>>>>>> field of computability theory, something you don't seem >>>>>>>>>>>>>>>> to understand.
Termination Analyzer HHH simulates its input until >>>>>>>>>>>>>>>>> it detects a non-terminating behavior pattern. When >>>>>>>>>>>>>>>>> HHH detects such a pattern it aborts its simulation >>>>>>>>>>>>>>>>> and returns 0. (HHH1 has identical code)
But it CAN'T simulate the above input. as it isn't valid. >>>>>>>>>>>>>>>>
You need to add the code of HHH to the input to let HHH >>>>>>>>>>>>>>>> simulate "the input" to get anything.
No I do not. The above paragraph has every detail that is >>>>>>>>>>>>>>> needed.
Then how do you correctly simulate something you do not have. >>>>>>>>>>>>>>
Note, your "description" of HHH is just incorrect, as it >>>>>>>>>>>>>> is also incomplete.
Simulating a LIE just gives you a lie.
Nope, becausee it violates the DEFINITION of what it means >>>>>>>>>>>>>> to simulate something.
And at that point, you have different inputs for >>>>>>>>>>>>>>>> different HHHs, and possibly different behaviors, which >>>>>>>>>>>>>>>> you logic forgets to take into account, which just >>>>>>>>>>>>>>>> breaks it.
Wrong.
It is because the what I specified does take this >>>>>>>>>>>>>>> into account that HHH(DDD)==0 and HHH1(DDD)==1 are correct. >>>>>>>>>>>>>>
*You don't even know what you mean by this*
What I mean is the execution trace that is derived
within the semantics of the C programming language.
C lanbuage definition does not specifiy the senatics of the >>>>>>>>>>>> non- standard
lanugage extension that your HHH and HHH1 use.
*This is the ONLY specification of HHH that chatbots see* >>>>>>>>>>> Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0.
There is no non-termination behaviour to detect, because the >>>>>>>>>> input specifies only a *finite* recursion.
When DDD is infinitely simulated by HHH it never reaches
When DDD is infinitely simulated by HHH that HHH never answers >>>>>>>> correctly
(or otherwise) and therefore is not a halting decider.
So by a kind of mathematical induction HHH correctly
predicts that DDD simulated by HHH (according to the
semantics of the C programming language) cannot possibly
reach its own simulated "return" statement final halt
state then HHH is correct to reject DDD as non-halting.
"By a kind of mathematical induction" is not a valid basis for
inference.
void DDD()
{
HHH(DDD);
return;
}
DDD simulated by HHH according to the semantics
of the C programming language specifies
HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)...
Simply reading the code of your HHH shows that that is not what
happens.
Your HHH does not simulate that many levels of recorsion.
I was showing the pattern of behavior that HHH recognizes.
As the input to HHH does not match to that pattern
*Here is HHH matching that pattern*
executed HHH simulates DDD that calls emulated HHH(DDD)
that simulates DDD that calls emulated emulated HHH(DDD)
*Here is the 197 page full execution trace of that* https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Line 996 is where it matches the above pattern. https://github.com/plolcott/x86utm/blob/master/Halt7.c
you should say
"hallucinates" instead of "recognizes". Though that does not alter
the end result that HHH gives the wrong answer.
On 7/9/2025 3:32 AM, Mikko wrote:
On 2025-07-08 14:16:13 +0000, olcott said:
On 7/8/2025 2:35 AM, Mikko wrote:
On 2025-07-07 14:02:49 +0000, olcott said:
On 7/7/2025 3:25 AM, Mikko wrote:
On 2025-07-06 15:00:25 +0000, olcott said:
On 7/6/2025 4:19 AM, Mikko wrote:
On 2025-07-05 15:59:50 +0000, olcott said:
On 7/5/2025 2:30 AM, Fred. Zwarts wrote:
Op 04.jul.2025 om 14:57 schreef olcott:
On 7/4/2025 2:42 AM, Mikko wrote:
On 2025-07-03 15:17:53 +0000, olcott said:
On 7/3/2025 9:50 AM, Richard Damon wrote:
On 7/3/25 10:39 AM, olcott wrote:
On 7/3/2025 9:16 AM, Richard Damon wrote:
On 7/2/25 10:50 PM, olcott wrote:
On 7/1/2025 11:37 AM, Mr Flibble wrote:Nope. It seems you don't understand what the question actually IS
On Mon, 30 Jun 2025 21:12:48 -0400, Richard Damon wrote: >>>>>>>>>>>>>>>>>>
On 6/30/25 2:30 PM, Mr Flibble wrote:No. A simulator does not have to run a simulation to completion if it can
PO just works off the lie that a correct simulation of the input is
different than the direct execution, even though he can't show the
instruction actually correctly simulated where they differ, and thus
proves he is lying.
The closest he comes is claiming that the simulation of the "Call HHH"
must be different when simulated then when executed, as for "some
reason" it must be just because otherwise HHH can't do the simulation.
Sorry, not being able to do something doesn't mean you get to redefine
it,
You ar4e just showing you are as stupid as he is. >>>>>>>>>>>>>>>>>>
determine that the input, A PROGRAM, never halts. >>>>>>>>>>>>>>>>>>
/Flibble
The most direct way to analyze this is that
HHH(DDD)==0 and HHH1(DDD)==1 are both correct >>>>>>>>>>>>>>>>> because DDD calls HHH(DDD) in recursive simulation and >>>>>>>>>>>>>>>>> DDD does not call HHH1(DDD) in recursive simulation. >>>>>>>>>>>>>>>>
because you have just lied to yourself so much that you lost the
understanding of the queiston.
*I can't imagine how Mike does not get this*
I can't understand
*Context of above dialogue*
*Context of above dialogue*
*Context of above dialogue*
Context of your context:
A Halt Decider is supposed to decide if the program given to it (via
some correct representation) will halt when run. >>>>>>>>>>>>>>>>
Thus, "the input" needs to represent a program >>>>>>>>>>>>>>>>
typedef void (*ptr)();
int HHH(ptr P);
void DDD()
{
HHH(DDD);
return;
}
int main()
{
HHH(DDD);
}
Which, by itself, isn't a valid input, or program. as HHH is undefined.
Each different definition of HHH, gives a different problem. >>>>>>>>>>>>>>>>
Your "logic" seems to be based on trying to re-define what a program
is, which just makes it a lie.
"Programs" must be complete and self-contained in the field of >>>>>>>>>>>>>>>> computability theory, something you don't seem to understand. >>>>>>>>>>>>>>>>
Termination Analyzer HHH simulates its input until >>>>>>>>>>>>>>>>> it detects a non-terminating behavior pattern. When >>>>>>>>>>>>>>>>> HHH detects such a pattern it aborts its simulation >>>>>>>>>>>>>>>>> and returns 0. (HHH1 has identical code)
But it CAN'T simulate the above input. as it isn't valid. >>>>>>>>>>>>>>>>
You need to add the code of HHH to the input to let HHH simulate "the
input" to get anything.
No I do not. The above paragraph has every detail that is needed.
Then how do you correctly simulate something you do not have. >>>>>>>>>>>>>>
Note, your "description" of HHH is just incorrect, as it is also incomplete.
Simulating a LIE just gives you a lie.
Nope, becausee it violates the DEFINITION of what it means to simulate
And at that point, you have different inputs for different HHHs, and
possibly different behaviors, which you logic forgets to take into
account, which just breaks it.
Wrong.
It is because the what I specified does take this >>>>>>>>>>>>>>> into account that HHH(DDD)==0 and HHH1(DDD)==1 are correct. >>>>>>>>>>>>>>
something.
*You don't even know what you mean by this*
What I mean is the execution trace that is derived
within the semantics of the C programming language.
C lanbuage definition does not specifiy the senatics of the non- standard
lanugage extension that your HHH and HHH1 use.
*This is the ONLY specification of HHH that chatbots see* >>>>>>>>>>> Termination Analyzer HHH simulates its input until
it detects a non-terminating behavior pattern. When
HHH detects such a pattern it aborts its simulation
and returns 0.
There is no non-termination behaviour to detect, because the input >>>>>>>>>> specifies only a *finite* recursion.
When DDD is infinitely simulated by HHH it never reaches
When DDD is infinitely simulated by HHH that HHH never answers correctly
(or otherwise) and therefore is not a halting decider.
So by a kind of mathematical induction HHH correctly
predicts that DDD simulated by HHH (according to the
semantics of the C programming language) cannot possibly
reach its own simulated "return" statement final halt
state then HHH is correct to reject DDD as non-halting.
"By a kind of mathematical induction" is not a valid basis for inference.
void DDD()
{
HHH(DDD);
return;
}
DDD simulated by HHH according to the semantics
of the C programming language specifies
HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)...
Simply reading the code of your HHH shows that that is not what happens. >>>> Your HHH does not simulate that many levels of recorsion.
I was showing the pattern of behavior that HHH recognizes.
As the input to HHH does not match to that pattern
*Here is HHH matching that pattern*
executed HHH simulates DDD that calls emulated HHH(DDD)
that simulates DDD that calls emulated emulated HHH(DDD)
*Here is the 197 page full execution trace of that* https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
On 7/10/2025 4:09 AM, Mikko wrote:
On 2025-07-09 12:45:54 +0000, olcott said:After the non-terminating behavior pattern is matched
*Here is HHH matching that pattern*
executed HHH simulates DDD that calls emulated HHH(DDD)
that simulates DDD that calls emulated emulated HHH(DDD)
*Here is the 197 page full execution trace of that*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
That trace is a little long. Where in that trace is the forth level of
recursive simulation statrted?
on line 996
https://github.com/plolcott/x86utm/blob/master/Halt7.c
HHH rejects DDD as specifying non-halting behavior.
On 7/11/2025 3:15 AM, Mikko wrote:
On 2025-07-10 14:15:31 +0000, olcott said:When you ask an incorrect question, like you did I provide an answer to
On 7/10/2025 4:09 AM, Mikko wrote:
On 2025-07-09 12:45:54 +0000, olcott said:After the non-terminating behavior pattern is matched on line 996
*Here is HHH matching that pattern*
executed HHH simulates DDD that calls emulated HHH(DDD) that
simulates DDD that calls emulated emulated HHH(DDD)
*Here is the 197 page full execution trace of that*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
That trace is a little long. Where in that trace is the forth level
of recursive simulation statrted?
https://github.com/plolcott/x86utm/blob/master/Halt7.c HHH rejects DDD
as specifying non-halting behavior.
This is a good example of what I meant in another comment when I said
that you don't answer questions.
the corrected question.
On 7/11/2025 3:15 AM, Mikko wrote:
On 2025-07-10 14:15:31 +0000, olcott said:
On 7/10/2025 4:09 AM, Mikko wrote:
On 2025-07-09 12:45:54 +0000, olcott said:After the non-terminating behavior pattern is matched
*Here is HHH matching that pattern*
executed HHH simulates DDD that calls emulated HHH(DDD)
that simulates DDD that calls emulated emulated HHH(DDD)
*Here is the 197 page full execution trace of that*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
That trace is a little long. Where in that trace is the forth level of >>>> recursive simulation statrted?
on line 996
https://github.com/plolcott/x86utm/blob/master/Halt7.c
HHH rejects DDD as specifying non-halting behavior.
This is a good example of what I meant in another comment when
I said that you don't answer questions.
When you ask an incorrect question, like you did I provide
an answer to the corrected question.
(1) HHH(DDD) is executed
(2) HHH emulates DDD
(3) Emulated DDD calls an emulated HHH(DDD)
(4) Emulated HHH emulates DDD
(5) this DDD calls HHH(DDD) again
We can know that HHH does emulate itself emulating
DDD because the first instruction of HHH [00001606]
is reached once when invoked in main() (page 38)
and again (page 47) after DDD emulated by HHH calls
HHH(DDD) [000021de] (page 45). This emulated DDD
calls HHH(DDD) On page 187.
DDD emulated by HHH has now met its non halting
behavior pattern on line 996: https://github.com/plolcott/x86utm/blob/master/Halt7.c
On 7/11/2025 10:54 AM, joes wrote:
Am Fri, 11 Jul 2025 10:01:33 -0500 schrieb olcott:
On 7/11/2025 3:15 AM, Mikko wrote:
On 2025-07-10 14:15:31 +0000, olcott said:When you ask an incorrect question, like you did I provide an answer to
On 7/10/2025 4:09 AM, Mikko wrote:
On 2025-07-09 12:45:54 +0000, olcott said:After the non-terminating behavior pattern is matched on line 996
*Here is HHH matching that pattern*
executed HHH simulates DDD that calls emulated HHH(DDD) that
simulates DDD that calls emulated emulated HHH(DDD)
*Here is the 197 page full execution trace of that*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
That trace is a little long. Where in that trace is the forth level >>>>>> of recursive simulation statrted?
https://github.com/plolcott/x86utm/blob/master/Halt7.c HHH rejects DDD >>>>> as specifying non-halting behavior.
This is a good example of what I meant in another comment when I said
that you don't answer questions.
the corrected question.
We know you like to twist words or take them literally, aka constructing
strawmen.
I always take words literally any other way is dishonest.
On 7/11/2025 3:15 AM, Mikko wrote:
On 2025-07-10 14:15:31 +0000, olcott said:
On 7/10/2025 4:09 AM, Mikko wrote:
On 2025-07-09 12:45:54 +0000, olcott said:After the non-terminating behavior pattern is matched
*Here is HHH matching that pattern*
executed HHH simulates DDD that calls emulated HHH(DDD)
that simulates DDD that calls emulated emulated HHH(DDD)
*Here is the 197 page full execution trace of that*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
That trace is a little long. Where in that trace is the forth level of >>>> recursive simulation statrted?
on line 996
https://github.com/plolcott/x86utm/blob/master/Halt7.c
HHH rejects DDD as specifying non-halting behavior.
This is a good example of what I meant in another comment when
I said that you don't answer questions.
When you ask an incorrect question, like you did I provide
an answer to the corrected question.
On 7/11/2025 11:07 AM, dbush wrote:
On 7/11/2025 11:01 AM, olcott wrote:
On 7/11/2025 3:15 AM, Mikko wrote:
On 2025-07-10 14:15:31 +0000, olcott said:
On 7/10/2025 4:09 AM, Mikko wrote:
On 2025-07-09 12:45:54 +0000, olcott said:After the non-terminating behavior pattern is matched
*Here is HHH matching that pattern*
executed HHH simulates DDD that calls emulated HHH(DDD)
that simulates DDD that calls emulated emulated HHH(DDD)
*Here is the 197 page full execution trace of that*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
That trace is a little long. Where in that trace is the forth level of >>>>>> recursive simulation statrted?
on line 996
https://github.com/plolcott/x86utm/blob/master/Halt7.c
HHH rejects DDD as specifying non-halting behavior.
This is a good example of what I meant in another comment when
I said that you don't answer questions.
When you ask an incorrect question, like you did I provide
an answer to the corrected question.
On 7/9/2025 12:06 PM, olcott wrote:
That changes the words of the question thus becomes
the strawman error.
*I do finally have a rebuttal to your other issue*
A Turing Machine halt decider has never been able
to report on the behavior of any directly executed
Turing Machine because anything besides finite
strings are outside of the domain of every TM decider.
On 7/12/2025 3:18 AM, Mikko wrote:
On 2025-07-11 17:32:57 +0000, olcott said:
On 7/11/2025 11:07 AM, dbush wrote:
On 7/11/2025 11:01 AM, olcott wrote:
On 7/11/2025 3:15 AM, Mikko wrote:
On 2025-07-10 14:15:31 +0000, olcott said:
On 7/10/2025 4:09 AM, Mikko wrote:
On 2025-07-09 12:45:54 +0000, olcott said:After the non-terminating behavior pattern is matched
*Here is HHH matching that pattern*
executed HHH simulates DDD that calls emulated HHH(DDD)
that simulates DDD that calls emulated emulated HHH(DDD)
*Here is the 197 page full execution trace of that*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
That trace is a little long. Where in that trace is the forth
level of
recursive simulation statrted?
on line 996
https://github.com/plolcott/x86utm/blob/master/Halt7.c
HHH rejects DDD as specifying non-halting behavior.
This is a good example of what I meant in another comment when
I said that you don't answer questions.
When you ask an incorrect question, like you did I provide
an answer to the corrected question.
On 7/9/2025 12:06 PM, olcott wrote:
That changes the words of the question thus becomes
the strawman error.
*I do finally have a rebuttal to your other issue*
A Turing Machine halt decider has never been able
to report on the behavior of any directly executed
Turing Machine because anything besides finite
strings are outside of the domain of every TM decider.
Mainly because there are no Turing machine halt deciders.
Because the definition of a halt decider requires Turing
machines to report on the behavior of non-inputs.
int sum(int x, int y) {return x + y;}
sum(3,4) reports in the sum of 3+4 it does not
report on the sum of 5+7. To require sum(3,4)
to report on the sum of 5+7 is an incorrect
requirement.
But there
are partial halt deciders that can report correctly on some directly
executed Turing machines but fail to report on others.
No TM has ever reported on the behavior of any
directly executed Turing machine.
They have always reported on the behavior specified
by their input.
On 7/12/2025 3:18 AM, Mikko wrote:
On 2025-07-11 17:32:57 +0000, olcott said:
On 7/11/2025 11:07 AM, dbush wrote:
On 7/11/2025 11:01 AM, olcott wrote:
On 7/11/2025 3:15 AM, Mikko wrote:
On 2025-07-10 14:15:31 +0000, olcott said:
On 7/10/2025 4:09 AM, Mikko wrote:
On 2025-07-09 12:45:54 +0000, olcott said:After the non-terminating behavior pattern is matched
*Here is HHH matching that pattern*
executed HHH simulates DDD that calls emulated HHH(DDD)
that simulates DDD that calls emulated emulated HHH(DDD)
*Here is the 197 page full execution trace of that*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
That trace is a little long. Where in that trace is the forth level of >>>>>>>> recursive simulation statrted?
on line 996
https://github.com/plolcott/x86utm/blob/master/Halt7.c
HHH rejects DDD as specifying non-halting behavior.
This is a good example of what I meant in another comment when
I said that you don't answer questions.
When you ask an incorrect question, like you did I provide
an answer to the corrected question.
On 7/9/2025 12:06 PM, olcott wrote:
That changes the words of the question thus becomes
the strawman error.
*I do finally have a rebuttal to your other issue*
A Turing Machine halt decider has never been able
to report on the behavior of any directly executed
Turing Machine because anything besides finite
strings are outside of the domain of every TM decider.
Mainly because there are no Turing machine halt deciders.
Because the definition of a halt decider requires Turing
machines to report on the behavior of non-inputs.
int sum(int x, int y) {return x + y;}
sum(3,4) reports in the sum of 3+4 it does not
report on the sum of 5+7. To require sum(3,4)
to report on the sum of 5+7 is an incorrect
requirement.
But there
are partial halt deciders that can report correctly on some directly
executed Turing machines but fail to report on others.
No TM has ever reported on the behavior of any
directly executed Turing machine.
They have always reported on the behavior specified
by their input.
On 7/13/2025 1:58 AM, Mikko wrote:
On 2025-07-12 14:48:14 +0000, olcott said:
On 7/12/2025 3:18 AM, Mikko wrote:
On 2025-07-11 17:32:57 +0000, olcott said:
On 7/11/2025 11:07 AM, dbush wrote:
On 7/11/2025 11:01 AM, olcott wrote:
On 7/11/2025 3:15 AM, Mikko wrote:
On 2025-07-10 14:15:31 +0000, olcott said:
On 7/10/2025 4:09 AM, Mikko wrote:
On 2025-07-09 12:45:54 +0000, olcott said:After the non-terminating behavior pattern is matched
*Here is HHH matching that pattern*
executed HHH simulates DDD that calls emulated HHH(DDD)
that simulates DDD that calls emulated emulated HHH(DDD) >>>>>>>>>>>
*Here is the 197 page full execution trace of that*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
That trace is a little long. Where in that trace is the forth >>>>>>>>>> level of
recursive simulation statrted?
on line 996
https://github.com/plolcott/x86utm/blob/master/Halt7.c
HHH rejects DDD as specifying non-halting behavior.
This is a good example of what I meant in another comment when >>>>>>>> I said that you don't answer questions.
When you ask an incorrect question, like you did I provide
an answer to the corrected question.
On 7/9/2025 12:06 PM, olcott wrote:
That changes the words of the question thus becomes
the strawman error.
*I do finally have a rebuttal to your other issue*
A Turing Machine halt decider has never been able
to report on the behavior of any directly executed
Turing Machine because anything besides finite
strings are outside of the domain of every TM decider.
Mainly because there are no Turing machine halt deciders.
Because the definition of a halt decider requires Turing
machines to report on the behavior of non-inputs.
int sum(int x, int y) {return x + y;}
sum(3,4) reports in the sum of 3+4 it does not
report on the sum of 5+7. To require sum(3,4)
to report on the sum of 5+7 is an incorrect
requirement.
But there
are partial halt deciders that can report correctly on some directly
executed Turing machines but fail to report on others.
No TM has ever reported on the behavior of any
directly executed Turing machine.
An universal Turing machin does exacly that. And so does, to a more
limited entent, a partial halt decider. And also a partial termination
analyzer.
This still is not reporting on the direct execution
of the input even though it matches the same behavior.
When the input unconditionally calls the UTM then
neither ever halts.
They have always reported on the behavior specified
by their input.
Which for in cases mentioned above is the behaviour of a directly
executed Turting machine.
Not in the case when the input to the UTM calls this
same UTM and the UTM has been adapted to recognize
this as non-halting criteria to abort its simulation.
On 7/13/2025 3:15 PM, Richard Damon wrote:
On 7/13/25 10:51 AM, olcott wrote:
On 7/13/2025 1:58 AM, Mikko wrote:
On 2025-07-12 14:48:14 +0000, olcott said:
On 7/12/2025 3:18 AM, Mikko wrote:
On 2025-07-11 17:32:57 +0000, olcott said:
On 7/11/2025 11:07 AM, dbush wrote:
On 7/11/2025 11:01 AM, olcott wrote:
On 7/11/2025 3:15 AM, Mikko wrote:
On 2025-07-10 14:15:31 +0000, olcott said:
On 7/10/2025 4:09 AM, Mikko wrote:
On 2025-07-09 12:45:54 +0000, olcott said:After the non-terminating behavior pattern is matched
*Here is HHH matching that pattern*
executed HHH simulates DDD that calls emulated HHH(DDD) >>>>>>>>>>>>> that simulates DDD that calls emulated emulated HHH(DDD) >>>>>>>>>>>>>
*Here is the 197 page full execution trace of that*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
That trace is a little long. Where in that trace is the >>>>>>>>>>>> forth level of
recursive simulation statrted?
on line 996
https://github.com/plolcott/x86utm/blob/master/Halt7.c
HHH rejects DDD as specifying non-halting behavior.
This is a good example of what I meant in another comment when >>>>>>>>>> I said that you don't answer questions.
When you ask an incorrect question, like you did I provide
an answer to the corrected question.
On 7/9/2025 12:06 PM, olcott wrote:
That changes the words of the question thus becomes
the strawman error.
*I do finally have a rebuttal to your other issue*
A Turing Machine halt decider has never been able
to report on the behavior of any directly executed
Turing Machine because anything besides finite
strings are outside of the domain of every TM decider.
Mainly because there are no Turing machine halt deciders.
Because the definition of a halt decider requires Turing
machines to report on the behavior of non-inputs.
int sum(int x, int y) {return x + y;}
sum(3,4) reports in the sum of 3+4 it does not
report on the sum of 5+7. To require sum(3,4)
to report on the sum of 5+7 is an incorrect
requirement.
But there
are partial halt deciders that can report correctly on some directly >>>>>> executed Turing machines but fail to report on others.
No TM has ever reported on the behavior of any
directly executed Turing machine.
An universal Turing machin does exacly that. And so does, to a more
limited entent, a partial halt decider. And also a partial termination >>>> analyzer.
This still is not reporting on the direct execution
of the input even though it matches the same behavior.
When the input unconditionally calls the UTM then
neither ever halts.
So, what is the difference you are trying to talk about.
It took me years to correctly answer that question.
It is only my most recent answer that is correct.
As soon as HHH begins emulating itself emulating DDD
the behavior differs from that of DDD emulated by HHH1
that never begins emulating itself.
And how is that ALLOWED by the DEFINITION of a Halt Decider.
All you are doing is trying to admit and deny at the same time that
you using a Strawman.
Note, DDD doesn't call the "UTM", it calls the HHH Halt Decider.
Yes, a DDD built on calling a UTM will not halt, but the actual DDD
isn't built on calling a UTM, it is calling HHH, so unle4ss you are
specifying that your HHH actually IS a UTM, and thus you are lying
that it aborts its simulation to return 0 (since UTMs can't do that)
your description of the wrong DDD is just irrelevent.
They have always reported on the behavior specified
by their input.
Which for in cases mentioned above is the behaviour of a directly
executed Turting machine.
Not in the case when the input to the UTM calls this
same UTM and the UTM has been adapted to recognize
this as non-halting criteria to abort its simulation.
So, are you saying your HHH *IS* a UTM.
Then you are just admitting everything else you have been saying is a
lie, as if HHH *IS* a UTM, then it NEVER aborts its simulation, and
thus you are lying when you say it does.
Or, are you lying that DDD was built on the actual decider, as
specified in the proof program, and thus you are admitting to lying
that it is that program, and thus lying that it does anything to
refute that proof.
It seems you just admitting that your arguement is just based on lies.
On 7/13/2025 1:58 AM, Mikko wrote:
On 2025-07-12 14:48:14 +0000, olcott said:
On 7/12/2025 3:18 AM, Mikko wrote:
On 2025-07-11 17:32:57 +0000, olcott said:
On 7/11/2025 11:07 AM, dbush wrote:
On 7/11/2025 11:01 AM, olcott wrote:
On 7/11/2025 3:15 AM, Mikko wrote:
On 2025-07-10 14:15:31 +0000, olcott said:
On 7/10/2025 4:09 AM, Mikko wrote:
On 2025-07-09 12:45:54 +0000, olcott said:After the non-terminating behavior pattern is matched
*Here is HHH matching that pattern*
executed HHH simulates DDD that calls emulated HHH(DDD)
that simulates DDD that calls emulated emulated HHH(DDD) >>>>>>>>>>>
*Here is the 197 page full execution trace of that*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
That trace is a little long. Where in that trace is the forth level of
recursive simulation statrted?
on line 996
https://github.com/plolcott/x86utm/blob/master/Halt7.c
HHH rejects DDD as specifying non-halting behavior.
This is a good example of what I meant in another comment when >>>>>>>> I said that you don't answer questions.
When you ask an incorrect question, like you did I provide
an answer to the corrected question.
On 7/9/2025 12:06 PM, olcott wrote:
That changes the words of the question thus becomes
the strawman error.
*I do finally have a rebuttal to your other issue*
A Turing Machine halt decider has never been able
to report on the behavior of any directly executed
Turing Machine because anything besides finite
strings are outside of the domain of every TM decider.
Mainly because there are no Turing machine halt deciders.
Because the definition of a halt decider requires Turing
machines to report on the behavior of non-inputs.
int sum(int x, int y) {return x + y;}
sum(3,4) reports in the sum of 3+4 it does not
report on the sum of 5+7. To require sum(3,4)
to report on the sum of 5+7 is an incorrect
requirement.
But there
are partial halt deciders that can report correctly on some directly
executed Turing machines but fail to report on others.
No TM has ever reported on the behavior of any
directly executed Turing machine.
An universal Turing machin does exacly that. And so does, to a more
limited entent, a partial halt decider. And also a partial termination
analyzer.
This still is not reporting on the direct execution
of the input even though it matches the same behavior.
On 7/13/2025 8:24 PM, Richard Damon wrote:In other words: both HHH and HHH1 execute the same instruction calling
On 7/13/25 5:11 PM, olcott wrote:
On 7/13/2025 3:15 PM, Richard Damon wrote:
On 7/13/25 10:51 AM, olcott wrote:
On 7/13/2025 1:58 AM, Mikko wrote:
On 2025-07-12 14:48:14 +0000, olcott said:
On 7/12/2025 3:18 AM, Mikko wrote:
On 2025-07-11 17:32:57 +0000, olcott said:
On 7/11/2025 11:07 AM, dbush wrote:
On 7/11/2025 11:01 AM, olcott wrote:
On 7/11/2025 3:15 AM, Mikko wrote:
On 2025-07-10 14:15:31 +0000, olcott said:
On 7/10/2025 4:09 AM, Mikko wrote:
On 2025-07-09 12:45:54 +0000, olcott said:After the non-terminating behavior pattern is matched >>>>>>>>>>>>> on line 996
*Here is HHH matching that pattern*
executed HHH simulates DDD that calls emulated HHH(DDD) >>>>>>>>>>>>>>> that simulates DDD that calls emulated emulated HHH(DDD) >>>>>>>>>>>>>>>
*Here is the 197 page full execution trace of that* >>>>>>>>>>>>>>> https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
That trace is a little long. Where in that trace is the >>>>>>>>>>>>>> forth level of
recursive simulation statrted?
https://github.com/plolcott/x86utm/blob/master/Halt7.c >>>>>>>>>>>>> HHH rejects DDD as specifying non-halting behavior.
This is a good example of what I meant in another comment when >>>>>>>>>>>> I said that you don't answer questions.
When you ask an incorrect question, like you did I provide >>>>>>>>>>> an answer to the corrected question.
On 7/9/2025 12:06 PM, olcott wrote:
That changes the words of the question thus becomes
the strawman error.
*I do finally have a rebuttal to your other issue*
A Turing Machine halt decider has never been able
to report on the behavior of any directly executed
Turing Machine because anything besides finite
strings are outside of the domain of every TM decider.
Mainly because there are no Turing machine halt deciders.
Because the definition of a halt decider requires Turing
machines to report on the behavior of non-inputs.
int sum(int x, int y) {return x + y;}
sum(3,4) reports in the sum of 3+4 it does not
report on the sum of 5+7. To require sum(3,4)
to report on the sum of 5+7 is an incorrect
requirement.
But there
are partial halt deciders that can report correctly on some
directly
executed Turing machines but fail to report on others.
No TM has ever reported on the behavior of any
directly executed Turing machine.
An universal Turing machin does exacly that. And so does, to a more >>>>>> limited entent, a partial halt decider. And also a partial
termination
analyzer.
This still is not reporting on the direct execution
of the input even though it matches the same behavior.
When the input unconditionally calls the UTM then
neither ever halts.
So, what is the difference you are trying to talk about.
It took me years to correctly answer that question.
It is only my most recent answer that is correct.
As soon as HHH begins emulating itself emulating DDD
the behavior differs from that of DDD emulated by HHH1
that never begins emulating itself.
So, WHAT INSTRUCTION CORRECTLY EMULATED differed?
Immediately after emulated HHH(DDD)->DDD calls HHH(DDD)
is the first instruction of HHH calling itself.
Immediately after emulated HHH1(DDD)->DDD calls HHH(DDD)
is NOT the first instruction of HHH1 calling itself.
On 7/13/2025 8:24 PM, Richard Damon wrote:
On 7/13/25 5:11 PM, olcott wrote:
On 7/13/2025 3:15 PM, Richard Damon wrote:
On 7/13/25 10:51 AM, olcott wrote:
On 7/13/2025 1:58 AM, Mikko wrote:
On 2025-07-12 14:48:14 +0000, olcott said:
On 7/12/2025 3:18 AM, Mikko wrote:
On 2025-07-11 17:32:57 +0000, olcott said:
On 7/11/2025 11:07 AM, dbush wrote:
On 7/11/2025 11:01 AM, olcott wrote:
On 7/11/2025 3:15 AM, Mikko wrote:
On 2025-07-10 14:15:31 +0000, olcott said:
On 7/10/2025 4:09 AM, Mikko wrote:
On 2025-07-09 12:45:54 +0000, olcott said:After the non-terminating behavior pattern is matched >>>>>>>>>>>>> on line 996
*Here is HHH matching that pattern*
executed HHH simulates DDD that calls emulated HHH(DDD) >>>>>>>>>>>>>>> that simulates DDD that calls emulated emulated HHH(DDD) >>>>>>>>>>>>>>>
*Here is the 197 page full execution trace of that* >>>>>>>>>>>>>>> https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
That trace is a little long. Where in that trace is the >>>>>>>>>>>>>> forth level of
recursive simulation statrted?
https://github.com/plolcott/x86utm/blob/master/Halt7.c >>>>>>>>>>>>> HHH rejects DDD as specifying non-halting behavior.
This is a good example of what I meant in another comment when >>>>>>>>>>>> I said that you don't answer questions.
When you ask an incorrect question, like you did I provide >>>>>>>>>>> an answer to the corrected question.
On 7/9/2025 12:06 PM, olcott wrote:
That changes the words of the question thus becomes
the strawman error.
*I do finally have a rebuttal to your other issue*
A Turing Machine halt decider has never been able
to report on the behavior of any directly executed
Turing Machine because anything besides finite
strings are outside of the domain of every TM decider.
Mainly because there are no Turing machine halt deciders.
Because the definition of a halt decider requires Turing
machines to report on the behavior of non-inputs.
int sum(int x, int y) {return x + y;}
sum(3,4) reports in the sum of 3+4 it does not
report on the sum of 5+7. To require sum(3,4)
to report on the sum of 5+7 is an incorrect
requirement.
But there
are partial halt deciders that can report correctly on some
directly
executed Turing machines but fail to report on others.
No TM has ever reported on the behavior of any
directly executed Turing machine.
An universal Turing machin does exacly that. And so does, to a more >>>>>> limited entent, a partial halt decider. And also a partial
termination
analyzer.
This still is not reporting on the direct execution
of the input even though it matches the same behavior.
When the input unconditionally calls the UTM then
neither ever halts.
So, what is the difference you are trying to talk about.
It took me years to correctly answer that question.
It is only my most recent answer that is correct.
As soon as HHH begins emulating itself emulating DDD
the behavior differs from that of DDD emulated by HHH1
that never begins emulating itself.
So, WHAT INSTRUCTION CORRECTLY EMULATED differed?
Immediately after emulated HHH(DDD)->DDD calls HHH(DDD)
is the first instruction of HHH calling itself.
Immediately after emulated HHH1(DDD)->DDD calls HHH(DDD)
is NOT the first instruction of HHH1 calling itself.
*Claude was able to figure all this out on its own*
The key difference is that HHH1 can complete its simulation
of DDD because the recursive call is to HHH (not HHH1),
so there's no infinite regress in the simulation process itself. https://claude.ai/share/da9b8e3f-eb16-42ca-a9e8-913f4b88202c
My half page of specification is followed by its
single page complete analysis. *Its a quick read*
On 7/14/2025 3:42 AM, Mikko wrote:No. It does not require them to simulate what the input would do if it
On 2025-07-13 14:51:04 +0000, olcott said:
On 7/13/2025 1:58 AM, Mikko wrote:
On 2025-07-12 14:48:14 +0000, olcott said:
On 7/12/2025 3:18 AM, Mikko wrote:
On 2025-07-11 17:32:57 +0000, olcott said:
A Turing Machine halt decider has never been able to report on the >>>>>>> behavior of any directly executed Turing Machine because anything >>>>>>> besides finite strings are outside of the domain of every TMMainly because there are no Turing machine halt deciders.
decider.
Because the definition of a halt decider requires Turing machines to >>>>> report on the behavior of non-inputs.
Then it's not a UTM anymore.Yes, it is. An universal Turing machine tells what will happen if theNot in the case when the input to the UTM calls this same UTM and the
computation is performed, which is what reporting on the direct
execution means.
UTM has been adapted to recognize this as non-halting criteria to abort
its simulation.
On 7/14/2025 6:14 AM, Richard Damon wrote:
On 7/13/25 10:09 PM, olcott wrote:
On 7/13/2025 8:24 PM, Richard Damon wrote:
On 7/13/25 5:11 PM, olcott wrote:
On 7/13/2025 3:15 PM, Richard Damon wrote:
On 7/13/25 10:51 AM, olcott wrote:
On 7/13/2025 1:58 AM, Mikko wrote:
On 2025-07-12 14:48:14 +0000, olcott said:
On 7/12/2025 3:18 AM, Mikko wrote:
On 2025-07-11 17:32:57 +0000, olcott said:
On 7/11/2025 11:07 AM, dbush wrote:
On 7/11/2025 11:01 AM, olcott wrote:
On 7/11/2025 3:15 AM, Mikko wrote:
On 2025-07-10 14:15:31 +0000, olcott said:
On 7/10/2025 4:09 AM, Mikko wrote:This is a good example of what I meant in another comment >>>>>>>>>>>>>> when
On 2025-07-09 12:45:54 +0000, olcott said:After the non-terminating behavior pattern is matched >>>>>>>>>>>>>>> on line 996
That trace is a little long. Where in that trace is the >>>>>>>>>>>>>>>> forth level of
*Here is HHH matching that pattern*
executed HHH simulates DDD that calls emulated HHH(DDD) >>>>>>>>>>>>>>>>> that simulates DDD that calls emulated emulated HHH(DDD) >>>>>>>>>>>>>>>>>
*Here is the 197 page full execution trace of that* >>>>>>>>>>>>>>>>> https://liarparadox.org/HHH(DDD)_Full_Trace.pdf >>>>>>>>>>>>>>>>
recursive simulation statrted?
https://github.com/plolcott/x86utm/blob/master/Halt7.c >>>>>>>>>>>>>>> HHH rejects DDD as specifying non-halting behavior. >>>>>>>>>>>>>>
I said that you don't answer questions.
When you ask an incorrect question, like you did I provide >>>>>>>>>>>>> an answer to the corrected question.
On 7/9/2025 12:06 PM, olcott wrote:
That changes the words of the question thus becomes
the strawman error.
*I do finally have a rebuttal to your other issue*
A Turing Machine halt decider has never been able
to report on the behavior of any directly executed
Turing Machine because anything besides finite
strings are outside of the domain of every TM decider.
Mainly because there are no Turing machine halt deciders.
Because the definition of a halt decider requires Turing
machines to report on the behavior of non-inputs.
int sum(int x, int y) {return x + y;}
sum(3,4) reports in the sum of 3+4 it does not
report on the sum of 5+7. To require sum(3,4)
to report on the sum of 5+7 is an incorrect
requirement.
But there
are partial halt deciders that can report correctly on some >>>>>>>>>> directly
executed Turing machines but fail to report on others.
No TM has ever reported on the behavior of any
directly executed Turing machine.
An universal Turing machin does exacly that. And so does, to a more >>>>>>>> limited entent, a partial halt decider. And also a partial
termination
analyzer.
This still is not reporting on the direct execution
of the input even though it matches the same behavior.
When the input unconditionally calls the UTM then
neither ever halts.
So, what is the difference you are trying to talk about.
It took me years to correctly answer that question.
It is only my most recent answer that is correct.
As soon as HHH begins emulating itself emulating DDD
the behavior differs from that of DDD emulated by HHH1
that never begins emulating itself.
So, WHAT INSTRUCTION CORRECTLY EMULATED differed?
Immediately after emulated HHH(DDD)->DDD calls HHH(DDD)
is the first instruction of HHH calling itself.
So? What was that first instruction in the HHH that DDD called?
Immediately after emulated HHH1(DDD)->DDD calls HHH(DDD)
is NOT the first instruction of HHH1 calling itself.
Irrelevent, it will be the same first instruction in the HHH that DDD
Called.
How an instruction operates depends only on the IMMEDIATE context, the
contents of all the CPU registers.
The is nothing in that context that changes because HHH1 is doing the
emulation rather than HHH.
*Claude was able to figure all this out on its own*
The key difference is that HHH1 can complete its simulation
of DDD because the recursive call is to HHH (not HHH1),
so there's no infinite regress in the simulation process itself.
https://claude.ai/share/da9b8e3f-eb16-42ca-a9e8-913f4b88202c
Becasuee you LIED to it.
My half page of specification is followed by its
single page complete analysis. *Its a quick read*
Rigth, and that specification is a LIE, as it claims that HHH DOES
simulate till if DOES find a non-halting pattern.
That Claude.ai figures out all of the details of exactly
how DDD simulated by HHH specifies non-terminating behavior
seems to prove that you are the liar. With the credentials
that you provided this could not be an honest mistake.
On 7/14/2025 3:42 AM, Mikko wrote:
On 2025-07-13 14:51:04 +0000, olcott said:
On 7/13/2025 1:58 AM, Mikko wrote:
On 2025-07-12 14:48:14 +0000, olcott said:
On 7/12/2025 3:18 AM, Mikko wrote:
On 2025-07-11 17:32:57 +0000, olcott said:
On 7/11/2025 11:07 AM, dbush wrote:
On 7/11/2025 11:01 AM, olcott wrote:
On 7/11/2025 3:15 AM, Mikko wrote:
On 2025-07-10 14:15:31 +0000, olcott said:
On 7/10/2025 4:09 AM, Mikko wrote:
On 2025-07-09 12:45:54 +0000, olcott said:After the non-terminating behavior pattern is matched
*Here is HHH matching that pattern*
executed HHH simulates DDD that calls emulated HHH(DDD) >>>>>>>>>>>>> that simulates DDD that calls emulated emulated HHH(DDD) >>>>>>>>>>>>>
*Here is the 197 page full execution trace of that*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
That trace is a little long. Where in that trace is the forth level of
recursive simulation statrted?
on line 996
https://github.com/plolcott/x86utm/blob/master/Halt7.c
HHH rejects DDD as specifying non-halting behavior.
This is a good example of what I meant in another comment when >>>>>>>>>> I said that you don't answer questions.
When you ask an incorrect question, like you did I provide
an answer to the corrected question.
On 7/9/2025 12:06 PM, olcott wrote:
That changes the words of the question thus becomes
the strawman error.
*I do finally have a rebuttal to your other issue*
A Turing Machine halt decider has never been able
to report on the behavior of any directly executed
Turing Machine because anything besides finite
strings are outside of the domain of every TM decider.
Mainly because there are no Turing machine halt deciders.
Because the definition of a halt decider requires Turing
machines to report on the behavior of non-inputs.
int sum(int x, int y) {return x + y;}
sum(3,4) reports in the sum of 3+4 it does not
report on the sum of 5+7. To require sum(3,4)
to report on the sum of 5+7 is an incorrect
requirement.
But there
are partial halt deciders that can report correctly on some directly >>>>>> executed Turing machines but fail to report on others.
No TM has ever reported on the behavior of any
directly executed Turing machine.
An universal Turing machin does exacly that. And so does, to a more
limited entent, a partial halt decider. And also a partial termination >>>> analyzer.
This still is not reporting on the direct execution
of the input even though it matches the same behavior.
Yes, it is. An universal Turing machine tells what will happen if the
computation is performed, which is what reporting on the direct
execution means.
Not in the case when the input to the UTM calls this
same UTM and the UTM has been adapted to recognize
this as non-halting criteria to abort its simulation.
On 7/14/2025 4:31 AM, Fred. Zwarts wrote:
Op 14.jul.2025 om 04:09 schreef olcott:
On 7/13/2025 8:24 PM, Richard Damon wrote:In other words: both HHH and HHH1 execute the same instruction calling
On 7/13/25 5:11 PM, olcott wrote:
On 7/13/2025 3:15 PM, Richard Damon wrote:
On 7/13/25 10:51 AM, olcott wrote:
On 7/13/2025 1:58 AM, Mikko wrote:
On 2025-07-12 14:48:14 +0000, olcott said:
On 7/12/2025 3:18 AM, Mikko wrote:
On 2025-07-11 17:32:57 +0000, olcott said:
On 7/11/2025 11:07 AM, dbush wrote:
On 7/11/2025 11:01 AM, olcott wrote:
On 7/11/2025 3:15 AM, Mikko wrote:
On 2025-07-10 14:15:31 +0000, olcott said:
On 7/10/2025 4:09 AM, Mikko wrote:This is a good example of what I meant in another comment >>>>>>>>>>>>>> when
On 2025-07-09 12:45:54 +0000, olcott said:After the non-terminating behavior pattern is matched >>>>>>>>>>>>>>> on line 996
That trace is a little long. Where in that trace is the >>>>>>>>>>>>>>>> forth level of
*Here is HHH matching that pattern*
executed HHH simulates DDD that calls emulated HHH(DDD) >>>>>>>>>>>>>>>>> that simulates DDD that calls emulated emulated HHH(DDD) >>>>>>>>>>>>>>>>>
*Here is the 197 page full execution trace of that* >>>>>>>>>>>>>>>>> https://liarparadox.org/HHH(DDD)_Full_Trace.pdf >>>>>>>>>>>>>>>>
recursive simulation statrted?
https://github.com/plolcott/x86utm/blob/master/Halt7.c >>>>>>>>>>>>>>> HHH rejects DDD as specifying non-halting behavior. >>>>>>>>>>>>>>
I said that you don't answer questions.
When you ask an incorrect question, like you did I provide >>>>>>>>>>>>> an answer to the corrected question.
On 7/9/2025 12:06 PM, olcott wrote:
That changes the words of the question thus becomes
the strawman error.
*I do finally have a rebuttal to your other issue*
A Turing Machine halt decider has never been able
to report on the behavior of any directly executed
Turing Machine because anything besides finite
strings are outside of the domain of every TM decider.
Mainly because there are no Turing machine halt deciders.
Because the definition of a halt decider requires Turing
machines to report on the behavior of non-inputs.
int sum(int x, int y) {return x + y;}
sum(3,4) reports in the sum of 3+4 it does not
report on the sum of 5+7. To require sum(3,4)
to report on the sum of 5+7 is an incorrect
requirement.
But there
are partial halt deciders that can report correctly on some >>>>>>>>>> directly
executed Turing machines but fail to report on others.
No TM has ever reported on the behavior of any
directly executed Turing machine.
An universal Turing machin does exacly that. And so does, to a more >>>>>>>> limited entent, a partial halt decider. And also a partial
termination
analyzer.
This still is not reporting on the direct execution
of the input even though it matches the same behavior.
When the input unconditionally calls the UTM then
neither ever halts.
So, what is the difference you are trying to talk about.
It took me years to correctly answer that question.
It is only my most recent answer that is correct.
As soon as HHH begins emulating itself emulating DDD
the behavior differs from that of DDD emulated by HHH1
that never begins emulating itself.
So, WHAT INSTRUCTION CORRECTLY EMULATED differed?
Immediately after emulated HHH(DDD)->DDD calls HHH(DDD)
is the first instruction of HHH calling itself.
Immediately after emulated HHH1(DDD)->DDD calls HHH(DDD)
is NOT the first instruction of HHH1 calling itself.
HHH, so there is no difference.
The difference is that the call from
HHH(DDD)->DDD->HHH(DDD) calls itself causing
recursive emulation
HHH1(DDD)->DDD->HHH(DDD) does not call itself
thus does not cause recursive emulation
On 7/14/2025 10:05 PM, Richard Damon wrote:And then simulation cannot decide anything, because it does not see the
On 7/14/25 11:26 AM, olcott wrote:I never admitted that and my current views
On 7/14/2025 6:14 AM, Richard Damon wrote:
On 7/13/25 10:09 PM, olcott wrote:
On 7/13/2025 8:24 PM, Richard Damon wrote:
On 7/13/25 5:11 PM, olcott wrote:
On 7/13/2025 3:15 PM, Richard Damon wrote:
On 7/13/25 10:51 AM, olcott wrote:
On 7/13/2025 1:58 AM, Mikko wrote:
On 2025-07-12 14:48:14 +0000, olcott said:
On 7/12/2025 3:18 AM, Mikko wrote:
On 2025-07-11 17:32:57 +0000, olcott said:Because the definition of a halt decider requires Turing >>>>>>>>>>> machines to report on the behavior of non-inputs.
On 7/11/2025 11:07 AM, dbush wrote:Mainly because there are no Turing machine halt deciders. >>>>>>>>>>>
On 7/11/2025 11:01 AM, olcott wrote:
On 7/11/2025 3:15 AM, Mikko wrote:
On 2025-07-10 14:15:31 +0000, olcott said:
On 7/10/2025 4:09 AM, Mikko wrote:This is a good example of what I meant in another >>>>>>>>>>>>>>>> comment when
On 2025-07-09 12:45:54 +0000, olcott said: >>>>>>>>>>>>>>>>>>After the non-terminating behavior pattern is matched >>>>>>>>>>>>>>>>> on line 996
That trace is a little long. Where in that trace is >>>>>>>>>>>>>>>>>> the forth level of
*Here is HHH matching that pattern*
executed HHH simulates DDD that calls emulated HHH(DDD) >>>>>>>>>>>>>>>>>>> that simulates DDD that calls emulated emulated HHH(DDD) >>>>>>>>>>>>>>>>>>>
*Here is the 197 page full execution trace of that* >>>>>>>>>>>>>>>>>>> https://liarparadox.org/HHH(DDD)_Full_Trace.pdf >>>>>>>>>>>>>>>>>>
recursive simulation statrted?
https://github.com/plolcott/x86utm/blob/master/Halt7.c >>>>>>>>>>>>>>>>> HHH rejects DDD as specifying non-halting behavior. >>>>>>>>>>>>>>>>
I said that you don't answer questions.
When you ask an incorrect question, like you did I provide >>>>>>>>>>>>>>> an answer to the corrected question.
On 7/9/2025 12:06 PM, olcott wrote:
That changes the words of the question thus becomes >>>>>>>>>>>>>>> the strawman error.
*I do finally have a rebuttal to your other issue*
A Turing Machine halt decider has never been able
to report on the behavior of any directly executed
Turing Machine because anything besides finite
strings are outside of the domain of every TM decider. >>>>>>>>>>>>
int sum(int x, int y) {return x + y;}
sum(3,4) reports in the sum of 3+4 it does not
report on the sum of 5+7. To require sum(3,4)
to report on the sum of 5+7 is an incorrect
requirement.
But there
are partial halt deciders that can report correctly on some >>>>>>>>>>>> directly
executed Turing machines but fail to report on others.
No TM has ever reported on the behavior of any
directly executed Turing machine.
An universal Turing machin does exacly that. And so does, to a >>>>>>>>>> more
limited entent, a partial halt decider. And also a partial >>>>>>>>>> termination
analyzer.
This still is not reporting on the direct execution
of the input even though it matches the same behavior.
When the input unconditionally calls the UTM then
neither ever halts.
So, what is the difference you are trying to talk about.
It took me years to correctly answer that question.
It is only my most recent answer that is correct.
As soon as HHH begins emulating itself emulating DDD
the behavior differs from that of DDD emulated by HHH1
that never begins emulating itself.
So, WHAT INSTRUCTION CORRECTLY EMULATED differed?
Immediately after emulated HHH(DDD)->DDD calls HHH(DDD)
is the first instruction of HHH calling itself.
So? What was that first instruction in the HHH that DDD called?
Immediately after emulated HHH1(DDD)->DDD calls HHH(DDD)
is NOT the first instruction of HHH1 calling itself.
Irrelevent, it will be the same first instruction in the HHH that
DDD Called.
How an instruction operates depends only on the IMMEDIATE context,
the contents of all the CPU registers.
The is nothing in that context that changes because HHH1 is doing
the emulation rather than HHH.
*Claude was able to figure all this out on its own*
The key difference is that HHH1 can complete its simulation
of DDD because the recursive call is to HHH (not HHH1),
so there's no infinite regress in the simulation process itself. >>>>> https://claude.ai/share/da9b8e3f-eb16-42ca-a9e8-913f4b88202c
Becasuee you LIED to it.
My half page of specification is followed by its
single page complete analysis. *Its a quick read*
Rigth, and that specification is a LIE, as it claims that HHH DOES
simulate till if DOES find a non-halting pattern.
That Claude.ai figures out all of the details of exactly
how DDD simulated by HHH specifies non-terminating behavior
seems to prove that you are the liar. With the credentials
that you provided this could not be an honest mistake.
That it build on your LIE just shows how stupid you both are.
Note, you are ADMITTED your system is a lie,
supersede and replace all of my prior views.
When one or more instructions of DDD are emulated
according to the semantics of the x86 language by
some HHH, no DDD ever reaches its "ret" instruction.
On 7/14/2025 8:37 AM, joes wrote:
Am Mon, 14 Jul 2025 07:59:36 -0500 schrieb olcott:
On 7/14/2025 3:42 AM, Mikko wrote:No. It does not require them to simulate what the input would do if it
On 2025-07-13 14:51:04 +0000, olcott said:
On 7/13/2025 1:58 AM, Mikko wrote:
On 2025-07-12 14:48:14 +0000, olcott said:
On 7/12/2025 3:18 AM, Mikko wrote:
On 2025-07-11 17:32:57 +0000, olcott said:
A Turing Machine halt decider has never been able to report on the >>>>>>>>> behavior of any directly executed Turing Machine because anything >>>>>>>>> besides finite strings are outside of the domain of every TM >>>>>>>>> decider.Mainly because there are no Turing machine halt deciders.
Because the definition of a halt decider requires Turing machines to >>>>>>> report on the behavior of non-inputs.
called a UTM.
Yes, it is. An universal Turing machine tells what will happen if theNot in the case when the input to the UTM calls this same UTM and the
computation is performed, which is what reporting on the direct
execution means.
UTM has been adapted to recognize this as non-halting criteria to abort
its simulation.
Then it's not a UTM anymore.
It <is> a UTM with the extra feature that it cannot
be tricked into infinite simulation.
On 7/14/2025 3:42 AM, Mikko wrote:
On 2025-07-13 14:51:04 +0000, olcott said:
On 7/13/2025 1:58 AM, Mikko wrote:
On 2025-07-12 14:48:14 +0000, olcott said:
On 7/12/2025 3:18 AM, Mikko wrote:
On 2025-07-11 17:32:57 +0000, olcott said:
On 7/11/2025 11:07 AM, dbush wrote:
On 7/11/2025 11:01 AM, olcott wrote:
On 7/11/2025 3:15 AM, Mikko wrote:
On 2025-07-10 14:15:31 +0000, olcott said:
On 7/10/2025 4:09 AM, Mikko wrote:
On 2025-07-09 12:45:54 +0000, olcott said:After the non-terminating behavior pattern is matched
*Here is HHH matching that pattern*
executed HHH simulates DDD that calls emulated HHH(DDD) >>>>>>>>>>>>> that simulates DDD that calls emulated emulated HHH(DDD) >>>>>>>>>>>>>
*Here is the 197 page full execution trace of that*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
That trace is a little long. Where in that trace is the >>>>>>>>>>>> forth level of
recursive simulation statrted?
on line 996
https://github.com/plolcott/x86utm/blob/master/Halt7.c
HHH rejects DDD as specifying non-halting behavior.
This is a good example of what I meant in another comment when >>>>>>>>>> I said that you don't answer questions.
When you ask an incorrect question, like you did I provide
an answer to the corrected question.
On 7/9/2025 12:06 PM, olcott wrote:
That changes the words of the question thus becomes
the strawman error.
*I do finally have a rebuttal to your other issue*
A Turing Machine halt decider has never been able
to report on the behavior of any directly executed
Turing Machine because anything besides finite
strings are outside of the domain of every TM decider.
Mainly because there are no Turing machine halt deciders.
Because the definition of a halt decider requires Turing
machines to report on the behavior of non-inputs.
int sum(int x, int y) {return x + y;}
sum(3,4) reports in the sum of 3+4 it does not
report on the sum of 5+7. To require sum(3,4)
to report on the sum of 5+7 is an incorrect
requirement.
But there
are partial halt deciders that can report correctly on some directly >>>>>> executed Turing machines but fail to report on others.
No TM has ever reported on the behavior of any
directly executed Turing machine.
An universal Turing machin does exacly that. And so does, to a more
limited entent, a partial halt decider. And also a partial termination >>>> analyzer.
This still is not reporting on the direct execution
of the input even though it matches the same behavior.
Yes, it is. An universal Turing machine tells what will happen if the
computation is performed, which is what reporting on the direct
execution means.
Not in the case when the input to the UTM calls this
same UTM and the UTM has been adapted to recognize
this as non-halting criteria to abort its simulation.
On 7/14/2025 10:05 PM, Richard Damon wrote:
On 7/14/25 11:26 AM, olcott wrote:I never admitted that and my current views
On 7/14/2025 6:14 AM, Richard Damon wrote:
On 7/13/25 10:09 PM, olcott wrote:
On 7/13/2025 8:24 PM, Richard Damon wrote:
On 7/13/25 5:11 PM, olcott wrote:
On 7/13/2025 3:15 PM, Richard Damon wrote:
On 7/13/25 10:51 AM, olcott wrote:
On 7/13/2025 1:58 AM, Mikko wrote:
On 2025-07-12 14:48:14 +0000, olcott said:
On 7/12/2025 3:18 AM, Mikko wrote:
On 2025-07-11 17:32:57 +0000, olcott said:Because the definition of a halt decider requires Turing >>>>>>>>>>> machines to report on the behavior of non-inputs.
On 7/11/2025 11:07 AM, dbush wrote:Mainly because there are no Turing machine halt deciders. >>>>>>>>>>>
On 7/11/2025 11:01 AM, olcott wrote:
On 7/11/2025 3:15 AM, Mikko wrote:
On 2025-07-10 14:15:31 +0000, olcott said:
On 7/10/2025 4:09 AM, Mikko wrote:This is a good example of what I meant in another >>>>>>>>>>>>>>>> comment when
On 2025-07-09 12:45:54 +0000, olcott said: >>>>>>>>>>>>>>>>>>After the non-terminating behavior pattern is matched >>>>>>>>>>>>>>>>> on line 996
That trace is a little long. Where in that trace is >>>>>>>>>>>>>>>>>> the forth level of
*Here is HHH matching that pattern*
executed HHH simulates DDD that calls emulated HHH(DDD) >>>>>>>>>>>>>>>>>>> that simulates DDD that calls emulated emulated HHH(DDD) >>>>>>>>>>>>>>>>>>>
*Here is the 197 page full execution trace of that* >>>>>>>>>>>>>>>>>>> https://liarparadox.org/HHH(DDD)_Full_Trace.pdf >>>>>>>>>>>>>>>>>>
recursive simulation statrted?
https://github.com/plolcott/x86utm/blob/master/Halt7.c >>>>>>>>>>>>>>>>> HHH rejects DDD as specifying non-halting behavior. >>>>>>>>>>>>>>>>
I said that you don't answer questions.
When you ask an incorrect question, like you did I provide >>>>>>>>>>>>>>> an answer to the corrected question.
On 7/9/2025 12:06 PM, olcott wrote:
That changes the words of the question thus becomes >>>>>>>>>>>>>>> the strawman error.
*I do finally have a rebuttal to your other issue*
A Turing Machine halt decider has never been able
to report on the behavior of any directly executed
Turing Machine because anything besides finite
strings are outside of the domain of every TM decider. >>>>>>>>>>>>
int sum(int x, int y) {return x + y;}
sum(3,4) reports in the sum of 3+4 it does not
report on the sum of 5+7. To require sum(3,4)
to report on the sum of 5+7 is an incorrect
requirement.
But there
are partial halt deciders that can report correctly on some >>>>>>>>>>>> directly
executed Turing machines but fail to report on others.
No TM has ever reported on the behavior of any
directly executed Turing machine.
An universal Turing machin does exacly that. And so does, to a >>>>>>>>>> more
limited entent, a partial halt decider. And also a partial >>>>>>>>>> termination
analyzer.
This still is not reporting on the direct execution
of the input even though it matches the same behavior.
When the input unconditionally calls the UTM then
neither ever halts.
So, what is the difference you are trying to talk about.
It took me years to correctly answer that question.
It is only my most recent answer that is correct.
As soon as HHH begins emulating itself emulating DDD
the behavior differs from that of DDD emulated by HHH1
that never begins emulating itself.
So, WHAT INSTRUCTION CORRECTLY EMULATED differed?
Immediately after emulated HHH(DDD)->DDD calls HHH(DDD)
is the first instruction of HHH calling itself.
So? What was that first instruction in the HHH that DDD called?
Immediately after emulated HHH1(DDD)->DDD calls HHH(DDD)
is NOT the first instruction of HHH1 calling itself.
Irrelevent, it will be the same first instruction in the HHH that
DDD Called.
How an instruction operates depends only on the IMMEDIATE context,
the contents of all the CPU registers.
The is nothing in that context that changes because HHH1 is doing
the emulation rather than HHH.
*Claude was able to figure all this out on its own*
The key difference is that HHH1 can complete its simulation
of DDD because the recursive call is to HHH (not HHH1),
so there's no infinite regress in the simulation process itself. >>>>> https://claude.ai/share/da9b8e3f-eb16-42ca-a9e8-913f4b88202c
Becasuee you LIED to it.
My half page of specification is followed by its
single page complete analysis. *Its a quick read*
Rigth, and that specification is a LIE, as it claims that HHH DOES
simulate till if DOES find a non-halting pattern.
That Claude.ai figures out all of the details of exactly
how DDD simulated by HHH specifies non-terminating behavior
seems to prove that you are the liar. With the credentials
that you provided this could not be an honest mistake.
That it build on your LIE just shows how stupid you both are.
Note, you are ADMITTED your system is a lie,
supersede and replace all of my prior views.
When one or more instructions of DDD are emulated
according to the semantics of the x86 language by
some HHH, no DDD ever reaches its "ret" instruction.
On 7/15/2025 6:27 AM, Richard Damon wrote:
On 7/14/25 11:11 PM, olcott wrote:If the emulation of 0 to ∞ steps of DDD by some HHH
On 7/14/2025 10:05 PM, Richard Damon wrote:
On 7/14/25 11:26 AM, olcott wrote:I never admitted that and my current views
On 7/14/2025 6:14 AM, Richard Damon wrote:
On 7/13/25 10:09 PM, olcott wrote:
On 7/13/2025 8:24 PM, Richard Damon wrote:
On 7/13/25 5:11 PM, olcott wrote:
On 7/13/2025 3:15 PM, Richard Damon wrote:
On 7/13/25 10:51 AM, olcott wrote:
On 7/13/2025 1:58 AM, Mikko wrote:
On 2025-07-12 14:48:14 +0000, olcott said:
On 7/12/2025 3:18 AM, Mikko wrote:
On 2025-07-11 17:32:57 +0000, olcott said:Because the definition of a halt decider requires Turing >>>>>>>>>>>>> machines to report on the behavior of non-inputs.
On 7/11/2025 11:07 AM, dbush wrote:Mainly because there are no Turing machine halt deciders. >>>>>>>>>>>>>
On 7/11/2025 11:01 AM, olcott wrote:
On 7/11/2025 3:15 AM, Mikko wrote:
On 2025-07-10 14:15:31 +0000, olcott said: >>>>>>>>>>>>>>>>>>
On 7/10/2025 4:09 AM, Mikko wrote:This is a good example of what I meant in another >>>>>>>>>>>>>>>>>> comment when
On 2025-07-09 12:45:54 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>After the non-terminating behavior pattern is matched >>>>>>>>>>>>>>>>>>> on line 996
That trace is a little long. Where in that trace is >>>>>>>>>>>>>>>>>>>> the forth level of
*Here is HHH matching that pattern*
executed HHH simulates DDD that calls emulated >>>>>>>>>>>>>>>>>>>>> HHH(DDD)
that simulates DDD that calls emulated emulated >>>>>>>>>>>>>>>>>>>>> HHH(DDD)
*Here is the 197 page full execution trace of that* >>>>>>>>>>>>>>>>>>>>> https://liarparadox.org/HHH(DDD)_Full_Trace.pdf >>>>>>>>>>>>>>>>>>>>
recursive simulation statrted?
https://github.com/plolcott/x86utm/blob/master/Halt7.c >>>>>>>>>>>>>>>>>>> HHH rejects DDD as specifying non-halting behavior. >>>>>>>>>>>>>>>>>>
I said that you don't answer questions.
When you ask an incorrect question, like you did I provide >>>>>>>>>>>>>>>>> an answer to the corrected question.
On 7/9/2025 12:06 PM, olcott wrote:
That changes the words of the question thus becomes >>>>>>>>>>>>>>>>> the strawman error.
*I do finally have a rebuttal to your other issue* >>>>>>>>>>>>>>> A Turing Machine halt decider has never been able >>>>>>>>>>>>>>> to report on the behavior of any directly executed >>>>>>>>>>>>>>> Turing Machine because anything besides finite
strings are outside of the domain of every TM decider. >>>>>>>>>>>>>>
int sum(int x, int y) {return x + y;}
sum(3,4) reports in the sum of 3+4 it does not
report on the sum of 5+7. To require sum(3,4)
to report on the sum of 5+7 is an incorrect
requirement.
But thereNo TM has ever reported on the behavior of any
are partial halt deciders that can report correctly on >>>>>>>>>>>>>> some directly
executed Turing machines but fail to report on others. >>>>>>>>>>>>>
directly executed Turing machine.
An universal Turing machin does exacly that. And so does, to >>>>>>>>>>>> a more
limited entent, a partial halt decider. And also a partial >>>>>>>>>>>> termination
analyzer.
This still is not reporting on the direct execution
of the input even though it matches the same behavior.
When the input unconditionally calls the UTM then
neither ever halts.
So, what is the difference you are trying to talk about.
It took me years to correctly answer that question.
It is only my most recent answer that is correct.
As soon as HHH begins emulating itself emulating DDD
the behavior differs from that of DDD emulated by HHH1
that never begins emulating itself.
So, WHAT INSTRUCTION CORRECTLY EMULATED differed?
Immediately after emulated HHH(DDD)->DDD calls HHH(DDD)
is the first instruction of HHH calling itself.
So? What was that first instruction in the HHH that DDD called?
Immediately after emulated HHH1(DDD)->DDD calls HHH(DDD)
is NOT the first instruction of HHH1 calling itself.
Irrelevent, it will be the same first instruction in the HHH that
DDD Called.
How an instruction operates depends only on the IMMEDIATE context, >>>>>> the contents of all the CPU registers.
The is nothing in that context that changes because HHH1 is doing
the emulation rather than HHH.
*Claude was able to figure all this out on its own*
The key difference is that HHH1 can complete its simulation >>>>>>> of DDD because the recursive call is to HHH (not HHH1),
so there's no infinite regress in the simulation process itself. >>>>>>> https://claude.ai/share/da9b8e3f-eb16-42ca-a9e8-913f4b88202c
Becasuee you LIED to it.
My half page of specification is followed by its
single page complete analysis. *Its a quick read*
Rigth, and that specification is a LIE, as it claims that HHH DOES >>>>>> simulate till if DOES find a non-halting pattern.
That Claude.ai figures out all of the details of exactly
how DDD simulated by HHH specifies non-terminating behavior
seems to prove that you are the liar. With the credentials
that you provided this could not be an honest mistake.
That it build on your LIE just shows how stupid you both are.
Note, you are ADMITTED your system is a lie,
supersede and replace all of my prior views.
When one or more instructions of DDD are emulated
according to the semantics of the x86 language by
some HHH, no DDD ever reaches its "ret" instruction.
Which is just more of your inane drivel. It doesn't matter that a
PARTIAL emulation never reaches an end, only that a COMPLETE emulation
never reaches an end,
cannot possibly reach the final state of DDD then
the input to HHH(DDD) definitely specifies non halting
behavior.
Lines 996 through 1006
https://github.com/plolcott/x86utm/blob/master/Halt7.c
detect that.
That you are simply not bright enough to see that
DDD correctly simulated by HHH matches a non-halting
behavior pattern this is less than no rebuttal at all.
On 7/15/2025 4:22 AM, Mikko wrote:
On 2025-07-14 12:59:36 +0000, olcott said:
On 7/14/2025 3:42 AM, Mikko wrote:
On 2025-07-13 14:51:04 +0000, olcott said:
On 7/13/2025 1:58 AM, Mikko wrote:
On 2025-07-12 14:48:14 +0000, olcott said:
On 7/12/2025 3:18 AM, Mikko wrote:
On 2025-07-11 17:32:57 +0000, olcott said:
On 7/11/2025 11:07 AM, dbush wrote:
On 7/11/2025 11:01 AM, olcott wrote:
On 7/11/2025 3:15 AM, Mikko wrote:
On 2025-07-10 14:15:31 +0000, olcott said:
On 7/10/2025 4:09 AM, Mikko wrote:
On 2025-07-09 12:45:54 +0000, olcott said:After the non-terminating behavior pattern is matched >>>>>>>>>>>>> on line 996
*Here is HHH matching that pattern*
executed HHH simulates DDD that calls emulated HHH(DDD) >>>>>>>>>>>>>>> that simulates DDD that calls emulated emulated HHH(DDD) >>>>>>>>>>>>>>>
*Here is the 197 page full execution trace of that* >>>>>>>>>>>>>>> https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
That trace is a little long. Where in that trace is the >>>>>>>>>>>>>> forth level of
recursive simulation statrted?
https://github.com/plolcott/x86utm/blob/master/Halt7.c >>>>>>>>>>>>> HHH rejects DDD as specifying non-halting behavior.
This is a good example of what I meant in another comment when >>>>>>>>>>>> I said that you don't answer questions.
When you ask an incorrect question, like you did I provide >>>>>>>>>>> an answer to the corrected question.
On 7/9/2025 12:06 PM, olcott wrote:
That changes the words of the question thus becomes
the strawman error.
*I do finally have a rebuttal to your other issue*
A Turing Machine halt decider has never been able
to report on the behavior of any directly executed
Turing Machine because anything besides finite
strings are outside of the domain of every TM decider.
Mainly because there are no Turing machine halt deciders.
Because the definition of a halt decider requires Turing
machines to report on the behavior of non-inputs.
int sum(int x, int y) {return x + y;}
sum(3,4) reports in the sum of 3+4 it does not
report on the sum of 5+7. To require sum(3,4)
to report on the sum of 5+7 is an incorrect
requirement.
But there
are partial halt deciders that can report correctly on some
directly
executed Turing machines but fail to report on others.
No TM has ever reported on the behavior of any
directly executed Turing machine.
An universal Turing machin does exacly that. And so does, to a more >>>>>> limited entent, a partial halt decider. And also a partial
termination
analyzer.
This still is not reporting on the direct execution
of the input even though it matches the same behavior.
Yes, it is. An universal Turing machine tells what will happen if the
computation is performed, which is what reporting on the direct
execution means.
Not in the case when the input to the UTM calls this
same UTM and the UTM has been adapted to recognize
this as non-halting criteria to abort its simulation.
An input does not call. A Turing machine is not called.
Professor Sipser would disagree.
"Now we construct a new Turing machine D with H as a
subroutine. This new TM calls H to determine what M
does when the input to M is its own description" https://www.liarparadox.org/Sipser_165_167.pdf
In any case a transition to its own internal state
of Ĥ.embedded_H is equivalent to a function call.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
its simulated final halt state of ⟨Ĥ.qn⟩, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly
reach its simulated final halt state of ⟨Ĥ.qn⟩.
As usual claims without evidence.In eny case, if the direct execution of a computation halts its UTM
simjlation also halts ahd the state and tapecontent after the direct
execution are as reported by the UTM. If the direct execution does
not halt then the UTM simulation does not halt either.
TM deciders can only report on the behavior specified
by their finite string inputs. This is a huge error
with all of the proofs.
On 7/15/2025 4:57 AM, Fred. Zwarts wrote:
Op 15.jul.2025 om 05:11 schreef olcott:
On 7/14/2025 10:05 PM, Richard Damon wrote:And then simulation cannot decide anything, because it does not see
On 7/14/25 11:26 AM, olcott wrote:I never admitted that and my current views
On 7/14/2025 6:14 AM, Richard Damon wrote:
On 7/13/25 10:09 PM, olcott wrote:
On 7/13/2025 8:24 PM, Richard Damon wrote:
On 7/13/25 5:11 PM, olcott wrote:
On 7/13/2025 3:15 PM, Richard Damon wrote:
On 7/13/25 10:51 AM, olcott wrote:
On 7/13/2025 1:58 AM, Mikko wrote:
On 2025-07-12 14:48:14 +0000, olcott said:
On 7/12/2025 3:18 AM, Mikko wrote:
On 2025-07-11 17:32:57 +0000, olcott said:Because the definition of a halt decider requires Turing >>>>>>>>>>>>> machines to report on the behavior of non-inputs.
On 7/11/2025 11:07 AM, dbush wrote:Mainly because there are no Turing machine halt deciders. >>>>>>>>>>>>>
On 7/11/2025 11:01 AM, olcott wrote:
On 7/11/2025 3:15 AM, Mikko wrote:
On 2025-07-10 14:15:31 +0000, olcott said: >>>>>>>>>>>>>>>>>>
On 7/10/2025 4:09 AM, Mikko wrote:This is a good example of what I meant in another >>>>>>>>>>>>>>>>>> comment when
On 2025-07-09 12:45:54 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>After the non-terminating behavior pattern is matched >>>>>>>>>>>>>>>>>>> on line 996
That trace is a little long. Where in that trace is >>>>>>>>>>>>>>>>>>>> the forth level of
*Here is HHH matching that pattern*
executed HHH simulates DDD that calls emulated >>>>>>>>>>>>>>>>>>>>> HHH(DDD)
that simulates DDD that calls emulated emulated >>>>>>>>>>>>>>>>>>>>> HHH(DDD)
*Here is the 197 page full execution trace of that* >>>>>>>>>>>>>>>>>>>>> https://liarparadox.org/HHH(DDD)_Full_Trace.pdf >>>>>>>>>>>>>>>>>>>>
recursive simulation statrted?
https://github.com/plolcott/x86utm/blob/master/Halt7.c >>>>>>>>>>>>>>>>>>> HHH rejects DDD as specifying non-halting behavior. >>>>>>>>>>>>>>>>>>
I said that you don't answer questions.
When you ask an incorrect question, like you did I provide >>>>>>>>>>>>>>>>> an answer to the corrected question.
On 7/9/2025 12:06 PM, olcott wrote:
That changes the words of the question thus becomes >>>>>>>>>>>>>>>>> the strawman error.
*I do finally have a rebuttal to your other issue* >>>>>>>>>>>>>>> A Turing Machine halt decider has never been able >>>>>>>>>>>>>>> to report on the behavior of any directly executed >>>>>>>>>>>>>>> Turing Machine because anything besides finite
strings are outside of the domain of every TM decider. >>>>>>>>>>>>>>
int sum(int x, int y) {return x + y;}
sum(3,4) reports in the sum of 3+4 it does not
report on the sum of 5+7. To require sum(3,4)
to report on the sum of 5+7 is an incorrect
requirement.
But thereNo TM has ever reported on the behavior of any
are partial halt deciders that can report correctly on >>>>>>>>>>>>>> some directly
executed Turing machines but fail to report on others. >>>>>>>>>>>>>
directly executed Turing machine.
An universal Turing machin does exacly that. And so does, to >>>>>>>>>>>> a more
limited entent, a partial halt decider. And also a partial >>>>>>>>>>>> termination
analyzer.
This still is not reporting on the direct execution
of the input even though it matches the same behavior.
When the input unconditionally calls the UTM then
neither ever halts.
So, what is the difference you are trying to talk about.
It took me years to correctly answer that question.
It is only my most recent answer that is correct.
As soon as HHH begins emulating itself emulating DDD
the behavior differs from that of DDD emulated by HHH1
that never begins emulating itself.
So, WHAT INSTRUCTION CORRECTLY EMULATED differed?
Immediately after emulated HHH(DDD)->DDD calls HHH(DDD)
is the first instruction of HHH calling itself.
So? What was that first instruction in the HHH that DDD called?
Immediately after emulated HHH1(DDD)->DDD calls HHH(DDD)
is NOT the first instruction of HHH1 calling itself.
Irrelevent, it will be the same first instruction in the HHH that
DDD Called.
How an instruction operates depends only on the IMMEDIATE context, >>>>>> the contents of all the CPU registers.
The is nothing in that context that changes because HHH1 is doing
the emulation rather than HHH.
*Claude was able to figure all this out on its own*
The key difference is that HHH1 can complete its simulation >>>>>>> of DDD because the recursive call is to HHH (not HHH1),
so there's no infinite regress in the simulation process itself. >>>>>>> https://claude.ai/share/da9b8e3f-eb16-42ca-a9e8-913f4b88202c
Becasuee you LIED to it.
My half page of specification is followed by its
single page complete analysis. *Its a quick read*
Rigth, and that specification is a LIE, as it claims that HHH DOES >>>>>> simulate till if DOES find a non-halting pattern.
That Claude.ai figures out all of the details of exactly
how DDD simulated by HHH specifies non-terminating behavior
seems to prove that you are the liar. With the credentials
that you provided this could not be an honest mistake.
That it build on your LIE just shows how stupid you both are.
Note, you are ADMITTED your system is a lie,
supersede and replace all of my prior views.
When one or more instructions of DDD are emulated
according to the semantics of the x86 language by
some HHH, no DDD ever reaches its "ret" instruction.
the whole behaviour specified by the input.
It is not the whole behavior specified by the input
that you are referring to. Is it the behavior of a
non-input that you are referring to.
Turing machines only take finite string inputs thus
the behavior of non-inputs are none of their damn business.
Other tools are needed in that case to analyse the behaviour.
On 7/15/2025 4:22 AM, Mikko wrote:
On 2025-07-14 12:59:36 +0000, olcott said:
On 7/14/2025 3:42 AM, Mikko wrote:
On 2025-07-13 14:51:04 +0000, olcott said:
On 7/13/2025 1:58 AM, Mikko wrote:
On 2025-07-12 14:48:14 +0000, olcott said:
On 7/12/2025 3:18 AM, Mikko wrote:
On 2025-07-11 17:32:57 +0000, olcott said:
On 7/11/2025 11:07 AM, dbush wrote:
On 7/11/2025 11:01 AM, olcott wrote:
On 7/11/2025 3:15 AM, Mikko wrote:
On 2025-07-10 14:15:31 +0000, olcott said:
On 7/10/2025 4:09 AM, Mikko wrote:
On 2025-07-09 12:45:54 +0000, olcott said:After the non-terminating behavior pattern is matched >>>>>>>>>>>>> on line 996
*Here is HHH matching that pattern*
executed HHH simulates DDD that calls emulated HHH(DDD) >>>>>>>>>>>>>>> that simulates DDD that calls emulated emulated HHH(DDD) >>>>>>>>>>>>>>>
*Here is the 197 page full execution trace of that* >>>>>>>>>>>>>>> https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
That trace is a little long. Where in that trace is the forth level of
recursive simulation statrted?
https://github.com/plolcott/x86utm/blob/master/Halt7.c >>>>>>>>>>>>> HHH rejects DDD as specifying non-halting behavior.
This is a good example of what I meant in another comment when >>>>>>>>>>>> I said that you don't answer questions.
When you ask an incorrect question, like you did I provide >>>>>>>>>>> an answer to the corrected question.
On 7/9/2025 12:06 PM, olcott wrote:
That changes the words of the question thus becomes
the strawman error.
*I do finally have a rebuttal to your other issue*
A Turing Machine halt decider has never been able
to report on the behavior of any directly executed
Turing Machine because anything besides finite
strings are outside of the domain of every TM decider.
Mainly because there are no Turing machine halt deciders.
Because the definition of a halt decider requires Turing
machines to report on the behavior of non-inputs.
int sum(int x, int y) {return x + y;}
sum(3,4) reports in the sum of 3+4 it does not
report on the sum of 5+7. To require sum(3,4)
to report on the sum of 5+7 is an incorrect
requirement.
But there
are partial halt deciders that can report correctly on some directly >>>>>>>> executed Turing machines but fail to report on others.
No TM has ever reported on the behavior of any
directly executed Turing machine.
An universal Turing machin does exacly that. And so does, to a more >>>>>> limited entent, a partial halt decider. And also a partial termination >>>>>> analyzer.
This still is not reporting on the direct execution
of the input even though it matches the same behavior.
Yes, it is. An universal Turing machine tells what will happen if the
computation is performed, which is what reporting on the direct
execution means.
Not in the case when the input to the UTM calls this
same UTM and the UTM has been adapted to recognize
this as non-halting criteria to abort its simulation.
An input does not call. A Turing machine is not called.
Professor Sipser would disagree.
"Now we construct a new Turing machine D with H as a
subroutine. This new TM calls H to determine what M
does when the input to M is its own description" https://www.liarparadox.org/Sipser_165_167.pdf
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 22:32:13 |
| Calls: | 10,390 |
| Calls today: | 1 |
| Files: | 14,063 |
| Messages: | 6,416,990 |