In other words you simply {don't believe in} mathematical induction that correctly infers an infinite sequence from a finite sequence. https://en.wikipedia.org/wiki/Mathematical_inductionYou keep disagreeing with the easily verified fact that D correctlysimulated by H cannot possibly terminate normally thus conclusively
proving your total lack of any interest in an honest dialogue.
Which is an irrelevent fact, since we aren't asking H about its own
PARTIAL simulation of its input,
simulated by H cannot possibly EVER terminate normally even if the
simulation could be infinite.
This seems to conclusively prove that your software engineering skills
are not very good or you have no intention on participating in any
honest dialogue.
I don't like to get into a battle of wits with an unarmed opponent, but
it seems you insist.
Please show where you claim has ANY actual significant, and isn't just
the strawman that describes your brains.
A Halt Decider is DEFINED to return an answer based on the behavior of
the machine DESCRIBED by its input, not a PARTIAL simulation done by the decider.
You must not have any software engineering skill.You keep disagreeing with the easily verified fact that D correctly
Thus, H(P,d) needs to decide what UTM(P,d) would do with the
exact same input. Note, D calls H, not the machine simulating it, >>>>>>> so UTM(D,D) would see D(D) calling H(D.D) and what H(D,D) does
with that input.
The behavior of the non-input is the behavior that is one
recursive invocation removed from the behavior of its input.
Nope, You are just proving you don't understand a THING about the >>>>>>> problem
I guess this is why you can't understand how Turing Machine
works. They are defined simply enough you can't twist them.
H uses an x86 emulator to correctly simulate D.
No, it partially simulates the execution path o D.
Since you ar equating simulation to direct execution, the only >>>>>>>>> meaning of correct includes being COMPLETE.
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 ...
You keep disagreeing with the easily verified fact that D correctly >>>>>> simulated by H cannot possibly terminate normally thus conclusively >>>>>> proving your total lack of any interest in an honest dialogue.
Which is an irrelevent fact, since we aren't asking H about its own
PARTIAL simulation of its input,
simulated by H cannot possibly EVER terminate normally even if the
simulation could be infinite.
This seems to conclusively prove that your software engineering skills >>>> are not very good or you have no intention on participating in any
honest dialogue.
I don't like to get into a battle of wits with an unarmed opponent,
but it seems you insist.
Please show where you claim has ANY actual significant, and isn't
just the strawman that describes your brains.
A Halt Decider is DEFINED to return an answer based on the behavior
of the machine DESCRIBED by its input, not a PARTIAL simulation done
by the decider.
So, no answer to any of the questions, I guess you are ADMITTING that
you have no answers.
In other words you simply {don't believe in} mathematical induction that
correctly infers an infinite sequence from a finite sequence.
https://en.wikipedia.org/wiki/Mathematical_induction
SO, provide the VALID induction proof for you assertion.
Remember to include the fact that EVERY H might abort its simulation.
I don't think you know how to do an actual proof by induction.
You are just showing that you are using word salid.
Yes, if you can actualy make a SOUND and VALID proof, from the partial simulation, you can do so.
H doesn't have enough information to make that decision,
You keep disagreeing with the easily verified fact that D correctlyNo, it partially simulates the execution path o D.
Since you ar equating simulation to direct execution, the only >>>>>>>> meaning of correct includes being COMPLETE.
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 ...
You keep disagreeing with the easily verified fact that D correctly
simulated by H cannot possibly terminate normally thus conclusively
proving your total lack of any interest in an honest dialogue.
Which is an irrelevent fact, since we aren't asking H about its own
PARTIAL simulation of its input,
simulated by H cannot possibly EVER terminate normally even if the
simulation could be infinite.
This seems to conclusively prove that your software engineering skills
are not very good or you have no intention on participating in any
honest dialogue.
I don't like to get into a battle of wits with an unarmed opponent,
but it seems you insist.
Please show where you claim has ANY actual significant, and isn't just
the strawman that describes your brains.
A Halt Decider is DEFINED to return an answer based on the behavior of
the machine DESCRIBED by its input, not a PARTIAL simulation done by
the decider.
In other words you simply {don't believe in} mathematical induction that correctly infers an infinite sequence from a finite sequence. https://en.wikipedia.org/wiki/Mathematical_induction
Anyone with sufficient software engineering skill can easily determine
that D correctly simulated by H will never terminate normally after N simulated steps for any value of N.
You must not have any software engineering skill.You keep disagreeing with the easily verified fact that D correctlyYou already know that a decider computes the mapping
*from its input* to its own accept or reject state.
Right, and the "Input" is a description of a machine it is to
decide the behavior of.
In fact, you CAN define the behavior basd on simulation, as long >>>>>>>> as the simulation is of the right sort, that of an UNCONDITION >>>>>>>> COMPLETE SIMULATION.
H needs to answer about what your x86 simulator, if put into
pure simulation mode, would do when simulating the input to H. >>>>>>>>
That is its exact input, just not what it itself would do with >>>>>>>> it. That is the difference between accurately simulating an
input and deciding on it. Accurate simulations of a non-halting >>>>>>>> input take forever, deciding on it must take finite time.
Thus, H(P,d) needs to decide what UTM(P,d) would do with the
exact same input. Note, D calls H, not the machine simulating
it, so UTM(D,D) would see D(D) calling H(D.D) and what H(D,D)
does with that input.
The behavior of the non-input is the behavior that is one
recursive invocation removed from the behavior of its input.
Nope, You are just proving you don't understand a THING about
the problem
I guess this is why you can't understand how Turing Machine
works. They are defined simply enough you can't twist them.
H uses an x86 emulator to correctly simulate D.
No, it partially simulates the execution path o D.
Since you ar equating simulation to direct execution, the only >>>>>>>>>> meaning of correct includes being COMPLETE.
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 ...
You keep disagreeing with the easily verified fact that D correctly >>>>>>> simulated by H cannot possibly terminate normally thus conclusively >>>>>>> proving your total lack of any interest in an honest dialogue.
Which is an irrelevent fact, since we aren't asking H about its
own PARTIAL simulation of its input,
simulated by H cannot possibly EVER terminate normally even if the
simulation could be infinite.
This seems to conclusively prove that your software engineering skills >>>>> are not very good or you have no intention on participating in any
honest dialogue.
I don't like to get into a battle of wits with an unarmed opponent,
but it seems you insist.
Please show where you claim has ANY actual significant, and isn't
just the strawman that describes your brains.
A Halt Decider is DEFINED to return an answer based on the behavior
of the machine DESCRIBED by its input, not a PARTIAL simulation done
by the decider.
So, no answer to any of the questions, I guess you are ADMITTING that
you have no answers.
In other words you simply {don't believe in} mathematical induction that >>> correctly infers an infinite sequence from a finite sequence.
https://en.wikipedia.org/wiki/Mathematical_induction
SO, provide the VALID induction proof for you assertion.
Remember to include the fact that EVERY H might abort its simulation.
I don't think you know how to do an actual proof by induction.
You are just showing that you are using word salid.
Yes, if you can actualy make a SOUND and VALID proof, from the partial
simulation, you can do so.
H doesn't have enough information to make that decision,
It is probably a good idea that I create an actual inductive proof.
Partial proof of program correctness has always relied on an adaptation
of mathematical induction, thus I can cite sources that this adaptation
is known to be legitimate.
You must not have any software engineering skill.You keep disagreeing with the easily verified fact that D correctly >>>>>> simulated by H cannot possibly EVER terminate normally even if the >>>>>> simulation could be infinite.*This is factually incorrect*You keep insisting on staying out-of-sync by one recursive >>>>>>>>>>>> invocation.My way results in a halt decider that recognizes the >>>>>>>>>>>>>> actual behavior ofThe reason that I did this concretely in C is the there >>>>>>>>>>>>>>>> is no wiggle
room of ambiguity to deny what is actually occurring. >>>>>>>>>>>>>>
the actual input so that it doesn't get stuck in recursive >>>>>>>>>>>>>> simulation.
No, becase the ACTUAL BEHAVIOR of the machine in question >>>>>>>>>>>>> is what it does when actually run.
Can D correctly simulated by H terminate normally?
Why does that matter?
Since H is being asked about the actual execution of D(D). >>>>>>>>>>
H is only being asked about the behavior of its input.
Which is DEFINED as the Behavior of the Machine it describes. >>>>>>>>>
H is not being asked about the behavior of a non-input.
So, you think the x86 code of a program isn't a suitable
description of an x86 program?
You already know that a decider computes the mapping
*from its input* to its own accept or reject state.
Right, and the "Input" is a description of a machine it is to >>>>>>>>> decide the behavior of.
In fact, you CAN define the behavior basd on simulation, as
long as the simulation is of the right sort, that of an
UNCONDITION COMPLETE SIMULATION.
H needs to answer about what your x86 simulator, if put into >>>>>>>>> pure simulation mode, would do when simulating the input to H. >>>>>>>>>
That is its exact input, just not what it itself would do with >>>>>>>>> it. That is the difference between accurately simulating an
input and deciding on it. Accurate simulations of a non-halting >>>>>>>>> input take forever, deciding on it must take finite time.
Thus, H(P,d) needs to decide what UTM(P,d) would do with the >>>>>>>>> exact same input. Note, D calls H, not the machine simulating >>>>>>>>> it, so UTM(D,D) would see D(D) calling H(D.D) and what H(D,D) >>>>>>>>> does with that input.
Nope, You are just proving you don't understand a THING about >>>>>>>>> the problem
The behavior of the non-input is the behavior that is one
recursive invocation removed from the behavior of its input. >>>>>>>>>
I guess this is why you can't understand how Turing Machine
works. They are defined simply enough you can't twist them.
H uses an x86 emulator to correctly simulate D.
No, it partially simulates the execution path o D.
Since you ar equating simulation to direct execution, the >>>>>>>>>>> only meaning of correct includes being COMPLETE.
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 ...
You keep disagreeing with the easily verified fact that D correctly >>>>>>>> simulated by H cannot possibly terminate normally thus conclusively >>>>>>>> proving your total lack of any interest in an honest dialogue. >>>>>>>>
Which is an irrelevent fact, since we aren't asking H about its
own PARTIAL simulation of its input,
This seems to conclusively prove that your software engineering
skills
are not very good or you have no intention on participating in any >>>>>> honest dialogue.
I don't like to get into a battle of wits with an unarmed opponent,
but it seems you insist.
Please show where you claim has ANY actual significant, and isn't
just the strawman that describes your brains.
A Halt Decider is DEFINED to return an answer based on the behavior
of the machine DESCRIBED by its input, not a PARTIAL simulation
done by the decider.
So, no answer to any of the questions, I guess you are ADMITTING that
you have no answers.
In other words you simply {don't believe in} mathematical induction
that
correctly infers an infinite sequence from a finite sequence.
https://en.wikipedia.org/wiki/Mathematical_induction
SO, provide the VALID induction proof for you assertion.
Remember to include the fact that EVERY H might abort its simulation.
I don't think you know how to do an actual proof by induction.
You are just showing that you are using word salid.
Yes, if you can actualy make a SOUND and VALID proof, from the
partial simulation, you can do so.
H doesn't have enough information to make that decision,
It is probably a good idea that I create an actual inductive proof.
Partial proof of program correctness has always relied on an adaptation
of mathematical induction, thus I can cite sources that this adaptation
is known to be legitimate.
No, you seem to lack the basic concepts of requirements
I still remembered the guy's name that essentially invented proof ofYou must not have any software engineering skill.You keep disagreeing with the easily verified fact that D correctly >>>>>>> simulated by H cannot possibly EVER terminate normally even if the >>>>>>> simulation could be infinite.*This is factually incorrect*You keep insisting on staying out-of-sync by one recursive >>>>>>>>>>>>> invocation.My way results in a halt decider that recognizes the >>>>>>>>>>>>>>> actual behavior ofThus you knew that H is correct to abort its simulation >>>>>>>>>>>>>>>>> of D to prevent
its own infinite execution.
H is allowed to abort its simulation for any reason its >>>>>>>>>>>>>>>> programmer wants. It still needs to give the right >>>>>>>>>>>>>>>> answer to be correct, and that answer needs to describe >>>>>>>>>>>>>>>> the behavior of directly running the machine given an >>>>>>>>>>>>>>>> input.
Since H(D,D) has been said to return 0, we can by simple >>>>>>>>>>>>>>>> inspection, and verify by actually running it, see that >>>>>>>>>>>>>>>> D(D) will Halt, which means that H's answer is just wrong. >>>>>>>>>>>>>>>>
It might be a correct POOP decider, but only you seem >>>>>>>>>>>>>>>> interested in your POOP.
The reason that I did this concretely in C is the there >>>>>>>>>>>>>>>>> is no wiggle
room of ambiguity to deny what is actually occurring. >>>>>>>>>>>>>>>
the actual input so that it doesn't get stuck in >>>>>>>>>>>>>>> recursive simulation.
No, becase the ACTUAL BEHAVIOR of the machine in question >>>>>>>>>>>>>> is what it does when actually run.
Can D correctly simulated by H terminate normally?
Why does that matter?
Since H is being asked about the actual execution of D(D). >>>>>>>>>>>
H is only being asked about the behavior of its input.
Which is DEFINED as the Behavior of the Machine it describes. >>>>>>>>>>
H is not being asked about the behavior of a non-input.
So, you think the x86 code of a program isn't a suitable
description of an x86 program?
You already know that a decider computes the mapping
*from its input* to its own accept or reject state.
Right, and the "Input" is a description of a machine it is to >>>>>>>>>> decide the behavior of.
In fact, you CAN define the behavior basd on simulation, as >>>>>>>>>> long as the simulation is of the right sort, that of an
UNCONDITION COMPLETE SIMULATION.
H needs to answer about what your x86 simulator, if put into >>>>>>>>>> pure simulation mode, would do when simulating the input to H. >>>>>>>>>>
That is its exact input, just not what it itself would do with >>>>>>>>>> it. That is the difference between accurately simulating an >>>>>>>>>> input and deciding on it. Accurate simulations of a
non-halting input take forever, deciding on it must take
finite time.
Thus, H(P,d) needs to decide what UTM(P,d) would do with the >>>>>>>>>> exact same input. Note, D calls H, not the machine simulating >>>>>>>>>> it, so UTM(D,D) would see D(D) calling H(D.D) and what H(D,D) >>>>>>>>>> does with that input.
Nope, You are just proving you don't understand a THING about >>>>>>>>>> the problem
The behavior of the non-input is the behavior that is one >>>>>>>>>>> recursive invocation removed from the behavior of its input. >>>>>>>>>>
I guess this is why you can't understand how Turing Machine >>>>>>>>>> works. They are defined simply enough you can't twist them. >>>>>>>>>>
H uses an x86 emulator to correctly simulate D.
No, it partially simulates the execution path o D.
Since you ar equating simulation to direct execution, the >>>>>>>>>>>> only meaning of correct includes being COMPLETE.
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 ...
You keep disagreeing with the easily verified fact that D
correctly
simulated by H cannot possibly terminate normally thus
conclusively
proving your total lack of any interest in an honest dialogue. >>>>>>>>>
Which is an irrelevent fact, since we aren't asking H about its >>>>>>>> own PARTIAL simulation of its input,
This seems to conclusively prove that your software engineering
skills
are not very good or you have no intention on participating in any >>>>>>> honest dialogue.
I don't like to get into a battle of wits with an unarmed
opponent, but it seems you insist.
Please show where you claim has ANY actual significant, and isn't
just the strawman that describes your brains.
A Halt Decider is DEFINED to return an answer based on the
behavior of the machine DESCRIBED by its input, not a PARTIAL
simulation done by the decider.
So, no answer to any of the questions, I guess you are ADMITTING
that you have no answers.
In other words you simply {don't believe in} mathematical induction
that
correctly infers an infinite sequence from a finite sequence.
https://en.wikipedia.org/wiki/Mathematical_induction
SO, provide the VALID induction proof for you assertion.
Remember to include the fact that EVERY H might abort its simulation.
I don't think you know how to do an actual proof by induction.
You are just showing that you are using word salid.
Yes, if you can actualy make a SOUND and VALID proof, from the
partial simulation, you can do so.
H doesn't have enough information to make that decision,
It is probably a good idea that I create an actual inductive proof.
Partial proof of program correctness has always relied on an adaptation
of mathematical induction, thus I can cite sources that this adaptation
is known to be legitimate.
No, you seem to lack the basic concepts of requirements
program correctness. I took a course on this and got an A. I have two textbooks on proof of program correctness. It is all anchored in
mathematical induction.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 366 |
Nodes: | 16 (2 / 14) |
Uptime: | 25:19:55 |
Calls: | 7,832 |
Calls today: | 1 |
Files: | 12,933 |
Messages: | 5,770,990 |