| olcott <NoOne@NoWhere.com>: Oct 23 10:12AM -0500 On 10/23/2020 9:34 AM, Malcolm McLean wrote: > H_Hat, of H_Hat detects that DebugTrace has aborted the instance of H_Hat > it is stepping through, and aborts itself. Either way, H_Hat(H_Hat) aborts, > and the behaviour is consistent. DebugTrace() creates new process contexts and everything that it slave process executes (including subsequent invocations of DebugTrace()) is executed in this same process context. Once DebugTrace() aborts the execution of its slave this slave cannot do anything at all. The slave it always under the total and complete control of DebugTrace(). The outermost DebugTrace() totally controls its slave and whatever code that its slave may have invoked such as another instance of DebugTrace(). Once the outermost DebugTrace() aborts its slave process the whole hieararchy is aborted. > Linz's proof shows that H cannot be a Turing machine. What you've shown is that > it doesn't apply if we make a small change to the specifications so that the > machines are allowed to abort. When you break the concept of a UTM and create an artificial limit you changed the subject. > A Turing machine can step through another machine > and then abort it if certain conditions are met. But it can't abort itself. That makes > all the difference. Not really, not at all, not in the least little bit. In fact when H_Hat() is executed with itself as input it does abort this input. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 23 10:19AM -0500 On 10/23/2020 9:51 AM, Ben Bacarisse wrote: > proofs), that do not fall foul of the obvious logic. He has not done > that. It can't be done. It can't be done even in models where halting > is decidable. If we take my redefined halting decider and interpret its return value using the conventional interpretation: DebugTrace() executes H_Hat() and decides that it would not otherwise halt so it terminates the execution of H_Hat() and reports: (1) Not_Halting. Decision:Not_Halting Behavior:Halting a contradiction DebugTrace() got the wrong answer. If we take my redefined halting decider and interpret its return value using the redefined interpretation: (2) Aborted_Because_Non_Halting_Behavior_Detected Decision:Aborted_Because_Non_Halting_Behavior_Detected Behavior:Aborted_Because_Non_Halting_Behavior_Detected Not a contradiction and the right answer! 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 10:30AM -0500 On 10/23/2020 9:56 AM, Ben Bacarisse wrote: > no effective procedure to detect them all. There /is/ an effective > procedure for the other kind where a previously entered configuration is > entered again. None-the-less I have refuted all of the conventional self-referential halting problem proof counter-examples. Also it is well known that machines such as this cannot physically exist. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 23 10:40AM -0500 On 10/23/2020 10:03 AM, Ben Bacarisse wrote: > I don't think you are taking this seriously. It's up to if you want to > come across as a clown. If not, you can take the questions people ask > seriously. DebugTrace() is totally complete as a function that creates new process contexts and executes virtual machines within this new process context. The most difficult part was to get DebugTrace() to DebugTrace() itself to an arbitrary recursive depth. I had to do this because H() invokes DebugTrace() to invoke H_Hat() to invoke DebugTrace() to invoke another H_Hat() process. As I have said dozens of times now the halt decider code has not been written. The x86utm operating system is complete. This took one man-year. The halt deciding criteria for the Linz proof has been complete since 2016. We spoke about this at very great length and you made sure not to pay any attention at all. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 23 10:49AM -0500 On 10/23/2020 10:04 AM, André G. Isaak wrote: >> https://en.wikipedia.org/wiki/Deep_Blue_(chess_computer) > Deep blue had no intelligence. It used a purely mechanical chess-playing > algorithm. You must be defining intelligence in some weird way. I define intelligence as the ability to do what a human mind can do. >> impossible to decide. > But here I am talking about the sole case that you claim to actually > have solved! I already know whether or not H_Hat() would need to have its process aborted and why since 2016. Once H_Hat() has its process aborted it cannot do anything at all, thus it cannot do the opposite of whatever the halt decider decides. > instance you are talking about; the one inside H or the one inside Ĥ. > Similarly, when you talk about 'behaviour' it isn't clear whether you > are talking about H or Ĥ. The outside instance of DebugTrace() invoked from H() totally controls its process and all of the sub processes invoked by its process. As soon as it aborts its process the whole process hierarchy stops running. -- Copyright 2020 Pete Olcott |
| "André G. Isaak" <agisaak@gm.invalid>: Oct 23 10:06AM -0600 On 2020-10-23 09:49, olcott wrote: > On 10/23/2020 10:04 AM, André G. Isaak wrote: <snip> >> chess-playing algorithm. > You must be defining intelligence in some weird way. > I define intelligence as the ability to do what a human mind can do. Deep Blue can play chess. Some human minds play chess, but they also do all sorts of other things that Deep Blue can't do, and the way in which humans approach chess is entirely different from how Deep Blue accomplishes this. <snip > The outside instance of DebugTrace() invoked from H() totally controls > its process and all of the sub processes invoked by its process. As soon > as it aborts its process the whole process hierarchy stops running. That doesn't clarify anything. Why don't you indicate which result the instance of DebugTrace() running inside Ĥ returns, along with the result which the instance running inside H returns. André -- To email remove 'invalid' & replace 'gm' with well known Google mail service. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 23 05:37PM +0100 On 23/10/2020 15:52, olcott wrote: >>> It always has complete access to the source code so that it can do anything that it wants including execute this code. >> It can't simply execute the code. If it just executes the code, then the halt decider isn't going to halt when given code that doesn't halt. It has to somehow determine what the code would do if executed. > The UTM executes the code of its input UTM one state transition at a time until it detects that its input UTM would not halt or until its input UTM terminates on its own. As soon as the UTM detects that its input UTM would not otherwise halt it stops executing its input UTM and reports non-halting behavior. But, troll, you still haven't shown how you can determine that for a given arbitrary input UTM your solution can "detect" that the input UTM will not halt; you repeatedly assert, without evidence, that you can do this. I see elsewhere in your reply that you have introduced the concept of "God" into your so called refutation: the great atheist Christopher Hitchens once said that assertions made without evidence can dismissed without evidence. /Flibble -- ¬ |
| olcott <NoOne@NoWhere.com>: Oct 23 11:38AM -0500 On 10/23/2020 11:18 AM, Mike Terry wrote: > which forced you to follow the Linz proof restrictions - > and you FINALLY > realised your idea didn't work, and WHY it didn't! Not at all. Not in the least little bit. You aren't paying very close attention are you? > H_copy [the copy of H embedded in H_Hat] on running H_Hat with input > <H_Hat> is made BEFORE H_Hat actually finishes running, so H_Hat's > actual behaviour can be different, showing H's decision to be incorrect. As in all of the conventional proofs the input program is based on modifications made to the halt decider. Next, we modify H to produce a Turing machine H' with the structure shown in Figure 12.2. http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf // Simpifications of H() and H_Hat() provided by // Ben Bacarisse wrote On 10/22/2020 11:00 PM // M has address of H_Hat() void H_Hat(u32 M) { if (!DebugTrace(M, M)) // M(M) Aborted? HERE: goto HERE; HALT } // M and N have the address of H_Hat() void H(u32 M, u32 N) { if (DebugTrace(M, N)) // M(N) Aborted? MOV_EAX_0 // Execution of M(N) has been aborted else MOV_EAX_1 // M(N) has halted HALT } int main() { u32 M = (u32)H_Hat; H(M, M); HALT; } > question" to try to make your problem go away. I think that what you're > thinking is that you can make the problem of H_Hat finishing AFTER > H_Copy has returned its decision JUST GO AWAY by Forcing H_Hat() to terminate before the decision is returned. This makes it impossible for H_Hat() to do anything at all, thus H_Hat() cannot possibly do the opposite of whatever DebugTrace() decides. > saying the decision of > H_Copy is not "whether H_Hat halts", but in fact should be read as > "whether or not I decided H_Hat would halt and aborted it". And since The unique discovery that I made in 2016 indicates that H_Hat() would never terminate unless it was aborted. > your H_Copy aborts it's emulation of H_Hat before the emulation actually > finishes, we're for some reason not allowed to talk about what H_Hat > /actually/ does. (Duh!) No. The DebugTrace() of H_Hat() that is invoked by H() aborts its execution of H_Hat() because unless H_Hat() is aborted it would never terminate. > with a plausible reason, but you can't! :) ] > Regards, > Mike. The reason that I can't admit that I am wrong this that I am correct and you can't show otherwise. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 23 11:43AM -0500 On 10/23/2020 11:37 AM, Mr Flibble wrote: > But, troll, you still haven't shown how you can determine that for a > given arbitrary input UTM your solution can "detect" that the input UTM > will not halt; Others have pointed out that this in not necessary. > Christopher Hitchens once said that assertions made without evidence can > dismissed without evidence. > /Flibble I have already provided complete proof. If we take my redefined halting decider and interpret its return value using the conventional interpretation: DebugTrace() executes H_Hat() and decides that it would not otherwise halt so it terminates the execution of H_Hat() and reports: (1) Not_Halting. Decision:Not_Halting Behavior:Halting a contradiction DebugTrace() got the wrong answer. If we take my redefined halting decider and interpret its return value using the redefined interpretation: (2) Aborted_Because_Non_Halting_Behavior_Detected Decision:Aborted_Because_Non_Halting_Behavior_Detected Behavior:Aborted_Because_Non_Halting_Behavior_Detected Not a contradiction and the right answer! 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 11:48AM -0500 On 10/23/2020 11:06 AM, André G. Isaak wrote: > inside Ĥ returns, along with the result which the instance running > inside H returns. > André The DebugTrace() invoked by H() returns Aborted_Because_Non_Halting_Behavior_Detected so the DebugTrace() invoked by Ĥ() never reaches the point where it would return a value. -- Copyright 2020 Pete Olcott |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 23 05:49PM +0100 On 23/10/2020 17:43, olcott wrote: [snip] > 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. "As soon as the halt decider UTM detects that its (already on the tape) input UTM would not halt" -- how does it do this? You assert that you can do this: assertions made without evidence can be dismissed without evidence. Until you show, to us, in this Usenet discussion, how your solution can "detect" the input UTM won't halt then your so called "refutation" is WORTHLESS. If you reply asserting the same thing, again, then I will reply with the same correct observation, again, until I get bored. You have nothing, mate. /Flibble -- ¬ |
| olcott <NoOne@NoWhere.com>: Oct 23 11:55AM -0500 On 10/23/2020 10:20 AM, Ben Bacarisse wrote: > up in. > He has the classic "report termination when you can, and give up > otherwise" partial decider. No you are totally incorrect and I have fully explained all of the details of why you are incorrect many different times in several different ways. It seems that you are never going to understand that simply ignoring what I say is really no rebuttal what-so-ever. You must very carefully study what I say and then find a key mistake that you then point out. Of course you would want to avoid this if you know that I am correct and want to provide something that gullible people will take as a rebuttal anyway. All of the conventional self-referential halting problem proofs have been proven to not show that a universal halt decider is impossible because the key counter-example of these proofs <IS> decidable. -- Copyright 2020 Pete Olcott |
| "André G. Isaak" <agisaak@gm.invalid>: Oct 23 11:04AM -0600 On 2020-10-23 10:48, olcott wrote: > The DebugTrace() invoked by H() returns > Aborted_Because_Non_Halting_Behavior_Detected so the DebugTrace() > invoked by Ĥ() never reaches the point where it would return a value. But if your DebugTrace() actually answers the question you claim it answers, then the only way H can claim that Ĥ needs to be aborted is if Ĥ is stuck in an infinite loop. And the only way Ĥ can be stuck in an infinite loop is if the instance of DebugTrace() inside Ĥ decided that the program did *not* need to be aborted. So your DebugTrace() inside H and Ĥ are reaching opposite conclusions. How can that be if they are the same procedure? André >>>>> (2) Aborted_Because_Non_Halting_Behavior_Detected >>>>> Decision:Aborted_Because_Non_Halting_Behavior_Detected >>>>> Behavior:Aborted_Because_Non_Halting_Behavior_Detected >>>>> Not a contradiction and the right answer! The decision might not contradict the behaviour of H, but it certainly contradicts what DebugTrace() should be doing inside Ĥ. André -- To email remove 'invalid' & replace 'gm' with well known Google mail service. |
| olcott <NoOne@NoWhere.com>: Oct 23 12:06PM -0500 On 10/23/2020 11:49 AM, Mr Flibble wrote: > input UTM would not halt" -- how does it do this? You assert that you > can do this: assertions made without evidence can be dismissed without > evidence. It has already been pointed out by others that this doesn't matter. If you want to wait until I write the code that does this that is OK. It can be determined that I already refuted the conventional self-referential halting problem proofs on the basis of my redefinition of the halt decider. This may be very difficult to understand. -- Copyright 2020 Pete Olcott |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 23 06:10PM +0100 On 23/10/2020 18:06, olcott wrote: >> "As soon as the halt decider UTM detects that its (already on the tape) input UTM would not halt" -- how does it do this? You assert that you can do this: assertions made without evidence can be dismissed without evidence. > It has already been pointed out by others that this doesn't matter. > If you want to wait until I write the code that does this that is OK. No we don't need to wait for an implementation; we just want a simple description now of how the implementation you plan to make actually works. Either provide the information now or fuck off you time wasting shower of shit. (that was a simple insult btw, not an ad hominem). /Flibble -- ¬ |
| olcott <NoOne@NoWhere.com>: Oct 23 12:20PM -0500 On 10/23/2020 11:59 AM, Malcolm McLean wrote: > The difference between an "abort" and a "decision" is that if you have an > "abort" you can't suppress it. You have to abort. The exact mechanism is > unimportant. Reporting that H_Hat() has already been aborted prevents H_Hat() from doing anything because it already has been aborted. > DebugTrace aborts its calling function or if the onus is on H_Hat to obey > conventions and abort. It doesn't matter. The abort cannot be suppressed, > so no paradox is possible. x86utm executes main() in the x86utm context. main() executes H() in the x86utm context. H() executes DebugTrace() in the x86utm context. DebugTrace() creates a whole new process context and executes H_Hat(). H_Hat() execute DebugTrace() in its own process context which creates a whole new process context and executes another instance of H_Hat(). After awhile the DebugTrace() invoked by H() in the x86utm process context decides that its invocation of H_Hat() would not terminate so it exits its DebugStep() loop of its H_Hat() and reports Aborted_Because_Non_Halting_Behavior_Detected to H(). >> He has the classic "report termination when you can, and give up >> otherwise" partial decider. > Of course. He's never claimed to have a full halt decider. The changes that I made make all of the conventional self-referential halting problem counter-examples decidable. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 23 12:24PM -0500 On 10/23/2020 12:10 PM, Mr Flibble wrote: > description now of how the implementation you plan to make actually > works. Either provide the information now or fuck off you time wasting > shower of shit. x86utm executes main() in the x86utm context. main() executes H() in the x86utm context. H() executes DebugTrace() in the x86utm context. DebugTrace() creates a whole new process context and executes H_Hat(). H_Hat() execute DebugTrace() in its own process context which creates a whole new process context and executes another instance of H_Hat(). After awhile the DebugTrace() invoked by H() in the x86utm process context decides that its invocation of H_Hat() would not terminate so it exits its DebugStep() loop of its H_Hat() and reports Aborted_Because_Non_Halting_Behavior_Detected to H(). I am not going to provide the basis for the DebugTrace() Aborted_Because_Non_Halting_Behavior_Detected halting decision until I have this fully operational so that the description of it can be confirmed as exactly correct. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 23 12:31PM -0500 On 10/23/2020 12:04 PM, André G. Isaak wrote: > and Ĥ are reaching opposite conclusions. How can that be if they are the > same procedure? > André The outermost DebugTrace() has the most information. The inner DebugTrace() invocations are a few processing steps behind. As soon as the outermost invocation of DebugTrace() can determine that its H_Hat() would not otherwise terminate unless it was aborted it aborts its invocation of H_Hat(). If this outermost invocation of DebugTrace() simply waits to see what its H_Hat() will do then H_Hat() will be stuck in infinite execution because it too will be waiting to see what its H_Hat() will do... -- Copyright 2020 Pete Olcott |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 23 06:35PM +0100 On 23/10/2020 18:24, olcott wrote: > DebugTrace() creates a whole new process context and executes H_Hat(). > H_Hat() execute DebugTrace() in its own process context which creates a whole new process context and executes another instance of H_Hat(). > After awhile the DebugTrace() invoked by H() in the x86utm process context decides that its invocation of H_Hat() would not terminate so it exits its DebugStep() loop of its H_Hat() and reports Aborted_Because_Non_Halting_Behavior_Detected to H(). "After awhile"? Not enough information I'm afraid: is this "awhile" a time duration? Number of steps? % of "tape" analysed? None of which can decide non-halting behaviour for an *arbitrary* UTM. Again: provide a simple description of how it is decided that UTM will not terminate, here and now. /Flibble -- ¬ |
| olcott <NoOne@NoWhere.com>: Oct 23 12:40PM -0500 On 10/23/2020 11:28 AM, Ben Bacarisse wrote: >> work. > For the record, that's exactly what I've thought all along. As usual, > you are being a bit kinder than I would be, but that's your way. 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. Thus DebugTrace() <is> equivalent to a UTM doing the same thing. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 23 12:46PM -0500 On 10/23/2020 12:35 PM, Mr Flibble wrote: > "After awhile"? Not enough information I'm afraid: is this "awhile" a > time duration? Number of steps? % of "tape" analysed? None of which can > decide non-halting behaviour for an *arbitrary* UTM. To refute the conventional self-referential halting problem proof counter-examples we only have to decide these counter-examples. We do not have to decide every arbitraty input. After a while is after a certain number of processing steps / state transitions. I don't know how many that is because I have not written the actual halt deciding code yet. -- Copyright 2020 Pete Olcott |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 23 06:53PM +0100 On 23/10/2020 18:46, olcott wrote: > After a while is after a certain number of processing steps / state transitions. I don't know how many that is because I have not written the actual halt deciding code yet. This tells us all we need to know. I think everyone can get on with their lives now: Alan Turing's proof stands. /Flibble -- ¬ |
| "André G. Isaak" <agisaak@gm.invalid>: Oct 23 12:00PM -0600 On 2020-10-23 11:31, olcott wrote: > simply waits to see what its H_Hat() will do then H_Hat() will be stuck > in infinite execution because it too will be waiting to see what its > H_Hat() will do... You're missing the point. It doesn't matter whether H allows Ĥ to complete its computation. What matters is that the behaviour of DebugTrace() is consistent regardless of whether it is invoked in H or Ĥ. If your Ĥ really does stand in the same relation to H as Linz's, then your Ĥ invokes DebugTrace() just as in H. The only difference is that after DebugTrace() returns with a result of 'halts/no need to abort', it goes into an infinite loop. Since DebugTrace() is claimed to be a decider, it cannot fail to halt (otherwise it would not be a decider). So the only circumstance in which H would be forced to abort Ĥ would be if the DebugTrace() called within Ĥ returned 'halts', thereby forcing it into an infinite loop. So why would DebugTrace(), when called from within Ĥ return 'halts', but when called from H, return 'aborted because of non halting behaviour'? If it is the same function in both, it should be returning the same result in both. André -- To email remove 'invalid' & replace 'gm' with well known Google mail service. |
| olcott <NoOne@NoWhere.com>: Oct 23 01:06PM -0500 On 10/23/2020 12:53 PM, Mr Flibble wrote: > This tells us all we need to know. I think everyone can get on with > their lives now: Alan Turing's proof stands. > /Flibble I figured out the halt deciding criteria for the conventional self-referential halting problem proof counter-examples in 2016. I would have had the code for this written a long time ago yet figured out that I had to write an opertating system first. It took me three years to realize that I needed an operating system and then one more year to write it. The x86utm operating system is now complete. Writing the code to decide the conventional self-referential halting problem proof counter-examples is trivial by comparison, once the halt deciding criteria is known. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 23 01:12PM -0500 On 10/23/2020 1:00 PM, André G. Isaak wrote: > So the only circumstance in which > H would be forced to abort Ĥ would be if the DebugTrace() called within > Ĥ returned 'halts', thereby forcing it into an infinite loop. False assumption. > So why would DebugTrace(), when called from within Ĥ return 'halts', but > when called from H, return 'aborted because of non halting behaviour'? It wouldn't do that. > If it is the same function in both, it should be returning the same > result in both. > André int main() { u32 M = (u32)H_Hat; H(M, M); HALT; } int main() { u32 M = (u32)H_Hat; H_Hat(M); HALT; } Receive the same: Aborted_Because_Non_Halting_Behavior_Detected from DebugTrace() -- 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