On 6/19/23 4:43 PM, olcott wrote:
The behavior of the directly executed P(P) is different than the
behavior of P(P) correctly simulated by H because in the first case H
has already aborted its simulation of its input and in the second case
this has not yet occurred.
By what definition of "Correctly Simulated"?
The fact that H aborts its simulation has NO affect on the direct
execution of the machine, so all you are saying that H has shut its eyes
and said "I don't see it, so it didn't happen".
That is just FALSEHOOD.
I now refer to P(P) as D(D).
Can D correctly simulated by H terminate normally?
No it cannot see the details below.
Which is not the question being asked. The fact that it is impossible to design an H that can correctly simulate its input to a halting state
just proves that H can not correctly decider that its input is Halting.
This does NOT mean that the input can't be Halting, just that H can
never prove it.
IF H doesn't ever abort its simulation, then yes, the D built on that H
is non-halting, but that H never gives that answer, so it is still wrong.
Each H gets a DIFFERENT D, since they include the H that the
"pathological test" is to be performed on, so the behavior of one D
built on a different H doesn't apply, and for correct reasoning, you
really need to give each one a different name. Reusing the same name for different machine, and then trying to confuse which one is which is just
a sign of being intentionally deceptive to try to tell a LIE.
The x86utm operating system based on an open source x86 emulator. This
system enables one C function to execute another C function in debug
step mode. When H simulates D it creates a separate process context for
D with its own memory, stack and virtual registers. H is able to
simulate D simulating itself, thus the only limit to recursive
simulations is RAM.
But D is not SPECIFIED in a seperate context, but share code space with
H, which means it fails to be truely distinctly, like a Turing Machine
would be.
It is NOT a full "separate process context" as all the contexts share
code space.
H correctly simulates N steps of D until H correctly predicts through
// The following is written in C
//
01 typedef int (*ptr)(); // pointer to int function
02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input
03
04 int D(ptr x)
05 {
06 int Halt_Status = H(x, x);
07 if (Halt_Status)
08 HERE: goto HERE;
09 return Halt_Status;
10 }
11
12 void main()
13 {
14 D(D);
15 }
D correctly simulated by H cannot possibly terminate normally by
reaching its own final state at line 09.
But D correctly simulated by a correct simulator would, at least as long
as you are using an H that answer H(D,D) as 0, as you claim.
The behavior of the directly executed P(P) is different than the
behavior of P(P) correctly simulated by H because in the first case H
has already aborted its simulation of its input and in the second case
this has not yet occurred.
I now refer to P(P) as D(D).
Can D correctly simulated by H terminate normally?
No it cannot see the details below.
The x86utm operating system based on an open source x86 emulator. This
system enables one C function to execute another C function in debug
step mode. When H simulates D it creates a separate process context for
D with its own memory, stack and virtual registers. H is able to
simulate D simulating itself, thus the only limit to recursive
simulations is RAM.
// The following is written in C
//
01 typedef int (*ptr)(); // pointer to int function
02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input
03
04 int D(ptr x)
05 {
06 int Halt_Status = H(x, x);
07 if (Halt_Status)
08 HERE: goto HERE;
09 return Halt_Status;
10 }
11
12 void main()
13 {
14 D(D);
15 }
D correctly simulated by H cannot possibly terminate normally by
reaching its own final state at line 09.
We can easily fix what Ben has misconstrued as a contradiction by
defining the return value of 0 from H as meaning:
(a) the input does not halt <or>
(b) the input is defined to have a pathological relationship to H.
Since it is true that D was defined to do the opposite of whatever
Boolean value that H returns H is correct to return 0.
*Termination Analyzer H is Not Fooled by Pathological Input D* https://www.researchgate.net/publication/369971402_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
On 6/19/2023 7:45 PM, Richard Damon wrote:
On 6/19/23 4:43 PM, olcott wrote:H correctly simulates N steps of D until H correctly predicts through
The behavior of the directly executed P(P) is different than the
behavior of P(P) correctly simulated by H because in the first case H
has already aborted its simulation of its input and in the second case
this has not yet occurred.
By what definition of "Correctly Simulated"?
The fact that H aborts its simulation has NO affect on the direct
execution of the machine, so all you are saying that H has shut its
eyes and said "I don't see it, so it didn't happen".
That is just FALSEHOOD.
I now refer to P(P) as D(D).
Can D correctly simulated by H terminate normally?
No it cannot see the details below.
Which is not the question being asked. The fact that it is impossible
to design an H that can correctly simulate its input to a halting
state just proves that H can not correctly decider that its input is
Halting.
This does NOT mean that the input can't be Halting, just that H can
never prove it.
IF H doesn't ever abort its simulation, then yes, the D built on that
H is non-halting, but that H never gives that answer, so it is still
wrong.
Each H gets a DIFFERENT D, since they include the H that the
"pathological test" is to be performed on, so the behavior of one D
built on a different H doesn't apply, and for correct reasoning, you
really need to give each one a different name. Reusing the same name
for different machine, and then trying to confuse which one is which
is just a sign of being intentionally deceptive to try to tell a LIE.
The x86utm operating system based on an open source x86 emulator. This
system enables one C function to execute another C function in debug
step mode. When H simulates D it creates a separate process context for
D with its own memory, stack and virtual registers. H is able to
simulate D simulating itself, thus the only limit to recursive
simulations is RAM.
But D is not SPECIFIED in a seperate context, but share code space
with H, which means it fails to be truely distinctly, like a Turing
Machine would be.
It is NOT a full "separate process context" as all the contexts share
code space.
// The following is written in C
//
01 typedef int (*ptr)(); // pointer to int function
02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input
03
04 int D(ptr x)
05 {
06 int Halt_Status = H(x, x);
07 if (Halt_Status)
08 HERE: goto HERE;
09 return Halt_Status;
10 }
11
12 void main()
13 {
14 D(D);
15 }
D correctly simulated by H cannot possibly terminate normally by
reaching its own final state at line 09.
But D correctly simulated by a correct simulator would, at least as
long as you are using an H that answer H(D,D) as 0, as you claim.
the type of mathematical induction used by termination analyzers that D correctly simulated by H cannot possibly terminate normally.
int factorial(int n)
{
if(n==0)
return(1);
return(n*factorial(n-1));
}
AProVE correctly determines that factorial(5) halts by
boiling the key behavior of entire function to this:
f(x) → f(x-1) :|: x > 0 && x <= 5
On 6/19/23 9:02 PM, olcott wrote:
On 6/19/2023 7:45 PM, Richard Damon wrote:
On 6/19/23 4:43 PM, olcott wrote:H correctly simulates N steps of D until H correctly predicts through
The behavior of the directly executed P(P) is different than the
behavior of P(P) correctly simulated by H because in the first case H
has already aborted its simulation of its input and in the second case >>>> this has not yet occurred.
By what definition of "Correctly Simulated"?
The fact that H aborts its simulation has NO affect on the direct
execution of the machine, so all you are saying that H has shut its
eyes and said "I don't see it, so it didn't happen".
That is just FALSEHOOD.
I now refer to P(P) as D(D).
Can D correctly simulated by H terminate normally?
No it cannot see the details below.
Which is not the question being asked. The fact that it is impossible
to design an H that can correctly simulate its input to a halting
state just proves that H can not correctly decider that its input is
Halting.
This does NOT mean that the input can't be Halting, just that H can
never prove it.
IF H doesn't ever abort its simulation, then yes, the D built on that
H is non-halting, but that H never gives that answer, so it is still
wrong.
Each H gets a DIFFERENT D, since they include the H that the
"pathological test" is to be performed on, so the behavior of one D
built on a different H doesn't apply, and for correct reasoning, you
really need to give each one a different name. Reusing the same name
for different machine, and then trying to confuse which one is which
is just a sign of being intentionally deceptive to try to tell a LIE.
The x86utm operating system based on an open source x86 emulator. This >>>> system enables one C function to execute another C function in debug
step mode. When H simulates D it creates a separate process context for >>>> D with its own memory, stack and virtual registers. H is able to
simulate D simulating itself, thus the only limit to recursive
simulations is RAM.
But D is not SPECIFIED in a seperate context, but share code space
with H, which means it fails to be truely distinctly, like a Turing
Machine would be.
It is NOT a full "separate process context" as all the contexts share
code space.
// The following is written in C
//
01 typedef int (*ptr)(); // pointer to int function
02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input
03
04 int D(ptr x)
05 {
06 int Halt_Status = H(x, x);
07 if (Halt_Status)
08 HERE: goto HERE;
09 return Halt_Status;
10 }
11
12 void main()
13 {
14 D(D);
15 }
D correctly simulated by H cannot possibly terminate normally by
reaching its own final state at line 09.
But D correctly simulated by a correct simulator would, at least as
long as you are using an H that answer H(D,D) as 0, as you claim.
the type of mathematical induction used by termination analyzers that D
correctly simulated by H cannot possibly terminate normally.
But that is the wrong prediction. It needs to predict if the input when
run will halt, as THAT is the Halting Question.
Thus, you are just admitting to working on POOP instead of Halting, and
ALL your statements are just LIES.
the drain.
int factorial(int n)
{
if(n==0)
return(1);
return(n*factorial(n-1));
}
AProVE correctly determines that factorial(5) halts by
boiling the key behavior of entire function to this:
f(x) → f(x-1) :|: x > 0 && x <= 5
Wrong Question leads to incorrect answer, and all your work goes down
You are just proving you don't understand basic English.
YOU ARE JUST TOO STUPID for this.
On 6/19/2023 8:13 PM, Richard Damon wrote:
On 6/19/23 9:02 PM, olcott wrote:
On 6/19/2023 7:45 PM, Richard Damon wrote:
On 6/19/23 4:43 PM, olcott wrote:H correctly simulates N steps of D until H correctly predicts through
The behavior of the directly executed P(P) is different than the
behavior of P(P) correctly simulated by H because in the first case H >>>>> has already aborted its simulation of its input and in the second case >>>>> this has not yet occurred.
By what definition of "Correctly Simulated"?
The fact that H aborts its simulation has NO affect on the direct
execution of the machine, so all you are saying that H has shut its
eyes and said "I don't see it, so it didn't happen".
That is just FALSEHOOD.
I now refer to P(P) as D(D).
Can D correctly simulated by H terminate normally?
No it cannot see the details below.
Which is not the question being asked. The fact that it is
impossible to design an H that can correctly simulate its input to a
halting state just proves that H can not correctly decider that its
input is Halting.
This does NOT mean that the input can't be Halting, just that H can
never prove it.
IF H doesn't ever abort its simulation, then yes, the D built on
that H is non-halting, but that H never gives that answer, so it is
still wrong.
Each H gets a DIFFERENT D, since they include the H that the
"pathological test" is to be performed on, so the behavior of one D
built on a different H doesn't apply, and for correct reasoning, you
really need to give each one a different name. Reusing the same name
for different machine, and then trying to confuse which one is which
is just a sign of being intentionally deceptive to try to tell a LIE. >>>>>
The x86utm operating system based on an open source x86 emulator. This >>>>> system enables one C function to execute another C function in debug >>>>> step mode. When H simulates D it creates a separate process context
for
D with its own memory, stack and virtual registers. H is able to
simulate D simulating itself, thus the only limit to recursive
simulations is RAM.
But D is not SPECIFIED in a seperate context, but share code space
with H, which means it fails to be truely distinctly, like a Turing
Machine would be.
It is NOT a full "separate process context" as all the contexts
share code space.
// The following is written in C
//
01 typedef int (*ptr)(); // pointer to int function
02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input >>>>> 03
04 int D(ptr x)
05 {
06 int Halt_Status = H(x, x);
07 if (Halt_Status)
08 HERE: goto HERE;
09 return Halt_Status;
10 }
11
12 void main()
13 {
14 D(D);
15 }
D correctly simulated by H cannot possibly terminate normally by
reaching its own final state at line 09.
But D correctly simulated by a correct simulator would, at least as
long as you are using an H that answer H(D,D) as 0, as you claim.
the type of mathematical induction used by termination analyzers that D
correctly simulated by H cannot possibly terminate normally.
But that is the wrong prediction. It needs to predict if the input
when run will halt, as THAT is the Halting Question.
That is just like Jack's question posed to Jack, self-contradictory.
ChatGPT could understand that I am correct.
Thus, you are just admitting to working on POOP instead of Halting,
and ALL your statements are just LIES.
the drain.
int factorial(int n)
{
if(n==0)
return(1);
return(n*factorial(n-1));
}
AProVE correctly determines that factorial(5) halts by
boiling the key behavior of entire function to this:
f(x) → f(x-1) :|: x > 0 && x <= 5
Wrong Question leads to incorrect answer, and all your work goes down
AProVE is the largest termination analysis project in the world.
You are just proving you don't understand basic English.
YOU ARE JUST TOO STUPID for this.
On 6/19/23 11:46 PM, olcott wrote:
On 6/19/2023 8:13 PM, Richard Damon wrote:
On 6/19/23 9:02 PM, olcott wrote:
On 6/19/2023 7:45 PM, Richard Damon wrote:
On 6/19/23 4:43 PM, olcott wrote:H correctly simulates N steps of D until H correctly predicts through
The behavior of the directly executed P(P) is different than the
behavior of P(P) correctly simulated by H because in the first case H >>>>>> has already aborted its simulation of its input and in the second
case
this has not yet occurred.
By what definition of "Correctly Simulated"?
The fact that H aborts its simulation has NO affect on the direct
execution of the machine, so all you are saying that H has shut its
eyes and said "I don't see it, so it didn't happen".
That is just FALSEHOOD.
I now refer to P(P) as D(D).
Can D correctly simulated by H terminate normally?
No it cannot see the details below.
Which is not the question being asked. The fact that it is
impossible to design an H that can correctly simulate its input to
a halting state just proves that H can not correctly decider that
its input is Halting.
This does NOT mean that the input can't be Halting, just that H can
never prove it.
IF H doesn't ever abort its simulation, then yes, the D built on
that H is non-halting, but that H never gives that answer, so it is
still wrong.
Each H gets a DIFFERENT D, since they include the H that the
"pathological test" is to be performed on, so the behavior of one D
built on a different H doesn't apply, and for correct reasoning,
you really need to give each one a different name. Reusing the same
name for different machine, and then trying to confuse which one is
which is just a sign of being intentionally deceptive to try to
tell a LIE.
The x86utm operating system based on an open source x86 emulator.
This
system enables one C function to execute another C function in debug >>>>>> step mode. When H simulates D it creates a separate process
context for
D with its own memory, stack and virtual registers. H is able to
simulate D simulating itself, thus the only limit to recursive
simulations is RAM.
But D is not SPECIFIED in a seperate context, but share code space
with H, which means it fails to be truely distinctly, like a Turing
Machine would be.
It is NOT a full "separate process context" as all the contexts
share code space.
// The following is written in C
//
01 typedef int (*ptr)(); // pointer to int function
02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input >>>>>> 03
04 int D(ptr x)
05 {
06 int Halt_Status = H(x, x);
07 if (Halt_Status)
08 HERE: goto HERE;
09 return Halt_Status;
10 }
11
12 void main()
13 {
14 D(D);
15 }
D correctly simulated by H cannot possibly terminate normally by
reaching its own final state at line 09.
But D correctly simulated by a correct simulator would, at least as
long as you are using an H that answer H(D,D) as 0, as you claim.
the type of mathematical induction used by termination analyzers that D >>>> correctly simulated by H cannot possibly terminate normally.
But that is the wrong prediction. It needs to predict if the input
when run will halt, as THAT is the Halting Question.
That is just like Jack's question posed to Jack, self-contradictory.
ChatGPT could understand that I am correct.
Nope, and you just seem too stupid to understand.
Thus, you are just admitting to working on POOP instead of Halting,
and ALL your statements are just LIES.
int factorial(int n)
{
if(n==0)
return(1);
return(n*factorial(n-1));
}
AProVE correctly determines that factorial(5) halts by
boiling the key behavior of entire function to this:
f(x) → f(x-1) :|: x > 0 && x <= 5
Wrong Question leads to incorrect answer, and all your work goes down >>> the drain.
AProVE is the largest termination analysis project in the world.
Yes, and it probably uses the RIGHT question, will the program halt when actually run.
It will probably also tell you that D(D) will Halt since H(D,D) returns 0.
Thus, it likely shows you are wrong about everything.
You are just proving you don't understand basic English.
YOU ARE JUST TOO STUPID for this.
On 6/20/2023 6:19 AM, Richard Damon wrote:
On 6/19/23 11:46 PM, olcott wrote:
On 6/19/2023 8:13 PM, Richard Damon wrote:
On 6/19/23 9:02 PM, olcott wrote:
On 6/19/2023 7:45 PM, Richard Damon wrote:
On 6/19/23 4:43 PM, olcott wrote:that D
The behavior of the directly executed P(P) is different than the >>>>>>> behavior of P(P) correctly simulated by H because in the first
case H
has already aborted its simulation of its input and in the second >>>>>>> case
this has not yet occurred.
By what definition of "Correctly Simulated"?
The fact that H aborts its simulation has NO affect on the direct
execution of the machine, so all you are saying that H has shut
its eyes and said "I don't see it, so it didn't happen".
That is just FALSEHOOD.
I now refer to P(P) as D(D).
Can D correctly simulated by H terminate normally?
No it cannot see the details below.
Which is not the question being asked. The fact that it is
impossible to design an H that can correctly simulate its input to >>>>>> a halting state just proves that H can not correctly decider that
its input is Halting.
This does NOT mean that the input can't be Halting, just that H
can never prove it.
IF H doesn't ever abort its simulation, then yes, the D built on
that H is non-halting, but that H never gives that answer, so it
is still wrong.
Each H gets a DIFFERENT D, since they include the H that the
"pathological test" is to be performed on, so the behavior of one
D built on a different H doesn't apply, and for correct reasoning, >>>>>> you really need to give each one a different name. Reusing the
same name for different machine, and then trying to confuse which
one is which is just a sign of being intentionally deceptive to
try to tell a LIE.
The x86utm operating system based on an open source x86 emulator. >>>>>>> This
system enables one C function to execute another C function in debug >>>>>>> step mode. When H simulates D it creates a separate process
context for
D with its own memory, stack and virtual registers. H is able to >>>>>>> simulate D simulating itself, thus the only limit to recursive
simulations is RAM.
But D is not SPECIFIED in a seperate context, but share code space >>>>>> with H, which means it fails to be truely distinctly, like a
Turing Machine would be.
It is NOT a full "separate process context" as all the contexts
share code space.
// The following is written in C
//
01 typedef int (*ptr)(); // pointer to int function
02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input >>>>>>> 03
04 int D(ptr x)
05 {
06 int Halt_Status = H(x, x);
07 if (Halt_Status)
08 HERE: goto HERE;
09 return Halt_Status;
10 }
11
12 void main()
13 {
14 D(D);
15 }
D correctly simulated by H cannot possibly terminate normally by >>>>>>> reaching its own final state at line 09.
But D correctly simulated by a correct simulator would, at least
as long as you are using an H that answer H(D,D) as 0, as you claim. >>>>> H correctly simulates N steps of D until H correctly predicts through >>>>> the type of mathematical induction used by termination analyzers
correctly simulated by H cannot possibly terminate normally.
But that is the wrong prediction. It needs to predict if the input
when run will halt, as THAT is the Halting Question.
That is just like Jack's question posed to Jack, self-contradictory.
ChatGPT could understand that I am correct.
Nope, and you just seem too stupid to understand.
Thus, you are just admitting to working on POOP instead of Halting,
and ALL your statements are just LIES.
down
int factorial(int n)
{
if(n==0)
return(1);
return(n*factorial(n-1));
}
AProVE correctly determines that factorial(5) halts by
boiling the key behavior of entire function to this:
f(x) → f(x-1) :|: x > 0 && x <= 5
Wrong Question leads to incorrect answer, and all your work goes
the drain.
AProVE is the largest termination analysis project in the world.
Yes, and it probably uses the RIGHT question, will the program halt
when actually run.
It will probably also tell you that D(D) will Halt since H(D,D)
returns 0.
Thus, it likely shows you are wrong about everything.
When we use the criteria:
Can D correctly simulated by H ever terminate normally?
After N steps of correct simulation the execution trace of D proves that
D cannot possibly reach its final instruction and terminate normally in
any finite number of steps.
This criteria matches non-halting input and it also matches the cases
where the input D has been intentionally defined to do the opposite of whatever Boolean value that H returns.
When H returns 1 it means that its input halts and when H return 0
it means that either its input does not halt or D was intentionally
defined to do the opposite of whatever Boolean value that H returns.
To the best of my knowledge no one has ever made this much progress on
the halting problem's pathological input. To the best of my knowledge everyone else was completely stumped by the halting problem's
pathological input.
On 6/20/23 11:02 AM, olcott wrote:
On 6/20/2023 6:19 AM, Richard Damon wrote:
On 6/19/23 11:46 PM, olcott wrote:
On 6/19/2023 8:13 PM, Richard Damon wrote:
On 6/19/23 9:02 PM, olcott wrote:
On 6/19/2023 7:45 PM, Richard Damon wrote:
On 6/19/23 4:43 PM, olcott wrote:that D
The behavior of the directly executed P(P) is different than the >>>>>>>> behavior of P(P) correctly simulated by H because in the first >>>>>>>> case H
has already aborted its simulation of its input and in the
second case
this has not yet occurred.
By what definition of "Correctly Simulated"?
The fact that H aborts its simulation has NO affect on the direct >>>>>>> execution of the machine, so all you are saying that H has shut
its eyes and said "I don't see it, so it didn't happen".
That is just FALSEHOOD.
I now refer to P(P) as D(D).
Can D correctly simulated by H terminate normally?
No it cannot see the details below.
Which is not the question being asked. The fact that it is
impossible to design an H that can correctly simulate its input
to a halting state just proves that H can not correctly decider
that its input is Halting.
This does NOT mean that the input can't be Halting, just that H
can never prove it.
IF H doesn't ever abort its simulation, then yes, the D built on >>>>>>> that H is non-halting, but that H never gives that answer, so it >>>>>>> is still wrong.
Each H gets a DIFFERENT D, since they include the H that the
"pathological test" is to be performed on, so the behavior of one >>>>>>> D built on a different H doesn't apply, and for correct
reasoning, you really need to give each one a different name.
Reusing the same name for different machine, and then trying to
confuse which one is which is just a sign of being intentionally >>>>>>> deceptive to try to tell a LIE.
The x86utm operating system based on an open source x86
emulator. This
system enables one C function to execute another C function in >>>>>>>> debug
step mode. When H simulates D it creates a separate process
context for
D with its own memory, stack and virtual registers. H is able to >>>>>>>> simulate D simulating itself, thus the only limit to recursive >>>>>>>> simulations is RAM.
But D is not SPECIFIED in a seperate context, but share code
space with H, which means it fails to be truely distinctly, like >>>>>>> a Turing Machine would be.
It is NOT a full "separate process context" as all the contexts
share code space.
// The following is written in C
//
01 typedef int (*ptr)(); // pointer to int function
02 int H(ptr x, ptr y) // uses x86 emulator to simulate its input >>>>>>>> 03
04 int D(ptr x)
05 {
06 int Halt_Status = H(x, x);
07 if (Halt_Status)
08 HERE: goto HERE;
09 return Halt_Status;
10 }
11
12 void main()
13 {
14 D(D);
15 }
D correctly simulated by H cannot possibly terminate normally by >>>>>>>> reaching its own final state at line 09.
But D correctly simulated by a correct simulator would, at least >>>>>>> as long as you are using an H that answer H(D,D) as 0, as you claim. >>>>>> H correctly simulates N steps of D until H correctly predicts through >>>>>> the type of mathematical induction used by termination analyzers
correctly simulated by H cannot possibly terminate normally.
But that is the wrong prediction. It needs to predict if the input
when run will halt, as THAT is the Halting Question.
That is just like Jack's question posed to Jack, self-contradictory.
ChatGPT could understand that I am correct.
Nope, and you just seem too stupid to understand.
Thus, you are just admitting to working on POOP instead of Halting,
and ALL your statements are just LIES.
the drain.
int factorial(int n)
{
if(n==0)
return(1);
return(n*factorial(n-1));
}
AProVE correctly determines that factorial(5) halts by
boiling the key behavior of entire function to this:
f(x) → f(x-1) :|: x > 0 && x <= 5
Wrong Question leads to incorrect answer, and all your work goes >>>>> down
AProVE is the largest termination analysis project in the world.
Yes, and it probably uses the RIGHT question, will the program halt
when actually run.
It will probably also tell you that D(D) will Halt since H(D,D)
returns 0.
Thus, it likely shows you are wrong about everything.
When we use the criteria:
Can D correctly simulated by H ever terminate normally?
So you are ADMITTING to working on a different problem, and lying about
what you are doing. Thank you for being honest about that.
Ben is just pointing out the ERRORS in your logic
The fact you can't see that just shows your lack of understanding.ChatGPT understood that Jack’s question is a self contradictory
On 6/20/23 1:46 PM, olcott wrote:Not at all. Not the least little bit.
On 6/20/2023 10:48 AM, Richard Damon wrote:
On 6/20/23 11:02 AM, olcott wrote:
On 6/20/2023 6:19 AM, Richard Damon wrote:
On 6/19/23 11:46 PM, olcott wrote:
On 6/19/2023 8:13 PM, Richard Damon wrote:
On 6/19/23 9:02 PM, olcott wrote:
On 6/19/2023 7:45 PM, Richard Damon wrote:
On 6/19/23 4:43 PM, olcott wrote:H correctly simulates N steps of D until H correctly predicts
The behavior of the directly executed P(P) is different than the >>>>>>>>>> behavior of P(P) correctly simulated by H because in the first >>>>>>>>>> case H
has already aborted its simulation of its input and in the >>>>>>>>>> second case
this has not yet occurred.
By what definition of "Correctly Simulated"?
The fact that H aborts its simulation has NO affect on the
direct execution of the machine, so all you are saying that H >>>>>>>>> has shut its eyes and said "I don't see it, so it didn't happen". >>>>>>>>>
That is just FALSEHOOD.
I now refer to P(P) as D(D).
Can D correctly simulated by H terminate normally?
No it cannot see the details below.
Which is not the question being asked. The fact that it is
impossible to design an H that can correctly simulate its input >>>>>>>>> to a halting state just proves that H can not correctly decider >>>>>>>>> that its input is Halting.
This does NOT mean that the input can't be Halting, just that H >>>>>>>>> can never prove it.
IF H doesn't ever abort its simulation, then yes, the D built >>>>>>>>> on that H is non-halting, but that H never gives that answer, >>>>>>>>> so it is still wrong.
Each H gets a DIFFERENT D, since they include the H that the >>>>>>>>> "pathological test" is to be performed on, so the behavior of >>>>>>>>> one D built on a different H doesn't apply, and for correct
reasoning, you really need to give each one a different name. >>>>>>>>> Reusing the same name for different machine, and then trying to >>>>>>>>> confuse which one is which is just a sign of being
intentionally deceptive to try to tell a LIE.
The x86utm operating system based on an open source x86
emulator. This
system enables one C function to execute another C function in >>>>>>>>>> debug
step mode. When H simulates D it creates a separate process >>>>>>>>>> context for
D with its own memory, stack and virtual registers. H is able to >>>>>>>>>> simulate D simulating itself, thus the only limit to recursive >>>>>>>>>> simulations is RAM.
But D is not SPECIFIED in a seperate context, but share code >>>>>>>>> space with H, which means it fails to be truely distinctly,
like a Turing Machine would be.
It is NOT a full "separate process context" as all the contexts >>>>>>>>> share code space.
// The following is written in C
//
01 typedef int (*ptr)(); // pointer to int function
02 int H(ptr x, ptr y) // uses x86 emulator to simulate its >>>>>>>>>> input
03
04 int D(ptr x)
05 {
06 int Halt_Status = H(x, x);
07 if (Halt_Status)
08 HERE: goto HERE;
09 return Halt_Status;
10 }
11
12 void main()
13 {
14 D(D);
15 }
D correctly simulated by H cannot possibly terminate normally >>>>>>>>>> by reaching its own final state at line 09.
But D correctly simulated by a correct simulator would, at
least as long as you are using an H that answer H(D,D) as 0, as >>>>>>>>> you claim.
through
the type of mathematical induction used by termination analyzers >>>>>>>> that D
correctly simulated by H cannot possibly terminate normally.
But that is the wrong prediction. It needs to predict if the
input when run will halt, as THAT is the Halting Question.
That is just like Jack's question posed to Jack, self-contradictory. >>>>>> ChatGPT could understand that I am correct.
Nope, and you just seem too stupid to understand.
Thus, you are just admitting to working on POOP instead of
Halting, and ALL your statements are just LIES.
goes down
int factorial(int n)
{
if(n==0)
return(1);
return(n*factorial(n-1));
}
AProVE correctly determines that factorial(5) halts by
boiling the key behavior of entire function to this:
f(x) → f(x-1) :|: x > 0 && x <= 5
Wrong Question leads to incorrect answer, and all your work
the drain.
AProVE is the largest termination analysis project in the world.
Yes, and it probably uses the RIGHT question, will the program halt
when actually run.
It will probably also tell you that D(D) will Halt since H(D,D)
returns 0.
Thus, it likely shows you are wrong about everything.
When we use the criteria:
Can D correctly simulated by H ever terminate normally?
So you are ADMITTING to working on a different problem, and lying
about what you are doing. Thank you for being honest about that.
Ben is just pointing out the ERRORS in your logic
When Ben pointed out that H(P,P) reports that P(P) does not halt when
P(P) does halt this seems to be a contradiction to people that lack a
complete understanding.
NO, it is a TRUE statement. H is NOT a correct HALT DECIDER.
It might be a valid POOP decider with your altered criteria, but it
isn't correct as a Halt Decider.
You don't get to change the meaning of words, attempting to just shows
you are a liar.
Halting is a property of the original machine, not of the partial
simulation that H does.
Because of this I changed the semantic meaning of a return value of 0
from H to mean either that P(P) does not halt or P(P) specifically
targets H to do the opposite of whatever Boolean value that H returns.
Which means you H need to return BOTH a 0 and 1 at the same time,
On 6/20/2023 10:48 AM, Richard Damon wrote:
On 6/20/23 11:02 AM, olcott wrote:
On 6/20/2023 6:19 AM, Richard Damon wrote:
On 6/19/23 11:46 PM, olcott wrote:
On 6/19/2023 8:13 PM, Richard Damon wrote:
On 6/19/23 9:02 PM, olcott wrote:
On 6/19/2023 7:45 PM, Richard Damon wrote:
On 6/19/23 4:43 PM, olcott wrote:H correctly simulates N steps of D until H correctly predicts
The behavior of the directly executed P(P) is different than the >>>>>>>>> behavior of P(P) correctly simulated by H because in the first >>>>>>>>> case H
has already aborted its simulation of its input and in the
second case
this has not yet occurred.
By what definition of "Correctly Simulated"?
The fact that H aborts its simulation has NO affect on the
direct execution of the machine, so all you are saying that H
has shut its eyes and said "I don't see it, so it didn't happen". >>>>>>>>
That is just FALSEHOOD.
I now refer to P(P) as D(D).
Can D correctly simulated by H terminate normally?
No it cannot see the details below.
Which is not the question being asked. The fact that it is
impossible to design an H that can correctly simulate its input >>>>>>>> to a halting state just proves that H can not correctly decider >>>>>>>> that its input is Halting.
This does NOT mean that the input can't be Halting, just that H >>>>>>>> can never prove it.
IF H doesn't ever abort its simulation, then yes, the D built on >>>>>>>> that H is non-halting, but that H never gives that answer, so it >>>>>>>> is still wrong.
Each H gets a DIFFERENT D, since they include the H that the
"pathological test" is to be performed on, so the behavior of
one D built on a different H doesn't apply, and for correct
reasoning, you really need to give each one a different name.
Reusing the same name for different machine, and then trying to >>>>>>>> confuse which one is which is just a sign of being intentionally >>>>>>>> deceptive to try to tell a LIE.
The x86utm operating system based on an open source x86
emulator. This
system enables one C function to execute another C function in >>>>>>>>> debug
step mode. When H simulates D it creates a separate process
context for
D with its own memory, stack and virtual registers. H is able to >>>>>>>>> simulate D simulating itself, thus the only limit to recursive >>>>>>>>> simulations is RAM.
But D is not SPECIFIED in a seperate context, but share code
space with H, which means it fails to be truely distinctly, like >>>>>>>> a Turing Machine would be.
It is NOT a full "separate process context" as all the contexts >>>>>>>> share code space.
// The following is written in C
//
01 typedef int (*ptr)(); // pointer to int function
02 int H(ptr x, ptr y) // uses x86 emulator to simulate its >>>>>>>>> input
03
04 int D(ptr x)
05 {
06 int Halt_Status = H(x, x);
07 if (Halt_Status)
08 HERE: goto HERE;
09 return Halt_Status;
10 }
11
12 void main()
13 {
14 D(D);
15 }
D correctly simulated by H cannot possibly terminate normally >>>>>>>>> by reaching its own final state at line 09.
But D correctly simulated by a correct simulator would, at least >>>>>>>> as long as you are using an H that answer H(D,D) as 0, as you
claim.
through
the type of mathematical induction used by termination analyzers >>>>>>> that D
correctly simulated by H cannot possibly terminate normally.
But that is the wrong prediction. It needs to predict if the input >>>>>> when run will halt, as THAT is the Halting Question.
That is just like Jack's question posed to Jack, self-contradictory. >>>>> ChatGPT could understand that I am correct.
Nope, and you just seem too stupid to understand.
Thus, you are just admitting to working on POOP instead of
Halting, and ALL your statements are just LIES.
goes down
int factorial(int n)
{
if(n==0)
return(1);
return(n*factorial(n-1));
}
AProVE correctly determines that factorial(5) halts by
boiling the key behavior of entire function to this:
f(x) → f(x-1) :|: x > 0 && x <= 5
Wrong Question leads to incorrect answer, and all your work
the drain.
AProVE is the largest termination analysis project in the world.
Yes, and it probably uses the RIGHT question, will the program halt
when actually run.
It will probably also tell you that D(D) will Halt since H(D,D)
returns 0.
Thus, it likely shows you are wrong about everything.
When we use the criteria:
Can D correctly simulated by H ever terminate normally?
So you are ADMITTING to working on a different problem, and lying
about what you are doing. Thank you for being honest about that.
Ben is just pointing out the ERRORS in your logic
When Ben pointed out that H(P,P) reports that P(P) does not halt when
P(P) does halt this seems to be a contradiction to people that lack a complete understanding.
Because of this I changed the semantic meaning of a return value of 0
from H to mean either that P(P) does not halt or P(P) specifically
targets H to do the opposite of whatever Boolean value that H returns.
When H(P,P) reports that P correctly simulated by H cannot possibly
reach its own last instruction this is an easily verified fact, thus
P(P) does not halt from the point of view of H.
When H returns 0 for input P means either that P does not halt or
P specifically targets H to do the opposite of whatever Boolean
value that H returns not even people with little understanding can
say that this is contradictory.
The fact you can't see that just shows your lack of understanding.ChatGPT understood that Jack’s question is a self contradictory
question when posed to Jack.
ChatGPT further understood that this makes Jack’s question posed
to Jack an incorrect question.
ChatGPT also understood that because D was intentionally defined
to do the opposite of whatever Boolean value that H returned,
that D is a self-contradictory input for H.
ChatGPT:
“Therefore, based on the understanding that self-contradictory
questions lack a correct answer and are deemed incorrect, one could
argue that the halting problem's pathological input D can be
categorized as an incorrect question when posed to the halting
decider H.”
https://chat.openai.com/c/2aae46ef-e7be-444d-a046-b76c1f971c5a
It did not leap to this conclusion it took a lot of convincing.
ChatGPT is not biased towards rebuttal against the truth.
My human reviewers are biased towards rebuttal against the truth.
On 6/20/2023 1:20 PM, Richard Damon wrote:
On 6/20/23 1:46 PM, olcott wrote:Not at all. Not the least little bit.
On 6/20/2023 10:48 AM, Richard Damon wrote:
On 6/20/23 11:02 AM, olcott wrote:
On 6/20/2023 6:19 AM, Richard Damon wrote:
On 6/19/23 11:46 PM, olcott wrote:
On 6/19/2023 8:13 PM, Richard Damon wrote:
On 6/19/23 9:02 PM, olcott wrote:
On 6/19/2023 7:45 PM, Richard Damon wrote:
On 6/19/23 4:43 PM, olcott wrote:H correctly simulates N steps of D until H correctly predicts >>>>>>>>> through
The behavior of the directly executed P(P) is different than the >>>>>>>>>>> behavior of P(P) correctly simulated by H because in the >>>>>>>>>>> first case H
has already aborted its simulation of its input and in the >>>>>>>>>>> second case
this has not yet occurred.
By what definition of "Correctly Simulated"?
The fact that H aborts its simulation has NO affect on the >>>>>>>>>> direct execution of the machine, so all you are saying that H >>>>>>>>>> has shut its eyes and said "I don't see it, so it didn't happen". >>>>>>>>>>
That is just FALSEHOOD.
I now refer to P(P) as D(D).
Can D correctly simulated by H terminate normally?
No it cannot see the details below.
Which is not the question being asked. The fact that it is >>>>>>>>>> impossible to design an H that can correctly simulate its
input to a halting state just proves that H can not correctly >>>>>>>>>> decider that its input is Halting.
This does NOT mean that the input can't be Halting, just that >>>>>>>>>> H can never prove it.
IF H doesn't ever abort its simulation, then yes, the D built >>>>>>>>>> on that H is non-halting, but that H never gives that answer, >>>>>>>>>> so it is still wrong.
Each H gets a DIFFERENT D, since they include the H that the >>>>>>>>>> "pathological test" is to be performed on, so the behavior of >>>>>>>>>> one D built on a different H doesn't apply, and for correct >>>>>>>>>> reasoning, you really need to give each one a different name. >>>>>>>>>> Reusing the same name for different machine, and then trying >>>>>>>>>> to confuse which one is which is just a sign of being
intentionally deceptive to try to tell a LIE.
The x86utm operating system based on an open source x86
emulator. This
system enables one C function to execute another C function >>>>>>>>>>> in debug
step mode. When H simulates D it creates a separate process >>>>>>>>>>> context for
D with its own memory, stack and virtual registers. H is able to >>>>>>>>>>> simulate D simulating itself, thus the only limit to recursive >>>>>>>>>>> simulations is RAM.
But D is not SPECIFIED in a seperate context, but share code >>>>>>>>>> space with H, which means it fails to be truely distinctly, >>>>>>>>>> like a Turing Machine would be.
It is NOT a full "separate process context" as all the
contexts share code space.
// The following is written in C
//
01 typedef int (*ptr)(); // pointer to int function
02 int H(ptr x, ptr y) // uses x86 emulator to simulate its >>>>>>>>>>> input
03
04 int D(ptr x)
05 {
06 int Halt_Status = H(x, x);
07 if (Halt_Status)
08 HERE: goto HERE;
09 return Halt_Status;
10 }
11
12 void main()
13 {
14 D(D);
15 }
D correctly simulated by H cannot possibly terminate normally >>>>>>>>>>> by reaching its own final state at line 09.
But D correctly simulated by a correct simulator would, at >>>>>>>>>> least as long as you are using an H that answer H(D,D) as 0, >>>>>>>>>> as you claim.
the type of mathematical induction used by termination
analyzers that D
correctly simulated by H cannot possibly terminate normally.
But that is the wrong prediction. It needs to predict if the
input when run will halt, as THAT is the Halting Question.
That is just like Jack's question posed to Jack, self-contradictory. >>>>>>> ChatGPT could understand that I am correct.
Nope, and you just seem too stupid to understand.
Thus, you are just admitting to working on POOP instead of
Halting, and ALL your statements are just LIES.
the drain.
int factorial(int n)
{
if(n==0)
return(1);
return(n*factorial(n-1));
}
AProVE correctly determines that factorial(5) halts by
boiling the key behavior of entire function to this:
f(x) → f(x-1) :|: x > 0 && x <= 5
Wrong Question leads to incorrect answer, and all your work >>>>>>>> goes down
AProVE is the largest termination analysis project in the world.
Yes, and it probably uses the RIGHT question, will the program
halt when actually run.
It will probably also tell you that D(D) will Halt since H(D,D)
returns 0.
Thus, it likely shows you are wrong about everything.
When we use the criteria:
Can D correctly simulated by H ever terminate normally?
So you are ADMITTING to working on a different problem, and lying
about what you are doing. Thank you for being honest about that.
Ben is just pointing out the ERRORS in your logic
When Ben pointed out that H(P,P) reports that P(P) does not halt when
P(P) does halt this seems to be a contradiction to people that lack a
complete understanding.
NO, it is a TRUE statement. H is NOT a correct HALT DECIDER.
It might be a valid POOP decider with your altered criteria, but it
isn't correct as a Halt Decider.
You don't get to change the meaning of words, attempting to just shows
you are a liar.
Halting is a property of the original machine, not of the partial
simulation that H does.
Because of this I changed the semantic meaning of a return value of 0
from H to mean either that P(P) does not halt or P(P) specifically
targets H to do the opposite of whatever Boolean value that H returns.
Which means you H need to return BOTH a 0 and 1 at the same time,
A return value of 0 also indicates that input D intentionally targets
H by doing the opposite of whatever Boolean value that H returns.
Because this is a verified fact that D does do this H is necessarily
correct and there is no contradiction.
On 6/20/23 2:33 PM, olcott wrote:If I am the one that is a Liar then why did you already say that 1 is
On 6/20/2023 1:20 PM, Richard Damon wrote:
On 6/20/23 1:46 PM, olcott wrote:Not at all. Not the least little bit.
On 6/20/2023 10:48 AM, Richard Damon wrote:
On 6/20/23 11:02 AM, olcott wrote:
On 6/20/2023 6:19 AM, Richard Damon wrote:
On 6/19/23 11:46 PM, olcott wrote:
On 6/19/2023 8:13 PM, Richard Damon wrote:
On 6/19/23 9:02 PM, olcott wrote:
On 6/19/2023 7:45 PM, Richard Damon wrote:But that is the wrong prediction. It needs to predict if the >>>>>>>>> input when run will halt, as THAT is the Halting Question.
On 6/19/23 4:43 PM, olcott wrote:H correctly simulates N steps of D until H correctly predicts >>>>>>>>>> through
The behavior of the directly executed P(P) is different than >>>>>>>>>>>> the
behavior of P(P) correctly simulated by H because in the >>>>>>>>>>>> first case H
has already aborted its simulation of its input and in the >>>>>>>>>>>> second case
this has not yet occurred.
By what definition of "Correctly Simulated"?
The fact that H aborts its simulation has NO affect on the >>>>>>>>>>> direct execution of the machine, so all you are saying that H >>>>>>>>>>> has shut its eyes and said "I don't see it, so it didn't >>>>>>>>>>> happen".
That is just FALSEHOOD.
I now refer to P(P) as D(D).
Can D correctly simulated by H terminate normally?
No it cannot see the details below.
Which is not the question being asked. The fact that it is >>>>>>>>>>> impossible to design an H that can correctly simulate its >>>>>>>>>>> input to a halting state just proves that H can not correctly >>>>>>>>>>> decider that its input is Halting.
This does NOT mean that the input can't be Halting, just that >>>>>>>>>>> H can never prove it.
IF H doesn't ever abort its simulation, then yes, the D built >>>>>>>>>>> on that H is non-halting, but that H never gives that answer, >>>>>>>>>>> so it is still wrong.
Each H gets a DIFFERENT D, since they include the H that the >>>>>>>>>>> "pathological test" is to be performed on, so the behavior of >>>>>>>>>>> one D built on a different H doesn't apply, and for correct >>>>>>>>>>> reasoning, you really need to give each one a different name. >>>>>>>>>>> Reusing the same name for different machine, and then trying >>>>>>>>>>> to confuse which one is which is just a sign of being
intentionally deceptive to try to tell a LIE.
The x86utm operating system based on an open source x86 >>>>>>>>>>>> emulator. This
system enables one C function to execute another C function >>>>>>>>>>>> in debug
step mode. When H simulates D it creates a separate process >>>>>>>>>>>> context for
D with its own memory, stack and virtual registers. H is >>>>>>>>>>>> able to
simulate D simulating itself, thus the only limit to recursive >>>>>>>>>>>> simulations is RAM.
But D is not SPECIFIED in a seperate context, but share code >>>>>>>>>>> space with H, which means it fails to be truely distinctly, >>>>>>>>>>> like a Turing Machine would be.
It is NOT a full "separate process context" as all the
contexts share code space.
// The following is written in C
//
01 typedef int (*ptr)(); // pointer to int function
02 int H(ptr x, ptr y) // uses x86 emulator to simulate >>>>>>>>>>>> its input
03
04 int D(ptr x)
05 {
06 int Halt_Status = H(x, x);
07 if (Halt_Status)
08 HERE: goto HERE;
09 return Halt_Status;
10 }
11
12 void main()
13 {
14 D(D);
15 }
D correctly simulated by H cannot possibly terminate
normally by reaching its own final state at line 09.
But D correctly simulated by a correct simulator would, at >>>>>>>>>>> least as long as you are using an H that answer H(D,D) as 0, >>>>>>>>>>> as you claim.
the type of mathematical induction used by termination
analyzers that D
correctly simulated by H cannot possibly terminate normally. >>>>>>>>>
That is just like Jack's question posed to Jack,
self-contradictory.
ChatGPT could understand that I am correct.
Nope, and you just seem too stupid to understand.
Yes, and it probably uses the RIGHT question, will the program
Thus, you are just admitting to working on POOP instead of
Halting, and ALL your statements are just LIES.
the drain.
int factorial(int n)
{
if(n==0)
return(1);
return(n*factorial(n-1));
}
AProVE correctly determines that factorial(5) halts by
boiling the key behavior of entire function to this:
f(x) → f(x-1) :|: x > 0 && x <= 5
Wrong Question leads to incorrect answer, and all your work >>>>>>>>> goes down
AProVE is the largest termination analysis project in the world. >>>>>>>
halt when actually run.
It will probably also tell you that D(D) will Halt since H(D,D)
returns 0.
Thus, it likely shows you are wrong about everything.
When we use the criteria:
Can D correctly simulated by H ever terminate normally?
So you are ADMITTING to working on a different problem, and lying
about what you are doing. Thank you for being honest about that.
Ben is just pointing out the ERRORS in your logic
When Ben pointed out that H(P,P) reports that P(P) does not halt when
P(P) does halt this seems to be a contradiction to people that lack a
complete understanding.
NO, it is a TRUE statement. H is NOT a correct HALT DECIDER.
It might be a valid POOP decider with your altered criteria, but it
isn't correct as a Halt Decider.
You don't get to change the meaning of words, attempting to just
shows you are a liar.
Halting is a property of the original machine, not of the partial
simulation that H does.
Because of this I changed the semantic meaning of a return value of 0
from H to mean either that P(P) does not halt or P(P) specifically
targets H to do the opposite of whatever Boolean value that H returns.
Which means you H need to return BOTH a 0 and 1 at the same time,
A return value of 0 also indicates that input D intentionally targets
H by doing the opposite of whatever Boolean value that H returns.
But a return of 1 signals that it halts, which it does.
You don't seem to understand English.
The Halting Problem asks if the Machine Described by the input Halts.
It Does (for the H that you are cliaming to be correct)
Therefore, the correct answer is YES / Halting, and you are PROVED to be
a LIAR.
On 6/20/2023 3:32 PM, Richard Damon wrote:
On 6/20/23 2:33 PM, olcott wrote:If I am the one that is a Liar then why did you already say that 1 is
On 6/20/2023 1:20 PM, Richard Damon wrote:
On 6/20/23 1:46 PM, olcott wrote:Not at all. Not the least little bit.
On 6/20/2023 10:48 AM, Richard Damon wrote:
On 6/20/23 11:02 AM, olcott wrote:
On 6/20/2023 6:19 AM, Richard Damon wrote:
On 6/19/23 11:46 PM, olcott wrote:
On 6/19/2023 8:13 PM, Richard Damon wrote:
On 6/19/23 9:02 PM, olcott wrote:
On 6/19/2023 7:45 PM, Richard Damon wrote:But that is the wrong prediction. It needs to predict if the >>>>>>>>>> input when run will halt, as THAT is the Halting Question. >>>>>>>>>>
On 6/19/23 4:43 PM, olcott wrote:H correctly simulates N steps of D until H correctly predicts >>>>>>>>>>> through
The behavior of the directly executed P(P) is different >>>>>>>>>>>>> than the
behavior of P(P) correctly simulated by H because in the >>>>>>>>>>>>> first case H
has already aborted its simulation of its input and in the >>>>>>>>>>>>> second case
this has not yet occurred.
By what definition of "Correctly Simulated"?
The fact that H aborts its simulation has NO affect on the >>>>>>>>>>>> direct execution of the machine, so all you are saying that >>>>>>>>>>>> H has shut its eyes and said "I don't see it, so it didn't >>>>>>>>>>>> happen".
That is just FALSEHOOD.
I now refer to P(P) as D(D).
Can D correctly simulated by H terminate normally?
No it cannot see the details below.
Which is not the question being asked. The fact that it is >>>>>>>>>>>> impossible to design an H that can correctly simulate its >>>>>>>>>>>> input to a halting state just proves that H can not
correctly decider that its input is Halting.
This does NOT mean that the input can't be Halting, just >>>>>>>>>>>> that H can never prove it.
IF H doesn't ever abort its simulation, then yes, the D >>>>>>>>>>>> built on that H is non-halting, but that H never gives that >>>>>>>>>>>> answer, so it is still wrong.
Each H gets a DIFFERENT D, since they include the H that the >>>>>>>>>>>> "pathological test" is to be performed on, so the behavior >>>>>>>>>>>> of one D built on a different H doesn't apply, and for >>>>>>>>>>>> correct reasoning, you really need to give each one a
different name. Reusing the same name for different machine, >>>>>>>>>>>> and then trying to confuse which one is which is just a sign >>>>>>>>>>>> of being intentionally deceptive to try to tell a LIE. >>>>>>>>>>>>>
The x86utm operating system based on an open source x86 >>>>>>>>>>>>> emulator. This
system enables one C function to execute another C function >>>>>>>>>>>>> in debug
step mode. When H simulates D it creates a separate process >>>>>>>>>>>>> context for
D with its own memory, stack and virtual registers. H is >>>>>>>>>>>>> able to
simulate D simulating itself, thus the only limit to recursive >>>>>>>>>>>>> simulations is RAM.
But D is not SPECIFIED in a seperate context, but share code >>>>>>>>>>>> space with H, which means it fails to be truely distinctly, >>>>>>>>>>>> like a Turing Machine would be.
It is NOT a full "separate process context" as all the >>>>>>>>>>>> contexts share code space.
// The following is written in C
//
01 typedef int (*ptr)(); // pointer to int function
02 int H(ptr x, ptr y) // uses x86 emulator to simulate >>>>>>>>>>>>> its input
03
04 int D(ptr x)
05 {
06 int Halt_Status = H(x, x);
07 if (Halt_Status)
08 HERE: goto HERE;
09 return Halt_Status;
10 }
11
12 void main()
13 {
14 D(D);
15 }
D correctly simulated by H cannot possibly terminate >>>>>>>>>>>>> normally by reaching its own final state at line 09.
But D correctly simulated by a correct simulator would, at >>>>>>>>>>>> least as long as you are using an H that answer H(D,D) as 0, >>>>>>>>>>>> as you claim.
the type of mathematical induction used by termination
analyzers that D
correctly simulated by H cannot possibly terminate normally. >>>>>>>>>>
That is just like Jack's question posed to Jack,
self-contradictory.
ChatGPT could understand that I am correct.
Nope, and you just seem too stupid to understand.
Yes, and it probably uses the RIGHT question, will the program >>>>>>>> halt when actually run.
Thus, you are just admitting to working on POOP instead of >>>>>>>>>> Halting, and ALL your statements are just LIES.
the drain.
int factorial(int n)
{
if(n==0)
return(1);
return(n*factorial(n-1));
}
AProVE correctly determines that factorial(5) halts by
boiling the key behavior of entire function to this:
f(x) → f(x-1) :|: x > 0 && x <= 5
Wrong Question leads to incorrect answer, and all your work >>>>>>>>>> goes down
AProVE is the largest termination analysis project in the world. >>>>>>>>
It will probably also tell you that D(D) will Halt since H(D,D) >>>>>>>> returns 0.
Thus, it likely shows you are wrong about everything.
When we use the criteria:
Can D correctly simulated by H ever terminate normally?
So you are ADMITTING to working on a different problem, and lying
about what you are doing. Thank you for being honest about that.
Ben is just pointing out the ERRORS in your logic
When Ben pointed out that H(P,P) reports that P(P) does not halt when >>>>> P(P) does halt this seems to be a contradiction to people that lack a >>>>> complete understanding.
NO, it is a TRUE statement. H is NOT a correct HALT DECIDER.
It might be a valid POOP decider with your altered criteria, but it
isn't correct as a Halt Decider.
You don't get to change the meaning of words, attempting to just
shows you are a liar.
Halting is a property of the original machine, not of the partial
simulation that H does.
Which means you H need to return BOTH a 0 and 1 at the same time,
Because of this I changed the semantic meaning of a return value of 0 >>>>> from H to mean either that P(P) does not halt or P(P) specifically
targets H to do the opposite of whatever Boolean value that H returns. >>>>
A return value of 0 also indicates that input D intentionally targets
H by doing the opposite of whatever Boolean value that H returns.
But a return of 1 signals that it halts, which it does.
You don't seem to understand English.
The Halting Problem asks if the Machine Described by the input Halts.
It Does (for the H that you are cliaming to be correct)
Therefore, the correct answer is YES / Halting, and you are PROVED to
be a LIAR.
the wrong answer and are now saying that it is the right answer?
On 6/20/2023 3:46 PM, Richard Damon wrote:
On 6/20/23 4:38 PM, olcott wrote:What happens when H returns 1 to D?
On 6/20/2023 3:32 PM, Richard Damon wrote:
On 6/20/23 2:33 PM, olcott wrote:If I am the one that is a Liar then why did you already say that 1 is
On 6/20/2023 1:20 PM, Richard Damon wrote:
On 6/20/23 1:46 PM, olcott wrote:Not at all. Not the least little bit.
On 6/20/2023 10:48 AM, Richard Damon wrote:
On 6/20/23 11:02 AM, olcott wrote:
On 6/20/2023 6:19 AM, Richard Damon wrote:
On 6/19/23 11:46 PM, olcott wrote:
On 6/19/2023 8:13 PM, Richard Damon wrote:
On 6/19/23 9:02 PM, olcott wrote:
On 6/19/2023 7:45 PM, Richard Damon wrote:But that is the wrong prediction. It needs to predict if the >>>>>>>>>>>> input when run will halt, as THAT is the Halting Question. >>>>>>>>>>>>
On 6/19/23 4:43 PM, olcott wrote:H correctly simulates N steps of D until H correctly >>>>>>>>>>>>> predicts through
The behavior of the directly executed P(P) is different >>>>>>>>>>>>>>> than the
behavior of P(P) correctly simulated by H because in the >>>>>>>>>>>>>>> first case H
has already aborted its simulation of its input and in >>>>>>>>>>>>>>> the second case
this has not yet occurred.
By what definition of "Correctly Simulated"?
The fact that H aborts its simulation has NO affect on the >>>>>>>>>>>>>> direct execution of the machine, so all you are saying >>>>>>>>>>>>>> that H has shut its eyes and said "I don't see it, so it >>>>>>>>>>>>>> didn't happen".
That is just FALSEHOOD.
I now refer to P(P) as D(D).
Can D correctly simulated by H terminate normally? >>>>>>>>>>>>>>> No it cannot see the details below.
Which is not the question being asked. The fact that it is >>>>>>>>>>>>>> impossible to design an H that can correctly simulate its >>>>>>>>>>>>>> input to a halting state just proves that H can not >>>>>>>>>>>>>> correctly decider that its input is Halting.
This does NOT mean that the input can't be Halting, just >>>>>>>>>>>>>> that H can never prove it.
IF H doesn't ever abort its simulation, then yes, the D >>>>>>>>>>>>>> built on that H is non-halting, but that H never gives >>>>>>>>>>>>>> that answer, so it is still wrong.
Each H gets a DIFFERENT D, since they include the H that >>>>>>>>>>>>>> the "pathological test" is to be performed on, so the >>>>>>>>>>>>>> behavior of one D built on a different H doesn't apply, >>>>>>>>>>>>>> and for correct reasoning, you really need to give each >>>>>>>>>>>>>> one a different name. Reusing the same name for different >>>>>>>>>>>>>> machine, and then trying to confuse which one is which is >>>>>>>>>>>>>> just a sign of being intentionally deceptive to try to >>>>>>>>>>>>>> tell a LIE.
The x86utm operating system based on an open source x86 >>>>>>>>>>>>>>> emulator. This
system enables one C function to execute another C >>>>>>>>>>>>>>> function in debug
step mode. When H simulates D it creates a separate >>>>>>>>>>>>>>> process context for
D with its own memory, stack and virtual registers. H is >>>>>>>>>>>>>>> able to
simulate D simulating itself, thus the only limit to >>>>>>>>>>>>>>> recursive
simulations is RAM.
But D is not SPECIFIED in a seperate context, but share >>>>>>>>>>>>>> code space with H, which means it fails to be truely >>>>>>>>>>>>>> distinctly, like a Turing Machine would be.
It is NOT a full "separate process context" as all the >>>>>>>>>>>>>> contexts share code space.
But D correctly simulated by a correct simulator would, at >>>>>>>>>>>>>> least as long as you are using an H that answer H(D,D) as >>>>>>>>>>>>>> 0, as you claim.
// The following is written in C
//
01 typedef int (*ptr)(); // pointer to int function >>>>>>>>>>>>>>> 02 int H(ptr x, ptr y) // uses x86 emulator to simulate >>>>>>>>>>>>>>> its input
03
04 int D(ptr x)
05 {
06 int Halt_Status = H(x, x);
07 if (Halt_Status)
08 HERE: goto HERE;
09 return Halt_Status;
10 }
11
12 void main()
13 {
14 D(D);
15 }
D correctly simulated by H cannot possibly terminate >>>>>>>>>>>>>>> normally by reaching its own final state at line 09. >>>>>>>>>>>>>>
the type of mathematical induction used by termination >>>>>>>>>>>>> analyzers that D
correctly simulated by H cannot possibly terminate normally. >>>>>>>>>>>>
That is just like Jack's question posed to Jack,
self-contradictory.
ChatGPT could understand that I am correct.
Nope, and you just seem too stupid to understand.
Yes, and it probably uses the RIGHT question, will the program >>>>>>>>>> halt when actually run.
Thus, you are just admitting to working on POOP instead of >>>>>>>>>>>> Halting, and ALL your statements are just LIES.
the drain.
int factorial(int n)
{
if(n==0)
return(1);
return(n*factorial(n-1));
}
AProVE correctly determines that factorial(5) halts by >>>>>>>>>>>>> boiling the key behavior of entire function to this: >>>>>>>>>>>>> f(x) → f(x-1) :|: x > 0 && x <= 5
Wrong Question leads to incorrect answer, and all your >>>>>>>>>>>> work goes down
AProVE is the largest termination analysis project in the world. >>>>>>>>>>
It will probably also tell you that D(D) will Halt since
H(D,D) returns 0.
Thus, it likely shows you are wrong about everything.
When we use the criteria:
Can D correctly simulated by H ever terminate normally?
So you are ADMITTING to working on a different problem, and
lying about what you are doing. Thank you for being honest about >>>>>>>> that.
Ben is just pointing out the ERRORS in your logic
When Ben pointed out that H(P,P) reports that P(P) does not halt >>>>>>> when
P(P) does halt this seems to be a contradiction to people that
lack a
complete understanding.
NO, it is a TRUE statement. H is NOT a correct HALT DECIDER.
It might be a valid POOP decider with your altered criteria, but
it isn't correct as a Halt Decider.
You don't get to change the meaning of words, attempting to just
shows you are a liar.
Halting is a property of the original machine, not of the partial
simulation that H does.
Because of this I changed the semantic meaning of a return value >>>>>>> of 0
from H to mean either that P(P) does not halt or P(P) specifically >>>>>>> targets H to do the opposite of whatever Boolean value that H
returns.
Which means you H need to return BOTH a 0 and 1 at the same time,
A return value of 0 also indicates that input D intentionally targets >>>>> H by doing the opposite of whatever Boolean value that H returns.
But a return of 1 signals that it halts, which it does.
You don't seem to understand English.
The Halting Problem asks if the Machine Described by the input Halts.
It Does (for the H that you are cliaming to be correct)
Therefore, the correct answer is YES / Halting, and you are PROVED
to be a LIAR.
the wrong answer and are now saying that it is the right answer?
Where did I say that 1 is the wrong answer to THAT question.
On 6/20/23 4:38 PM, olcott wrote:
On 6/20/2023 3:32 PM, Richard Damon wrote:
On 6/20/23 2:33 PM, olcott wrote:If I am the one that is a Liar then why did you already say that 1 is
On 6/20/2023 1:20 PM, Richard Damon wrote:
On 6/20/23 1:46 PM, olcott wrote:Not at all. Not the least little bit.
On 6/20/2023 10:48 AM, Richard Damon wrote:
On 6/20/23 11:02 AM, olcott wrote:
On 6/20/2023 6:19 AM, Richard Damon wrote:
On 6/19/23 11:46 PM, olcott wrote:
On 6/19/2023 8:13 PM, Richard Damon wrote:
On 6/19/23 9:02 PM, olcott wrote:
On 6/19/2023 7:45 PM, Richard Damon wrote:But that is the wrong prediction. It needs to predict if the >>>>>>>>>>> input when run will halt, as THAT is the Halting Question. >>>>>>>>>>>
On 6/19/23 4:43 PM, olcott wrote:H correctly simulates N steps of D until H correctly
The behavior of the directly executed P(P) is different >>>>>>>>>>>>>> than the
behavior of P(P) correctly simulated by H because in the >>>>>>>>>>>>>> first case H
has already aborted its simulation of its input and in the >>>>>>>>>>>>>> second case
this has not yet occurred.
By what definition of "Correctly Simulated"?
The fact that H aborts its simulation has NO affect on the >>>>>>>>>>>>> direct execution of the machine, so all you are saying that >>>>>>>>>>>>> H has shut its eyes and said "I don't see it, so it didn't >>>>>>>>>>>>> happen".
That is just FALSEHOOD.
I now refer to P(P) as D(D).
Can D correctly simulated by H terminate normally? >>>>>>>>>>>>>> No it cannot see the details below.
Which is not the question being asked. The fact that it is >>>>>>>>>>>>> impossible to design an H that can correctly simulate its >>>>>>>>>>>>> input to a halting state just proves that H can not
correctly decider that its input is Halting.
This does NOT mean that the input can't be Halting, just >>>>>>>>>>>>> that H can never prove it.
IF H doesn't ever abort its simulation, then yes, the D >>>>>>>>>>>>> built on that H is non-halting, but that H never gives that >>>>>>>>>>>>> answer, so it is still wrong.
Each H gets a DIFFERENT D, since they include the H that >>>>>>>>>>>>> the "pathological test" is to be performed on, so the >>>>>>>>>>>>> behavior of one D built on a different H doesn't apply, and >>>>>>>>>>>>> for correct reasoning, you really need to give each one a >>>>>>>>>>>>> different name. Reusing the same name for different
machine, and then trying to confuse which one is which is >>>>>>>>>>>>> just a sign of being intentionally deceptive to try to tell >>>>>>>>>>>>> a LIE.
The x86utm operating system based on an open source x86 >>>>>>>>>>>>>> emulator. This
system enables one C function to execute another C >>>>>>>>>>>>>> function in debug
step mode. When H simulates D it creates a separate >>>>>>>>>>>>>> process context for
D with its own memory, stack and virtual registers. H is >>>>>>>>>>>>>> able to
simulate D simulating itself, thus the only limit to >>>>>>>>>>>>>> recursive
simulations is RAM.
But D is not SPECIFIED in a seperate context, but share >>>>>>>>>>>>> code space with H, which means it fails to be truely >>>>>>>>>>>>> distinctly, like a Turing Machine would be.
It is NOT a full "separate process context" as all the >>>>>>>>>>>>> contexts share code space.
But D correctly simulated by a correct simulator would, at >>>>>>>>>>>>> least as long as you are using an H that answer H(D,D) as >>>>>>>>>>>>> 0, as you claim.
// The following is written in C
//
01 typedef int (*ptr)(); // pointer to int function >>>>>>>>>>>>>> 02 int H(ptr x, ptr y) // uses x86 emulator to simulate >>>>>>>>>>>>>> its input
03
04 int D(ptr x)
05 {
06 int Halt_Status = H(x, x);
07 if (Halt_Status)
08 HERE: goto HERE;
09 return Halt_Status;
10 }
11
12 void main()
13 {
14 D(D);
15 }
D correctly simulated by H cannot possibly terminate >>>>>>>>>>>>>> normally by reaching its own final state at line 09. >>>>>>>>>>>>>
predicts through
the type of mathematical induction used by termination >>>>>>>>>>>> analyzers that D
correctly simulated by H cannot possibly terminate normally. >>>>>>>>>>>
That is just like Jack's question posed to Jack,
self-contradictory.
ChatGPT could understand that I am correct.
Nope, and you just seem too stupid to understand.
Yes, and it probably uses the RIGHT question, will the program >>>>>>>>> halt when actually run.
Thus, you are just admitting to working on POOP instead of >>>>>>>>>>> Halting, and ALL your statements are just LIES.
the drain.
int factorial(int n)
{
if(n==0)
return(1);
return(n*factorial(n-1));
}
AProVE correctly determines that factorial(5) halts by >>>>>>>>>>>> boiling the key behavior of entire function to this:
f(x) → f(x-1) :|: x > 0 && x <= 5
Wrong Question leads to incorrect answer, and all your >>>>>>>>>>> work goes down
AProVE is the largest termination analysis project in the world. >>>>>>>>>
It will probably also tell you that D(D) will Halt since H(D,D) >>>>>>>>> returns 0.
Thus, it likely shows you are wrong about everything.
When we use the criteria:
Can D correctly simulated by H ever terminate normally?
So you are ADMITTING to working on a different problem, and lying >>>>>>> about what you are doing. Thank you for being honest about that. >>>>>>>
Ben is just pointing out the ERRORS in your logic
When Ben pointed out that H(P,P) reports that P(P) does not halt when >>>>>> P(P) does halt this seems to be a contradiction to people that lack a >>>>>> complete understanding.
NO, it is a TRUE statement. H is NOT a correct HALT DECIDER.
It might be a valid POOP decider with your altered criteria, but it
isn't correct as a Halt Decider.
You don't get to change the meaning of words, attempting to just
shows you are a liar.
Halting is a property of the original machine, not of the partial
simulation that H does.
Because of this I changed the semantic meaning of a return value of 0 >>>>>> from H to mean either that P(P) does not halt or P(P) specifically >>>>>> targets H to do the opposite of whatever Boolean value that H
returns.
Which means you H need to return BOTH a 0 and 1 at the same time,
A return value of 0 also indicates that input D intentionally targets
H by doing the opposite of whatever Boolean value that H returns.
But a return of 1 signals that it halts, which it does.
You don't seem to understand English.
The Halting Problem asks if the Machine Described by the input Halts.
It Does (for the H that you are cliaming to be correct)
Therefore, the correct answer is YES / Halting, and you are PROVED to
be a LIAR.
the wrong answer and are now saying that it is the right answer?
Where did I say that 1 is the wrong answer to THAT question.
On 6/20/23 5:27 PM, olcott wrote:No H can possibly be defined that can be embedded within
On 6/20/2023 3:46 PM, Richard Damon wrote:
On 6/20/23 4:38 PM, olcott wrote:What happens when H returns 1 to D?
On 6/20/2023 3:32 PM, Richard Damon wrote:
On 6/20/23 2:33 PM, olcott wrote:If I am the one that is a Liar then why did you already say that 1 is
On 6/20/2023 1:20 PM, Richard Damon wrote:
On 6/20/23 1:46 PM, olcott wrote:A return value of 0 also indicates that input D intentionally targets >>>>>> H by doing the opposite of whatever Boolean value that H returns.
On 6/20/2023 10:48 AM, Richard Damon wrote:
On 6/20/23 11:02 AM, olcott wrote:
On 6/20/2023 6:19 AM, Richard Damon wrote:
On 6/19/23 11:46 PM, olcott wrote:
On 6/19/2023 8:13 PM, Richard Damon wrote:
On 6/19/23 9:02 PM, olcott wrote:
On 6/19/2023 7:45 PM, Richard Damon wrote:But that is the wrong prediction. It needs to predict if >>>>>>>>>>>>> the input when run will halt, as THAT is the Halting Question. >>>>>>>>>>>>>
On 6/19/23 4:43 PM, olcott wrote:H correctly simulates N steps of D until H correctly >>>>>>>>>>>>>> predicts through
The behavior of the directly executed P(P) is different >>>>>>>>>>>>>>>> than the
behavior of P(P) correctly simulated by H because in the >>>>>>>>>>>>>>>> first case H
has already aborted its simulation of its input and in >>>>>>>>>>>>>>>> the second case
this has not yet occurred.
By what definition of "Correctly Simulated"?
The fact that H aborts its simulation has NO affect on >>>>>>>>>>>>>>> the direct execution of the machine, so all you are >>>>>>>>>>>>>>> saying that H has shut its eyes and said "I don't see it, >>>>>>>>>>>>>>> so it didn't happen".
That is just FALSEHOOD.
I now refer to P(P) as D(D).
Can D correctly simulated by H terminate normally? >>>>>>>>>>>>>>>> No it cannot see the details below.
Which is not the question being asked. The fact that it >>>>>>>>>>>>>>> is impossible to design an H that can correctly simulate >>>>>>>>>>>>>>> its input to a halting state just proves that H can not >>>>>>>>>>>>>>> correctly decider that its input is Halting.
This does NOT mean that the input can't be Halting, just >>>>>>>>>>>>>>> that H can never prove it.
IF H doesn't ever abort its simulation, then yes, the D >>>>>>>>>>>>>>> built on that H is non-halting, but that H never gives >>>>>>>>>>>>>>> that answer, so it is still wrong.
Each H gets a DIFFERENT D, since they include the H that >>>>>>>>>>>>>>> the "pathological test" is to be performed on, so the >>>>>>>>>>>>>>> behavior of one D built on a different H doesn't apply, >>>>>>>>>>>>>>> and for correct reasoning, you really need to give each >>>>>>>>>>>>>>> one a different name. Reusing the same name for different >>>>>>>>>>>>>>> machine, and then trying to confuse which one is which is >>>>>>>>>>>>>>> just a sign of being intentionally deceptive to try to >>>>>>>>>>>>>>> tell a LIE.
The x86utm operating system based on an open source x86 >>>>>>>>>>>>>>>> emulator. This
system enables one C function to execute another C >>>>>>>>>>>>>>>> function in debug
step mode. When H simulates D it creates a separate >>>>>>>>>>>>>>>> process context for
D with its own memory, stack and virtual registers. H is >>>>>>>>>>>>>>>> able to
simulate D simulating itself, thus the only limit to >>>>>>>>>>>>>>>> recursive
simulations is RAM.
But D is not SPECIFIED in a seperate context, but share >>>>>>>>>>>>>>> code space with H, which means it fails to be truely >>>>>>>>>>>>>>> distinctly, like a Turing Machine would be.
It is NOT a full "separate process context" as all the >>>>>>>>>>>>>>> contexts share code space.
But D correctly simulated by a correct simulator would, >>>>>>>>>>>>>>> at least as long as you are using an H that answer H(D,D) >>>>>>>>>>>>>>> as 0, as you claim.
// The following is written in C
//
01 typedef int (*ptr)(); // pointer to int function >>>>>>>>>>>>>>>> 02 int H(ptr x, ptr y) // uses x86 emulator to >>>>>>>>>>>>>>>> simulate its input
03
04 int D(ptr x)
05 {
06 int Halt_Status = H(x, x);
07 if (Halt_Status)
08 HERE: goto HERE;
09 return Halt_Status;
10 }
11
12 void main()
13 {
14 D(D);
15 }
D correctly simulated by H cannot possibly terminate >>>>>>>>>>>>>>>> normally by reaching its own final state at line 09. >>>>>>>>>>>>>>>
the type of mathematical induction used by termination >>>>>>>>>>>>>> analyzers that D
correctly simulated by H cannot possibly terminate normally. >>>>>>>>>>>>>
That is just like Jack's question posed to Jack,
self-contradictory.
ChatGPT could understand that I am correct.
Nope, and you just seem too stupid to understand.
Thus, you are just admitting to working on POOP instead of >>>>>>>>>>>>> Halting, and ALL your statements are just LIES.
the drain.
int factorial(int n)
{
if(n==0)
return(1);
return(n*factorial(n-1));
}
AProVE correctly determines that factorial(5) halts by >>>>>>>>>>>>>> boiling the key behavior of entire function to this: >>>>>>>>>>>>>> f(x) → f(x-1) :|: x > 0 && x <= 5
Wrong Question leads to incorrect answer, and all your >>>>>>>>>>>>> work goes down
AProVE is the largest termination analysis project in the >>>>>>>>>>>> world.
Yes, and it probably uses the RIGHT question, will the
program halt when actually run.
It will probably also tell you that D(D) will Halt since >>>>>>>>>>> H(D,D) returns 0.
Thus, it likely shows you are wrong about everything.
When we use the criteria:
Can D correctly simulated by H ever terminate normally?
So you are ADMITTING to working on a different problem, and
lying about what you are doing. Thank you for being honest
about that.
Ben is just pointing out the ERRORS in your logic
When Ben pointed out that H(P,P) reports that P(P) does not halt >>>>>>>> when
P(P) does halt this seems to be a contradiction to people that >>>>>>>> lack a
complete understanding.
NO, it is a TRUE statement. H is NOT a correct HALT DECIDER.
It might be a valid POOP decider with your altered criteria, but >>>>>>> it isn't correct as a Halt Decider.
You don't get to change the meaning of words, attempting to just >>>>>>> shows you are a liar.
Halting is a property of the original machine, not of the partial >>>>>>> simulation that H does.
Because of this I changed the semantic meaning of a return value >>>>>>>> of 0
from H to mean either that P(P) does not halt or P(P) specifically >>>>>>>> targets H to do the opposite of whatever Boolean value that H
returns.
Which means you H need to return BOTH a 0 and 1 at the same time, >>>>>> Not at all. Not the least little bit.
But a return of 1 signals that it halts, which it does.
You don't seem to understand English.
The Halting Problem asks if the Machine Described by the input Halts. >>>>>
It Does (for the H that you are cliaming to be correct)
Therefore, the correct answer is YES / Halting, and you are PROVED
to be a LIAR.
the wrong answer and are now saying that it is the right answer?
Where did I say that 1 is the wrong answer to THAT question.
But it doesn't, so it doesn't matter.
On 6/20/2023 4:56 PM, Richard Damon wrote:
On 6/20/23 5:27 PM, olcott wrote:No H can possibly be defined that can be embedded within
On 6/20/2023 3:46 PM, Richard Damon wrote:
On 6/20/23 4:38 PM, olcott wrote:What happens when H returns 1 to D?
On 6/20/2023 3:32 PM, Richard Damon wrote:
On 6/20/23 2:33 PM, olcott wrote:If I am the one that is a Liar then why did you already say that 1 is >>>>> the wrong answer and are now saying that it is the right answer?
On 6/20/2023 1:20 PM, Richard Damon wrote:But a return of 1 signals that it halts, which it does.
On 6/20/23 1:46 PM, olcott wrote:A return value of 0 also indicates that input D intentionally
On 6/20/2023 10:48 AM, Richard Damon wrote:
On 6/20/23 11:02 AM, olcott wrote:
On 6/20/2023 6:19 AM, Richard Damon wrote:
On 6/19/23 11:46 PM, olcott wrote:
On 6/19/2023 8:13 PM, Richard Damon wrote:
On 6/19/23 9:02 PM, olcott wrote:
On 6/19/2023 7:45 PM, Richard Damon wrote:But that is the wrong prediction. It needs to predict if >>>>>>>>>>>>>> the input when run will halt, as THAT is the Halting >>>>>>>>>>>>>> Question.
On 6/19/23 4:43 PM, olcott wrote:H correctly simulates N steps of D until H correctly >>>>>>>>>>>>>>> predicts through
The behavior of the directly executed P(P) is different >>>>>>>>>>>>>>>>> than the
behavior of P(P) correctly simulated by H because in >>>>>>>>>>>>>>>>> the first case H
has already aborted its simulation of its input and in >>>>>>>>>>>>>>>>> the second case
this has not yet occurred.
By what definition of "Correctly Simulated"?
The fact that H aborts its simulation has NO affect on >>>>>>>>>>>>>>>> the direct execution of the machine, so all you are >>>>>>>>>>>>>>>> saying that H has shut its eyes and said "I don't see >>>>>>>>>>>>>>>> it, so it didn't happen".
That is just FALSEHOOD.
I now refer to P(P) as D(D).
Can D correctly simulated by H terminate normally? >>>>>>>>>>>>>>>>> No it cannot see the details below.
Which is not the question being asked. The fact that it >>>>>>>>>>>>>>>> is impossible to design an H that can correctly simulate >>>>>>>>>>>>>>>> its input to a halting state just proves that H can not >>>>>>>>>>>>>>>> correctly decider that its input is Halting.
This does NOT mean that the input can't be Halting, just >>>>>>>>>>>>>>>> that H can never prove it.
IF H doesn't ever abort its simulation, then yes, the D >>>>>>>>>>>>>>>> built on that H is non-halting, but that H never gives >>>>>>>>>>>>>>>> that answer, so it is still wrong.
Each H gets a DIFFERENT D, since they include the H that >>>>>>>>>>>>>>>> the "pathological test" is to be performed on, so the >>>>>>>>>>>>>>>> behavior of one D built on a different H doesn't apply, >>>>>>>>>>>>>>>> and for correct reasoning, you really need to give each >>>>>>>>>>>>>>>> one a different name. Reusing the same name for >>>>>>>>>>>>>>>> different machine, and then trying to confuse which one >>>>>>>>>>>>>>>> is which is just a sign of being intentionally deceptive >>>>>>>>>>>>>>>> to try to tell a LIE.
The x86utm operating system based on an open source x86 >>>>>>>>>>>>>>>>> emulator. This
system enables one C function to execute another C >>>>>>>>>>>>>>>>> function in debug
step mode. When H simulates D it creates a separate >>>>>>>>>>>>>>>>> process context for
D with its own memory, stack and virtual registers. H >>>>>>>>>>>>>>>>> is able to
simulate D simulating itself, thus the only limit to >>>>>>>>>>>>>>>>> recursive
simulations is RAM.
But D is not SPECIFIED in a seperate context, but share >>>>>>>>>>>>>>>> code space with H, which means it fails to be truely >>>>>>>>>>>>>>>> distinctly, like a Turing Machine would be.
It is NOT a full "separate process context" as all the >>>>>>>>>>>>>>>> contexts share code space.
But D correctly simulated by a correct simulator would, >>>>>>>>>>>>>>>> at least as long as you are using an H that answer >>>>>>>>>>>>>>>> H(D,D) as 0, as you claim.
// The following is written in C
//
01 typedef int (*ptr)(); // pointer to int function >>>>>>>>>>>>>>>>> 02 int H(ptr x, ptr y) // uses x86 emulator to >>>>>>>>>>>>>>>>> simulate its input
03
04 int D(ptr x)
05 {
06 int Halt_Status = H(x, x);
07 if (Halt_Status)
08 HERE: goto HERE;
09 return Halt_Status;
10 }
11
12 void main()
13 {
14 D(D);
15 }
D correctly simulated by H cannot possibly terminate >>>>>>>>>>>>>>>>> normally by reaching its own final state at line 09. >>>>>>>>>>>>>>>>
the type of mathematical induction used by termination >>>>>>>>>>>>>>> analyzers that D
correctly simulated by H cannot possibly terminate normally. >>>>>>>>>>>>>>
That is just like Jack's question posed to Jack,
self-contradictory.
ChatGPT could understand that I am correct.
Nope, and you just seem too stupid to understand.
Thus, you are just admitting to working on POOP instead of >>>>>>>>>>>>>> Halting, and ALL your statements are just LIES.
the drain.
int factorial(int n)
{
if(n==0)
return(1);
return(n*factorial(n-1));
}
AProVE correctly determines that factorial(5) halts by >>>>>>>>>>>>>>> boiling the key behavior of entire function to this: >>>>>>>>>>>>>>> f(x) → f(x-1) :|: x > 0 && x <= 5
Wrong Question leads to incorrect answer, and all your >>>>>>>>>>>>>> work goes down
AProVE is the largest termination analysis project in the >>>>>>>>>>>>> world.
Yes, and it probably uses the RIGHT question, will the >>>>>>>>>>>> program halt when actually run.
It will probably also tell you that D(D) will Halt since >>>>>>>>>>>> H(D,D) returns 0.
Thus, it likely shows you are wrong about everything.
When we use the criteria:
Can D correctly simulated by H ever terminate normally?
So you are ADMITTING to working on a different problem, and >>>>>>>>>> lying about what you are doing. Thank you for being honest >>>>>>>>>> about that.
Ben is just pointing out the ERRORS in your logic
When Ben pointed out that H(P,P) reports that P(P) does not
halt when
P(P) does halt this seems to be a contradiction to people that >>>>>>>>> lack a
complete understanding.
NO, it is a TRUE statement. H is NOT a correct HALT DECIDER.
It might be a valid POOP decider with your altered criteria, but >>>>>>>> it isn't correct as a Halt Decider.
You don't get to change the meaning of words, attempting to just >>>>>>>> shows you are a liar.
Halting is a property of the original machine, not of the
partial simulation that H does.
Because of this I changed the semantic meaning of a return
value of 0
from H to mean either that P(P) does not halt or P(P) specifically >>>>>>>>> targets H to do the opposite of whatever Boolean value that H >>>>>>>>> returns.
Which means you H need to return BOTH a 0 and 1 at the same time, >>>>>>> Not at all. Not the least little bit.
targets
H by doing the opposite of whatever Boolean value that H returns. >>>>>>
You don't seem to understand English.
The Halting Problem asks if the Machine Described by the input Halts. >>>>>>
It Does (for the H that you are cliaming to be correct)
Therefore, the correct answer is YES / Halting, and you are PROVED >>>>>> to be a LIAR.
Where did I say that 1 is the wrong answer to THAT question.
But it doesn't, so it doesn't matter.
Linz Ĥ such that embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to Ĥ.qy or Ĥ.qn consistently with the behavior of Ĥ applied to ⟨Ĥ⟩.
The reason for this is that Ĥ does the opposite of both
Ĥ.qy and Ĥ.qn. This makes the input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H self-contradictory for embedded_H.
You will not be able to explain why embedded_H cannot do
this for any reason other than the fact that the input
⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H is self-contradictory for embedded_H.
(a) Because it just can't dodges the question.
(b) Because the input is undecidable for H is equivalent to (a)
On 6/20/23 6:19 PM, olcott wrote:
On 6/20/2023 4:56 PM, Richard Damon wrote:
On 6/20/23 5:27 PM, olcott wrote:No H can possibly be defined that can be embedded within
On 6/20/2023 3:46 PM, Richard Damon wrote:
On 6/20/23 4:38 PM, olcott wrote:What happens when H returns 1 to D?
On 6/20/2023 3:32 PM, Richard Damon wrote:
On 6/20/23 2:33 PM, olcott wrote:If I am the one that is a Liar then why did you already say that 1 is >>>>>> the wrong answer and are now saying that it is the right answer?
On 6/20/2023 1:20 PM, Richard Damon wrote:But a return of 1 signals that it halts, which it does.
On 6/20/23 1:46 PM, olcott wrote:A return value of 0 also indicates that input D intentionally
On 6/20/2023 10:48 AM, Richard Damon wrote:
On 6/20/23 11:02 AM, olcott wrote:
On 6/20/2023 6:19 AM, Richard Damon wrote:So you are ADMITTING to working on a different problem, and >>>>>>>>>>> lying about what you are doing. Thank you for being honest >>>>>>>>>>> about that.
On 6/19/23 11:46 PM, olcott wrote:When we use the criteria:
On 6/19/2023 8:13 PM, Richard Damon wrote:
On 6/19/23 9:02 PM, olcott wrote:
On 6/19/2023 7:45 PM, Richard Damon wrote:
On 6/19/23 4:43 PM, olcott wrote:H correctly simulates N steps of D until H correctly >>>>>>>>>>>>>>>> predicts through
The behavior of the directly executed P(P) is >>>>>>>>>>>>>>>>>> different than the
behavior of P(P) correctly simulated by H because in >>>>>>>>>>>>>>>>>> the first case H
has already aborted its simulation of its input and in >>>>>>>>>>>>>>>>>> the second case
this has not yet occurred.
By what definition of "Correctly Simulated"? >>>>>>>>>>>>>>>>>
The fact that H aborts its simulation has NO affect on >>>>>>>>>>>>>>>>> the direct execution of the machine, so all you are >>>>>>>>>>>>>>>>> saying that H has shut its eyes and said "I don't see >>>>>>>>>>>>>>>>> it, so it didn't happen".
That is just FALSEHOOD.
I now refer to P(P) as D(D).
Can D correctly simulated by H terminate normally? >>>>>>>>>>>>>>>>>> No it cannot see the details below.
Which is not the question being asked. The fact that it >>>>>>>>>>>>>>>>> is impossible to design an H that can correctly >>>>>>>>>>>>>>>>> simulate its input to a halting state just proves that >>>>>>>>>>>>>>>>> H can not correctly decider that its input is Halting. >>>>>>>>>>>>>>>>>
This does NOT mean that the input can't be Halting, >>>>>>>>>>>>>>>>> just that H can never prove it.
IF H doesn't ever abort its simulation, then yes, the D >>>>>>>>>>>>>>>>> built on that H is non-halting, but that H never gives >>>>>>>>>>>>>>>>> that answer, so it is still wrong.
Each H gets a DIFFERENT D, since they include the H >>>>>>>>>>>>>>>>> that the "pathological test" is to be performed on, so >>>>>>>>>>>>>>>>> the behavior of one D built on a different H doesn't >>>>>>>>>>>>>>>>> apply, and for correct reasoning, you really need to >>>>>>>>>>>>>>>>> give each one a different name. Reusing the same name >>>>>>>>>>>>>>>>> for different machine, and then trying to confuse which >>>>>>>>>>>>>>>>> one is which is just a sign of being intentionally >>>>>>>>>>>>>>>>> deceptive to try to tell a LIE.
The x86utm operating system based on an open source >>>>>>>>>>>>>>>>>> x86 emulator. This
system enables one C function to execute another C >>>>>>>>>>>>>>>>>> function in debug
step mode. When H simulates D it creates a separate >>>>>>>>>>>>>>>>>> process context for
D with its own memory, stack and virtual registers. H >>>>>>>>>>>>>>>>>> is able to
simulate D simulating itself, thus the only limit to >>>>>>>>>>>>>>>>>> recursive
simulations is RAM.
But D is not SPECIFIED in a seperate context, but share >>>>>>>>>>>>>>>>> code space with H, which means it fails to be truely >>>>>>>>>>>>>>>>> distinctly, like a Turing Machine would be.
It is NOT a full "separate process context" as all the >>>>>>>>>>>>>>>>> contexts share code space.
But D correctly simulated by a correct simulator would, >>>>>>>>>>>>>>>>> at least as long as you are using an H that answer >>>>>>>>>>>>>>>>> H(D,D) as 0, as you claim.
// The following is written in C
//
01 typedef int (*ptr)(); // pointer to int function >>>>>>>>>>>>>>>>>> 02 int H(ptr x, ptr y) // uses x86 emulator to >>>>>>>>>>>>>>>>>> simulate its input
03
04 int D(ptr x)
05 {
06 int Halt_Status = H(x, x);
07 if (Halt_Status)
08 HERE: goto HERE;
09 return Halt_Status;
10 }
11
12 void main()
13 {
14 D(D);
15 }
D correctly simulated by H cannot possibly terminate >>>>>>>>>>>>>>>>>> normally by reaching its own final state at line 09. >>>>>>>>>>>>>>>>>
the type of mathematical induction used by termination >>>>>>>>>>>>>>>> analyzers that D
correctly simulated by H cannot possibly terminate >>>>>>>>>>>>>>>> normally.
But that is the wrong prediction. It needs to predict if >>>>>>>>>>>>>>> the input when run will halt, as THAT is the Halting >>>>>>>>>>>>>>> Question.
That is just like Jack's question posed to Jack,
self-contradictory.
ChatGPT could understand that I am correct.
Nope, and you just seem too stupid to understand.
Thus, you are just admitting to working on POOP instead >>>>>>>>>>>>>>> of Halting, and ALL your statements are just LIES. >>>>>>>>>>>>>>>
the drain.
int factorial(int n)
{
if(n==0)
return(1);
return(n*factorial(n-1));
}
AProVE correctly determines that factorial(5) halts by >>>>>>>>>>>>>>>> boiling the key behavior of entire function to this: >>>>>>>>>>>>>>>> f(x) → f(x-1) :|: x > 0 && x <= 5
Wrong Question leads to incorrect answer, and all your >>>>>>>>>>>>>>> work goes down
AProVE is the largest termination analysis project in the >>>>>>>>>>>>>> world.
Yes, and it probably uses the RIGHT question, will the >>>>>>>>>>>>> program halt when actually run.
It will probably also tell you that D(D) will Halt since >>>>>>>>>>>>> H(D,D) returns 0.
Thus, it likely shows you are wrong about everything. >>>>>>>>>>>>
Can D correctly simulated by H ever terminate normally? >>>>>>>>>>>
Ben is just pointing out the ERRORS in your logic
When Ben pointed out that H(P,P) reports that P(P) does not >>>>>>>>>> halt when
P(P) does halt this seems to be a contradiction to people that >>>>>>>>>> lack a
complete understanding.
NO, it is a TRUE statement. H is NOT a correct HALT DECIDER. >>>>>>>>>
It might be a valid POOP decider with your altered criteria, >>>>>>>>> but it isn't correct as a Halt Decider.
You don't get to change the meaning of words, attempting to
just shows you are a liar.
Halting is a property of the original machine, not of the
partial simulation that H does.
Because of this I changed the semantic meaning of a return >>>>>>>>>> value of 0
from H to mean either that P(P) does not halt or P(P)
specifically
targets H to do the opposite of whatever Boolean value that H >>>>>>>>>> returns.
Which means you H need to return BOTH a 0 and 1 at the same time, >>>>>>>> Not at all. Not the least little bit.
targets
H by doing the opposite of whatever Boolean value that H returns. >>>>>>>
You don't seem to understand English.
The Halting Problem asks if the Machine Described by the input
Halts.
It Does (for the H that you are cliaming to be correct)
Therefore, the correct answer is YES / Halting, and you are
PROVED to be a LIAR.
Where did I say that 1 is the wrong answer to THAT question.
But it doesn't, so it doesn't matter.
Linz Ĥ such that embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to Ĥ.qy or Ĥ.qn >> consistently with the behavior of Ĥ applied to ⟨Ĥ⟩.
Right, which is why it is impossible to make a correct Halt Decider.
The reason for this is that Ĥ does the opposite of both
Ĥ.qy and Ĥ.qn. This makes the input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H
self-contradictory for embedded_H.
Not SELF contradicotory, but just contradictory.
On 6/20/2023 5:52 PM, Richard Damon wrote:
On 6/20/23 6:19 PM, olcott wrote:
On 6/20/2023 4:56 PM, Richard Damon wrote:
On 6/20/23 5:27 PM, olcott wrote:No H can possibly be defined that can be embedded within
On 6/20/2023 3:46 PM, Richard Damon wrote:
On 6/20/23 4:38 PM, olcott wrote:What happens when H returns 1 to D?
On 6/20/2023 3:32 PM, Richard Damon wrote:
On 6/20/23 2:33 PM, olcott wrote:If I am the one that is a Liar then why did you already say that >>>>>>> 1 is
On 6/20/2023 1:20 PM, Richard Damon wrote:But a return of 1 signals that it halts, which it does.
On 6/20/23 1:46 PM, olcott wrote:A return value of 0 also indicates that input D intentionally >>>>>>>>> targets
On 6/20/2023 10:48 AM, Richard Damon wrote:
On 6/20/23 11:02 AM, olcott wrote:
On 6/20/2023 6:19 AM, Richard Damon wrote:So you are ADMITTING to working on a different problem, and >>>>>>>>>>>> lying about what you are doing. Thank you for being honest >>>>>>>>>>>> about that.
On 6/19/23 11:46 PM, olcott wrote:When we use the criteria:
On 6/19/2023 8:13 PM, Richard Damon wrote:
On 6/19/23 9:02 PM, olcott wrote:
On 6/19/2023 7:45 PM, Richard Damon wrote:
On 6/19/23 4:43 PM, olcott wrote:H correctly simulates N steps of D until H correctly >>>>>>>>>>>>>>>>> predicts through
The behavior of the directly executed P(P) is >>>>>>>>>>>>>>>>>>> different than the
behavior of P(P) correctly simulated by H because in >>>>>>>>>>>>>>>>>>> the first case H
has already aborted its simulation of its input and >>>>>>>>>>>>>>>>>>> in the second case
this has not yet occurred.
By what definition of "Correctly Simulated"? >>>>>>>>>>>>>>>>>>
The fact that H aborts its simulation has NO affect on >>>>>>>>>>>>>>>>>> the direct execution of the machine, so all you are >>>>>>>>>>>>>>>>>> saying that H has shut its eyes and said "I don't see >>>>>>>>>>>>>>>>>> it, so it didn't happen".
That is just FALSEHOOD.
I now refer to P(P) as D(D).
Can D correctly simulated by H terminate normally? >>>>>>>>>>>>>>>>>>> No it cannot see the details below.
Which is not the question being asked. The fact that >>>>>>>>>>>>>>>>>> it is impossible to design an H that can correctly >>>>>>>>>>>>>>>>>> simulate its input to a halting state just proves that >>>>>>>>>>>>>>>>>> H can not correctly decider that its input is Halting. >>>>>>>>>>>>>>>>>>
This does NOT mean that the input can't be Halting, >>>>>>>>>>>>>>>>>> just that H can never prove it.
IF H doesn't ever abort its simulation, then yes, the >>>>>>>>>>>>>>>>>> D built on that H is non-halting, but that H never >>>>>>>>>>>>>>>>>> gives that answer, so it is still wrong.
Each H gets a DIFFERENT D, since they include the H >>>>>>>>>>>>>>>>>> that the "pathological test" is to be performed on, so >>>>>>>>>>>>>>>>>> the behavior of one D built on a different H doesn't >>>>>>>>>>>>>>>>>> apply, and for correct reasoning, you really need to >>>>>>>>>>>>>>>>>> give each one a different name. Reusing the same name >>>>>>>>>>>>>>>>>> for different machine, and then trying to confuse >>>>>>>>>>>>>>>>>> which one is which is just a sign of being >>>>>>>>>>>>>>>>>> intentionally deceptive to try to tell a LIE. >>>>>>>>>>>>>>>>>>>
The x86utm operating system based on an open source >>>>>>>>>>>>>>>>>>> x86 emulator. This
system enables one C function to execute another C >>>>>>>>>>>>>>>>>>> function in debug
step mode. When H simulates D it creates a separate >>>>>>>>>>>>>>>>>>> process context for
D with its own memory, stack and virtual registers. H >>>>>>>>>>>>>>>>>>> is able to
simulate D simulating itself, thus the only limit to >>>>>>>>>>>>>>>>>>> recursive
simulations is RAM.
But D is not SPECIFIED in a seperate context, but >>>>>>>>>>>>>>>>>> share code space with H, which means it fails to be >>>>>>>>>>>>>>>>>> truely distinctly, like a Turing Machine would be. >>>>>>>>>>>>>>>>>>
It is NOT a full "separate process context" as all the >>>>>>>>>>>>>>>>>> contexts share code space.
But D correctly simulated by a correct simulator >>>>>>>>>>>>>>>>>> would, at least as long as you are using an H that >>>>>>>>>>>>>>>>>> answer H(D,D) as 0, as you claim.
// The following is written in C
//
01 typedef int (*ptr)(); // pointer to int function >>>>>>>>>>>>>>>>>>> 02 int H(ptr x, ptr y) // uses x86 emulator to >>>>>>>>>>>>>>>>>>> simulate its input
03
04 int D(ptr x)
05 {
06 int Halt_Status = H(x, x);
07 if (Halt_Status)
08 HERE: goto HERE;
09 return Halt_Status;
10 }
11
12 void main()
13 {
14 D(D);
15 }
D correctly simulated by H cannot possibly terminate >>>>>>>>>>>>>>>>>>> normally by reaching its own final state at line 09. >>>>>>>>>>>>>>>>>>
the type of mathematical induction used by termination >>>>>>>>>>>>>>>>> analyzers that D
correctly simulated by H cannot possibly terminate >>>>>>>>>>>>>>>>> normally.
But that is the wrong prediction. It needs to predict if >>>>>>>>>>>>>>>> the input when run will halt, as THAT is the Halting >>>>>>>>>>>>>>>> Question.
That is just like Jack's question posed to Jack, >>>>>>>>>>>>>>> self-contradictory.
ChatGPT could understand that I am correct.
Nope, and you just seem too stupid to understand.
Thus, you are just admitting to working on POOP instead >>>>>>>>>>>>>>>> of Halting, and ALL your statements are just LIES. >>>>>>>>>>>>>>>>
the drain.
int factorial(int n)
{
if(n==0)
return(1);
return(n*factorial(n-1));
}
AProVE correctly determines that factorial(5) halts by >>>>>>>>>>>>>>>>> boiling the key behavior of entire function to this: >>>>>>>>>>>>>>>>> f(x) → f(x-1) :|: x > 0 && x <= 5
Wrong Question leads to incorrect answer, and all >>>>>>>>>>>>>>>> your work goes down
AProVE is the largest termination analysis project in the >>>>>>>>>>>>>>> world.
Yes, and it probably uses the RIGHT question, will the >>>>>>>>>>>>>> program halt when actually run.
It will probably also tell you that D(D) will Halt since >>>>>>>>>>>>>> H(D,D) returns 0.
Thus, it likely shows you are wrong about everything. >>>>>>>>>>>>>
Can D correctly simulated by H ever terminate normally? >>>>>>>>>>>>
Ben is just pointing out the ERRORS in your logic
When Ben pointed out that H(P,P) reports that P(P) does not >>>>>>>>>>> halt when
P(P) does halt this seems to be a contradiction to people >>>>>>>>>>> that lack a
complete understanding.
NO, it is a TRUE statement. H is NOT a correct HALT DECIDER. >>>>>>>>>>
It might be a valid POOP decider with your altered criteria, >>>>>>>>>> but it isn't correct as a Halt Decider.
You don't get to change the meaning of words, attempting to >>>>>>>>>> just shows you are a liar.
Halting is a property of the original machine, not of the
partial simulation that H does.
Because of this I changed the semantic meaning of a return >>>>>>>>>>> value of 0
from H to mean either that P(P) does not halt or P(P)
specifically
targets H to do the opposite of whatever Boolean value that H >>>>>>>>>>> returns.
Which means you H need to return BOTH a 0 and 1 at the same time, >>>>>>>>> Not at all. Not the least little bit.
H by doing the opposite of whatever Boolean value that H returns. >>>>>>>>
You don't seem to understand English.
The Halting Problem asks if the Machine Described by the input >>>>>>>> Halts.
It Does (for the H that you are cliaming to be correct)
Therefore, the correct answer is YES / Halting, and you are
PROVED to be a LIAR.
the wrong answer and are now saying that it is the right answer? >>>>>>>
Where did I say that 1 is the wrong answer to THAT question.
But it doesn't, so it doesn't matter.
Linz Ĥ such that embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to Ĥ.qy or Ĥ.qn
consistently with the behavior of Ĥ applied to ⟨Ĥ⟩.
Right, which is why it is impossible to make a correct Halt Decider.
The reason for this is that Ĥ does the opposite of both
Ĥ.qy and Ĥ.qn. This makes the input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H
self-contradictory for embedded_H.
Not SELF contradicotory, but just contradictory.
OK that may make sense. One of our very rare agreements. The
question does not contradict itself it contradicts every answer.
Contradictory questions are also incorrect questions.
Likewise Jack's question contradicts every answer.
On 6/20/23 6:59 PM, olcott wrote:If this is true then you can say which of yes/no are correct for Jack to
On 6/20/2023 5:52 PM, Richard Damon wrote:
On 6/20/23 6:19 PM, olcott wrote:
On 6/20/2023 4:56 PM, Richard Damon wrote:
On 6/20/23 5:27 PM, olcott wrote:No H can possibly be defined that can be embedded within
On 6/20/2023 3:46 PM, Richard Damon wrote:
On 6/20/23 4:38 PM, olcott wrote:What happens when H returns 1 to D?
On 6/20/2023 3:32 PM, Richard Damon wrote:
On 6/20/23 2:33 PM, olcott wrote:If I am the one that is a Liar then why did you already say that >>>>>>>> 1 is
On 6/20/2023 1:20 PM, Richard Damon wrote:But a return of 1 signals that it halts, which it does.
On 6/20/23 1:46 PM, olcott wrote:Not at all. Not the least little bit.
On 6/20/2023 10:48 AM, Richard Damon wrote:
On 6/20/23 11:02 AM, olcott wrote:
On 6/20/2023 6:19 AM, Richard Damon wrote:So you are ADMITTING to working on a different problem, and >>>>>>>>>>>>> lying about what you are doing. Thank you for being honest >>>>>>>>>>>>> about that.
On 6/19/23 11:46 PM, olcott wrote:When we use the criteria:
On 6/19/2023 8:13 PM, Richard Damon wrote:
On 6/19/23 9:02 PM, olcott wrote:
On 6/19/2023 7:45 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>> On 6/19/23 4:43 PM, olcott wrote:
H correctly simulates N steps of D until H correctly >>>>>>>>>>>>>>>>>> predicts throughThe behavior of the directly executed P(P) is >>>>>>>>>>>>>>>>>>>> different than the
behavior of P(P) correctly simulated by H because in >>>>>>>>>>>>>>>>>>>> the first case H
has already aborted its simulation of its input and >>>>>>>>>>>>>>>>>>>> in the second case
this has not yet occurred.
By what definition of "Correctly Simulated"? >>>>>>>>>>>>>>>>>>>
The fact that H aborts its simulation has NO affect >>>>>>>>>>>>>>>>>>> on the direct execution of the machine, so all you >>>>>>>>>>>>>>>>>>> are saying that H has shut its eyes and said "I don't >>>>>>>>>>>>>>>>>>> see it, so it didn't happen".
That is just FALSEHOOD.
I now refer to P(P) as D(D).
Can D correctly simulated by H terminate normally? >>>>>>>>>>>>>>>>>>>> No it cannot see the details below.
Which is not the question being asked. The fact that >>>>>>>>>>>>>>>>>>> it is impossible to design an H that can correctly >>>>>>>>>>>>>>>>>>> simulate its input to a halting state just proves >>>>>>>>>>>>>>>>>>> that H can not correctly decider that its input is >>>>>>>>>>>>>>>>>>> Halting.
This does NOT mean that the input can't be Halting, >>>>>>>>>>>>>>>>>>> just that H can never prove it.
IF H doesn't ever abort its simulation, then yes, the >>>>>>>>>>>>>>>>>>> D built on that H is non-halting, but that H never >>>>>>>>>>>>>>>>>>> gives that answer, so it is still wrong. >>>>>>>>>>>>>>>>>>>
Each H gets a DIFFERENT D, since they include the H >>>>>>>>>>>>>>>>>>> that the "pathological test" is to be performed on, >>>>>>>>>>>>>>>>>>> so the behavior of one D built on a different H >>>>>>>>>>>>>>>>>>> doesn't apply, and for correct reasoning, you really >>>>>>>>>>>>>>>>>>> need to give each one a different name. Reusing the >>>>>>>>>>>>>>>>>>> same name for different machine, and then trying to >>>>>>>>>>>>>>>>>>> confuse which one is which is just a sign of being >>>>>>>>>>>>>>>>>>> intentionally deceptive to try to tell a LIE. >>>>>>>>>>>>>>>>>>>>
The x86utm operating system based on an open source >>>>>>>>>>>>>>>>>>>> x86 emulator. This
system enables one C function to execute another C >>>>>>>>>>>>>>>>>>>> function in debug
step mode. When H simulates D it creates a separate >>>>>>>>>>>>>>>>>>>> process context for
D with its own memory, stack and virtual registers. >>>>>>>>>>>>>>>>>>>> H is able to
simulate D simulating itself, thus the only limit to >>>>>>>>>>>>>>>>>>>> recursive
simulations is RAM.
But D is not SPECIFIED in a seperate context, but >>>>>>>>>>>>>>>>>>> share code space with H, which means it fails to be >>>>>>>>>>>>>>>>>>> truely distinctly, like a Turing Machine would be. >>>>>>>>>>>>>>>>>>>
It is NOT a full "separate process context" as all >>>>>>>>>>>>>>>>>>> the contexts share code space.
But D correctly simulated by a correct simulator >>>>>>>>>>>>>>>>>>> would, at least as long as you are using an H that >>>>>>>>>>>>>>>>>>> answer H(D,D) as 0, as you claim.
// The following is written in C
//
01 typedef int (*ptr)(); // pointer to int function >>>>>>>>>>>>>>>>>>>> 02 int H(ptr x, ptr y) // uses x86 emulator to >>>>>>>>>>>>>>>>>>>> simulate its input
03
04 int D(ptr x)
05 {
06 int Halt_Status = H(x, x);
07 if (Halt_Status)
08 HERE: goto HERE;
09 return Halt_Status;
10 }
11
12 void main()
13 {
14 D(D);
15 }
D correctly simulated by H cannot possibly terminate >>>>>>>>>>>>>>>>>>>> normally by reaching its own final state at line 09. >>>>>>>>>>>>>>>>>>>
the type of mathematical induction used by termination >>>>>>>>>>>>>>>>>> analyzers that D
correctly simulated by H cannot possibly terminate >>>>>>>>>>>>>>>>>> normally.
But that is the wrong prediction. It needs to predict >>>>>>>>>>>>>>>>> if the input when run will halt, as THAT is the Halting >>>>>>>>>>>>>>>>> Question.
That is just like Jack's question posed to Jack, >>>>>>>>>>>>>>>> self-contradictory.
ChatGPT could understand that I am correct.
Nope, and you just seem too stupid to understand. >>>>>>>>>>>>>>>
Thus, you are just admitting to working on POOP instead >>>>>>>>>>>>>>>>> of Halting, and ALL your statements are just LIES. >>>>>>>>>>>>>>>>>
the drain.
int factorial(int n)
{
if(n==0)
return(1);
return(n*factorial(n-1));
}
AProVE correctly determines that factorial(5) halts by >>>>>>>>>>>>>>>>>> boiling the key behavior of entire function to this: >>>>>>>>>>>>>>>>>> f(x) → f(x-1) :|: x > 0 && x <= 5
Wrong Question leads to incorrect answer, and all >>>>>>>>>>>>>>>>> your work goes down
AProVE is the largest termination analysis project in >>>>>>>>>>>>>>>> the world.
Yes, and it probably uses the RIGHT question, will the >>>>>>>>>>>>>>> program halt when actually run.
It will probably also tell you that D(D) will Halt since >>>>>>>>>>>>>>> H(D,D) returns 0.
Thus, it likely shows you are wrong about everything. >>>>>>>>>>>>>>
Can D correctly simulated by H ever terminate normally? >>>>>>>>>>>>>
Ben is just pointing out the ERRORS in your logic
When Ben pointed out that H(P,P) reports that P(P) does not >>>>>>>>>>>> halt when
P(P) does halt this seems to be a contradiction to people >>>>>>>>>>>> that lack a
complete understanding.
NO, it is a TRUE statement. H is NOT a correct HALT DECIDER. >>>>>>>>>>>
It might be a valid POOP decider with your altered criteria, >>>>>>>>>>> but it isn't correct as a Halt Decider.
You don't get to change the meaning of words, attempting to >>>>>>>>>>> just shows you are a liar.
Halting is a property of the original machine, not of the >>>>>>>>>>> partial simulation that H does.
Because of this I changed the semantic meaning of a return >>>>>>>>>>>> value of 0
from H to mean either that P(P) does not halt or P(P)
specifically
targets H to do the opposite of whatever Boolean value that >>>>>>>>>>>> H returns.
Which means you H need to return BOTH a 0 and 1 at the same >>>>>>>>>>> time,
A return value of 0 also indicates that input D intentionally >>>>>>>>>> targets
H by doing the opposite of whatever Boolean value that H returns. >>>>>>>>>
You don't seem to understand English.
The Halting Problem asks if the Machine Described by the input >>>>>>>>> Halts.
It Does (for the H that you are cliaming to be correct)
Therefore, the correct answer is YES / Halting, and you are
PROVED to be a LIAR.
the wrong answer and are now saying that it is the right answer? >>>>>>>>
Where did I say that 1 is the wrong answer to THAT question.
But it doesn't, so it doesn't matter.
Linz Ĥ such that embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to Ĥ.qy or Ĥ.qn
consistently with the behavior of Ĥ applied to ⟨Ĥ⟩.
Right, which is why it is impossible to make a correct Halt Decider.
The reason for this is that Ĥ does the opposite of both
Ĥ.qy and Ĥ.qn. This makes the input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H
self-contradictory for embedded_H.
Not SELF contradicotory, but just contradictory.
OK that may make sense. One of our very rare agreements. The
question does not contradict itself it contradicts every answer.
Contradictory questions are also incorrect questions.
Likewise Jack's question contradicts every answer.
It doesn't contradict the answer to the actual question,
On 6/20/2023 7:41 PM, Richard Damon wrote:
On 6/20/23 6:59 PM, olcott wrote:If this is true then you can say which of yes/no are correct for Jack to reply and which of true/false that H can return.
On 6/20/2023 5:52 PM, Richard Damon wrote:
On 6/20/23 6:19 PM, olcott wrote:
On 6/20/2023 4:56 PM, Richard Damon wrote:
On 6/20/23 5:27 PM, olcott wrote:No H can possibly be defined that can be embedded within
On 6/20/2023 3:46 PM, Richard Damon wrote:
On 6/20/23 4:38 PM, olcott wrote:What happens when H returns 1 to D?
On 6/20/2023 3:32 PM, Richard Damon wrote:
On 6/20/23 2:33 PM, olcott wrote:If I am the one that is a Liar then why did you already say
On 6/20/2023 1:20 PM, Richard Damon wrote:
On 6/20/23 1:46 PM, olcott wrote:Not at all. Not the least little bit.
On 6/20/2023 10:48 AM, Richard Damon wrote:
On 6/20/23 11:02 AM, olcott wrote:
On 6/20/2023 6:19 AM, Richard Damon wrote:So you are ADMITTING to working on a different problem, >>>>>>>>>>>>>> and lying about what you are doing. Thank you for being >>>>>>>>>>>>>> honest about that.
On 6/19/23 11:46 PM, olcott wrote:When we use the criteria:
On 6/19/2023 8:13 PM, Richard Damon wrote:
On 6/19/23 9:02 PM, olcott wrote:
On 6/19/2023 7:45 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 6/19/23 4:43 PM, olcott wrote:
H correctly simulates N steps of D until H correctly >>>>>>>>>>>>>>>>>>> predicts throughThe behavior of the directly executed P(P) is >>>>>>>>>>>>>>>>>>>>> different than the
behavior of P(P) correctly simulated by H because >>>>>>>>>>>>>>>>>>>>> in the first case H
has already aborted its simulation of its input and >>>>>>>>>>>>>>>>>>>>> in the second case
this has not yet occurred.
By what definition of "Correctly Simulated"? >>>>>>>>>>>>>>>>>>>>
The fact that H aborts its simulation has NO affect >>>>>>>>>>>>>>>>>>>> on the direct execution of the machine, so all you >>>>>>>>>>>>>>>>>>>> are saying that H has shut its eyes and said "I >>>>>>>>>>>>>>>>>>>> don't see it, so it didn't happen".
That is just FALSEHOOD.
I now refer to P(P) as D(D).
Can D correctly simulated by H terminate normally? >>>>>>>>>>>>>>>>>>>>> No it cannot see the details below.
Which is not the question being asked. The fact that >>>>>>>>>>>>>>>>>>>> it is impossible to design an H that can correctly >>>>>>>>>>>>>>>>>>>> simulate its input to a halting state just proves >>>>>>>>>>>>>>>>>>>> that H can not correctly decider that its input is >>>>>>>>>>>>>>>>>>>> Halting.
This does NOT mean that the input can't be Halting, >>>>>>>>>>>>>>>>>>>> just that H can never prove it.
IF H doesn't ever abort its simulation, then yes, >>>>>>>>>>>>>>>>>>>> the D built on that H is non-halting, but that H >>>>>>>>>>>>>>>>>>>> never gives that answer, so it is still wrong. >>>>>>>>>>>>>>>>>>>>
Each H gets a DIFFERENT D, since they include the H >>>>>>>>>>>>>>>>>>>> that the "pathological test" is to be performed on, >>>>>>>>>>>>>>>>>>>> so the behavior of one D built on a different H >>>>>>>>>>>>>>>>>>>> doesn't apply, and for correct reasoning, you really >>>>>>>>>>>>>>>>>>>> need to give each one a different name. Reusing the >>>>>>>>>>>>>>>>>>>> same name for different machine, and then trying to >>>>>>>>>>>>>>>>>>>> confuse which one is which is just a sign of being >>>>>>>>>>>>>>>>>>>> intentionally deceptive to try to tell a LIE. >>>>>>>>>>>>>>>>>>>>>
The x86utm operating system based on an open source >>>>>>>>>>>>>>>>>>>>> x86 emulator. This
system enables one C function to execute another C >>>>>>>>>>>>>>>>>>>>> function in debug
step mode. When H simulates D it creates a separate >>>>>>>>>>>>>>>>>>>>> process context for
D with its own memory, stack and virtual registers. >>>>>>>>>>>>>>>>>>>>> H is able to
simulate D simulating itself, thus the only limit >>>>>>>>>>>>>>>>>>>>> to recursive
simulations is RAM.
But D is not SPECIFIED in a seperate context, but >>>>>>>>>>>>>>>>>>>> share code space with H, which means it fails to be >>>>>>>>>>>>>>>>>>>> truely distinctly, like a Turing Machine would be. >>>>>>>>>>>>>>>>>>>>
It is NOT a full "separate process context" as all >>>>>>>>>>>>>>>>>>>> the contexts share code space.
// The following is written in C
//
01 typedef int (*ptr)(); // pointer to int function >>>>>>>>>>>>>>>>>>>>> 02 int H(ptr x, ptr y) // uses x86 emulator to >>>>>>>>>>>>>>>>>>>>> simulate its input
03
04 int D(ptr x)
05 {
06 int Halt_Status = H(x, x);
07 if (Halt_Status)
08 HERE: goto HERE;
09 return Halt_Status;
10 }
11
12 void main()
13 {
14 D(D);
15 }
D correctly simulated by H cannot possibly >>>>>>>>>>>>>>>>>>>>> terminate normally by reaching its own final state >>>>>>>>>>>>>>>>>>>>> at line 09.
But D correctly simulated by a correct simulator >>>>>>>>>>>>>>>>>>>> would, at least as long as you are using an H that >>>>>>>>>>>>>>>>>>>> answer H(D,D) as 0, as you claim.
the type of mathematical induction used by >>>>>>>>>>>>>>>>>>> termination analyzers that D
correctly simulated by H cannot possibly terminate >>>>>>>>>>>>>>>>>>> normally.
But that is the wrong prediction. It needs to predict >>>>>>>>>>>>>>>>>> if the input when run will halt, as THAT is the >>>>>>>>>>>>>>>>>> Halting Question.
That is just like Jack's question posed to Jack, >>>>>>>>>>>>>>>>> self-contradictory.
ChatGPT could understand that I am correct.
Nope, and you just seem too stupid to understand. >>>>>>>>>>>>>>>>
Thus, you are just admitting to working on POOP >>>>>>>>>>>>>>>>>> instead of Halting, and ALL your statements are just >>>>>>>>>>>>>>>>>> LIES.
the drain.
int factorial(int n)
{
if(n==0)
return(1);
return(n*factorial(n-1));
}
AProVE correctly determines that factorial(5) halts by >>>>>>>>>>>>>>>>>>> boiling the key behavior of entire function to this: >>>>>>>>>>>>>>>>>>> f(x) → f(x-1) :|: x > 0 && x <= 5
Wrong Question leads to incorrect answer, and all >>>>>>>>>>>>>>>>>> your work goes down
AProVE is the largest termination analysis project in >>>>>>>>>>>>>>>>> the world.
Yes, and it probably uses the RIGHT question, will the >>>>>>>>>>>>>>>> program halt when actually run.
It will probably also tell you that D(D) will Halt since >>>>>>>>>>>>>>>> H(D,D) returns 0.
Thus, it likely shows you are wrong about everything. >>>>>>>>>>>>>>>
Can D correctly simulated by H ever terminate normally? >>>>>>>>>>>>>>
Ben is just pointing out the ERRORS in your logic
When Ben pointed out that H(P,P) reports that P(P) does not >>>>>>>>>>>>> halt when
P(P) does halt this seems to be a contradiction to people >>>>>>>>>>>>> that lack a
complete understanding.
NO, it is a TRUE statement. H is NOT a correct HALT DECIDER. >>>>>>>>>>>>
It might be a valid POOP decider with your altered criteria, >>>>>>>>>>>> but it isn't correct as a Halt Decider.
You don't get to change the meaning of words, attempting to >>>>>>>>>>>> just shows you are a liar.
Halting is a property of the original machine, not of the >>>>>>>>>>>> partial simulation that H does.
Because of this I changed the semantic meaning of a return >>>>>>>>>>>>> value of 0
from H to mean either that P(P) does not halt or P(P) >>>>>>>>>>>>> specifically
targets H to do the opposite of whatever Boolean value that >>>>>>>>>>>>> H returns.
Which means you H need to return BOTH a 0 and 1 at the same >>>>>>>>>>>> time,
A return value of 0 also indicates that input D intentionally >>>>>>>>>>> targets
H by doing the opposite of whatever Boolean value that H >>>>>>>>>>> returns.
But a return of 1 signals that it halts, which it does.
You don't seem to understand English.
The Halting Problem asks if the Machine Described by the input >>>>>>>>>> Halts.
It Does (for the H that you are cliaming to be correct)
Therefore, the correct answer is YES / Halting, and you are >>>>>>>>>> PROVED to be a LIAR.
that 1 is
the wrong answer and are now saying that it is the right answer? >>>>>>>>>
Where did I say that 1 is the wrong answer to THAT question.
But it doesn't, so it doesn't matter.
Linz Ĥ such that embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to Ĥ.qy or Ĥ.qn
consistently with the behavior of Ĥ applied to ⟨Ĥ⟩.
Right, which is why it is impossible to make a correct Halt Decider.
The reason for this is that Ĥ does the opposite of both
Ĥ.qy and Ĥ.qn. This makes the input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H >>>>> self-contradictory for embedded_H.
Not SELF contradicotory, but just contradictory.
OK that may make sense. One of our very rare agreements. The
question does not contradict itself it contradicts every answer.
Contradictory questions are also incorrect questions.
Likewise Jack's question contradicts every answer.
It doesn't contradict the answer to the actual question,
On 6/20/23 9:36 PM, olcott wrote:
On 6/20/2023 7:41 PM, Richard Damon wrote:
On 6/20/23 6:59 PM, olcott wrote:If this is true then you can say which of yes/no are correct for Jack to
On 6/20/2023 5:52 PM, Richard Damon wrote:
On 6/20/23 6:19 PM, olcott wrote:
On 6/20/2023 4:56 PM, Richard Damon wrote:
On 6/20/23 5:27 PM, olcott wrote:No H can possibly be defined that can be embedded within
On 6/20/2023 3:46 PM, Richard Damon wrote:
On 6/20/23 4:38 PM, olcott wrote:What happens when H returns 1 to D?
On 6/20/2023 3:32 PM, Richard Damon wrote:
On 6/20/23 2:33 PM, olcott wrote:If I am the one that is a Liar then why did you already say >>>>>>>>>> that 1 is
On 6/20/2023 1:20 PM, Richard Damon wrote:
On 6/20/23 1:46 PM, olcott wrote:Not at all. Not the least little bit.
On 6/20/2023 10:48 AM, Richard Damon wrote:
On 6/20/23 11:02 AM, olcott wrote:
On 6/20/2023 6:19 AM, Richard Damon wrote:So you are ADMITTING to working on a different problem, >>>>>>>>>>>>>>> and lying about what you are doing. Thank you for being >>>>>>>>>>>>>>> honest about that.
On 6/19/23 11:46 PM, olcott wrote:When we use the criteria:
On 6/19/2023 8:13 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>> On 6/19/23 9:02 PM, olcott wrote:Nope, and you just seem too stupid to understand. >>>>>>>>>>>>>>>>>
On 6/19/2023 7:45 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>> On 6/19/23 4:43 PM, olcott wrote:
H correctly simulates N steps of D until H correctly >>>>>>>>>>>>>>>>>>>> predicts throughThe behavior of the directly executed P(P) is >>>>>>>>>>>>>>>>>>>>>> different than the
behavior of P(P) correctly simulated by H because >>>>>>>>>>>>>>>>>>>>>> in the first case H
has already aborted its simulation of its input >>>>>>>>>>>>>>>>>>>>>> and in the second case
this has not yet occurred.
By what definition of "Correctly Simulated"? >>>>>>>>>>>>>>>>>>>>>
The fact that H aborts its simulation has NO affect >>>>>>>>>>>>>>>>>>>>> on the direct execution of the machine, so all you >>>>>>>>>>>>>>>>>>>>> are saying that H has shut its eyes and said "I >>>>>>>>>>>>>>>>>>>>> don't see it, so it didn't happen".
That is just FALSEHOOD.
Which is not the question being asked. The fact >>>>>>>>>>>>>>>>>>>>> that it is impossible to design an H that can >>>>>>>>>>>>>>>>>>>>> correctly simulate its input to a halting state >>>>>>>>>>>>>>>>>>>>> just proves that H can not correctly decider that >>>>>>>>>>>>>>>>>>>>> its input is Halting.
I now refer to P(P) as D(D).
Can D correctly simulated by H terminate normally? >>>>>>>>>>>>>>>>>>>>>> No it cannot see the details below. >>>>>>>>>>>>>>>>>>>>>
This does NOT mean that the input can't be Halting, >>>>>>>>>>>>>>>>>>>>> just that H can never prove it.
IF H doesn't ever abort its simulation, then yes, >>>>>>>>>>>>>>>>>>>>> the D built on that H is non-halting, but that H >>>>>>>>>>>>>>>>>>>>> never gives that answer, so it is still wrong. >>>>>>>>>>>>>>>>>>>>>
Each H gets a DIFFERENT D, since they include the H >>>>>>>>>>>>>>>>>>>>> that the "pathological test" is to be performed on, >>>>>>>>>>>>>>>>>>>>> so the behavior of one D built on a different H >>>>>>>>>>>>>>>>>>>>> doesn't apply, and for correct reasoning, you >>>>>>>>>>>>>>>>>>>>> really need to give each one a different name. >>>>>>>>>>>>>>>>>>>>> Reusing the same name for different machine, and >>>>>>>>>>>>>>>>>>>>> then trying to confuse which one is which is just a >>>>>>>>>>>>>>>>>>>>> sign of being intentionally deceptive to try to >>>>>>>>>>>>>>>>>>>>> tell a LIE.
The x86utm operating system based on an open >>>>>>>>>>>>>>>>>>>>>> source x86 emulator. This
system enables one C function to execute another C >>>>>>>>>>>>>>>>>>>>>> function in debug
step mode. When H simulates D it creates a >>>>>>>>>>>>>>>>>>>>>> separate process context for
D with its own memory, stack and virtual >>>>>>>>>>>>>>>>>>>>>> registers. H is able to
simulate D simulating itself, thus the only limit >>>>>>>>>>>>>>>>>>>>>> to recursive
simulations is RAM.
But D is not SPECIFIED in a seperate context, but >>>>>>>>>>>>>>>>>>>>> share code space with H, which means it fails to be >>>>>>>>>>>>>>>>>>>>> truely distinctly, like a Turing Machine would be. >>>>>>>>>>>>>>>>>>>>>
It is NOT a full "separate process context" as all >>>>>>>>>>>>>>>>>>>>> the contexts share code space.
// The following is written in C
//
01 typedef int (*ptr)(); // pointer to int function >>>>>>>>>>>>>>>>>>>>>> 02 int H(ptr x, ptr y) // uses x86 emulator to >>>>>>>>>>>>>>>>>>>>>> simulate its input
03
04 int D(ptr x)
05 {
06 int Halt_Status = H(x, x);
07 if (Halt_Status)
08 HERE: goto HERE;
09 return Halt_Status;
10 }
11
12 void main()
13 {
14 D(D);
15 }
D correctly simulated by H cannot possibly >>>>>>>>>>>>>>>>>>>>>> terminate normally by reaching its own final state >>>>>>>>>>>>>>>>>>>>>> at line 09.
But D correctly simulated by a correct simulator >>>>>>>>>>>>>>>>>>>>> would, at least as long as you are using an H that >>>>>>>>>>>>>>>>>>>>> answer H(D,D) as 0, as you claim.
the type of mathematical induction used by >>>>>>>>>>>>>>>>>>>> termination analyzers that D
correctly simulated by H cannot possibly terminate >>>>>>>>>>>>>>>>>>>> normally.
But that is the wrong prediction. It needs to predict >>>>>>>>>>>>>>>>>>> if the input when run will halt, as THAT is the >>>>>>>>>>>>>>>>>>> Halting Question.
That is just like Jack's question posed to Jack, >>>>>>>>>>>>>>>>>> self-contradictory.
ChatGPT could understand that I am correct. >>>>>>>>>>>>>>>>>
Thus, you are just admitting to working on POOP >>>>>>>>>>>>>>>>>>> instead of Halting, and ALL your statements are just >>>>>>>>>>>>>>>>>>> LIES.
the drain.
int factorial(int n)
{
if(n==0)
return(1);
return(n*factorial(n-1));
}
AProVE correctly determines that factorial(5) halts by >>>>>>>>>>>>>>>>>>>> boiling the key behavior of entire function to this: >>>>>>>>>>>>>>>>>>>> f(x) → f(x-1) :|: x > 0 && x <= 5
Wrong Question leads to incorrect answer, and all >>>>>>>>>>>>>>>>>>> your work goes down
AProVE is the largest termination analysis project in >>>>>>>>>>>>>>>>>> the world.
Yes, and it probably uses the RIGHT question, will the >>>>>>>>>>>>>>>>> program halt when actually run.
It will probably also tell you that D(D) will Halt >>>>>>>>>>>>>>>>> since H(D,D) returns 0.
Thus, it likely shows you are wrong about everything. >>>>>>>>>>>>>>>>
Can D correctly simulated by H ever terminate normally? >>>>>>>>>>>>>>>
Ben is just pointing out the ERRORS in your logic >>>>>>>>>>>>>>>
When Ben pointed out that H(P,P) reports that P(P) does >>>>>>>>>>>>>> not halt when
P(P) does halt this seems to be a contradiction to people >>>>>>>>>>>>>> that lack a
complete understanding.
NO, it is a TRUE statement. H is NOT a correct HALT DECIDER. >>>>>>>>>>>>>
It might be a valid POOP decider with your altered
criteria, but it isn't correct as a Halt Decider.
You don't get to change the meaning of words, attempting to >>>>>>>>>>>>> just shows you are a liar.
Halting is a property of the original machine, not of the >>>>>>>>>>>>> partial simulation that H does.
Because of this I changed the semantic meaning of a return >>>>>>>>>>>>>> value of 0
from H to mean either that P(P) does not halt or P(P) >>>>>>>>>>>>>> specifically
targets H to do the opposite of whatever Boolean value >>>>>>>>>>>>>> that H returns.
Which means you H need to return BOTH a 0 and 1 at the same >>>>>>>>>>>>> time,
A return value of 0 also indicates that input D
intentionally targets
H by doing the opposite of whatever Boolean value that H >>>>>>>>>>>> returns.
But a return of 1 signals that it halts, which it does.
You don't seem to understand English.
The Halting Problem asks if the Machine Described by the >>>>>>>>>>> input Halts.
It Does (for the H that you are cliaming to be correct)
Therefore, the correct answer is YES / Halting, and you are >>>>>>>>>>> PROVED to be a LIAR.
the wrong answer and are now saying that it is the right answer? >>>>>>>>>>
Where did I say that 1 is the wrong answer to THAT question. >>>>>>>>>
But it doesn't, so it doesn't matter.
Linz Ĥ such that embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to Ĥ.qy or Ĥ.qn
consistently with the behavior of Ĥ applied to ⟨Ĥ⟩.
Right, which is why it is impossible to make a correct Halt Decider. >>>>>
The reason for this is that Ĥ does the opposite of both
Ĥ.qy and Ĥ.qn. This makes the input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H >>>>>> self-contradictory for embedded_H.
Not SELF contradicotory, but just contradictory.
OK that may make sense. One of our very rare agreements. The
question does not contradict itself it contradicts every answer.
Contradictory questions are also incorrect questions.
Likewise Jack's question contradicts every answer.
It doesn't contradict the answer to the actual question,
reply and which of true/false that H can return.
SO, you are just to dumb to understand
On 6/20/2023 9:32 PM, Richard Damon wrote:
On 6/20/23 9:36 PM, olcott wrote:
On 6/20/2023 7:41 PM, Richard Damon wrote:
On 6/20/23 6:59 PM, olcott wrote:If this is true then you can say which of yes/no are correct for Jack to >>> reply and which of true/false that H can return.
On 6/20/2023 5:52 PM, Richard Damon wrote:
On 6/20/23 6:19 PM, olcott wrote:
On 6/20/2023 4:56 PM, Richard Damon wrote:
On 6/20/23 5:27 PM, olcott wrote:No H can possibly be defined that can be embedded within
On 6/20/2023 3:46 PM, Richard Damon wrote:
On 6/20/23 4:38 PM, olcott wrote:What happens when H returns 1 to D?
On 6/20/2023 3:32 PM, Richard Damon wrote:
On 6/20/23 2:33 PM, olcott wrote:If I am the one that is a Liar then why did you already say >>>>>>>>>>> that 1 is
On 6/20/2023 1:20 PM, Richard Damon wrote:
On 6/20/23 1:46 PM, olcott wrote:Not at all. Not the least little bit.
On 6/20/2023 10:48 AM, Richard Damon wrote:
On 6/20/23 11:02 AM, olcott wrote:
On 6/20/2023 6:19 AM, Richard Damon wrote:So you are ADMITTING to working on a different problem, >>>>>>>>>>>>>>>> and lying about what you are doing. Thank you for being >>>>>>>>>>>>>>>> honest about that.
On 6/19/23 11:46 PM, olcott wrote:When we use the criteria:
On 6/19/2023 8:13 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 6/19/23 9:02 PM, olcott wrote:Nope, and you just seem too stupid to understand. >>>>>>>>>>>>>>>>>>
On 6/19/2023 7:45 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>> On 6/19/23 4:43 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>> The behavior of the directly executed P(P) is >>>>>>>>>>>>>>>>>>>>>>> different than the
H correctly simulates N steps of D until H >>>>>>>>>>>>>>>>>>>>> correctly predicts throughbehavior of P(P) correctly simulated by H because >>>>>>>>>>>>>>>>>>>>>>> in the first case H
has already aborted its simulation of its input >>>>>>>>>>>>>>>>>>>>>>> and in the second case
this has not yet occurred.
By what definition of "Correctly Simulated"? >>>>>>>>>>>>>>>>>>>>>>
The fact that H aborts its simulation has NO >>>>>>>>>>>>>>>>>>>>>> affect on the direct execution of the machine, so >>>>>>>>>>>>>>>>>>>>>> all you are saying that H has shut its eyes and >>>>>>>>>>>>>>>>>>>>>> said "I don't see it, so it didn't happen". >>>>>>>>>>>>>>>>>>>>>>
That is just FALSEHOOD.
Which is not the question being asked. The fact >>>>>>>>>>>>>>>>>>>>>> that it is impossible to design an H that can >>>>>>>>>>>>>>>>>>>>>> correctly simulate its input to a halting state >>>>>>>>>>>>>>>>>>>>>> just proves that H can not correctly decider that >>>>>>>>>>>>>>>>>>>>>> its input is Halting.
I now refer to P(P) as D(D).
Can D correctly simulated by H terminate normally? >>>>>>>>>>>>>>>>>>>>>>> No it cannot see the details below. >>>>>>>>>>>>>>>>>>>>>>
This does NOT mean that the input can't be >>>>>>>>>>>>>>>>>>>>>> Halting, just that H can never prove it. >>>>>>>>>>>>>>>>>>>>>>
IF H doesn't ever abort its simulation, then yes, >>>>>>>>>>>>>>>>>>>>>> the D built on that H is non-halting, but that H >>>>>>>>>>>>>>>>>>>>>> never gives that answer, so it is still wrong. >>>>>>>>>>>>>>>>>>>>>>
Each H gets a DIFFERENT D, since they include the >>>>>>>>>>>>>>>>>>>>>> H that the "pathological test" is to be performed >>>>>>>>>>>>>>>>>>>>>> on, so the behavior of one D built on a different >>>>>>>>>>>>>>>>>>>>>> H doesn't apply, and for correct reasoning, you >>>>>>>>>>>>>>>>>>>>>> really need to give each one a different name. >>>>>>>>>>>>>>>>>>>>>> Reusing the same name for different machine, and >>>>>>>>>>>>>>>>>>>>>> then trying to confuse which one is which is just >>>>>>>>>>>>>>>>>>>>>> a sign of being intentionally deceptive to try to >>>>>>>>>>>>>>>>>>>>>> tell a LIE.
The x86utm operating system based on an open >>>>>>>>>>>>>>>>>>>>>>> source x86 emulator. This
system enables one C function to execute another >>>>>>>>>>>>>>>>>>>>>>> C function in debug
step mode. When H simulates D it creates a >>>>>>>>>>>>>>>>>>>>>>> separate process context for
D with its own memory, stack and virtual >>>>>>>>>>>>>>>>>>>>>>> registers. H is able to
simulate D simulating itself, thus the only limit >>>>>>>>>>>>>>>>>>>>>>> to recursive
simulations is RAM.
But D is not SPECIFIED in a seperate context, but >>>>>>>>>>>>>>>>>>>>>> share code space with H, which means it fails to >>>>>>>>>>>>>>>>>>>>>> be truely distinctly, like a Turing Machine would be. >>>>>>>>>>>>>>>>>>>>>>
It is NOT a full "separate process context" as all >>>>>>>>>>>>>>>>>>>>>> the contexts share code space.
// The following is written in C >>>>>>>>>>>>>>>>>>>>>>> //
01 typedef int (*ptr)(); // pointer to int function >>>>>>>>>>>>>>>>>>>>>>> 02 int H(ptr x, ptr y) // uses x86 emulator to >>>>>>>>>>>>>>>>>>>>>>> simulate its input
03
04 int D(ptr x)
05 {
06 int Halt_Status = H(x, x); >>>>>>>>>>>>>>>>>>>>>>> 07 if (Halt_Status)
08 HERE: goto HERE;
09 return Halt_Status;
10 }
11
12 void main()
13 {
14 D(D);
15 }
D correctly simulated by H cannot possibly >>>>>>>>>>>>>>>>>>>>>>> terminate normally by reaching its own final >>>>>>>>>>>>>>>>>>>>>>> state at line 09.
But D correctly simulated by a correct simulator >>>>>>>>>>>>>>>>>>>>>> would, at least as long as you are using an H that >>>>>>>>>>>>>>>>>>>>>> answer H(D,D) as 0, as you claim.
the type of mathematical induction used by >>>>>>>>>>>>>>>>>>>>> termination analyzers that D
correctly simulated by H cannot possibly terminate >>>>>>>>>>>>>>>>>>>>> normally.
But that is the wrong prediction. It needs to >>>>>>>>>>>>>>>>>>>> predict if the input when run will halt, as THAT is >>>>>>>>>>>>>>>>>>>> the Halting Question.
That is just like Jack's question posed to Jack, >>>>>>>>>>>>>>>>>>> self-contradictory.
ChatGPT could understand that I am correct. >>>>>>>>>>>>>>>>>>
Thus, you are just admitting to working on POOP >>>>>>>>>>>>>>>>>>>> instead of Halting, and ALL your statements are just >>>>>>>>>>>>>>>>>>>> LIES.
the drain.
int factorial(int n)
{
if(n==0)
return(1);
return(n*factorial(n-1));
}
AProVE correctly determines that factorial(5) halts by >>>>>>>>>>>>>>>>>>>>> boiling the key behavior of entire function to this: >>>>>>>>>>>>>>>>>>>>> f(x) → f(x-1) :|: x > 0 && x <= 5
Wrong Question leads to incorrect answer, and all >>>>>>>>>>>>>>>>>>>> your work goes down
AProVE is the largest termination analysis project in >>>>>>>>>>>>>>>>>>> the world.
Yes, and it probably uses the RIGHT question, will the >>>>>>>>>>>>>>>>>> program halt when actually run.
It will probably also tell you that D(D) will Halt >>>>>>>>>>>>>>>>>> since H(D,D) returns 0.
Thus, it likely shows you are wrong about everything. >>>>>>>>>>>>>>>>>
Can D correctly simulated by H ever terminate normally? >>>>>>>>>>>>>>>>
Ben is just pointing out the ERRORS in your logic >>>>>>>>>>>>>>>>
When Ben pointed out that H(P,P) reports that P(P) does >>>>>>>>>>>>>>> not halt when
P(P) does halt this seems to be a contradiction to people >>>>>>>>>>>>>>> that lack a
complete understanding.
NO, it is a TRUE statement. H is NOT a correct HALT DECIDER. >>>>>>>>>>>>>>
It might be a valid POOP decider with your altered >>>>>>>>>>>>>> criteria, but it isn't correct as a Halt Decider.
You don't get to change the meaning of words, attempting >>>>>>>>>>>>>> to just shows you are a liar.
Halting is a property of the original machine, not of the >>>>>>>>>>>>>> partial simulation that H does.
Because of this I changed the semantic meaning of a >>>>>>>>>>>>>>> return value of 0
from H to mean either that P(P) does not halt or P(P) >>>>>>>>>>>>>>> specifically
targets H to do the opposite of whatever Boolean value >>>>>>>>>>>>>>> that H returns.
Which means you H need to return BOTH a 0 and 1 at the >>>>>>>>>>>>>> same time,
A return value of 0 also indicates that input D
intentionally targets
H by doing the opposite of whatever Boolean value that H >>>>>>>>>>>>> returns.
But a return of 1 signals that it halts, which it does. >>>>>>>>>>>>
You don't seem to understand English.
The Halting Problem asks if the Machine Described by the >>>>>>>>>>>> input Halts.
It Does (for the H that you are cliaming to be correct) >>>>>>>>>>>>
Therefore, the correct answer is YES / Halting, and you are >>>>>>>>>>>> PROVED to be a LIAR.
the wrong answer and are now saying that it is the right answer? >>>>>>>>>>>
Where did I say that 1 is the wrong answer to THAT question. >>>>>>>>>>
But it doesn't, so it doesn't matter.
Linz Ĥ such that embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to Ĥ.qy or Ĥ.qn
consistently with the behavior of Ĥ applied to ⟨Ĥ⟩.
Right, which is why it is impossible to make a correct Halt Decider. >>>>>>
The reason for this is that Ĥ does the opposite of both
Ĥ.qy and Ĥ.qn. This makes the input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H >>>>>>> self-contradictory for embedded_H.
Not SELF contradicotory, but just contradictory.
OK that may make sense. One of our very rare agreements. The
question does not contradict itself it contradicts every answer.
Contradictory questions are also incorrect questions.
Likewise Jack's question contradicts every answer.
It doesn't contradict the answer to the actual question,
SO, you are just to dumb to understand
That simply dodges my yes/no question.
My IQ is probably higher than yours. Did you pass the Mensa test?
In any case creative genius has its algorithm: https://www.scientificamerican.com/article/the-science-of-genius1/
If this is true then you can say which of yes/no are correct for
Jack to reply and which of true/false that H can return.
The only reason that no one can do this is that in both of
these cases the correct reply from Jack and return value from H
are contradicted by his question and the input to H.
On 6/20/23 10:59 PM, olcott wrote:
On 6/20/2023 9:32 PM, Richard Damon wrote:
On 6/20/23 9:36 PM, olcott wrote:
On 6/20/2023 7:41 PM, Richard Damon wrote:
On 6/20/23 6:59 PM, olcott wrote:If this is true then you can say which of yes/no are correct for
On 6/20/2023 5:52 PM, Richard Damon wrote:
On 6/20/23 6:19 PM, olcott wrote:
On 6/20/2023 4:56 PM, Richard Damon wrote:
On 6/20/23 5:27 PM, olcott wrote:No H can possibly be defined that can be embedded within
On 6/20/2023 3:46 PM, Richard Damon wrote:
On 6/20/23 4:38 PM, olcott wrote:What happens when H returns 1 to D?
On 6/20/2023 3:32 PM, Richard Damon wrote:
On 6/20/23 2:33 PM, olcott wrote:If I am the one that is a Liar then why did you already say >>>>>>>>>>>> that 1 is
On 6/20/2023 1:20 PM, Richard Damon wrote:
On 6/20/23 1:46 PM, olcott wrote:Not at all. Not the least little bit.
On 6/20/2023 10:48 AM, Richard Damon wrote:
On 6/20/23 11:02 AM, olcott wrote:
On 6/20/2023 6:19 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>> On 6/19/23 11:46 PM, olcott wrote:So you are ADMITTING to working on a different problem, >>>>>>>>>>>>>>>>> and lying about what you are doing. Thank you for being >>>>>>>>>>>>>>>>> honest about that.
When we use the criteria:On 6/19/2023 8:13 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>> On 6/19/23 9:02 PM, olcott wrote:Nope, and you just seem too stupid to understand. >>>>>>>>>>>>>>>>>>>
On 6/19/2023 7:45 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>> On 6/19/23 4:43 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>> The behavior of the directly executed P(P) is >>>>>>>>>>>>>>>>>>>>>>>> different than the
the type of mathematical induction used by >>>>>>>>>>>>>>>>>>>>>> termination analyzers that Dbehavior of P(P) correctly simulated by H >>>>>>>>>>>>>>>>>>>>>>>> because in the first case H
has already aborted its simulation of its input >>>>>>>>>>>>>>>>>>>>>>>> and in the second case
this has not yet occurred.
By what definition of "Correctly Simulated"? >>>>>>>>>>>>>>>>>>>>>>>
The fact that H aborts its simulation has NO >>>>>>>>>>>>>>>>>>>>>>> affect on the direct execution of the machine, so >>>>>>>>>>>>>>>>>>>>>>> all you are saying that H has shut its eyes and >>>>>>>>>>>>>>>>>>>>>>> said "I don't see it, so it didn't happen". >>>>>>>>>>>>>>>>>>>>>>>
That is just FALSEHOOD.
Which is not the question being asked. The fact >>>>>>>>>>>>>>>>>>>>>>> that it is impossible to design an H that can >>>>>>>>>>>>>>>>>>>>>>> correctly simulate its input to a halting state >>>>>>>>>>>>>>>>>>>>>>> just proves that H can not correctly decider that >>>>>>>>>>>>>>>>>>>>>>> its input is Halting.
I now refer to P(P) as D(D).
Can D correctly simulated by H terminate normally? >>>>>>>>>>>>>>>>>>>>>>>> No it cannot see the details below. >>>>>>>>>>>>>>>>>>>>>>>
This does NOT mean that the input can't be >>>>>>>>>>>>>>>>>>>>>>> Halting, just that H can never prove it. >>>>>>>>>>>>>>>>>>>>>>>
IF H doesn't ever abort its simulation, then yes, >>>>>>>>>>>>>>>>>>>>>>> the D built on that H is non-halting, but that H >>>>>>>>>>>>>>>>>>>>>>> never gives that answer, so it is still wrong. >>>>>>>>>>>>>>>>>>>>>>>
Each H gets a DIFFERENT D, since they include the >>>>>>>>>>>>>>>>>>>>>>> H that the "pathological test" is to be performed >>>>>>>>>>>>>>>>>>>>>>> on, so the behavior of one D built on a different >>>>>>>>>>>>>>>>>>>>>>> H doesn't apply, and for correct reasoning, you >>>>>>>>>>>>>>>>>>>>>>> really need to give each one a different name. >>>>>>>>>>>>>>>>>>>>>>> Reusing the same name for different machine, and >>>>>>>>>>>>>>>>>>>>>>> then trying to confuse which one is which is just >>>>>>>>>>>>>>>>>>>>>>> a sign of being intentionally deceptive to try to >>>>>>>>>>>>>>>>>>>>>>> tell a LIE.
The x86utm operating system based on an open >>>>>>>>>>>>>>>>>>>>>>>> source x86 emulator. This
system enables one C function to execute another >>>>>>>>>>>>>>>>>>>>>>>> C function in debug
step mode. When H simulates D it creates a >>>>>>>>>>>>>>>>>>>>>>>> separate process context for
D with its own memory, stack and virtual >>>>>>>>>>>>>>>>>>>>>>>> registers. H is able to
simulate D simulating itself, thus the only >>>>>>>>>>>>>>>>>>>>>>>> limit to recursive
simulations is RAM.
But D is not SPECIFIED in a seperate context, but >>>>>>>>>>>>>>>>>>>>>>> share code space with H, which means it fails to >>>>>>>>>>>>>>>>>>>>>>> be truely distinctly, like a Turing Machine would >>>>>>>>>>>>>>>>>>>>>>> be.
It is NOT a full "separate process context" as >>>>>>>>>>>>>>>>>>>>>>> all the contexts share code space. >>>>>>>>>>>>>>>>>>>>>>>
// The following is written in C >>>>>>>>>>>>>>>>>>>>>>>> //
01 typedef int (*ptr)(); // pointer to int function >>>>>>>>>>>>>>>>>>>>>>>> 02 int H(ptr x, ptr y) // uses x86 emulator to >>>>>>>>>>>>>>>>>>>>>>>> simulate its input
03
04 int D(ptr x)
05 {
06 int Halt_Status = H(x, x); >>>>>>>>>>>>>>>>>>>>>>>> 07 if (Halt_Status)
08 HERE: goto HERE;
09 return Halt_Status;
10 }
11
12 void main()
13 {
14 D(D);
15 }
D correctly simulated by H cannot possibly >>>>>>>>>>>>>>>>>>>>>>>> terminate normally by reaching its own final >>>>>>>>>>>>>>>>>>>>>>>> state at line 09.
But D correctly simulated by a correct simulator >>>>>>>>>>>>>>>>>>>>>>> would, at least as long as you are using an H >>>>>>>>>>>>>>>>>>>>>>> that answer H(D,D) as 0, as you claim. >>>>>>>>>>>>>>>>>>>>>> H correctly simulates N steps of D until H >>>>>>>>>>>>>>>>>>>>>> correctly predicts through
correctly simulated by H cannot possibly terminate >>>>>>>>>>>>>>>>>>>>>> normally.
But that is the wrong prediction. It needs to >>>>>>>>>>>>>>>>>>>>> predict if the input when run will halt, as THAT is >>>>>>>>>>>>>>>>>>>>> the Halting Question.
That is just like Jack's question posed to Jack, >>>>>>>>>>>>>>>>>>>> self-contradictory.
ChatGPT could understand that I am correct. >>>>>>>>>>>>>>>>>>>
Thus, you are just admitting to working on POOP >>>>>>>>>>>>>>>>>>>>> instead of Halting, and ALL your statements are >>>>>>>>>>>>>>>>>>>>> just LIES.
the drain.
int factorial(int n)
{
if(n==0)
return(1);
return(n*factorial(n-1));
}
AProVE correctly determines that factorial(5) >>>>>>>>>>>>>>>>>>>>>> halts by
boiling the key behavior of entire function to this: >>>>>>>>>>>>>>>>>>>>>> f(x) → f(x-1) :|: x > 0 && x <= 5 >>>>>>>>>>>>>>>>>>>>>>
Wrong Question leads to incorrect answer, and >>>>>>>>>>>>>>>>>>>>> all your work goes down
AProVE is the largest termination analysis project >>>>>>>>>>>>>>>>>>>> in the world.
Yes, and it probably uses the RIGHT question, will >>>>>>>>>>>>>>>>>>> the program halt when actually run.
It will probably also tell you that D(D) will Halt >>>>>>>>>>>>>>>>>>> since H(D,D) returns 0.
Thus, it likely shows you are wrong about everything. >>>>>>>>>>>>>>>>>>
Can D correctly simulated by H ever terminate normally? >>>>>>>>>>>>>>>>>
Ben is just pointing out the ERRORS in your logic >>>>>>>>>>>>>>>>>
When Ben pointed out that H(P,P) reports that P(P) does >>>>>>>>>>>>>>>> not halt when
P(P) does halt this seems to be a contradiction to >>>>>>>>>>>>>>>> people that lack a
complete understanding.
NO, it is a TRUE statement. H is NOT a correct HALT DECIDER. >>>>>>>>>>>>>>>
It might be a valid POOP decider with your altered >>>>>>>>>>>>>>> criteria, but it isn't correct as a Halt Decider. >>>>>>>>>>>>>>>
You don't get to change the meaning of words, attempting >>>>>>>>>>>>>>> to just shows you are a liar.
Halting is a property of the original machine, not of the >>>>>>>>>>>>>>> partial simulation that H does.
Because of this I changed the semantic meaning of a >>>>>>>>>>>>>>>> return value of 0
from H to mean either that P(P) does not halt or P(P) >>>>>>>>>>>>>>>> specifically
targets H to do the opposite of whatever Boolean value >>>>>>>>>>>>>>>> that H returns.
Which means you H need to return BOTH a 0 and 1 at the >>>>>>>>>>>>>>> same time,
A return value of 0 also indicates that input D
intentionally targets
H by doing the opposite of whatever Boolean value that H >>>>>>>>>>>>>> returns.
But a return of 1 signals that it halts, which it does. >>>>>>>>>>>>>
You don't seem to understand English.
The Halting Problem asks if the Machine Described by the >>>>>>>>>>>>> input Halts.
It Does (for the H that you are cliaming to be correct) >>>>>>>>>>>>>
Therefore, the correct answer is YES / Halting, and you are >>>>>>>>>>>>> PROVED to be a LIAR.
the wrong answer and are now saying that it is the right >>>>>>>>>>>> answer?
Where did I say that 1 is the wrong answer to THAT question. >>>>>>>>>>>
But it doesn't, so it doesn't matter.
Linz Ĥ such that embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to Ĥ.qy or Ĥ.qn
consistently with the behavior of Ĥ applied to ⟨Ĥ⟩.
Right, which is why it is impossible to make a correct Halt Decider. >>>>>>>
The reason for this is that Ĥ does the opposite of both
Ĥ.qy and Ĥ.qn. This makes the input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H >>>>>>>> self-contradictory for embedded_H.
Not SELF contradicotory, but just contradictory.
OK that may make sense. One of our very rare agreements. The
question does not contradict itself it contradicts every answer.
Contradictory questions are also incorrect questions.
Likewise Jack's question contradicts every answer.
It doesn't contradict the answer to the actual question,
Jack to
reply and which of true/false that H can return.
SO, you are just to dumb to understand
That simply dodges my yes/no question.
My IQ is probably higher than yours. Did you pass the Mensa test?
In any case creative genius has its algorithm:
https://www.scientificamerican.com/article/the-science-of-genius1/
I never took the Mensa test, as I saw no benefit to taking it.
If this is true then you can say which of yes/no are correct for
Jack to reply and which of true/false that H can return.
How do you get that conclusion? You are working off BAD LOGIC.
On 6/21/2023 6:38 AM, Richard Damon wrote:
On 6/20/23 10:59 PM, olcott wrote:In other words you are saying that when a question contradicts every
On 6/20/2023 9:32 PM, Richard Damon wrote:
On 6/20/23 9:36 PM, olcott wrote:
On 6/20/2023 7:41 PM, Richard Damon wrote:
On 6/20/23 6:59 PM, olcott wrote:If this is true then you can say which of yes/no are correct for
On 6/20/2023 5:52 PM, Richard Damon wrote:
On 6/20/23 6:19 PM, olcott wrote:
On 6/20/2023 4:56 PM, Richard Damon wrote:
On 6/20/23 5:27 PM, olcott wrote:No H can possibly be defined that can be embedded within
On 6/20/2023 3:46 PM, Richard Damon wrote:
On 6/20/23 4:38 PM, olcott wrote:What happens when H returns 1 to D?
On 6/20/2023 3:32 PM, Richard Damon wrote:
On 6/20/23 2:33 PM, olcott wrote:If I am the one that is a Liar then why did you already say >>>>>>>>>>>>> that 1 is
On 6/20/2023 1:20 PM, Richard Damon wrote:
On 6/20/23 1:46 PM, olcott wrote:Not at all. Not the least little bit.
On 6/20/2023 10:48 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>> On 6/20/23 11:02 AM, olcott wrote:
On 6/20/2023 6:19 AM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>> On 6/19/23 11:46 PM, olcott wrote:So you are ADMITTING to working on a different >>>>>>>>>>>>>>>>>> problem, and lying about what you are doing. Thank you >>>>>>>>>>>>>>>>>> for being honest about that.
When we use the criteria:On 6/19/2023 8:13 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>> On 6/19/23 9:02 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>> On 6/19/2023 7:45 PM, Richard Damon wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 6/19/23 4:43 PM, olcott wrote: >>>>>>>>>>>>>>>>>>>>>>>>> The behavior of the directly executed P(P) is >>>>>>>>>>>>>>>>>>>>>>>>> different than theNope, and you just seem too stupid to understand. >>>>>>>>>>>>>>>>>>>>
the type of mathematical induction used by >>>>>>>>>>>>>>>>>>>>>>> termination analyzers that Dbehavior of P(P) correctly simulated by H >>>>>>>>>>>>>>>>>>>>>>>>> because in the first case H
has already aborted its simulation of its input >>>>>>>>>>>>>>>>>>>>>>>>> and in the second case
this has not yet occurred.
By what definition of "Correctly Simulated"? >>>>>>>>>>>>>>>>>>>>>>>>
The fact that H aborts its simulation has NO >>>>>>>>>>>>>>>>>>>>>>>> affect on the direct execution of the machine, >>>>>>>>>>>>>>>>>>>>>>>> so all you are saying that H has shut its eyes >>>>>>>>>>>>>>>>>>>>>>>> and said "I don't see it, so it didn't happen". >>>>>>>>>>>>>>>>>>>>>>>>
That is just FALSEHOOD.
Which is not the question being asked. The fact >>>>>>>>>>>>>>>>>>>>>>>> that it is impossible to design an H that can >>>>>>>>>>>>>>>>>>>>>>>> correctly simulate its input to a halting state >>>>>>>>>>>>>>>>>>>>>>>> just proves that H can not correctly decider >>>>>>>>>>>>>>>>>>>>>>>> that its input is Halting.
I now refer to P(P) as D(D). >>>>>>>>>>>>>>>>>>>>>>>>>
Can D correctly simulated by H terminate normally? >>>>>>>>>>>>>>>>>>>>>>>>> No it cannot see the details below. >>>>>>>>>>>>>>>>>>>>>>>>
This does NOT mean that the input can't be >>>>>>>>>>>>>>>>>>>>>>>> Halting, just that H can never prove it. >>>>>>>>>>>>>>>>>>>>>>>>
IF H doesn't ever abort its simulation, then >>>>>>>>>>>>>>>>>>>>>>>> yes, the D built on that H is non-halting, but >>>>>>>>>>>>>>>>>>>>>>>> that H never gives that answer, so it is still >>>>>>>>>>>>>>>>>>>>>>>> wrong.
Each H gets a DIFFERENT D, since they include >>>>>>>>>>>>>>>>>>>>>>>> the H that the "pathological test" is to be >>>>>>>>>>>>>>>>>>>>>>>> performed on, so the behavior of one D built on >>>>>>>>>>>>>>>>>>>>>>>> a different H doesn't apply, and for correct >>>>>>>>>>>>>>>>>>>>>>>> reasoning, you really need to give each one a >>>>>>>>>>>>>>>>>>>>>>>> different name. Reusing the same name for >>>>>>>>>>>>>>>>>>>>>>>> different machine, and then trying to confuse >>>>>>>>>>>>>>>>>>>>>>>> which one is which is just a sign of being >>>>>>>>>>>>>>>>>>>>>>>> intentionally deceptive to try to tell a LIE. >>>>>>>>>>>>>>>>>>>>>>>>>
The x86utm operating system based on an open >>>>>>>>>>>>>>>>>>>>>>>>> source x86 emulator. This
system enables one C function to execute >>>>>>>>>>>>>>>>>>>>>>>>> another C function in debug
step mode. When H simulates D it creates a >>>>>>>>>>>>>>>>>>>>>>>>> separate process context for >>>>>>>>>>>>>>>>>>>>>>>>> D with its own memory, stack and virtual >>>>>>>>>>>>>>>>>>>>>>>>> registers. H is able to
simulate D simulating itself, thus the only >>>>>>>>>>>>>>>>>>>>>>>>> limit to recursive
simulations is RAM.
But D is not SPECIFIED in a seperate context, >>>>>>>>>>>>>>>>>>>>>>>> but share code space with H, which means it >>>>>>>>>>>>>>>>>>>>>>>> fails to be truely distinctly, like a Turing >>>>>>>>>>>>>>>>>>>>>>>> Machine would be.
It is NOT a full "separate process context" as >>>>>>>>>>>>>>>>>>>>>>>> all the contexts share code space. >>>>>>>>>>>>>>>>>>>>>>>>
// The following is written in C >>>>>>>>>>>>>>>>>>>>>>>>> //
01 typedef int (*ptr)(); // pointer to int >>>>>>>>>>>>>>>>>>>>>>>>> function
02 int H(ptr x, ptr y) // uses x86 emulator >>>>>>>>>>>>>>>>>>>>>>>>> to simulate its input
03
04 int D(ptr x)
05 {
06 int Halt_Status = H(x, x); >>>>>>>>>>>>>>>>>>>>>>>>> 07 if (Halt_Status)
08 HERE: goto HERE;
09 return Halt_Status;
10 }
11
12 void main()
13 {
14 D(D);
15 }
D correctly simulated by H cannot possibly >>>>>>>>>>>>>>>>>>>>>>>>> terminate normally by reaching its own final >>>>>>>>>>>>>>>>>>>>>>>>> state at line 09.
But D correctly simulated by a correct simulator >>>>>>>>>>>>>>>>>>>>>>>> would, at least as long as you are using an H >>>>>>>>>>>>>>>>>>>>>>>> that answer H(D,D) as 0, as you claim. >>>>>>>>>>>>>>>>>>>>>>> H correctly simulates N steps of D until H >>>>>>>>>>>>>>>>>>>>>>> correctly predicts through
correctly simulated by H cannot possibly >>>>>>>>>>>>>>>>>>>>>>> terminate normally.
But that is the wrong prediction. It needs to >>>>>>>>>>>>>>>>>>>>>> predict if the input when run will halt, as THAT >>>>>>>>>>>>>>>>>>>>>> is the Halting Question.
That is just like Jack's question posed to Jack, >>>>>>>>>>>>>>>>>>>>> self-contradictory.
ChatGPT could understand that I am correct. >>>>>>>>>>>>>>>>>>>>
Thus, you are just admitting to working on POOP >>>>>>>>>>>>>>>>>>>>>> instead of Halting, and ALL your statements are >>>>>>>>>>>>>>>>>>>>>> just LIES.
the drain.
int factorial(int n)
{
if(n==0)
return(1);
return(n*factorial(n-1));
}
AProVE correctly determines that factorial(5) >>>>>>>>>>>>>>>>>>>>>>> halts by
boiling the key behavior of entire function to this: >>>>>>>>>>>>>>>>>>>>>>> f(x) → f(x-1) :|: x > 0 && x <= 5 >>>>>>>>>>>>>>>>>>>>>>>
Wrong Question leads to incorrect answer, and >>>>>>>>>>>>>>>>>>>>>> all your work goes down
AProVE is the largest termination analysis project >>>>>>>>>>>>>>>>>>>>> in the world.
Yes, and it probably uses the RIGHT question, will >>>>>>>>>>>>>>>>>>>> the program halt when actually run.
It will probably also tell you that D(D) will Halt >>>>>>>>>>>>>>>>>>>> since H(D,D) returns 0.
Thus, it likely shows you are wrong about everything. >>>>>>>>>>>>>>>>>>>
Can D correctly simulated by H ever terminate normally? >>>>>>>>>>>>>>>>>>
Ben is just pointing out the ERRORS in your logic >>>>>>>>>>>>>>>>>>
When Ben pointed out that H(P,P) reports that P(P) does >>>>>>>>>>>>>>>>> not halt when
P(P) does halt this seems to be a contradiction to >>>>>>>>>>>>>>>>> people that lack a
complete understanding.
NO, it is a TRUE statement. H is NOT a correct HALT >>>>>>>>>>>>>>>> DECIDER.
It might be a valid POOP decider with your altered >>>>>>>>>>>>>>>> criteria, but it isn't correct as a Halt Decider. >>>>>>>>>>>>>>>>
You don't get to change the meaning of words, attempting >>>>>>>>>>>>>>>> to just shows you are a liar.
Halting is a property of the original machine, not of >>>>>>>>>>>>>>>> the partial simulation that H does.
Because of this I changed the semantic meaning of a >>>>>>>>>>>>>>>>> return value of 0
from H to mean either that P(P) does not halt or P(P) >>>>>>>>>>>>>>>>> specifically
targets H to do the opposite of whatever Boolean value >>>>>>>>>>>>>>>>> that H returns.
Which means you H need to return BOTH a 0 and 1 at the >>>>>>>>>>>>>>>> same time,
A return value of 0 also indicates that input D
intentionally targets
H by doing the opposite of whatever Boolean value that H >>>>>>>>>>>>>>> returns.
But a return of 1 signals that it halts, which it does. >>>>>>>>>>>>>>
You don't seem to understand English.
The Halting Problem asks if the Machine Described by the >>>>>>>>>>>>>> input Halts.
It Does (for the H that you are cliaming to be correct) >>>>>>>>>>>>>>
Therefore, the correct answer is YES / Halting, and you >>>>>>>>>>>>>> are PROVED to be a LIAR.
the wrong answer and are now saying that it is the right >>>>>>>>>>>>> answer?
Where did I say that 1 is the wrong answer to THAT question. >>>>>>>>>>>>
But it doesn't, so it doesn't matter.
Linz Ĥ such that embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to Ĥ.qy or Ĥ.qn
consistently with the behavior of Ĥ applied to ⟨Ĥ⟩.
Right, which is why it is impossible to make a correct Halt
Decider.
The reason for this is that Ĥ does the opposite of both
Ĥ.qy and Ĥ.qn. This makes the input ⟨Ĥ⟩ ⟨Ĥ⟩ to embedded_H >>>>>>>>> self-contradictory for embedded_H.
Not SELF contradicotory, but just contradictory.
OK that may make sense. One of our very rare agreements. The
question does not contradict itself it contradicts every answer. >>>>>>>
Contradictory questions are also incorrect questions.
Likewise Jack's question contradicts every answer.
It doesn't contradict the answer to the actual question,
Jack to
reply and which of true/false that H can return.
SO, you are just to dumb to understand
That simply dodges my yes/no question.
My IQ is probably higher than yours. Did you pass the Mensa test?
In any case creative genius has its algorithm:
https://www.scientificamerican.com/article/the-science-of-genius1/
I never took the Mensa test, as I saw no benefit to taking it.
If this is true then you can say which of yes/no are correct for
Jack to reply and which of true/false that H can return.
How do you get that conclusion? You are working off BAD LOGIC.
answer From X that the reason that X cannot correctly answer the
question has nothing to do with the fact that the question contradicts
every answer from X instead it must be the case that X is very stupid.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 120:12:37 |
| Calls: | 6,662 |
| Files: | 12,210 |
| Messages: | 5,334,422 |