| "André G. Isaak" <agisaak@gm.invalid>: Oct 23 12:35PM -0600 On 2020-10-23 12:12, olcott wrote: >> be if the DebugTrace() called within Ĥ returned 'halts', thereby >> forcing it into an infinite loop. > False assumption. Not a false assumption. At least not provided your Ĥ actually stands in the correct relation to H. In which other circumstances would H be required to abort Ĥ? >> but when called from H, return 'aborted because of non halting >> behaviour'? > It wouldn't do that. It has to in order to account for the alleged behaviour that you describe. André -- To email remove 'invalid' & replace 'gm' with well known Google mail service. |
| olcott <NoOne@NoWhere.com>: Oct 23 01:49PM -0500 On 10/23/2020 1:15 PM, Malcolm McLean wrote: > It never enters the infinite loop. H_Hat calls DebugTrace in what woud be > an infinite recusion, if DebugTrace didn't detect the situation and raise an > abortion condition. Yes I pointed this out back in 2016 when I first noticed it: Self Modifying Turing Machine (SMTM) Solution to the Halting Problem (concrete example) August 2016 PL Olcott It looks like the original specification provided in the Linz text may be infinitely recursive in that each TM requires its own input. https://www.researchgate.net/publication/307509556_Self_Modifying_Turing_Machine_SMTM_Solution_to_the_Halting_Problem_concrete_example > Now what you could say is that "aborts" is really another name for "halts" when > we are calling H_Hat directly, another name for "doesn't halt" when we are calling > "H". I call this: Aborted_Because_Non_Halting_Behavior_Detected. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 23 02:04PM -0500 On 10/23/2020 1:35 PM, André G. Isaak wrote: > Not a false assumption. At least not provided your Ĥ actually stands in > the correct relation to H. In which other circumstances would H be > required to abort Ĥ? No, Malcolm McLean figured out the key discovery that I first made in 2016, H_hat()** never reaches its undecidable states, it is stuck in infinite recursion before it ever gets there. Self Modifying Turing Machine (SMTM) Solution to the Halting Problem (concrete example) August 2016 PL Olcott It looks like the original specification provided in the Linz text may be infinitely recursive in that each TM requires its own input. https://www.researchgate.net/publication/307509556_Self_Modifying_Turing_Machine_SMTM_Solution_to_the_Halting_Problem_concrete_example ** And every other conventional self-referential halting problem proof counter-example. >>> behaviour'? >> It wouldn't do that. > It has to in order to account for the alleged behaviour that you describe. On 10/23/2020 1:15 PM, Malcolm McLean wrote: > the result is "aborts". > if we run H_Hat(H_Hat) > the result is "aborts". The outermost DebugTrace() simply stops running its slave H_Hat() as soon as it detects that H_Hat() is stuck in infinite recursion. Then after the H_Hat() process is terminated it reports: Aborted_Because_Non_Halting_Behavior_Detected indicating that it terminated H_Hat() when it detected infinite recursion. In the conventional halting problem proof H_Hat() would then do the opposite of whatever DebugTrace() decided. In this case it can't do that because its process has been terminated. -- Copyright 2020 Pete Olcott |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Oct 23 01:03PM -0700 olcott <NoOne@NoWhere.com> writes: [SNIP] The parent article was posted only to comp.theory. You deliberately cross-posted your followup to comp.theory, comp.lang.c, comp.lang.prolog, and comp.lang.c++. You've done that multiple times. Please stop doing that. You've already taken over comp.theory. You're not discussing programming languages. Please stop polluting other newsgroups where people are still trying to discuss programming languages. I expect you'll reply to this with some ridiculous excuse and continue your misbehavior. If so, I will resume ignoring you. And again, I ask everyone else replying to olcott's posts to remove irrelevant newsgroups from your followups. I know it's annoying to have to do that. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */ |
| olcott <NoOne@NoWhere.com>: Oct 23 03:24PM -0500 On 10/23/2020 3:03 PM, Keith Thompson wrote: > And again, I ask everyone else replying to olcott's posts to remove > irrelevant newsgroups from your followups. I know it's annoying > to have to do that. I will stop cross-posting as soon as: (1) It is accepted that I just correctly refuted the halting problem proofs. (2) It is proven that I did not correctly refute the halting problem proofs. This latter proof would be very easy if and only if I am incorrect and utterly impossible if I am correct. If a halt decider is defined to return a value that indicates that its input program halts and input program can be defined on the basis of the halt decider that does the opposite of whatever the halt decider decides. If a UTM executes an (already on the tape) input UTM. The halt decider UTM could execute its (already on the tape) input UTM one state transition at a time. As soon as the halt decider UTM detects that its (already on the tape) input UTM would not halt, the halt decider UTM stops executing its (already on the tape) input UTM and transitions to its own final state indicating: Aborted_Because_Non_Halting_Behavior_Detected. In this case the (already on the tape) input UTM cannot possibly do the opposite of what the halt decider UTM decided because it is no longer executing. This redefinition of the halt decider eliminates the undecidability of the halting problem. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 23 03:56PM -0500 On 10/23/2020 3:29 PM, Malcolm McLean wrote: > returned "abort" so it halted". We have to agree that a certain state is > equivalent to smashing the machine, even if the machine isn't physically > smashed. A Turing machine has no way of smashing itself. H_hat() is executed inside a process context that was created by DebugTrace(). DebugTrace() is in complete control of H_Hat() in this process context and H_Hat() never has enough information to know that it must be aborted. As soon as DebugTrace() stops executing H_Hat() in its DebugStep() loop it returns its decision and the process context of H_Hat() that was stored in the local memory of this instance of DebugTrace() is released. > And H_Hat can't be decided because if H decides "halt" it loops > forever whilst if H decides "no halt" it halts. So H_Hat is a paradox for > H. In the case of my redefinition of the halt decider H_hat() cannot do anything because the act of returning a value from DebugTrace() releases all of the local memory of DebugTrace() so its process context no longer exists. We have the exact same effect when we redefine that halt decider as a UTM that executes an (already on the tape) input UTM. This halt decider UTM would execute its (already on the tape) input UTM one state transition at a time. As soon as the halt decider UTM detects that its (already on the tape) input UTM would not halt, the halt decider UTM stops executing its (already on the tape) input UTM and transitions to its own final state indicating: Aborted_Because_Non_Halting_Behavior_Detected. We get the same result. The H_Hat UTM cannot do the opposite of what its halt decider decided because the UTM that was executing it stopped executing it before providing its decision. Whenever the halting decision is provided after the program under test (PUT) has stopped executing the (PUT) cannot possibly do the opposite of whatever its halt decider decided thus making halting decidable. -- Copyright 2020 Pete Olcott |
| "André G. Isaak" <agisaak@gm.invalid>: Oct 23 03:34PM -0600 On 2020-10-23 13:04, olcott wrote: >> Not a false assumption. At least not provided your Ĥ actually stands >> in the correct relation to H. In which other circumstances would H be >> required to abort Ĥ? You didn't actually answer the question. In which other circumstances would H be forced to abort Ĥ? André -- To email remove 'invalid' & replace 'gm' with well known Google mail service. |
| olcott <NoOne@NoWhere.com>: Oct 23 04:58PM -0500 On 10/23/2020 4:12 PM, Malcolm McLean wrote: > If H says H_Hat halts, H_Hat(H_Hat) must halt when called directly, if H > says that H_Hat(H_Hat) diesn't halt, then H_Hat(H_Hat) must not halt > when called directly. To state this simplistically (leaving out the DebugTrace() and DebugStep() details) H() executes H_Hat() until it first sees that H_Hat() is infinitely recursive and then stops executing H_Hat(). > being called directly. So it must abort, you must do something equivalent > to smashing the machine. It can't be shut down gracefully by a supervisor > because is no supervisor. The more detailed execution trace is H() calls DebugTrace() that creates a separate execution context that executes H_Hat() that calls DebugTrace() the creates another separate execution context that executes another instance of H_Hat(). The outermost DebugTrace() sees the infinite recursion of the outermost H_Hat() before H_Hat() sees its own infinite recursion. The outermost DebugTrace() stops running the outermost H_Hat() in the outermost DebugTrace() DebugStep() loop. Then the outermost DebugTrace() returns Aborted_Because_Non_Halting_Behavior_Detected. > This means that H_Hat cannot be a Turing machine. All of the machines can be construed as UTM's: Instead of the C function DebugTrace() we could simply have a UTM that executes an (already on the tape) input UTM. This halt decider UTM would execute its (already on the tape) input UTM one state transition at a time. As soon as the halt decider UTM detects that its (already on the tape) input UTM would not halt, the halt decider UTM stops executing its (already on the tape) input UTM and transitions to its own final state indicating Aborted_Because_Non_Halting_Behavior_Detected. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 23 05:05PM -0500 On 10/23/2020 4:34 PM, André G. Isaak wrote: > You didn't actually answer the question. In which other circumstances > would H be forced to abort Ĥ? > André Yes I did you ignored it and erased it. I just went back to double check. When you glance at a couple of words and then ignore the rest you miss an awful lot of what I am saying. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 23 06:06PM -0500 On 10/23/2020 5:51 PM, Mike Terry wrote: > HERE: goto HERE; // so we loop > } > } The key difference is that if (Was_Its_Execution_Aborted(M, M)) is true, then its execution has already been aborted so it never reaches this if statement. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 23 06:14PM -0500 On 10/23/2020 6:03 PM, Malcolm McLean wrote: > That's the step you are missing. At least this is what I understand. PO > sems to be changing his argument slightly and I don't want to speak for > him. Good job. You are the only one that mostly understands me. -- 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