| olcott <NoOne@NoWhere.com>: Oct 22 12:32PM -0500 On 10/22/2020 12:27 PM, Malcolm McLean wrote: >> The halt decider either detects non-halting behavior and reports it or >> allows the input program to terminate on its own. > Sure. The details of the infinite loop detection aren't important here. When-so-ever the halting problem question is stated as: Was the execution of the input program on its input aborted because non-halting behavior was detected? The undecidability of the halting problem has been refuted. -- Copyright 2020 Pete Olcott |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 22 06:33PM +0100 On 22/10/2020 18:32, olcott wrote: > When-so-ever the halting problem question is stated as: > Was the execution of the input program on its input aborted because non-halting behavior was detected? > The undecidability of the halting problem has been refuted. I am calling TROLL at this point. Move on, nothing to see here. /Flibble -- ¬ |
| olcott <NoOne@NoWhere.com>: Oct 22 12:35PM -0500 On 10/22/2020 12:30 PM, Mr Flibble wrote: > And you still haven't answered the question: how does it "detect" that > the unknown function never terminates, clueless WANKER? > /Flibble Unless what I have currently presented is sufficiently understood no one is paying enough attention to appreciate the next step of how halting is decided. -- Copyright 2020 Pete Olcott |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 22 06:43PM +0100 On 22/10/2020 18:35, olcott wrote: >> And you still haven't answered the question: how does it "detect" that the unknown function never terminates, clueless WANKER? >> /Flibble > Unless what I have currently presented is sufficiently understood no one is paying enough attention to appreciate the next step of how halting is decided. I recommend you read my definition of the word "hubris" again and then spend some time in quiet self-reflection. /Flibble -- ¬ |
| Jeff Barnett <jbb@notatt.com>: Oct 22 11:59AM -0600 On 10/22/2020 11:35 AM, olcott wrote: > Unless what I have currently presented is sufficiently understood no one > is paying enough attention to appreciate the next step of how halting is > decided. Alright. I conclude that you haven't paid enough attention to what you said; but that's okay, it's gibberish. What is the real problem is you haven't paid enough attention to what your betters have said. See? I just agreed with you. Well I've agreed with what you said but pointed the pronouns more accurately. I hope that doesn't mean we have to justify the self reference in this case. -- Jeff Barnett |
| olcott <NoOne@NoWhere.com>: Oct 22 01:08PM -0500 On 10/22/2020 12:43 PM, Mr Flibble wrote: > I recommend you read my definition of the word "hubris" again and then > spend some time in quiet self-reflection. > /Flibble I recommend that you earnestly try to actually understand what I am saying before providing any foolishly baseless attempts at rebuttal. -- Copyright 2020 Pete Olcott |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 22 07:12PM +0100 On 22/10/2020 19:08, olcott wrote: >> I recommend you read my definition of the word "hubris" again and then spend some time in quiet self-reflection. >> /Flibble > I recommend that you earnestly try to actually understand what I am saying before providing any foolishly baseless attempts at rebuttal. Rebut what exactly? You repeatedly refuse to give a straight answer to the questions that get to the heart of the matter. You have no refutation to rebut, dear. /Flibble -- ¬ |
| olcott <NoOne@NoWhere.com>: Oct 22 01:13PM -0500 On 10/22/2020 12:45 PM, Malcolm McLean wrote: >> And you still haven't answered the question: how does it "detect" that the unknown function never terminates, clueless WANKER? > The claim is to have refuted the Linz proof that no universal halt detector is possible. Not to have a completely functional > halt detector. The actual revised claim is that the Linz proof is correct based on its false assumption that the only way to define a universal halt decider is to create a program that answers the following question: Does the input program halt on its input? When-so-ever the halting problem question is stated as: Was the execution of the input program on its input aborted because non-halting behavior was detected? The undecidability of the halting problem has been refuted. -- Copyright 2020 Pete Olcott |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 22 07:17PM +0100 On 22/10/2020 19:13, olcott wrote: > When-so-ever the halting problem question is stated as: > Was the execution of the input program on its input aborted because non-halting behavior was detected? > The undecidability of the halting problem has been refuted. You are now on automatic and are just restating the same thing without addressing the actual question. I can also restate things in a similar way: TROLL DETECTED. /Flibble -- ¬ |
| olcott <NoOne@NoWhere.com>: Oct 22 01:19PM -0500 On 10/22/2020 12:58 PM, Malcolm McLean wrote: >> non-halting behavior was detected? >> The undecidability of the halting problem has been refuted. > Sounds reasonable, doesn't it? Most people here have not gotten anywhere near the point where it seems that what I am saying is reasonable. They are all stuck on I know that you must be wrong because I really really believe that you are wrong therefore there is no need to pay any attention to what you say. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 22 01:21PM -0500 On 10/22/2020 1:17 PM, Malcolm McLean wrote: > When we change the question from "does this program halt?" to "does DebugTrace raise an abortion condition on > this program because it would otherwise never terminate?" we don't change anything important, right? > Or do we? You are the only one that is getting it, congratulations! -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 22 01:24PM -0500 On 10/22/2020 1:17 PM, Mr Flibble wrote: >> The undecidability of the halting problem has been refuted. > You are now on automatic and are just restating the same thing without > addressing the actual question. On 10/22/2020 1:17 PM, Malcolm McLean wrote: -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 22 01:30PM -0500 On 10/22/2 020 12:58 PM, Malcolm McLean wrote: > Sounds reasonable, doesn't it? As I said, if you want H to make the correct call > on H_Hat, you have to smuggle into H the information about whether it is > being called directly or through H_Hat. You appear to have done that quite well. Executing von Neumann architecture machine in DebugStep() mode or executing a UTM inside another UTM is a perfectly legitimate thing to do. By doing this a halt decider can directly see all the relevant details. -- Copyright 2020 Pete Olcott |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 22 07:34PM +0100 On 22/10/2020 19:30, olcott wrote: >> on H_Hat, you have to smuggle into H the information about whether it is >> being called directly or through H_Hat. You appear to have done that quite well. > Executing von Neumann architecture machine in DebugStep() mode or executing a UTM inside another UTM is a perfectly legitimate thing to do. By doing this a halt decider can directly see all the relevant details. Mate, you need to do three things: 1) Re-read what a UTM actually is; 2) Re-read what the halting problem actually is; 3) take your meds. I could add: 4) Fuck off. But that would be rude. /Flibble -- ¬ |
| olcott <NoOne@NoWhere.com>: Oct 22 01:35PM -0500 On 10/22/2020 1:30 PM, Malcolm McLean wrote: >>> Or do we? >> You are the only one that is getting it, congratulations! > I think that's going a bit far. There will be other people who understand exactly what you have done. "Will be", yes for sure, eventually. The first step of this "will be" is to drop the idea that I am certainly incorrect long enough to actually pay attention to what I am saying. > But at least some posters are unable to provide a refutation of what you have achieved.So it > isn't trivial. Yes it looks like I am on the right track so far. -- Copyright 2020 Pete Olcott |
| Joe Pfeiffer <pfeiffer@cs.nmsu.edu>: Oct 22 12:55PM -0600 > spend my time doing or thinking about. Life is fucking finite and time > is fucking precious, mate, and there is no fucking afterlife. Stop > wasting our time. Crackpots will always be among us. There is no one to blame for engaging this one but yourself. You've established he's not worth your time; let those who wish to try to teach the unteachable spend their time as they wish. Killfile him and move on. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 22 07:59PM +0100 On 22/10/2020 19:55, Joe Pfeiffer wrote: > engaging this one but yourself. You've established he's not worth your > time; let those who wish to try to teach the unteachable spend their > time as they wish. Killfile him and move on. You are right: I have wasted enough time on this troll (assuming he is a troll and not simply batshit crazy like you suggest). /Flibble -- ¬ |
| Lew Pitcher <lew.pitcher@digitalfreehold.ca>: Oct 22 07:13PM On Thu, 22 Oct 2020 19:59:17 +0100, Mr Flibble wrote: > On 22/10/2020 19:55, Joe Pfeiffer wrote: [snip] >> time as they wish. Killfile him and move on. > You are right: I have wasted enough time on this troll (assuming he is a > troll and not simply batshit crazy like you suggest). In this case, there doesn't seem to be much of a difference. He passed the "duck test" ("If it looks like a duck, and quacks like a duck, then we can call it a duck."), anyway. -- Lew Pitcher "In Skills, We Trust" |
| olcott <NoOne@NoWhere.com>: Oct 22 03:13PM -0500 On 10/22/2020 2:43 PM, André G. Isaak wrote: > If the relation between your H and Ĥ is the same as in the Linz proof, > the same contradiction results despite your change of wording. > André If we keep everything in the Linz proof the same** except we change the name of what the halt decider decides: (a) Decision:Not_Halting and Behavior:Halts (a contradiction) (b) Decision:Aborted_Execution_Because_Not_Halting_Detected and Behavior:Aborted Execution (not a contradiction) http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf ** We also assume that the halt decider works on the basis of executing its input program in DebugStep() mode until it detects non-halting behavior or its input program terminates. If the halt decider detects non halting behavior it immediately stops executing its input in DebugStep() mode and returns its Boolean value. If it returns a value meaning Not_Halting then a contradiction of formed because its input program did halt. If it returns a value meaning Aborted_Execution_Because_Not_Halting_Detected then no contradiction is formed because its input program was aborted. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 22 03:24PM -0500 On 10/22/2020 2:53 PM, Ben Bacarisse wrote: > you were wrong? Do you now acknowledge that Linz is right about his > construction of H^ from H, and you were ... mistaken ... when you said > you had "exactly and precisely" what Linz was talking about? The more general claim that I made is that I would show exactly how the conventional self-referential halting problem proof counter-examples do not prove that the halting problem is undecidable. This has now been totally fulfilled. As soon as you acknowledge this we can move on to talking about other aspects. -- Copyright 2020 Pete Olcott |
| "André G. Isaak" <agisaak@gm.invalid>: Oct 22 02:34PM -0600 On 2020-10-22 14:13, olcott wrote: >> So how exactly does that avoid the contradiction inherent in Linz proof? >> If the relation between your H and Ĥ is the same as in the Linz proof, >> the same contradiction results despite your change of wording. No. If your H() returns 'terminated normally', then Ĥ(Ĥ) must have been forced to abort if they were really using the same halt deciding code. And if your H() returns 'forced to abort', then Ĥ(Ĥ) must have terminated normally if they were really using the same halt deciding code. The contradiction is there despite your change of wording. André -- To email remove 'invalid' & replace 'gm' with well known Google mail service. |
| olcott <NoOne@NoWhere.com>: Oct 22 04:28PM -0500 On 10/22/2020 3:34 PM, André G. Isaak wrote: > forced to abort if they were really using the same halt deciding code. > And if your H() returns 'forced to abort', then Ĥ(Ĥ) must have > terminated normally if they were really using the same halt deciding code. bool DebugTrace() only returns forced to abort or not forced to abort. -- Copyright 2020 Pete Olcott |
| "André G. Isaak" <agisaak@gm.invalid>: Oct 22 03:34PM -0600 On 2020-10-22 15:28, olcott wrote: >> terminated normally if they were really using the same halt deciding >> code. > bool DebugTrace() only returns forced to abort or not forced to abort. So replace 'terminated normally' with 'not forced to abort' in what I say above. There is still a contradiction. André -- To email remove 'invalid' & replace 'gm' with well known Google mail service. |
| olcott <NoOne@NoWhere.com>: Oct 22 04:47PM -0500 On 10/22/2020 4:34 PM, André G. Isaak wrote: > So replace 'terminated normally' with 'not forced to abort' in what I > say above. There is still a contradiction. > André (1) Original self-referential halting problem counter example (a) Decision: ~Halting and Behavior: Halts (a contradiction) (b) Decision: Halting and Behavior: Loops (a contradiction) (2) Revised halting problem decision (a) Decision: Aborted_Execution and Behavior: Aborted Execution (b) Decision: ~Aborted_Execution and Behavior: ~Aborted Execution In the first case the decision and the behavior contradict each other. In the second case the decision and the behavior DO NOT contradict each other. It is only hard if it is welded into your brain that I must be wrong. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 22 06:05PM -0500 On 10/22/2020 5:14 PM, Mike Terry wrote: > - halts if Was_Its_Execution_Aborted() decides "aborted" > - loops if Was_Its_Execution_Aborted() decides "halted" > (right?) Wrong. There is no way to make the revised halting question contradictory. DebugTrace() either reports that it has aborted the execution of its input or it reports that its input has not been aborted after its input has terminated. > is not equivalent to the halting question, and the fact that such a new > question can be correctly answered has no relevence to the HP question > or to Linz proof. That you can define a halt decider that does not meet the conventional specs of a halt decider provide zero rebuttal what-so-ever. > additional characteristics: > a) if Was_Its_Execution_Aborted() returns "program halted" > then H_Hat(H_Hat) [IF RUN NATIVELY] will actually terminate YES > b) if Was_Its_Execution_Aborted() returns "program aborted" > then H_Hat(H_Hat) [IF RUN NATIVELY] will never halt Not really because H_Hat() has the same halt decider as H() so when we run H_Hat() on itself it aborts itself. > name-changed to Does_It_Halt() and I think you've already admitted > elsewhere the Linz argument is correct with the [IF RUN NATIVELY] > proviso, and so this can't be possible. We could say that the Linz proof is correct on the basis of its terribly incorrect basic assumptions or we cold say that the Linz proof is fundamentally incorrect because its foundational basis is incorrect. These are two different ways of saying the same thing. > (b) above? In which case although it may be answering your new > question, IT WOULD AT THE SAME TIME BE CORRECTLY ANSWERING THE OLD > QUESTION! No because in the case where DebugTrace() decides to abort its input in the prior language this would be a case where H() decides not halting and then H_Hat() halts. > Is the issue here that when you say "cases of non-halting behavior", you > mean something other than "cases where P run with input I never halts > [when run natively]"? Not exactly. Since the invocation of DebugTrace() by H_Hat() aborts H_Hat() we can't really say that when it runs natively it never halts. We can say that unless H_Hat() is aborted it would never halt. > Thinking about it, your use of the term "non-halting *behavior*" seems a > likely area of confusion! > What exactly do you mean by "cases of non-halting behavior"? The obvious one is infinite loop. Can you think of the other one? > And just to be doubly clear, does this /mean/ the same as "program run > /natively/ with given input never halts"? (I.e. in the usual sense of > "non-halting TMs" in the literature and HP proof?) If H_Hat() is run and never aborted it would never halt. If it is executed with itself as input its invocation of DebugTrace() would abort this input. >> complete control of H(). > ..but as explained above, H_Hat CAN have the behaviour that it halts if > H() decides it was aborted, and it loops if H() decides it terminated. As soon as H_Hat() is terminated and DebugTrace() returns a value the H_Hat() process ceases to exist in memory because it was stored on the DebugTrace() stack. > (The H_Hat in your skeleton code is designed exactly this way.) It is designed to precisely match the Linz templates. >> I didn't say that. As soon as people pay enough attention they will see >> that I am correct. > I fear this is one of your delusions! Your proof is almost nonexistent My proof is very very concise yet infinitely more elborate than any rebuttals of it. Try and show how a non existent H_Hat() that no longer exists as a process in memory can do anything at all and you will start to begin to see that changing the halt deciding question converts an undecidable problem into a decidable one. > then pointing out that the proof no longer works using those new terms. > I don't believe /anyone/ has ever agreed with /any/ of those attempts, > so I can't see them starting now. That no one agrees with me is zero rebuttal at all. > publishing the code anyway (and I think you can see by now that will get > you nowhere), or abandoning your life's work, having wasted 12,000 hours > (your own reckoning) unnecessarily. Take my challenge and show how the H_Hat() process that no longer exists in memory can do anything at all that is the opposite of what DebugTrace() decided. -- Copyright 2020 Pete Olcott |
| 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