On 7/17/22 11:45 PM, olcott wrote:
On 7/17/2022 9:53 PM, Richard Damon wrote:
On 7/17/22 9:48 PM, olcott wrote:
On 7/17/2022 8:27 PM, Richard Damon wrote:
We have been talking about this for many months and you haven't
On 7/17/22 8:56 PM, olcott wrote:
On 7/17/2022 4:10 PM, Richard Damon wrote:
On 7/17/22 3:42 PM, olcott wrote:
On 7/17/2022 2:20 PM, Richard Damon wrote:
On 7/17/22 2:15 PM, olcott wrote:*Yes it does, this is simply over your head*
On 7/17/2022 11:55 AM, Richard Damon wrote:
On 7/17/22 12:47 PM, olcott wrote:On 7/16/2022 2:28 PM, Mike Terry wrote:
On 7/17/2022 11:41 AM, Richard Damon wrote:
On 7/17/22 9:23 AM, olcott wrote:
On 7/17/2022 6:37 AM, Richard Damon wrote:
On 7/16/22 11:11 PM, olcott wrote:
On 7/16/2022 10:54 AM, Mike Terry wrote:
On 16/07/2022 12:23, Paul N wrote:
PO's simulation is correct at the individual >>>>>>>>>>>>>>>> instruction level.
His H steps the simulation forward a number of steps, >>>>>>>>>>>>>>>> and each
of those steps exactly matches the P(P) calculation >>>>>>>>>>>>>>>> steps.
We can see from the x86 execution trace of the simulated >>>>>>>>>>>>>>>> P that the behavior of this simulated P exactly matches >>>>>>>>>>>>>>>> its x86 source-code, line-by-line.
What we can also see from this same execution trace is >>>>>>>>>>>>>>>> that when H calls H(P,P) the simulated P remains stuck >>>>>>>>>>>>>>>> calling H(P,P) to simulate itself again thus forever >>>>>>>>>>>>>>>> preventing this simulated P from ever terminating >>>>>>>>>>>>>>>> normally by reaching its C:"return" or x86:"ret" >>>>>>>>>>>>>>>> instruction.
Except it doesn't because H is KNOWN to abort its >>>>>>>>>>>>>>> simulation when it sees that the simulation will reach >>>>>>>>>>>>>>> the first call to H in the simulation.
You logic is based on the assumption that H actually >>>>>>>>>>>>>>> won't stop simulating its input, when in actual fact it >>>>>>>>>>>>>>> will. Thus you have a false premise in your logic, so H >>>>>>>>>>>>>>> never actually proved its fact considering the H that it is. >>>>>>>>>>>>>>>
Yes, H can prove that IF H never aborts, that this makes >>>>>>>>>>>>>>> a P that never halts. But since this is NOT the
definition of H, that doesn't say anything about what the >>>>>>>>>>>>>>> machine where H does abort its simulation.
Halting means terminated normally when the correctly >>>>>>>>>>>>>> simulated P reaches its last instruction. Even though I >>>>>>>>>>>>>> have corrected you on this many hundreds of times you >>>>>>>>>>>>>> still fail to understand that an aborted simulation does >>>>>>>>>>>>>> not mean that the simulated input halted. You are
moronically stupid on this point.
And YOU are the moron for thinking that just because a >>>>>>>>>>>>> simulation was aborted the CORRECT simulation of that input >>>>>>>>>>>>> can't continue to reach the final state.
Your replies are moronically stupid because they always make >>>>>>>>>>>> sure to maimtain the same false assumptions (utterly
impervious to all reason) even when these false assumptions >>>>>>>>>>>> corrected hundreds of times.
NAME ONE FALSE ASSUMPTION!
On 16/07/2022 17:40, Richard Damon wrote:
But "incomplete" is incorrect if your logic assumes that the >>>>>>>>>> Â >> simulation not reaching the final state PROVES non-halting. >>>>>>>>>> Â >I don't believe PO thinks that, irrespective of how badly >>>>>>>>>> he explains
things. I think he believes that the simulation would >>>>>>>>>> never halt
*because his never-halting-abort test matched*, NOT simply >>>>>>>>>> as a
consequence of aborting. E.g. he seems to understand that >>>>>>>>>> a simulator
that steps 10 steps then stops regardless, does not imply >>>>>>>>>> that the
simulated computation does not halt.
SO, whats wrong with my statement.
An incomplete simulation not reaching a halting state does NOT >>>>>>>>> prove that the input is non-halting.
Once a non-halting behavior pattern is correctly matched the
simulation can be aborted and the input rejected as non-halting. >>>>>>>>
No, you are totally wrong on that. If you say I am mistaken,
which of these statements, which PROVE my point, is in error? If >>>>>>> none are, then my statement is PROVEN. Note, these are based on
the well established definition of Computation Theory and
statement YOU have made about your program.
Just claiming you have proven the opposite is NOT enough, as all >>>>>>> that does is show that your logic system is inconsistent, because >>>>>>> you have added inconsistent rules to your system (likely rules
that just aren't true).
1) You claim H(P,P) correctly returns 0, so H(P,P) must actually >>>>>>> be returning 0.
2) P calls H(P,P)
P is aborted before the call is ever made.
This seems to be the key to overcome referential transparency.
Just you proving your an idiot, and not reading?
That was saying that the SOURCE CODE of P calls H(P,P)
There IS no "Aborts" at the source code level.
noticed that H operates at the machine language level?
But the code for P was still specified at a source code level.
You keep on trying to say that the behavior of the input to H(P,P)
doesn't match the behavior of P(P), but the point you miss is that
then your code for P is wrong.
You are simply too stupid to verify that facts to prove that it is
correct.
*Halting problem proofs refuted on the basis of software engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
So, you are admitting that there is no error in my claim and it IS a
fact that H does not correctly determine to Halting of P(P)?
Then who is the one too stupid to verify facts?
Note, if my proof is correct, and your proof is corret, all this proves
is that the extra rules you added to your logic make your logic system inconsistent, by the basic definition of inconsistency.
On 7/18/2022 5:56 AM, Richard Damon wrote:
On 7/17/22 11:45 PM, olcott wrote:
On 7/17/2022 9:53 PM, Richard Damon wrote:
On 7/17/22 9:48 PM, olcott wrote:
On 7/17/2022 8:27 PM, Richard Damon wrote:
We have been talking about this for many months and you haven't noticed that H operates at the
On 7/17/22 8:56 PM, olcott wrote:
On 7/17/2022 4:10 PM, Richard Damon wrote:
On 7/17/22 3:42 PM, olcott wrote:
On 7/17/2022 2:20 PM, Richard Damon wrote:
On 7/17/22 2:15 PM, olcott wrote:*Yes it does, this is simply over your head*
On 7/17/2022 11:55 AM, Richard Damon wrote:
On 7/17/22 12:47 PM, olcott wrote:On 7/16/2022 2:28 PM, Mike Terry wrote:
On 7/17/2022 11:41 AM, Richard Damon wrote:
On 7/17/22 9:23 AM, olcott wrote:
On 7/17/2022 6:37 AM, Richard Damon wrote:And YOU are the moron for thinking that just because a simulation was aborted the
On 7/16/22 11:11 PM, olcott wrote:
On 7/16/2022 10:54 AM, Mike Terry wrote:
On 16/07/2022 12:23, Paul N wrote:We can see from the x86 execution trace of the simulated P that the behavior of
PO's simulation is correct at the individual instruction level.
His H steps the simulation forward a number of steps, and each
of those steps exactly matches the P(P) calculation steps. >>>>>>>>>>>>>>>>>
this simulated P exactly matches its x86 source-code, line-by-line.
What we can also see from this same execution trace is that when H calls H(P,P) the
simulated P remains stuck calling H(P,P) to simulate itself again thus forever
preventing this simulated P from ever terminating normally by reaching its
C:"return" or x86:"ret" instruction.
Except it doesn't because H is KNOWN to abort its simulation when it sees that the
simulation will reach the first call to H in the simulation. >>>>>>>>>>>>>>>>
You logic is based on the assumption that H actually won't stop simulating its
input, when in actual fact it will. Thus you have a false premise in your logic, so
H never actually proved its fact considering the H that it is. >>>>>>>>>>>>>>>>
Yes, H can prove that IF H never aborts, that this makes a P that never halts. But
since this is NOT the definition of H, that doesn't say anything about what the
machine where H does abort its simulation.
Halting means terminated normally when the correctly simulated P reaches its last
instruction. Even though I have corrected you on this many hundreds of times you
still fail to understand that an aborted simulation does not mean that the simulated
input halted. You are moronically stupid on this point. >>>>>>>>>>>>>>
CORRECT simulation of that input can't continue to reach the final state.
Your replies are moronically stupid because they always make sure to maimtain the same
false assumptions (utterly impervious to all reason) even when these false assumptions
corrected hundreds of times.
NAME ONE FALSE ASSUMPTION!
On 16/07/2022 17:40, Richard Damon wrote:
But "incomplete" is incorrect if your logic assumes that the >>>>>>>>>>> >> simulation not reaching the final state PROVES non-halting. >>>>>>>>>>> >I don't believe PO thinks that, irrespective of how badly he explains
things. I think he believes that the simulation would never halt
*because his never-halting-abort test matched*, NOT simply as a >>>>>>>>>>> > consequence of aborting. E.g. he seems to understand that a simulator
that steps 10 steps then stops regardless, does not imply that the
simulated computation does not halt.
SO, whats wrong with my statement.
An incomplete simulation not reaching a halting state does NOT prove that the input is
non-halting.
Once a non-halting behavior pattern is correctly matched the simulation can be aborted and
the input rejected as non-halting.
No, you are totally wrong on that. If you say I am mistaken, which of these statements,
which PROVE my point, is in error? If none are, then my statement is PROVEN. Note, these are
based on the well established definition of Computation Theory and statement YOU have made
about your program.
Just claiming you have proven the opposite is NOT enough, as all that does is show that your
logic system is inconsistent, because you have added inconsistent rules to your system
(likely rules that just aren't true).
1) You claim H(P,P) correctly returns 0, so H(P,P) must actually be returning 0.
2) P calls H(P,P)
P is aborted before the call is ever made.
This seems to be the key to overcome referential transparency.
Just you proving your an idiot, and not reading?
That was saying that the SOURCE CODE of P calls H(P,P)
There IS no "Aborts" at the source code level.
machine language level?
But the code for P was still specified at a source code level.
You keep on trying to say that the behavior of the input to H(P,P) doesn't match the behavior of
P(P), but the point you miss is that then your code for P is wrong.
You are simply too stupid to verify that facts to prove that it is correct. >>>
*Halting problem proofs refuted on the basis of software engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
So, you are admitting that there is no error in my claim and it IS a fact that H does not
correctly determine to Halting of P(P)?
Then who is the one too stupid to verify facts?
Note, if my proof is correct, and your proof is corret, all this proves is that the extra rules
you added to your logic make your logic system inconsistent, by the basic definition of
inconsistency.
I have told you a thousands times that halting is terminating normally by reaching the last
instruction (final state) and you still have it stuck in your head that halting is stopping for any
reason.
Mike still says that I get this wrong when I have proven that I get it correctly hundreds of times:
*computation that halts* … the Turing machine will halt whenever it enters a final state.
(Linz:1990:234)
Linz, Peter 1990. An Introduction to Formal Languages and Automata. Lexington/Toronto: D. C. Heath
and Company.
On 7/18/2022 5:56 AM, Richard Damon wrote:
On 7/17/22 11:45 PM, olcott wrote:
On 7/17/2022 9:53 PM, Richard Damon wrote:
On 7/17/22 9:48 PM, olcott wrote:
On 7/17/2022 8:27 PM, Richard Damon wrote:
We have been talking about this for many months and you haven't
On 7/17/22 8:56 PM, olcott wrote:
On 7/17/2022 4:10 PM, Richard Damon wrote:
On 7/17/22 3:42 PM, olcott wrote:
On 7/17/2022 2:20 PM, Richard Damon wrote:
On 7/17/22 2:15 PM, olcott wrote:*Yes it does, this is simply over your head*
On 7/17/2022 11:55 AM, Richard Damon wrote:
On 7/17/22 12:47 PM, olcott wrote:On 7/16/2022 2:28 PM, Mike Terry wrote:
On 7/17/2022 11:41 AM, Richard Damon wrote:
On 7/17/22 9:23 AM, olcott wrote:
On 7/17/2022 6:37 AM, Richard Damon wrote:
On 7/16/22 11:11 PM, olcott wrote:
On 7/16/2022 10:54 AM, Mike Terry wrote:
On 16/07/2022 12:23, Paul N wrote:
PO's simulation is correct at the individual >>>>>>>>>>>>>>>>> instruction level.
His H steps the simulation forward a number of >>>>>>>>>>>>>>>>> steps, and each
of those steps exactly matches the P(P) calculation >>>>>>>>>>>>>>>>> steps.
We can see from the x86 execution trace of the >>>>>>>>>>>>>>>>> simulated P that the behavior of this simulated P >>>>>>>>>>>>>>>>> exactly matches its x86 source-code, line-by-line. >>>>>>>>>>>>>>>>>
What we can also see from this same execution trace is >>>>>>>>>>>>>>>>> that when H calls H(P,P) the simulated P remains stuck >>>>>>>>>>>>>>>>> calling H(P,P) to simulate itself again thus forever >>>>>>>>>>>>>>>>> preventing this simulated P from ever terminating >>>>>>>>>>>>>>>>> normally by reaching its C:"return" or x86:"ret" >>>>>>>>>>>>>>>>> instruction.
Except it doesn't because H is KNOWN to abort its >>>>>>>>>>>>>>>> simulation when it sees that the simulation will reach >>>>>>>>>>>>>>>> the first call to H in the simulation.
You logic is based on the assumption that H actually >>>>>>>>>>>>>>>> won't stop simulating its input, when in actual fact it >>>>>>>>>>>>>>>> will. Thus you have a false premise in your logic, so H >>>>>>>>>>>>>>>> never actually proved its fact considering the H that it >>>>>>>>>>>>>>>> is.
Yes, H can prove that IF H never aborts, that this makes >>>>>>>>>>>>>>>> a P that never halts. But since this is NOT the >>>>>>>>>>>>>>>> definition of H, that doesn't say anything about what >>>>>>>>>>>>>>>> the machine where H does abort its simulation. >>>>>>>>>>>>>>>>
Halting means terminated normally when the correctly >>>>>>>>>>>>>>> simulated P reaches its last instruction. Even though I >>>>>>>>>>>>>>> have corrected you on this many hundreds of times you >>>>>>>>>>>>>>> still fail to understand that an aborted simulation does >>>>>>>>>>>>>>> not mean that the simulated input halted. You are >>>>>>>>>>>>>>> moronically stupid on this point.
And YOU are the moron for thinking that just because a >>>>>>>>>>>>>> simulation was aborted the CORRECT simulation of that >>>>>>>>>>>>>> input can't continue to reach the final state.
Your replies are moronically stupid because they always >>>>>>>>>>>>> make sure to maimtain the same false assumptions (utterly >>>>>>>>>>>>> impervious to all reason) even when these false assumptions >>>>>>>>>>>>> corrected hundreds of times.
NAME ONE FALSE ASSUMPTION!
On 16/07/2022 17:40, Richard Damon wrote:
But "incomplete" is incorrect if your logic assumes that the >>>>>>>>>>> Â >> simulation not reaching the final state PROVES non-halting. >>>>>>>>>>> Â >I don't believe PO thinks that, irrespective of how badly >>>>>>>>>>> he explains
things. I think he believes that the simulation would >>>>>>>>>>> never halt
*because his never-halting-abort test matched*, NOT simply >>>>>>>>>>> as a
consequence of aborting. E.g. he seems to understand that >>>>>>>>>>> a simulator
that steps 10 steps then stops regardless, does not imply >>>>>>>>>>> that the
simulated computation does not halt.
SO, whats wrong with my statement.
An incomplete simulation not reaching a halting state does NOT >>>>>>>>>> prove that the input is non-halting.
Once a non-halting behavior pattern is correctly matched the >>>>>>>>> simulation can be aborted and the input rejected as non-halting. >>>>>>>>>
No, you are totally wrong on that. If you say I am mistaken,
which of these statements, which PROVE my point, is in error? If >>>>>>>> none are, then my statement is PROVEN. Note, these are based on >>>>>>>> the well established definition of Computation Theory and
statement YOU have made about your program.
Just claiming you have proven the opposite is NOT enough, as all >>>>>>>> that does is show that your logic system is inconsistent,
because you have added inconsistent rules to your system (likely >>>>>>>> rules that just aren't true).
1) You claim H(P,P) correctly returns 0, so H(P,P) must actually >>>>>>>> be returning 0.
2) P calls H(P,P)
P is aborted before the call is ever made.
This seems to be the key to overcome referential transparency.
Just you proving your an idiot, and not reading?
That was saying that the SOURCE CODE of P calls H(P,P)
There IS no "Aborts" at the source code level.
noticed that H operates at the machine language level?
But the code for P was still specified at a source code level.
You keep on trying to say that the behavior of the input to H(P,P)
doesn't match the behavior of P(P), but the point you miss is that
then your code for P is wrong.
You are simply too stupid to verify that facts to prove that it is
correct.
*Halting problem proofs refuted on the basis of software engineering*
https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
So, you are admitting that there is no error in my claim and it IS a
fact that H does not correctly determine to Halting of P(P)?
Then who is the one too stupid to verify facts?
Note, if my proof is correct, and your proof is corret, all this
proves is that the extra rules you added to your logic make your logic
system inconsistent, by the basic definition of inconsistency.
I have told you a thousands times that halting is terminating normally
by reaching the last instruction (final state) and you still have it
stuck in your head that halting is stopping for any reason.
Mike still says that I get this wrong when I have proven that I get it correctly hundreds of times:
*computation that halts* … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)
Linz, Peter 1990. An Introduction to Formal Languages and Automata. Lexington/Toronto: D. C. Heath and Company.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 155:47:46 |
| Calls: | 10,383 |
| Files: | 14,056 |
| Messages: | 6,416,464 |