Can D simulated by H terminate normally?
The following code is executed in 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.
01 int D(int (*x)())
02 {
03 int Halt_Status = H(x, x);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 void main()
10 {
11 H(D,D);
12 }
*Execution Trace*
main() calls H(D,D) that simulates D(D) at line 11
*keeps repeating*
simulated D(D) calls simulated H(D,D) that simulates D(D) at line 03 ...
Is this clear enough to see that D correctly simulated by H can never terminate normally ? (because D remains stuck in recursive simulation) ?
For any program H that might determine whether programs halt, a "pathological" program D, called with some input, can pass its own
source and its input to H and then specifically do the opposite of what
H predicts D will do. *No H can exist that handles this case* https://en.wikipedia.org/wiki/Halting_problem
H(D,D) fully operational in x86utm operating system: https://github.com/plolcott/x86utm
Source-code of several different partial halt deciders and their sample inputs. https://github.com/plolcott/x86utm/blob/master/Halt7.c
This paper shows how that same idea is applied to the Peter Linz Turing machine based Halting Problem Proofs.
*Simulating (partial) Halt Deciders Defeat the Halting Problem Proofs* https://www.researchgate.net/publication/369971402_Simulating_partial_Halt_Deciders_Defeat_the_Halting_Problem_Proofs
*At 10/13/2022 11:29 AM in an email*
MIT Professor Michael Sipser has agreed that the following verbatim
paragraph is correct (he has not agreed to anything else):
If simulating halt decider H correctly simulates its input D until H correctly determines that its simulated D would never stop running
unless aborted then H can abort its simulation of D and correctly report
that D specifies a non-halting sequence of configurations.
It is clear that H does determine the halt status of D precisely
according to that criteria.
On 5/19/23 10:50 AM, olcott wrote:
Can D simulated by H terminate normally?
Wrong Question!
You are showing your stupidity by repeatig the Strawman error that has
been pointed out to you many times, showing your Stupidity.
First you have to ask and answer does the ACTUAL H even do a "Correct Simulation" by the definition that allows you to use the simulation to determine halting.
Since the answer is NO, your question is mute.
YOU FAIL.
The following code is executed in 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.
01 int D(int (*x)())
02 {
03 int Halt_Status = H(x, x);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 void main()
10 {
11 H(D,D);
12 }
*Execution Trace*
main() calls H(D,D) that simulates D(D) at line 11
*keeps repeating*
simulated D(D) calls simulated H(D,D) that simulates D(D) at line 03 ...
Is this clear enough to see that D correctly simulated by H can never
terminate normally ? (because D remains stuck in recursive simulation) ?
For any program H that might determine whether programs halt, a
"pathological" program D, called with some input, can pass its own
source and its input to H and then specifically do the opposite of what
H predicts D will do. *No H can exist that handles this case*
https://en.wikipedia.org/wiki/Halting_problem
H(D,D) fully operational in x86utm operating system:
https://github.com/plolcott/x86utm
Source-code of several different partial halt deciders and their
sample inputs. https://github.com/plolcott/x86utm/blob/master/Halt7.c
This paper shows how that same idea is applied to the Peter Linz Turing
machine based Halting Problem Proofs.
*Simulating (partial) Halt Deciders Defeat the Halting Problem Proofs*
https://www.researchgate.net/publication/369971402_Simulating_partial_Halt_Deciders_Defeat_the_Halting_Problem_Proofs
*At 10/13/2022 11:29 AM in an email*
MIT Professor Michael Sipser has agreed that the following verbatim
paragraph is correct (he has not agreed to anything else):
If simulating halt decider H correctly simulates its input D until H
correctly determines that its simulated D would never stop running
unless aborted then H can abort its simulation of D and correctly report
that D specifies a non-halting sequence of configurations.
It is clear that H does determine the halt status of D precisely
according to that criteria.
On 5/19/2023 5:54 PM, Richard Damon wrote:
On 5/19/23 10:50 AM, olcott wrote:
Can D simulated by H terminate normally?
Wrong Question!
In other words the question is over you head.
It took me many years to recognize this same dodge by Ben.
You are showing your stupidity by repeatig the Strawman error that has
been pointed out to you many times, showing your Stupidity.
First you have to ask and answer does the ACTUAL H even do a "Correct
Simulation" by the definition that allows you to use the simulation to
determine halting.
Since the answer is NO, your question is mute.
YOU FAIL.
The following code is executed in 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.
01 int D(int (*x)())
02 {
03 int Halt_Status = H(x, x);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 void main()
10 {
11 H(D,D);
12 }
*Execution Trace*
main() calls H(D,D) that simulates D(D) at line 11
*keeps repeating*
simulated D(D) calls simulated H(D,D) that simulates D(D) at line 03 ... >>>
Is this clear enough to see that D correctly simulated by H can never
terminate normally ? (because D remains stuck in recursive simulation) ? >>>
For any program H that might determine whether programs halt, a
"pathological" program D, called with some input, can pass its own
source and its input to H and then specifically do the opposite of what
H predicts D will do. *No H can exist that handles this case*
https://en.wikipedia.org/wiki/Halting_problem
H(D,D) fully operational in x86utm operating system:
https://github.com/plolcott/x86utm
Source-code of several different partial halt deciders and their
sample inputs. https://github.com/plolcott/x86utm/blob/master/Halt7.c
This paper shows how that same idea is applied to the Peter Linz Turing
machine based Halting Problem Proofs.
*Simulating (partial) Halt Deciders Defeat the Halting Problem Proofs*
https://www.researchgate.net/publication/369971402_Simulating_partial_Halt_Deciders_Defeat_the_Halting_Problem_Proofs
*At 10/13/2022 11:29 AM in an email*
MIT Professor Michael Sipser has agreed that the following verbatim
paragraph is correct (he has not agreed to anything else):
If simulating halt decider H correctly simulates its input D until H
correctly determines that its simulated D would never stop running
unless aborted then H can abort its simulation of D and correctly report >>> that D specifies a non-halting sequence of configurations.
It is clear that H does determine the halt status of D precisely
according to that criteria.
On 5/19/23 9:47 PM, olcott wrote:
On 5/19/2023 5:54 PM, Richard Damon wrote:
On 5/19/23 10:50 AM, olcott wrote:
Can D simulated by H terminate normally?
Wrong Question!
In other words the question is over you head.
It took me many years to recognize this same dodge by Ben.
No, it is the WRONG question once you try to apply the answer to the
Halting Problem, which you do.
The following code is executed in 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.
01 int D(int (*x)())
02 {
03 int Halt_Status = H(x, x);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 void main()
10 {
11 H(D,D);
12 }
*Execution Trace*
main() calls H(D,D) that simulates D(D) at line 11
*keeps repeating*
simulated D(D) calls simulated H(D,D) that simulates D(D) at line 03
...
Is this clear enough to see that D correctly simulated by H can never
terminate normally ? (because D remains stuck in recursive
simulation) ?
For any program H that might determine whether programs halt, a
"pathological" program D, called with some input, can pass its own
source and its input to H and then specifically do the opposite of what >>>> H predicts D will do. *No H can exist that handles this case*
https://en.wikipedia.org/wiki/Halting_problem
H(D,D) fully operational in x86utm operating system:
https://github.com/plolcott/x86utm
Source-code of several different partial halt deciders and their
sample inputs. https://github.com/plolcott/x86utm/blob/master/Halt7.c
This paper shows how that same idea is applied to the Peter Linz Turing >>>> machine based Halting Problem Proofs.
*Simulating (partial) Halt Deciders Defeat the Halting Problem Proofs* >>>> https://www.researchgate.net/publication/369971402_Simulating_partial_Halt_Deciders_Defeat_the_Halting_Problem_Proofs
*At 10/13/2022 11:29 AM in an email*
MIT Professor Michael Sipser has agreed that the following verbatim
paragraph is correct (he has not agreed to anything else):
If simulating halt decider H correctly simulates its input D until H
correctly determines that its simulated D would never stop running
unless aborted then H can abort its simulation of D and correctly
report
that D specifies a non-halting sequence of configurations.
It is clear that H does determine the halt status of D precisely
according to that criteria.
On 5/19/23 10:10 PM, olcott wrote:
On 5/19/2023 8:56 PM, Richard Damon wrote:
On 5/19/23 9:47 PM, olcott wrote:
On 5/19/2023 5:54 PM, Richard Damon wrote:
On 5/19/23 10:50 AM, olcott wrote:
Can D simulated by H terminate normally?
Wrong Question!
In other words the question is over you head.
It took me many years to recognize this same dodge by Ben.
No, it is the WRONG question once you try to apply the answer to the
Halting Problem, which you do.
So the software engineering really is over your head?
I see, so like Ben you have never actually written any code.
But you aren't talking about Software Engineering unless you are lying
about this applying to the Halting Problem described by Linz, since that
is the Halting Problem of Computability Theory.
Of course, the likely explanation is that you are just ignorant of what
you are talking about, so you don't understand the diference.
Ben kept masking his coding incompetence this way.
It never occurred to me that you have never written any code.
I have possibly written more WORKING code than you have.
On 5/19/2023 8:56 PM, Richard Damon wrote:
On 5/19/23 9:47 PM, olcott wrote:
On 5/19/2023 5:54 PM, Richard Damon wrote:
On 5/19/23 10:50 AM, olcott wrote:
Can D simulated by H terminate normally?
Wrong Question!
In other words the question is over you head.
It took me many years to recognize this same dodge by Ben.
No, it is the WRONG question once you try to apply the answer to the
Halting Problem, which you do.
So the software engineering really is over your head?
I see, so like Ben you have never actually written any code.
Ben kept masking his coding incompetence this way.
It never occurred to me that you have never written any code.
On 5/19/2023 8:56 PM, Richard Damon wrote:
On 5/19/23 9:47 PM, olcott wrote:
On 5/19/2023 5:54 PM, Richard Damon wrote:
On 5/19/23 10:50 AM, olcott wrote:
Can D simulated by H terminate normally?
Wrong Question!
In other words the question is over you head.
It took me many years to recognize this same dodge by Ben.
No, it is the WRONG question once you try to apply the answer to the
Halting Problem, which you do.
So the software engineering really is over your head?
I see, so like Ben you have never actually written any code.
Ben kept masking his coding incompetence this way.
It never occurred to me that you have never written any code.
The following code is executed in 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.
01 int D(int (*x)())
02 {
03 int Halt_Status = H(x, x);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 void main()
10 {
11 H(D,D);
12 }
*Execution Trace*
main() calls H(D,D) that simulates D(D) at line 11
*keeps repeating*
simulated D(D) calls simulated H(D,D) that simulates D(D) at line
03 ...
Is this clear enough to see that D correctly simulated by H can never >>>>> terminate normally ? (because D remains stuck in recursive
simulation) ?
For any program H that might determine whether programs halt, a
"pathological" program D, called with some input, can pass its own
source and its input to H and then specifically do the opposite of
what
H predicts D will do. *No H can exist that handles this case*
https://en.wikipedia.org/wiki/Halting_problem
H(D,D) fully operational in x86utm operating system:
https://github.com/plolcott/x86utm
Source-code of several different partial halt deciders and their
sample inputs. https://github.com/plolcott/x86utm/blob/master/Halt7.c >>>>>
This paper shows how that same idea is applied to the Peter Linz
Turing
machine based Halting Problem Proofs.
*Simulating (partial) Halt Deciders Defeat the Halting Problem Proofs* >>>>> https://www.researchgate.net/publication/369971402_Simulating_partial_Halt_Deciders_Defeat_the_Halting_Problem_Proofs
*At 10/13/2022 11:29 AM in an email*
MIT Professor Michael Sipser has agreed that the following verbatim
paragraph is correct (he has not agreed to anything else):
If simulating halt decider H correctly simulates its input D until H >>>>> correctly determines that its simulated D would never stop running
unless aborted then H can abort its simulation of D and correctly
report
that D specifies a non-halting sequence of configurations.
It is clear that H does determine the halt status of D precisely
according to that criteria.
On 5/19/23 11:00 PM, olcott wrote:
On 5/19/2023 9:51 PM, Richard Damon wrote:
On 5/19/23 10:10 PM, olcott wrote:
On 5/19/2023 8:56 PM, Richard Damon wrote:
On 5/19/23 9:47 PM, olcott wrote:
On 5/19/2023 5:54 PM, Richard Damon wrote:
On 5/19/23 10:50 AM, olcott wrote:
Can D simulated by H terminate normally?
Wrong Question!
In other words the question is over you head.
It took me many years to recognize this same dodge by Ben.
No, it is the WRONG question once you try to apply the answer to
the Halting Problem, which you do.
So the software engineering really is over your head?
I see, so like Ben you have never actually written any code.
But you aren't talking about Software Engineering unless you are
lying about this applying to the Halting Problem described by Linz,
since that is the Halting Problem of Computability Theory.
Of course, the likely explanation is that you are just ignorant of
what you are talking about, so you don't understand the diference.
Ben kept masking his coding incompetence this way.
It never occurred to me that you have never written any code.
I have possibly written more WORKING code than you have.
I don't believe you. Your inability to answer an straight forward
software engineering question seems to prove otherwise.
What software engineering question?
On 5/19/2023 9:51 PM, Richard Damon wrote:
On 5/19/23 10:10 PM, olcott wrote:
On 5/19/2023 8:56 PM, Richard Damon wrote:
On 5/19/23 9:47 PM, olcott wrote:
On 5/19/2023 5:54 PM, Richard Damon wrote:
On 5/19/23 10:50 AM, olcott wrote:
Can D simulated by H terminate normally?
Wrong Question!
In other words the question is over you head.
It took me many years to recognize this same dodge by Ben.
No, it is the WRONG question once you try to apply the answer to the
Halting Problem, which you do.
So the software engineering really is over your head?
I see, so like Ben you have never actually written any code.
But you aren't talking about Software Engineering unless you are lying
about this applying to the Halting Problem described by Linz, since
that is the Halting Problem of Computability Theory.
Of course, the likely explanation is that you are just ignorant of
what you are talking about, so you don't understand the diference.
Ben kept masking his coding incompetence this way.
It never occurred to me that you have never written any code.
I have possibly written more WORKING code than you have.
I don't believe you. Your inability to answer an straight forward
software engineering question seems to prove otherwise.
Ben successfully pulled this same crap for nearly two decades.
He may know some things at the abstract textbook level very well.
That seems to be the total extent of his technical knowledge.
Mike had to coach on some relatively simple things.
On 5/19/23 11:00 PM, olcott wrote:
On 5/19/2023 9:51 PM, Richard Damon wrote:
On 5/19/23 10:10 PM, olcott wrote:
On 5/19/2023 8:56 PM, Richard Damon wrote:
On 5/19/23 9:47 PM, olcott wrote:
On 5/19/2023 5:54 PM, Richard Damon wrote:
On 5/19/23 10:50 AM, olcott wrote:
Can D simulated by H terminate normally?
Wrong Question!
In other words the question is over you head.
It took me many years to recognize this same dodge by Ben.
No, it is the WRONG question once you try to apply the answer to
the Halting Problem, which you do.
So the software engineering really is over your head?
I see, so like Ben you have never actually written any code.
But you aren't talking about Software Engineering unless you are
lying about this applying to the Halting Problem described by Linz,
since that is the Halting Problem of Computability Theory.
Of course, the likely explanation is that you are just ignorant of
what you are talking about, so you don't understand the diference.
Ben kept masking his coding incompetence this way.
It never occurred to me that you have never written any code.
I have possibly written more WORKING code than you have.
I don't believe you. Your inability to answer an straight forward
software engineering question seems to prove otherwise.
What software engineering question?
On 5/19/2023 10:27 PM, Richard Damon wrote:
On 5/19/23 11:00 PM, olcott wrote:
On 5/19/2023 9:51 PM, Richard Damon wrote:
On 5/19/23 10:10 PM, olcott wrote:
On 5/19/2023 8:56 PM, Richard Damon wrote:
On 5/19/23 9:47 PM, olcott wrote:
On 5/19/2023 5:54 PM, Richard Damon wrote:
On 5/19/23 10:50 AM, olcott wrote:
Can D simulated by H terminate normally?
Wrong Question!
In other words the question is over you head.
It took me many years to recognize this same dodge by Ben.
No, it is the WRONG question once you try to apply the answer to
the Halting Problem, which you do.
So the software engineering really is over your head?
I see, so like Ben you have never actually written any code.
But you aren't talking about Software Engineering unless you are
lying about this applying to the Halting Problem described by Linz,
since that is the Halting Problem of Computability Theory.
Of course, the likely explanation is that you are just ignorant of
what you are talking about, so you don't understand the diference.
Ben kept masking his coding incompetence this way.
It never occurred to me that you have never written any code.
I have possibly written more WORKING code than you have.
I don't believe you. Your inability to answer an straight forward
software engineering question seems to prove otherwise.
What software engineering question?
Can D simulated by H terminate normally?
Can D simulated by H terminate normally?
Can D simulated by H terminate normally?
Can D simulated by H terminate normally?
Can D simulated by H terminate normally?
Can D simulated by H terminate normally?
Can D simulated by H terminate normally?
The following code is executed in 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.
01 int D(int (*x)())
02 {
03 int Halt_Status = H(x, x);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 void main()
10 {
11 H(D,D);
12 }
*Execution Trace*
main() calls H(D,D) that simulates D(D) at line 11
*keeps repeating*
simulated D(D) calls simulated H(D,D) that simulates D(D) at line 03 ...
Is this clear enough to see that D correctly simulated by H can never terminate normally ? (because D remains stuck in recursive simulation) ?
Software engineers can easily verify that D correctly simulated by H
cannot possibly reach its own line 09 and terminate normally.
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 }
*Execution Trace*
Line 14: main() invokes D(D)
*keeps repeating* (unless aborted)
Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D)
*Simulation invariant*
D correctly simulated by H cannot possibly reach its own line 09.
Is it dead obvious to everyone here when examining the execution
trace of lines 14 and 06 above that D correctly simulated by H cannot possibly terminate normally by reaching its own line 09?
This means that when termination analyzer H aborts its simulation of D
and reports that its correctly simulated input cannot possibly terminate normally it is merely reporting an easily verified fact.
*THE ABOVE IS AN EASILY VERIFIED FACT OF CORRECT SOFTWARE ENGINEERING*
I will provide the next steps of the analysis after the above has been accepted.
On 6/12/23 12:40 PM, olcott wrote:
Software engineers can easily verify that D correctly simulated by H
cannot possibly reach its own line 09 and terminate normally.
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 }
*Execution Trace*
Line 14: main() invokes D(D)
*keeps repeating* (unless aborted)
Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D)
*Simulation invariant*
D correctly simulated by H cannot possibly reach its own line 09.
Is it dead obvious to everyone here when examining the execution
trace of lines 14 and 06 above that D correctly simulated by H cannot
possibly terminate normally by reaching its own line 09?
This means that when termination analyzer H aborts its simulation of D
and reports that its correctly simulated input cannot possibly terminate
normally it is merely reporting an easily verified fact.
*THE ABOVE IS AN EASILY VERIFIED FACT OF CORRECT SOFTWARE ENGINEERING*
I will provide the next steps of the analysis after the above has been
accepted.
Right, it is impossibl to design an H that can correctly simulate that D
and reach a final state.
Thus, no H can validly say the D built on it is Halting.
On 6/12/2023 6:36 PM, Richard Damon wrote:
On 6/12/23 12:40 PM, olcott wrote:It is a verified fact that H does correctly report that D correctly
Software engineers can easily verify that D correctly simulated by H
cannot possibly reach its own line 09 and terminate normally.
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 }
*Execution Trace*
Line 14: main() invokes D(D)
*keeps repeating* (unless aborted)
Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D)
*Simulation invariant*
D correctly simulated by H cannot possibly reach its own line 09.
Is it dead obvious to everyone here when examining the execution
trace of lines 14 and 06 above that D correctly simulated by H cannot
possibly terminate normally by reaching its own line 09?
This means that when termination analyzer H aborts its simulation of D
and reports that its correctly simulated input cannot possibly terminate >>> normally it is merely reporting an easily verified fact.
*THE ABOVE IS AN EASILY VERIFIED FACT OF CORRECT SOFTWARE ENGINEERING*
I will provide the next steps of the analysis after the above has
been accepted.
Right, it is impossibl to design an H that can correctly simulate that
D and reach a final state.
Thus, no H can validly say the D built on it is Halting.
simulated by H cannot possibly terminate normally.
For any program H that might determine whether programs halt, a "pathological" program D, called with some input, can pass its own
source and its input to H and then specifically do the opposite of what
H predicts D will do. *No H can exist that handles this case* https://en.wikipedia.org/wiki/Halting_problem
It is a verified fact that H and D have the halting problem pathological relationship to each other.
Until you acknowledge these two verified facts it remains obvious that
you are only playing troll head games and have no interest in any honest dialogue.
On 6/12/23 8:31 PM, olcott wrote:
On 6/12/2023 6:36 PM, Richard Damon wrote:
On 6/12/23 12:40 PM, olcott wrote:It is a verified fact that H does correctly report that D correctly
Software engineers can easily verify that D correctly simulated by H
cannot possibly reach its own line 09 and terminate normally.
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 }
*Execution Trace*
Line 14: main() invokes D(D)
*keeps repeating* (unless aborted)
Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D)
*Simulation invariant*
D correctly simulated by H cannot possibly reach its own line 09.
Is it dead obvious to everyone here when examining the execution
trace of lines 14 and 06 above that D correctly simulated by H cannot
possibly terminate normally by reaching its own line 09?
This means that when termination analyzer H aborts its simulation of D >>>> and reports that its correctly simulated input cannot possibly
terminate
normally it is merely reporting an easily verified fact.
*THE ABOVE IS AN EASILY VERIFIED FACT OF CORRECT SOFTWARE ENGINEERING* >>>>
I will provide the next steps of the analysis after the above has
been accepted.
Right, it is impossibl to design an H that can correctly simulate
that D and reach a final state.
Thus, no H can validly say the D built on it is Halting.
simulated by H cannot possibly terminate normally.
So, you admit you are working on POOP and not the Halting Problem?
On 6/12/23 9:38 PM, olcott wrote:Until you explicitly acknowledge that verified fact I am no longer
On 6/12/2023 8:26 PM, Richard Damon wrote:
On 6/12/23 8:31 PM, olcott wrote:
On 6/12/2023 6:36 PM, Richard Damon wrote:
On 6/12/23 12:40 PM, olcott wrote:It is a verified fact that H does correctly report that D correctly
Software engineers can easily verify that D correctly simulated by H >>>>>> cannot possibly reach its own line 09 and terminate normally.
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 }
*Execution Trace*
Line 14: main() invokes D(D)
*keeps repeating* (unless aborted)
Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D) >>>>>>
*Simulation invariant*
D correctly simulated by H cannot possibly reach its own line 09.
Is it dead obvious to everyone here when examining the execution
trace of lines 14 and 06 above that D correctly simulated by H cannot >>>>>> possibly terminate normally by reaching its own line 09?
This means that when termination analyzer H aborts its simulation
of D
and reports that its correctly simulated input cannot possibly
terminate
normally it is merely reporting an easily verified fact.
*THE ABOVE IS AN EASILY VERIFIED FACT OF CORRECT SOFTWARE
ENGINEERING*
I will provide the next steps of the analysis after the above has
been accepted.
Right, it is impossibl to design an H that can correctly simulate
that D and reach a final state.
Thus, no H can validly say the D built on it is Halting.
simulated by H cannot possibly terminate normally.
So, you admit you are working on POOP and not the Halting Problem?
It is a verified fact that H does correctly report that D correctly
simulated by H cannot possibly terminate normally.
Until you explicitly acknowledge that verified fact I am no longer
willing to talk to you.
Since that isn't the question of the Halting Problem,
On 6/12/2023 8:26 PM, Richard Damon wrote:
On 6/12/23 8:31 PM, olcott wrote:
On 6/12/2023 6:36 PM, Richard Damon wrote:
On 6/12/23 12:40 PM, olcott wrote:It is a verified fact that H does correctly report that D correctly
Software engineers can easily verify that D correctly simulated by H >>>>> cannot possibly reach its own line 09 and terminate normally.
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 }
*Execution Trace*
Line 14: main() invokes D(D)
*keeps repeating* (unless aborted)
Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D) >>>>>
*Simulation invariant*
D correctly simulated by H cannot possibly reach its own line 09.
Is it dead obvious to everyone here when examining the execution
trace of lines 14 and 06 above that D correctly simulated by H cannot >>>>> possibly terminate normally by reaching its own line 09?
This means that when termination analyzer H aborts its simulation of D >>>>> and reports that its correctly simulated input cannot possibly
terminate
normally it is merely reporting an easily verified fact.
*THE ABOVE IS AN EASILY VERIFIED FACT OF CORRECT SOFTWARE ENGINEERING* >>>>>
I will provide the next steps of the analysis after the above has
been accepted.
Right, it is impossibl to design an H that can correctly simulate
that D and reach a final state.
Thus, no H can validly say the D built on it is Halting.
simulated by H cannot possibly terminate normally.
So, you admit you are working on POOP and not the Halting Problem?
It is a verified fact that H does correctly report that D correctly
simulated by H cannot possibly terminate normally.
Until you explicitly acknowledge that verified fact I am no longer
willing to talk to you.
On 6/12/2023 10:03 PM, Richard Damon wrote:
On 6/12/23 9:59 PM, olcott wrote:It is a verified fact that H does correctly report that D correctly
On 6/12/2023 8:55 PM, Richard Damon wrote:
On 6/12/23 9:38 PM, olcott wrote:Until you explicitly acknowledge that verified fact I am no longer
On 6/12/2023 8:26 PM, Richard Damon wrote:
On 6/12/23 8:31 PM, olcott wrote:
On 6/12/2023 6:36 PM, Richard Damon wrote:
On 6/12/23 12:40 PM, olcott wrote:It is a verified fact that H does correctly report that D correctly >>>>>>> simulated by H cannot possibly terminate normally.
Software engineers can easily verify that D correctly simulated >>>>>>>>> by H
cannot possibly reach its own line 09 and terminate normally. >>>>>>>>>
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 }
*Execution Trace*
Line 14: main() invokes D(D)
*keeps repeating* (unless aborted)
Line 06: simulated D(D) invokes simulated H(D,D) that simulates >>>>>>>>> D(D)
*Simulation invariant*
D correctly simulated by H cannot possibly reach its own line 09. >>>>>>>>>
Is it dead obvious to everyone here when examining the execution >>>>>>>>> trace of lines 14 and 06 above that D correctly simulated by H >>>>>>>>> cannot
possibly terminate normally by reaching its own line 09?
This means that when termination analyzer H aborts its
simulation of D
and reports that its correctly simulated input cannot possibly >>>>>>>>> terminate
normally it is merely reporting an easily verified fact.
*THE ABOVE IS AN EASILY VERIFIED FACT OF CORRECT SOFTWARE
ENGINEERING*
I will provide the next steps of the analysis after the above >>>>>>>>> has been accepted.
Right, it is impossibl to design an H that can correctly
simulate that D and reach a final state.
Thus, no H can validly say the D built on it is Halting.
So, you admit you are working on POOP and not the Halting Problem? >>>>>>
It is a verified fact that H does correctly report that D correctly
simulated by H cannot possibly terminate normally.
Until you explicitly acknowledge that verified fact I am no longer
willing to talk to you.
Since that isn't the question of the Halting Problem,
willing to talk to you.
Which verifyied fact?
simulated by H cannot possibly terminate normally.
On 6/12/2023 8:55 PM, Richard Damon wrote:
On 6/12/23 9:38 PM, olcott wrote:Until you explicitly acknowledge that verified fact I am no longer
On 6/12/2023 8:26 PM, Richard Damon wrote:
On 6/12/23 8:31 PM, olcott wrote:
On 6/12/2023 6:36 PM, Richard Damon wrote:
On 6/12/23 12:40 PM, olcott wrote:It is a verified fact that H does correctly report that D correctly
Software engineers can easily verify that D correctly simulated by H >>>>>>> cannot possibly reach its own line 09 and terminate normally.
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 }
*Execution Trace*
Line 14: main() invokes D(D)
*keeps repeating* (unless aborted)
Line 06: simulated D(D) invokes simulated H(D,D) that simulates D(D) >>>>>>>
*Simulation invariant*
D correctly simulated by H cannot possibly reach its own line 09. >>>>>>>
Is it dead obvious to everyone here when examining the execution >>>>>>> trace of lines 14 and 06 above that D correctly simulated by H
cannot
possibly terminate normally by reaching its own line 09?
This means that when termination analyzer H aborts its simulation >>>>>>> of D
and reports that its correctly simulated input cannot possibly
terminate
normally it is merely reporting an easily verified fact.
*THE ABOVE IS AN EASILY VERIFIED FACT OF CORRECT SOFTWARE
ENGINEERING*
I will provide the next steps of the analysis after the above has >>>>>>> been accepted.
Right, it is impossibl to design an H that can correctly simulate
that D and reach a final state.
Thus, no H can validly say the D built on it is Halting.
simulated by H cannot possibly terminate normally.
So, you admit you are working on POOP and not the Halting Problem?
It is a verified fact that H does correctly report that D correctly
simulated by H cannot possibly terminate normally.
Until you explicitly acknowledge that verified fact I am no longer
willing to talk to you.
Since that isn't the question of the Halting Problem,
willing to talk to you.
On 6/12/23 9:59 PM, olcott wrote:
On 6/12/2023 8:55 PM, Richard Damon wrote:
On 6/12/23 9:38 PM, olcott wrote:Until you explicitly acknowledge that verified fact I am no longer
On 6/12/2023 8:26 PM, Richard Damon wrote:
On 6/12/23 8:31 PM, olcott wrote:
On 6/12/2023 6:36 PM, Richard Damon wrote:
On 6/12/23 12:40 PM, olcott wrote:It is a verified fact that H does correctly report that D correctly >>>>>> simulated by H cannot possibly terminate normally.
Software engineers can easily verify that D correctly simulated >>>>>>>> by H
cannot possibly reach its own line 09 and terminate normally.
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 }
*Execution Trace*
Line 14: main() invokes D(D)
*keeps repeating* (unless aborted)
Line 06: simulated D(D) invokes simulated H(D,D) that simulates >>>>>>>> D(D)
*Simulation invariant*
D correctly simulated by H cannot possibly reach its own line 09. >>>>>>>>
Is it dead obvious to everyone here when examining the execution >>>>>>>> trace of lines 14 and 06 above that D correctly simulated by H >>>>>>>> cannot
possibly terminate normally by reaching its own line 09?
This means that when termination analyzer H aborts its
simulation of D
and reports that its correctly simulated input cannot possibly >>>>>>>> terminate
normally it is merely reporting an easily verified fact.
*THE ABOVE IS AN EASILY VERIFIED FACT OF CORRECT SOFTWARE
ENGINEERING*
I will provide the next steps of the analysis after the above
has been accepted.
Right, it is impossibl to design an H that can correctly simulate >>>>>>> that D and reach a final state.
Thus, no H can validly say the D built on it is Halting.
So, you admit you are working on POOP and not the Halting Problem?
It is a verified fact that H does correctly report that D correctly
simulated by H cannot possibly terminate normally.
Until you explicitly acknowledge that verified fact I am no longer
willing to talk to you.
Since that isn't the question of the Halting Problem,
willing to talk to you.
Which verifyied fact?
On 6/12/23 11:04 PM, olcott wrote:
On 6/12/2023 10:03 PM, Richard Damon wrote:
On 6/12/23 9:59 PM, olcott wrote:It is a verified fact that H does correctly report that D correctly
On 6/12/2023 8:55 PM, Richard Damon wrote:
On 6/12/23 9:38 PM, olcott wrote:Until you explicitly acknowledge that verified fact I am no longer
On 6/12/2023 8:26 PM, Richard Damon wrote:
On 6/12/23 8:31 PM, olcott wrote:
On 6/12/2023 6:36 PM, Richard Damon wrote:
On 6/12/23 12:40 PM, olcott wrote:It is a verified fact that H does correctly report that D correctly >>>>>>>> simulated by H cannot possibly terminate normally.
Software engineers can easily verify that D correctly
simulated by H
cannot possibly reach its own line 09 and terminate normally. >>>>>>>>>>
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 }
*Execution Trace*
Line 14: main() invokes D(D)
*keeps repeating* (unless aborted)
Line 06: simulated D(D) invokes simulated H(D,D) that
simulates D(D)
*Simulation invariant*
D correctly simulated by H cannot possibly reach its own line 09. >>>>>>>>>>
Is it dead obvious to everyone here when examining the execution >>>>>>>>>> trace of lines 14 and 06 above that D correctly simulated by H >>>>>>>>>> cannot
possibly terminate normally by reaching its own line 09?
This means that when termination analyzer H aborts its
simulation of D
and reports that its correctly simulated input cannot possibly >>>>>>>>>> terminate
normally it is merely reporting an easily verified fact.
*THE ABOVE IS AN EASILY VERIFIED FACT OF CORRECT SOFTWARE
ENGINEERING*
I will provide the next steps of the analysis after the above >>>>>>>>>> has been accepted.
Right, it is impossibl to design an H that can correctly
simulate that D and reach a final state.
Thus, no H can validly say the D built on it is Halting.
So, you admit you are working on POOP and not the Halting Problem? >>>>>>>
It is a verified fact that H does correctly report that D correctly >>>>>> simulated by H cannot possibly terminate normally.
Until you explicitly acknowledge that verified fact I am no longer >>>>>> willing to talk to you.
Since that isn't the question of the Halting Problem,
willing to talk to you.
Which verifyied fact?
simulated by H cannot possibly terminate normally.
And how have you "verified" that?
Remember, any H that has aborted its simulation has not "correctly
simulated" its input
On 6/12/2023 10:14 PM, Richard Damon wrote:
On 6/12/23 11:04 PM, olcott wrote:
On 6/12/2023 10:03 PM, Richard Damon wrote:
On 6/12/23 9:59 PM, olcott wrote:It is a verified fact that H does correctly report that D correctly
On 6/12/2023 8:55 PM, Richard Damon wrote:
On 6/12/23 9:38 PM, olcott wrote:Until you explicitly acknowledge that verified fact I am no longer
On 6/12/2023 8:26 PM, Richard Damon wrote:
On 6/12/23 8:31 PM, olcott wrote:
On 6/12/2023 6:36 PM, Richard Damon wrote:
On 6/12/23 12:40 PM, olcott wrote:It is a verified fact that H does correctly report that D
Software engineers can easily verify that D correctly
simulated by H
cannot possibly reach its own line 09 and terminate normally. >>>>>>>>>>>
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 }
*Execution Trace*
Line 14: main() invokes D(D)
*keeps repeating* (unless aborted)
Line 06: simulated D(D) invokes simulated H(D,D) that
simulates D(D)
*Simulation invariant*
D correctly simulated by H cannot possibly reach its own line >>>>>>>>>>> 09.
Is it dead obvious to everyone here when examining the execution >>>>>>>>>>> trace of lines 14 and 06 above that D correctly simulated by >>>>>>>>>>> H cannot
possibly terminate normally by reaching its own line 09? >>>>>>>>>>>
This means that when termination analyzer H aborts its
simulation of D
and reports that its correctly simulated input cannot
possibly terminate
normally it is merely reporting an easily verified fact. >>>>>>>>>>>
*THE ABOVE IS AN EASILY VERIFIED FACT OF CORRECT SOFTWARE >>>>>>>>>>> ENGINEERING*
I will provide the next steps of the analysis after the above >>>>>>>>>>> has been accepted.
Right, it is impossibl to design an H that can correctly
simulate that D and reach a final state.
Thus, no H can validly say the D built on it is Halting.
correctly
simulated by H cannot possibly terminate normally.
So, you admit you are working on POOP and not the Halting Problem? >>>>>>>>
It is a verified fact that H does correctly report that D correctly >>>>>>> simulated by H cannot possibly terminate normally.
Until you explicitly acknowledge that verified fact I am no longer >>>>>>> willing to talk to you.
Since that isn't the question of the Halting Problem,
willing to talk to you.
Which verifyied fact?
simulated by H cannot possibly terminate normally.
And how have you "verified" that?
Remember, any H that has aborted its simulation has not "correctly
simulated" its input
As per the requirements of a termination analyzer that has been designed
to prevent DOS attacks
It is a verified fact that H does correctly report that D correctly
simulated by H cannot possibly terminate normally, thus D must not be
allowed to execute.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 109:44:13 |
| Calls: | 6,662 |
| Files: | 12,209 |
| Messages: | 5,335,727 |