| olcott <NoOne@NoWhere.com>: Oct 21 06:28PM -0500 On 10/21/2020 6:16 PM, Ben Bacarisse wrote: >> pathological self-reference. > Now that your method has been revealed, please post what you had two > years ago. I am going beyond that. What I had two years ago was far too terse for anyone here to understand. Now that the man-years worth of work creating the x86utm operating system is totally complete I can write much more robust halt deciding code. If you can't see how I have already refuted the halting problem proofs by transforming the halting question: (a) Does H_Hat() halt on its input? Into an equivalent question that is not subject to pathological self-reference: (b) Does the execution of H_Hat() have to be aborted to prevent the halt decider from getting stuck in infinite execution? Then it makes no sense to provide the halt decider code. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 21 09:14PM -0500 On 10/21/2020 8:22 PM, Richard Damon wrote: > clearly a legal modification, so any problems with it must have been > contained in H, so saying H can't exist is exactly what Linz was trying > to prove. When we make the single change that I suggest the halting problem ceases to be impossible to solve because this revised question is not subject to pathological self-reference. All of the inputs are divided into halting and not halting and the halt decider cannot be fooled by a program based on itself that does the opposite of whatever it decides. -- Copyright 2020 Pete Olcott |
| Mike Terry <news.dead.person.stones@darjeeling.plus.com>: Oct 22 03:38AM +0100 On 21/10/2020 23:55, olcott wrote: > pathological self-reference into a question that is not subject to > pathological self-reference thus eliminating the impossibility of > solving the halting problem. You forgot to answer the question! Here it is again: Will both the DebugTrace() return codes be ZERO, or will they be NON-ZERO? (You previously agreed they would be the same...) Mike. |
| olcott <NoOne@NoWhere.com>: Oct 21 09:54PM -0500 On 10/21/2020 9:38 PM, Mike Terry wrote: > Will both the DebugTrace() return codes be ZERO, or will they be > NON-ZERO? (You previously agreed they would be the same...) > Mike. That question will only be answered by fully operational code. The key proof has already been provided. No matter what return value that DebugTrace() provides if it is always answering the question: Was your input aborted because it would not otherwise halt? The halting problem becomes decidable. -- Copyright 2020 Pete Olcott |
| Mike Terry <news.dead.person.stones@darjeeling.plus.com>: Oct 22 04:38AM +0100 On 22/10/2020 03:54, olcott wrote: >> NON-ZERO? (You previously agreed they would be the same...) >> Mike. > That question will only be answered by fully operational code. That's what I expected you to say. It won't make the slightest difference to how your work is received if you answer now or in a few weeks, but it's your choice. > The key proof has already been provided. ?! All you've provided so far is: a) the skeleton C code, which clearly is going to support the Linz proof, if what you've said about how DebugTrace() behaves is true; and b) what you've said below about changing the question, which makes no difference to anything at all. Have I missed an actual proof of something? The Usenet server I use (Giganews) does that from time to time - it has a bug in its "add new message to database" logic where certain updates are not atomic (w.r.t client enquiries) when they should be. (Or is your "changing the question" supposed to be some kind of proof?) > that DebugTrace() provides if it is always answering the question: > Was your input aborted because it would not otherwise halt? > The halting problem becomes decidable. Sorry, but that's nonsense. Oh well, guess we'll just have to wait and see the full code. Mike. |
| olcott <NoOne@NoWhere.com>: Oct 21 11:33PM -0500 On 10/21/2020 10:38 PM, Mike Terry wrote: > going to support the Linz proof, if what you've said about how > DebugTrace() behaves is true; and b) what you've said below about > changing the question, which makes no difference to anything at all. The difference is that it is no longer possible for H_Hat() to do the opposite of what H() decides. This transforms an undecidable problem into a decidable problem. > message to database" logic where certain updates are not atomic (w.r.t > client enquiries) when they should be. > (Or is your "changing the question" supposed to be some kind of proof?) By changing the question H_Hat() can no longer do the opposite of what H() decides making an undecidable problem into a decidable problem. > Sorry, but that's nonsense. Oh well, guess we'll just have to wait and > see the full code. > Mike. The full code will not be provided until you (and others) understand how I already proved my point. By searching the comp.theory forum for "olcott" (11,415 messages from me) it can be verified that it took me about 12,000 hours since 2004 to come up with this simple "change the question" refutation. In the mean time I will complete the code that uses a key detail about the halting problem that no one ever noticed for 80 years to correctly decide the halting of H_Hat(). I already showed THAT the halting problem is decidable. Next I will show HOW the conventional self-referential halting problem counter examples are decided. -- Copyright 2020 Pete Olcott |
| Richard Damon <Richard@Damon-Family.org>: Oct 22 08:00AM -0400 On 10/22/20 12:33 AM, olcott wrote: > The difference is that it is no longer possible for H_Hat() to do the > opposite of what H() decides. This transforms an undecidable problem > into a decidable problem. If H_Hat no longer does what the proof defined, then your demonstration is no longer applicable to the proof. One possible counter might be showing that the steps that Linz did to make H_Hat aren't allowed by the definition of Turning Machines, but they clearly are, being a fairly simple augmentation to the state table of H. Showing that some thing you call "H_Hat" doesn't contradict something you call "H", which doesn't do what H is required to do proves absolutely nothing. At best it provides some evidence that the creation of a universal halt detector is in fact impossible, because you are going to such off-beat arguments that it is possible. |
| olcott <NoOne@NoWhere.com>: Oct 22 09:36AM -0500 On 10/22/2020 7:00 AM, Richard Damon wrote: >> into a decidable problem. > If H_Hat no longer does what the proof defined, then your demonstration > is no longer applicable to the proof. If the halt decider is to report whether or not its input halts another program can be constructed on the the basis of this halt decider that does the opposite of whatever the halt decider decides. This is how H() and H_Hat() are defined in the Linz proof. If the halt decider is to report whether or not it aborted its input program because its input program would otherwise cause the halt decider to get stuck in infinite execution then this other program can no longer fool its halt decider and do the opposite of whatever it decides. If H() aborts the execution of H_Hat() then H_Hat() cannot continue to execute because H() has complete control over H_Hat. The end result of this slight change is that the halting problem can no longer be shown to be undecidable. -- Copyright 2020 Pete Olcott |
| Mike Terry <news.dead.person.stones@darjeeling.plus.com>: Oct 22 04:25PM +0100 On 22/10/2020 15:36, olcott wrote: > execute because H() has complete control over H_Hat. > The end result of this slight change is that the halting problem can no > longer be shown to be undecidable. It is suspicious that in none of this have you ever stated what is actually wrong in the Linz proof. It's almost as though you accept there is nothing wrong with it, and yet you still think its conclusion is incorrect! Or that you can't see anything wrong with it, and in your head the mistake in the proof is that its conclusion is wrong? (Thinking a conclusion is wrong does not refute anything...) Anyhow, you talk about the halt decider reporting that it "aborted its input program, because blah blah". If you read the Linz proof, you'll notice that it is completely unaffected of any internal reasoning as to WHY H might have made whatever decision it made. All it depends on is that H actually makes a decision! In your example, as long as H actually makes /some/ decision, the H_Hat will do the opposite of what H decided, and so the Linz proof will be confirmed, not refuted. If H loops, never making any decision, then H is not a decider for the H_Hat(H_Hat) question (contrary to what you have always explicitly stated) and so is irrelevant to the Linz proof. You have said you won't reveal your final code unless I (and others) agree that what you've said so far already proves your point. Well, you haven't proved anything, so that's that. So... this was to be the culmination of your life's work, and now you're simply not going to publish it? I thought the whole purpose of producing the actual TMs was that it would override any objections people raised to a mere verbal claim, and prove you right despite the objections? Two years ago I told you that if you just gave your reasoning and perhaps some high-level pseudo-code, and forgot about producing actual "TM"s and traces and whatnot, people would quickly tell you your mistake and you could save months of effort. And it turns out (no surprise) that this was correct! Had you posted 2 years ago just what you've said in this thread people would have said exactly the same as they're saying now, and nothing whatsoever would be different, except you would have saved a year's work on your part. :) Regards, Mike. |
| olcott <NoOne@NoWhere.com>: Oct 22 10:44AM -0500 On 10/22/2020 9:57 AM, Ben Bacarisse wrote: > have a pair, H and H^, related exactly as in Linz, where H gives the > correct halting answer for H(H^, H^). Do you now see that such a pair > is impossible? I think that the problem is that you are not even glancing at what I say before you form your baseless rebuttal. I have already proven that the H() to H_Hat() relationship is the same as the conventional self-referential halting problem counter-example relationship by providing its exact source code. I adapted Mike's version of H_Hat(), His comments regarding the halting decision were incorrect. On 10/20/2020 8:57 PM, Mike Terry wrote: > for (;;); // ..so we loop > } > } // M has address of H_Hat() int H_Hat(u32 M) { int Abort = DebugTrace(M, M); if (Abort) { MOV_EAX_0 // DebugTrace says that M(M) HALT // has been aborted } else { MOV_EAX_1 // M(M) has halted HERE: goto HERE; HALT } } The much more subtle nuance that cannot be understood by anyone that is not an expert in this field and only then with very intense focused concentration is that my simple change to the halting question converts the halting problem from an undecidable problem into a decidable problem. Did the input program have to be aborted to prevent the halt decider from getting stuck in infinite execution? Cannot be thwarted by pathological self-reference. It is no longer impossible for a halt decider to divide all of its inputs into (a) halting and (b) would not otherwise halt. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 22 11:38AM -0500 On 10/22/2020 10:25 AM, Mike Terry wrote: >> longer be shown to be undecidable. > It is suspicious that in none of this have you ever stated what is > actually wrong in the Linz proof. When the halting problem is defined as: bool Does_It_Halt(u32 P, u32 I) another program can be constructed on the basis of Does_It_Halt() that does the opposite of whatever Does_It_Halt() decides. When the halting problem is defined as: bool Was_Its_Execution_Aborted(u32 P, u32 I) another program CANNOT be constructed on the basis of Was_Its_Execution_Aborted() that does the opposite of whatever Was_Its_Execution_Aborted() decides. All of the cases where Was_Its_Execution_Aborted() returns true are cases of non-halting behavior. All of the cases where Was_Its_Execution_Aborted() returns false are cases of halting behavior. > notice that it is completely unaffected of any internal reasoning as to > WHY H might have made whatever decision it made. All it depends on is > that H actually makes a decision! In the Linz case if a program would not halt and we are asking would it halt and we abort the execution of H_Hat() then H() gets the wrong answer because H() says that it would not halt and it does halt. If we keep everything else the same except change the question to: Was the input program aborted because it would not otherwise terminate? Now when we answer yes we get the right answer. H_hat() cannot possibly do the opposite of what H() decides because H_Hat() is under the complete control of H(). > In your example, as long as H actually makes /some/ decision, the H_Hat > will do the opposite of what H decided, and so the Linz proof will be No not at all, not in the least little bit, as exaplained above. > confirmed, not refuted. If H loops, never making any decision, then H That violates the defintion of a halt decider. > You have said you won't reveal your final code unless I (and others) > agree that what you've said so far already proves your point. Well, you > haven't proved anything, so that's that. I took me 12,000 hours to derive this simple little proof so it is OK if you don't get it right away. > So... this was to be the culmination of your life's work, and now you're > simply not going to publish it? I thought the whole purpose of I didn't say that. As soon as people pay enough attention they will see that I am correct. > producing the actual TMs was that it would override any objections > people raised to a mere verbal claim, and prove you right despite the > objections? The "objections" are merely not paying enough attention to understand what I am saying. -- Copyright 2020 Pete Olcott |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 22 05:41PM +0100 On 20/10/2020 22:26, Chris M. Thomasson wrote: >> DebugTrace() continues a DebugStep() of M(N) unless M(N) would not otherwise terminate. >> At the first point that DebugTrace() determines that M(N) would not otherwise terminate it aborts the DebugStep() of M(N). > How does it determine that an unknown function will never terminate? Excellent question; in fact it is the ONLY question that matters .. we await Olcott's answer... ;D /Flibble -- ¬ |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 22 05:54PM +0100 On 20/10/2020 17:33, olcott wrote: > x86utm is as much as possible a Universal Turing Machine UTM that has the x86 language as its Turing Machine Description language. Occam's Razor suggests that my assumption that Turing is correct and you, random Usenet person, are incorrect is a fair assumption so I don't have the time to read your refutation. If your "solution" to the HP is an "oracle" then: "A machine with an oracle for the halting problem can determine whether particular Turing machines will halt on particular inputs, but they cannot determine, in general, if machines equivalent to themselves will halt." /Flibble -- ¬ |
| olcott <NoOne@NoWhere.com>: Oct 22 11:57AM -0500 On 10/22/2020 11:54 AM, Mr Flibble wrote: >> x86utm is as much as possible a Universal Turing Machine UTM that has >> the x86 language as its Turing Machine Description language. > Occam's Razor suggests that my assumption that Turing is correct and Perhaps you are totally unaware that Occam's Razor is merely a heuristic used to save time and money and no aspect what-so-ever of correct reasoning. -- Copyright 2020 Pete Olcott |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 22 06:05PM +0100 On 22/10/2020 17:57, olcott wrote: >>> x86utm is as much as possible a Universal Turing Machine UTM that has the x86 language as its Turing Machine Description language. >> Occam's Razor suggests that my assumption that Turing is correct and > Perhaps you are totally unaware that Occam's Razor is merely a heuristic used to save time and money and no aspect what-so-ever of correct reasoning. Yes I am aware that it a heuristic which I can use to decide on what I 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. /Flibble -- ¬ |
| olcott <NoOne@NoWhere.com>: Oct 22 12:09PM -0500 On 10/22/2020 11:56 AM, Malcolm McLean wrote: > the paradox goes away. > I'll leave it to others to explain why this only seems to refute the LInz > proof that halting is undecideable. It refutes the general assertion that the halting problem is undecidable by showing how the halting question can be transformed into an equivalent question that cannot be thwarted by pathological self-reference. So within Linz's faulty assumption that the only possible way to create a universal halt decider is to directly ask the question: Does the input program halt on its input? The Linz proof is correct. When we realize that this assumption is faulty and instead ask the question: Was the execution of the input program on its input aborted? Then creating a universal halt decider is no longer "proved" to be impossible on the basis of the conventional self-referential halting problem counter-examples. The halt decider either detects non-halting behavior and reports it or allows the input program to terminate on its own. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 22 12:19PM -0500 On 10/22/2020 11:41 AM, Mr Flibble wrote: > Excellent question; in fact it is the ONLY question that matters .. we > await Olcott's answer... ;D > /Flibble The only question that matters more than any other question is whether or not changing the question from: (a) Does the program halt on its input? (b) Was the program aborted because non-halting behavior was detected? eliminates the undecidability of all of the conventional self-referential halting problem proof counter-examples? How the halt decider actually decides these conventional self-referential halting problem proof counter-examples is icing on the cake because its basis is a crucial detail about the halting problem counter-examples that no one (besides me) ever noticed for 80 years. -- Copyright 2020 Pete Olcott |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 22 06:21PM +0100 On 22/10/2020 18:19, olcott wrote: > (b) Was the program aborted because non-halting behavior was detected? > eliminates the undecidability of all of the conventional self-referential halting problem proof counter-examples? > How the halt decider actually decides these conventional self-referential halting problem proof counter-examples is icing on the cake because its basis is a crucial detail about the halting problem counter-examples that no one (besides me) ever noticed for 80 years. hubris /ˈhjuːbrɪs/ noun excessive pride or self-confidence. "the self-assured hubris among economists was shaken in the late 1980s" Similar: arrogance conceit conceitedness haughtiness pride vanity self-importance self-conceit pomposity superciliousness feeling of superiority hauteur uppitiness big-headedness Opposite: modesty (in Greek tragedy) excessive pride towards or defiance of the gods, leading to nemesis. /Flibble -- ¬ |
| olcott <NoOne@NoWhere.com>: Oct 22 12:26PM -0500 On 10/22/2020 11:57 AM, Mike Terry wrote: > "H can not give the correct halting answer for the input pair <[H^], > [H^]>" is a /conclusion/ within the proof, based on a contradiction > generated in turn by the previous state transition diagrams. Within Linz's faulty assumption that the only possible way to create a universal halt decider is to directly ask the question: Does the input program halt on its input? The Linz proof is correct. When we realize that this assumption is faulty and instead ask the question: Was the execution of the input program on its input aborted because non halting behavior was detected? Then creating a universal halt decider is no longer "proved" to be impossible on the basis of the conventional self-referential halting problem counter-examples. The halt decider either detects non-halting behavior and reports it or allows the input program to terminate on its own. -- Copyright 2020 Pete Olcott |
| olcott <NoOne@NoWhere.com>: Oct 22 12:27PM -0500 On 10/22/2020 12:21 PM, Mr Flibble wrote: >> years. > hubris > /ˈhjuːbrɪs/ Ad hominem attacks are the first resort of clueless wonders. -- Copyright 2020 Pete Olcott |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 22 06:30PM +0100 On 22/10/2020 18:27, olcott wrote: >> hubris >> /ˈhjuːbrɪs/ > Ad hominem attacks are the first resort of clueless wonders. And you still haven't answered the question: how does it "detect" that the unknown function never terminates, clueless WANKER? /Flibble -- ¬ |
| Ralf Fassel <ralfixx@gmx.de>: Oct 22 06:05PM +0200 I am canceling my own article. |
| Frederick Gotham <cauldwell.thomas@gmail.com>: Oct 22 03:48AM -0700 I have an idea for making a 'fat binary' that doesn't require any kernel support on Linux or Mac. So let's say we start off with a small shell script like this: #!/bin/sh arch=`uname -m` if [ $arch = "x86_64" ] ; then // Do something elif [ $arch = "aarch64" ] ; then // Do something fi exit 0 The most important line is the last one "exit 0" because it will stop the script. It is after this line that I will put the x86_64 binary, followed by the aarch64 binary, so the script will look something like this: #!/bin/sh arch=`uname -m` if [ $arch = "x86_64" ] ; then skip=00290 count=08816 elif [ $arch = "aarch64" ] ; then skip=09106 count=14688 else exit 1 fi dd if="$0" of=/tmp/binaryfile bs=1 skip=${skip} count=${count} > /dev/null 2>&1 chmod +x /tmp/binaryfile /tmp/binaryfile exit 0 [ - - - x86_64 binary goes here - - - ] [ - - - aarch64 binary goes here - - - ] So as a test program to try it out, I'll now write a small C++ program that prints a number sequence: #include <iostream> /* cout, endl */ #include <thread> /* this_thread::sleep_for */ #include <chrono> /* seconds */ auto main(void) -> int { for ( unsigned i = 0; /* ever */ ; ++i ) { std::this_thread::sleep_for(std::chrono::seconds(1u)); std::cout << i << std::endl; } } I have compiled this program for two architectures: g++ main.cpp -DNDEBUG -Os -o prog_x86_64 aarch64-linux-gnu-g++ main.cpp -DNDEBUG -Os -o prog_aarch64 and so I have two binaries as follows: -rwxr-xr-x 1 root root 8816 Oct 22 10:53 prog_x86_64 -rwxr-xr-x 1 root root 14688 Oct 22 10:52 prog_aarch64 The x86_64 binary is 8816 bytes. The aarch64 binary is 14688 bytes. So now I get the size of my small script above: -rwxr-xr-x 1 root root 290 Oct 22 11:31 myscript.sh It is 290 bytes, which means I know how much to skip by: dd if="$0" of=/tmp/binaryfile bs=1 skip=00290 count=08816 Finally I concatenate the 3 files: cat myscript.sh prog_x86_64 prog_aarch64 > fatbin And I run my fat binary: chmod +x fatbin ./fatbin I've tried this 'fatbin' file on both architectures and it works. You can download the files here and try it yourself: http://virjacode.com/experimental/prog.cpp http://virjacode.com/experimental/prog_aarch64 http://virjacode.com/experimental/prog_x86_64 http://virjacode.com/experimental/myscript.sh http://virjacode.com/experimental/fatbin I think it might even be possible to extend this script so that it doubles as a batch file for Microsft Windows, so maybe we could have two Linux binaries, a Mac binary, as well as a Microsoft binary all in one file. It can made threadsafe and re-enterable by using system-supplied temporary filenames or UUID's instead of "/tmp/binaryfile". |
| Juha Nieminen <nospam@thanks.invalid>: Oct 22 02:03PM > dd if="$0" of=/tmp/binaryfile bs=1 skip=${skip} count=${count} > /dev/null 2>&1 Since you are copying the contents somewhere else anyway, you could jsut as well compress that content and run it through gunzip (or even xz), to make this file smaller. Also, if you don't want to rely in this actually being a file with an actual name (rather than, for example, being piped through something else, or for any other reason this script not having a valid name as $0), what you can do instead is to use heredoc in conjunction with base64 encoding/deconding (and gzip compression to boot). It will make the file larger, but you won't be relaying on it being actually a file and $0 being its name. In other words, something along the lines of: base64 -d << 'DATA_END' | gunzip > /tmp/binaryfile (gzip-compressed base64-encoded data here) DATA_END |
| Ralf Fassel <ralfixx@gmx.de>: Oct 22 06:04PM +0200 * Frederick Gotham <cauldwell.thomas@gmail.com> | dd if="$0" of=/tmp/binaryfile bs=1 skip=${skip} count=${count} > /dev/null 2>&1 Nitpick: use mktemp(1), or at least something along these lines to create the temporary file and remove it after use: cleanup () { rm -f "$TMPFILE" exit $1 } TMPFILE=${TMPDIR:-/tmp}/foobar.$$ trap "cleanup 1" 1 2 15 dd ... of="$TMPFILE" ... TNX R' |
| 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