| olcott <NoOne@NoWhere.com>: Jul 14 02:19PM -0500 This is an explanation of a key new insight into the halting problem provided in the language of software engineering. Technical computer science terms are explained using software engineering terms. No knowledge of the halting problem is required. It is based on fully operational software executed in the x86utm operating system. The x86utm operating system (based on an excellent open source x86 emulator) was created to study the details of the halting problem proof counter-examples at the much higher level of abstraction of C/x86. typedef void (*ptr)(); int H(ptr p, ptr i); // simulating halt decider void P(ptr x) { int Halt_Status = H(x, x); if (Halt_Status) HERE: goto HERE; return; } int main() { Output("Input_Halts = ", H(P, P)); } When simulating halt decider H(P,P) simulates its input we can see that: (1) Function H() is called from P(). (2) With the same arguments to H(). (3) With no instructions in P preceding its invocation of H(P,P). The above shows that the simulated P cannot possibly terminate normally. Because H can see the same (1)(2)(3) that we see H aborts its simulation of P and rejects P as non-halting. In computability theory, the halting problem is the problem of determining, from a description of an arbitrary computer program and an input, whether the program will finish running, or continue to run forever. Alan Turing proved in 1936 that a general algorithm to solve the halting problem for all possible program- input pairs cannot exist. For any program H that might determine if programs halt, a "pathological" program P, called with some input, can pass its own source and its input to H and then specifically do the opposite of what H predicts P will do. No H can exist that handles this case. https://en.wikipedia.org/wiki/Halting_problem H and P implement the exact pathological relationship to each other as described above. Because H(P,P) does handle this case the above halting problem undecidable input template has been refuted. *When this halt deciding principle understood to be correct* A halt decider must compute the mapping from its inputs to an accept or reject state on the basis of the actual behavior that is actually specified by these inputs. *Then (by logical necessity) this implements that principle* Every simulating halt decider that correctly simulates its input until it correctly predicts that this simulated input would never terminate normally, correctly rejects this input as non-halting. *H is a Pure function* https://en.wikipedia.org/wiki/Pure_function thus implements a *Computable function* https://en.wikipedia.org/wiki/Computable_function Thus H is Turing computable. *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 -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| Mr Flibble <flibble@reddwarf.jmc.corp>: Jul 14 08:28PM +0100 On Thu, 14 Jul 2022 14:19:38 -0500 > Thus H is Turing computable. > *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 You forgot to mention infinite recursion which I suppose is progress. /Flibble |
| Richard Damon <Richard@Damon-Family.org>: Jul 13 07:51PM -0400 On 7/13/22 8:19 AM, olcott wrote: > Most everyone here knows that every function called in infinite > recursion never returns any value to its caller. There is no gibberish > that you can say that would convince them otherwise. That can't be a verified fact because the opposite is a verified fact, that the CORRECT simulation of the input to H(P,P), which is the correct simulation of P(P) will actually Halt if H(P,P) returns 0, as you claim it does. It doesn't matter that *H* can't do that emulation (and there is nothing in the actual Halting Problem definition that says it should), because H is a FIXED program in this case, which is admitted to aborting its simulation, based on (provenly incorrect) conditions it detected in its emulation of P(P). You claim that only H's emulation can show it is an error in your specification that means that NO program can be proved to be non-halting and so indicated by H, since if H indicates it, it didn't do a complete emulation of the program to show it. FAIL. What CAN be shown, and in fact even YOU have posted, is that an actual correct simulation of this input does halt. Note you proof of "essentially infinte recursion" is based on an error that ignores the ACTUAL behavor of H, but assumes that H actually meets its requirements. The fact that it doesn't meet its design requirements just shouws you don't actually know how to debug your own code. Also note, your claim that the behavior of input to H(P,P) doesn't actually match the behavior of P(P) just shows that you have a bug in P (or H), as it is supposed to ask H for it to decide on what P(P) will do, and if H(P,P) isn't defined to do that, it shouldn't make that call. |
| olcott <NoOne@NoWhere.com>: Jul 13 07:06PM -0500 On 7/13/2022 6:51 PM, Richard Damon wrote: > that the CORRECT simulation of the input to H(P,P), which is the correct > simulation of P(P) will actually Halt if H(P,P) returns 0, as you claim > it does. I already gave Paul N a great explanation of that on comp.theory. I won't be able to see your reply there because I have you blocked there. My explanation to wjj even sums it up better: On 7/13/2022 3:51 PM, olcott wrote: >> The property that an arbitrary program P will finish >> running or not is determined by running P as an >> independent program Because that would require that a halt decider must sometimes make its halt status decision on a basis other than the actual behavior of its actual input that long standing misconception has been refuted. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| Richard Damon <Richard@Damon-Family.org>: Jul 13 09:20PM -0400 On 7/13/22 8:06 PM, olcott wrote: > Because that would require that a halt decider must sometimes make its > halt status decision on a basis other than the actual behavior of its > actual input that long standing misconception has been refuted. No, because all the behavior of that program exists will be encoded in the representation of the program given to the decider. The fact that H can't correct USE that information doesn't mean it wasn't given to it. From the complete description of a Turing Machine and it input, the ENTIRE behavior has been defined, though it may take infinite time to determine this if the machine is non-halting. Give the complete x86 code of a program, and its input, the behavior of that program is completely defined. Thus, H has been given everything that it should need to determine what it needs to, if the results are actually computable. You big problem is you are confusing the phases of the programming process. During the DESIGN Phase, you get to change your program as you desire and work on logic asking how to get the right answer. When (and if) you comlete that design process, you now have a SPECIFIC program that you can test to see if it works. At this stage, the program does what it has been programmed to do, and you don't look at other possible behaviors of it. At this point you need to actually DEFINE what you H is, you have used several different sets of defiitions. One is that it just DOES a complete and correct simulation of its input, that this H has been show to not return an answer to H(P,P) and does make P(P) non-halting, but this can't be your "correct" H, since it never returns the answer. (and you can't say P is using this, when you are deciding with a different one). THe next design uses your defined rule that you CLAIM proves non-halting, that if P(P) calls H with the same input that H started with, then it can presume the input is non-halting. THis is proved incorrect by just running P(P), seeing it call H(P,P) and then that H(P,P) sees its simulation do this, it aborting the simulation, and returning to P and P(P) halting. This PROVES the rule wrong. You claim that the input to H(P,P) not being the same as P(P) is shown wrong because it MUST be or your P is defined incorrectly. Remember, the "impossible" program was defined to ask H about itself with its input and doing the opposite. Since P(P) calls H(P,P) to ask that question, if it doesn't actually mean that, you have an error in your problem construction. You sometimes go more nebulous and just say that H will simulate until it can actually PROVE that the input is non-halting, and while if it can actually do that, it will be right, all this is actually doing is saying that your Halt Decider will use a Halt Decider to tell it if its input is non-halting, and thus your DESIGN recurses and you end up with an infinite program. You ASSUME that there is SOME finite pattern that H can detect, since it is clear that if H doesn't abort its simulation it will never halt, but the problem is that this doesn't mean that if it does abort it is correct to say the input is non-halting, because the proof was based on a now false premise, that H will not abort its simulation. We can (and I have shown you) prove that there IS no finite pattern in P(P) that H could detect, because ANY pattern in P(P), if put into H as a non-halting pattern, cause H(P,P) to return 0 to P(P) and P(P) then halts. Thus there does NOT exist a pattern to detect that this P(P) is non-halting that H could use to answer non-halting. It IS possible for H to detect this fact, it just can't act on that knowledge without breaking the premise it uses to make this proof. The problem is that the Field of Computation Theory requries that Deciders actually return the answer, and in a way that another program can get it, to be considered a Decider. THus, we see that ANY H you design by your technique will either not answer or give the wrong answer, which is EXACTLY what the proof you are trying to refute says will happen. |
| olcott <NoOne@NoWhere.com>: Jul 13 08:34PM -0500 On 7/13/2022 8:20 PM, Richard Damon wrote: >> actual input that long standing misconception has been refuted. > No, because all the behavior of that program exists will be encoded in > the representation of the program given to the decider. The reason that I stop talking to you is that you make false assumptions that are utterly impervious to all reasoning. It is a verified fact that the input that is correctly simulated by H(P,P) cannot possibly terminate normally. It is also a verified fact that the direct execution of P(P) does terminate normally. It is also common knowledge that the correct simulation of a program is a correct measure of the behavior of this program. This conclusively proves that H(P,P) is correct to reject its input as non-halting and the behavior of a non-input cannot possibly contradict this. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| Richard Damon <Richard@Damon-Family.org>: Jul 13 09:55PM -0400 On 7/13/22 9:34 PM, olcott wrote: > This conclusively proves that H(P,P) is correct to reject its input as > non-halting and the behavior of a non-input cannot possibly contradict > this. YOU SAY THAT, but it is a FACT that you H doesn't correctly simulate the input (since it aborts it to return 0) so it doesn't MATTER that if it was a different program it wouldn't be able to simulate to a final state. You are just showing you don't understand the nature of what an algorithm IS> P calls H, and YOUR H simulates for a while, INCORRECTLY decides it doesn't halt, and returns 0, thus making P(P) a Halting Program. It doesn't matter that some other H that might exist that doesn't abort results in a P(P) that doesn't halt, that isn't the H that we are looking at the you claim correctly return 0, as THAT H never returns from H(P,P)/ The fact that you see these two DIFFERENT H's as the same thing just proves that YOU don't have a firm grip of what is true. Unless you can actually provide a H that with the EXACT SAME CODE, and as a PURE FUNCTION of its ihput does both of these, you are just caught in the lie you have been working on for decades. This code is of course impossible, which is why you have refused to show any version of this code that you have claimed to have had (with "small" errors) for years. The "Small errors" are fundamental design bugs that you may be trying to fix, and if you actually publish your code, it will become obvious that you have been lying about what you program does. You keep on saying that P(P) is a non-input, but then you are shown to LIE that your P meets the requirements of the "impossible program", as that asks H about the behavior of itself with its input, that is P(P), and you have coded that as H(P,P), so if the behavior of the input to H(P,P) is not the behabior of P(P) your P is not correct, and you proof is INVALID. You need to change P to call H in the way that DOES ask about P(P), and if you can't do that, you H is automattically proven wrong as you have shown an machine and input that it can not decide. Or perhaps more simply, you haven't shown that it gives the right answer for the impossible program, because you never asked it about it. You are showing your total lack of understanding of the basics of computation theory, or even basic logic. Your "proof" is a model for how not to try to prove something. |
| olcott <NoOne@NoWhere.com>: Jul 13 09:08PM -0500 On 7/13/2022 8:55 PM, Richard Damon wrote: > YOU SAY THAT, but it is a FACT that you H doesn't correctly simulate the > input (since it aborts it to return 0) so it doesn't MATTER that if it > was a different program it wouldn't be able to simulate to a final state. That you (and others) continue to lack the technical capacity to comprehend that H does correctly predict that its complete and correct simulation of its input would never result in this input terminating normally is far less than no rebuttal at all. Until you (and others) gain this technical capacity there is no sense continuing a dialogue. My grandfather George P. Olcott MD had a very key brilliant insight that my father often repeated to me: "One cannot argue with ignorance. *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 -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| Richard Damon <Richard@Damon-Family.org>: Jul 13 10:21PM -0400 On 7/13/22 10:08 PM, olcott wrote: > simulation of its input would never result in this input terminating > normally is far less than no rebuttal at all. Until you (and others) > gain this technical capacity there is no sense continuing a dialogue. How is it correct when H(P,P) sayts P(P) is non-halting when a direct exectuion of P(P) or a correct simulation by simualte(P,P) (where P still calls the previous H) show that it halts. Note, if you claim that the input behavior of the input to H(P,P) isn't the same as P(P) then you P isn't defined correctly, as that is how it asked H to decide on P(P). > My grandfather George P. Olcott MD had a very key brilliant insight that > my father often repeated to me: "One cannot argue with ignorance. Yep, YOU are a perfect proof of that. > *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 And condition (3) near the bottom of page 1 is just flat out incorrect, showing you don't understand what a PROGRAM actually is. The REAL rule you are thinking of includes the code of H in the space that needs to be looked at for the conditionals, since the H that P calls IS part of the 'code' of P. FAIL. PROOF OF YOUR IGNORANCE. Note, this has been pointed out ot you MANY times, but the fact that you continue repeating it with out showing how you establish this variant of the accepted rules just proves that you are just being intentionally deceptive. |
| Richard Damon <Richard@Damon-Family.org>: Jul 13 10:29PM -0400 On 7/13/22 9:34 PM, olcott wrote: >> the representation of the program given to the decider. > The reason that I stop talking to you is that you make false assumptions > that are utterly impervious to all reasoning. No, you stop talking to me because I am being too good at pointing out the errors in your logic. > It is a verified fact that the input that is correctly simulated by > H(P,P) cannot possibly terminate normally. It is also a verified fact > that the direct execution of P(P) does terminate normally. Nope. Pointed out elsewhere, the CORRECT simulation of the input to H(P,P) by a simulator that DOESN'T abort (but P still calls the H that does) shows that the input to H(P,P) will Halt if H(P,P) returns 0. > It is also common knowledge that the correct simulation of a program is > a correct measure of the behavior of this program. Right CORRECT, as in NOT ABORTED part way. > This conclusively proves that H(P,P) is correct to reject its input as > non-halting and the behavior of a non-input cannot possibly contradict > this. Nope. Since the correct (non-aborted) simulation of the input given to H(P,P) by a simulator that actually does a complete simulation while the input still calls the original H shows that the input to H(P,P) will halt if H(P,P) returns 0. If you try to claim that the correct simulation of the input to H(P,P) depends on the simulator that is doing the simulation, then you are showing you just don't understand how computations and simulations work. Since H doesn't do a complete simulation, you can't use proofs based on it doing so to show something. That is the DEFINITION of an UNSOUND argument. Since H (the one that gives the answer 0 to H(P,P), and that is the onne that the P we are talkng about is using) doesn't do a complete and correct simulation, ANY proof that include a condition "If H doesn't abort ..." is a false premise. Note, Halting is based on the program that is ACTUALLY there, not the theoretical one you were trying to write. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Jul 13 07:41PM -0700 > On 7/13/22 9:34 PM, olcott wrote: [214 lines deleted] Richard, please stop cross-posting to comp.lang.c and comp.lang.c++. Followups directed back where they belong. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips void Void(void) { Void(); } /* The recursive call of the void */ |
| olcott <NoOne@NoWhere.com>: Jul 13 09:55PM -0500 On 7/13/2022 9:21 PM, Richard Damon wrote: > How is it correct when H(P,P) sayts P(P) is non-halting when a direct > exectuion of P(P) or a correct simulation by simualte(P,P) (where P > still calls the previous H) show that it halts. Most everyone here can see: (from my updated simplified paper) It is a verified fact that the input that is correctly simulated by H(P,P) cannot possibly terminate normally. The smartest software engineers here can also see that H does correctly predict this. People at the bottom 10% of technical competence may not see either one of these. No sense continuing to talk to these people. *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 -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| - Olcott <polcott2@gmail.com>: Jul 13 08:03PM -0700 On Wednesday, July 13, 2022 at 9:41:40 PM UTC-5, Keith Thompson wrote: > Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com > Working, but not speaking, for Philips > void Void(void) { Void(); } /* The recursive call of the void */ I will stop cross-posting to comp.theory the posts belong here. I could very quickly get closure and be done with this if someone with your degree of technical competence to take ten minutes to see that I am actually correct. The newest revision to my paper is much easier to understand no knowledge of x86 assembly language is required. *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 |
| Mr Flibble <flibble@reddwarf.jmc.corp>: Jul 14 05:18AM +0100 On Wed, 13 Jul 2022 21:55:25 -0500 > Most everyone here can see: (from my updated simplified paper) > It is a verified fact that the input that is correctly simulated by > H(P,P) cannot possibly terminate normally. I have shown that a simulating halting decider needn't be recursive in nature thus can terminate normally. You are wrong on all fronts. /Flibble |
| olcott <NoOne@NoWhere.com>: Jul 13 11:27PM -0500 On 7/13/2022 11:18 PM, Mr Flibble wrote: > I have shown that a simulating halting decider needn't be recursive in > nature thus can terminate normally. You are wrong on all fronts. > /Flibble No you have not. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| olcott <NoOne@NoWhere.com>: Jul 13 11:29PM -0500 On 7/13/2022 11:18 PM, Mr Flibble wrote: > I have shown that a simulating halting decider needn't be recursive in > nature thus can terminate normally. You are wrong on all fronts. > /Flibble You have shown that you don't fully understand the concept of unreachable code. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| Mr Flibble <flibble@reddwarf.jmc.corp>: Jul 14 07:52AM +0100 On Wed, 13 Jul 2022 23:29:53 -0500 > > /Flibble > You have shown that you don't fully understand the concept of > unreachable code. Of course I understand the concept of unreachable code in fact I recall giving you several examples of it. /Flibble |
| Mr Flibble <flibble@reddwarf.jmc.corp>: Jul 14 07:53AM +0100 On Wed, 13 Jul 2022 23:27:38 -0500 > > in nature thus can terminate normally. You are wrong on all fronts. > > /Flibble > No you have not. Yes I have: see my post "An idea for a simulating halt decider" in comp.theory. /Flibble |
| olcott <NoOne@NoWhere.com>: Jul 14 05:43AM -0500 On 7/14/2022 1:53 AM, Mr Flibble wrote: > Yes I have: see my post "An idea for a simulating halt decider" in > comp.theory. > /Flibble Its gibberish, you never provide the halt status criterion measure. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| olcott <NoOne@NoWhere.com>: Jul 14 05:49AM -0500 On 7/14/2022 1:52 AM, Mr Flibble wrote: > Of course I understand the concept of unreachable code in fact I recall > giving you several examples of it. > /Flibble I did not say that you have no idea what unreachable code is, you simply do not understand that infinite recursion prevents all the code below the infinitely recursive function call to ever be reached. There are a sequence of many posts that prove this where you believe that removing the infinite loop eliminates the pathological relationship. You and Richard are at the bottom 10% of technical competence in this forum most everyone else could validate that I am correct. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| Richard Damon <Richard@Damon-Family.org>: Jul 14 07:07AM -0400 On 7/13/22 10:55 PM, olcott wrote: > Most everyone here can see: (from my updated simplified paper) > It is a verified fact that the input that is correctly simulated by > H(P,P) cannot possibly terminate normally. But then how do you explain that P(P) does halt, as you have even shown when H(P,P) returns 0? Your problem is that you show that *IF* H behaves one way, that the simulation done by H(P,P) can't stop, and then you have H behave differently. You hide the logic flaw with glib words, but it is still an error. The input to H(P,P) MUST refer to the behavior of P(P) or P isn't asking H the right question to be the "Impossible Program", and P(P) Halt if H(P,P) says it will be non-halting, so that isn't a correct anseer. All you are showing is that you call fool some people some of the time. And I think if you take an honest look arround, it isn't "most everyone" who thinks you are correct. Yes, it is a fact that *IF* H does simulate its input until it can actually PROVE that its input is non-halting, that for THAT H, P(P) will be non-halting. H can, by assuming that H is such a machine, detect that IF H WAS such a machine, this P would be non-halting. The problem is, that by H assuming that it is such a machine, it no longer is such a machine, and the logic fails. > The smartest software engineers here can also see that H does correctly > predict this. People at the bottom 10% of technical competence may not > see either one of these. No sense continuing to talk to these people. But it isn't true! H(P,P) MUST decide about P(P) or P isn't correct, and P(P) Halts if H(P,P) says it is non-halting, so H is just wrong with its answer. You are the Emperor who is believing his own lie that he has made a fabulous set of clothes that only important people can see, but in reality has gone out into the parade naked. You logic is just BAD, and doesn't actually prove anything that you are trying to claim. H does NOT get the answer right, but you refuse to look at the REAL evidence that even you have created, because you so want to believe your lie, because you just can't face the actual truth. |
| Richard Damon <Richard@Damon-Family.org>: Jul 14 07:08AM -0400 On 7/14/22 6:43 AM, olcott wrote: >> /Flibble > Its gibberish, you never provide the halt status criterion measure. Pot, Kettle, Black. |
| Richard Damon <Richard@Damon-Family.org>: Jul 14 07:12AM -0400 On 7/14/22 6:49 AM, olcott wrote: > that removing the infinite loop eliminates the pathological relationship. > You and Richard are at the bottom 10% of technical competence in this > forum most everyone else could validate that I am correct. No, you are in the bottom 0.01 % of technical competence to beleive your lie that the H that returns 0 for H(P,P) actually generates infinite recursion. You believe that you can have simultaneously an immovable object and an irresistible force that it can be applied to (does it move or is it resisted?) You think you H can simulate its input forever, but still finish and answer in finite time. |
| Muttley@dastardlyhq.com: Jul 14 04:06PM On Thu, 14 Jul 2022 05:43:56 -0500 >> comp.theory. >> /Flibble >Its gibberish, you never provide the halt status criterion measure. The irony, strong it is in this one! |
| Mr Flibble <flibble@reddwarf.jmc.corp>: Jul 14 05:48PM +0100 On Thu, 14 Jul 2022 05:49:52 -0500 > I did not say that you have no idea what unreachable code is, you > simply do not understand that infinite recursion prevents all the > code below the infinitely recursive function call to ever be reached. Of course I have always understood that code after an infinite recursion is unreachable, I have never claimed otherwise however what I have claimed is that [Strachey 1965] is NOT recursive nor are the proofs based on it; I have claimed that your solution is broken if it invokes infinite recursion and I have shown that a simulating halting decider needn't be recursive in nature (see my post in comp.theory). Why don't you try acknowledging and addressing what people actually say rather than misrepresenting what they say to try to make it fit with your ongoing false narrative? > There are a sequence of many posts that prove this where you believe > that removing the infinite loop eliminates the pathological > relationship. Nope; see above - your solution is broken if it has an issue with infinite recursion. > You and Richard are at the bottom 10% of technical competence in this > forum most everyone else could validate that I am correct. Are you going to actually address our arguments or are you just going to rely on ad hominem attacks? /Flibble |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment