Skip navigation.

Software Development

Correcting The Future

Proofing the Ouroboros

On Technometria, I found this short verse[pdf] Dr. Seuss style about the Halting Problem.

If you are one of the people that still believes in the greatest hoax in computing, then you need to read on. This will be done in the easiest way possible for anyone to understand. All you need is basic math.

The first thing we need to do is to explain the halting problem. Functions can go into infinite loops or they can return a value. The Halting Problem asks if there exists an Oracle (software) that can determine if any given program will halt or not when its input is also known. Right there, I can tell you that the Halting Problem sets up its own answer. But it's not easy to see why.

Instead of asking about halting or not, let's try something simpler just so I can explain how absurd the Halting Problem really is. Let's assume ALL programs DO halt. Any program that doesn't halt is not considered. We leave those out. Instead of asking for a Halting Oracle, we will instead ask if it's possible for a Result Oracle to exist. If we give it any given program and its input, we want to know the output value.

Is it possible to create a Result Oracle?

Of course it is. You just run the given program. We know it will halt, so we'll get a result every time. Even so, I can use the Halting Problem Proof to 'prove' that it can't be done. And yet all programmers know that if you call a function that is known to halt, you will get a result.

How do I 'prove' that it can't be done? Well, we take advantage of a little property about functions. What is this property? Let me explain using the Socratic method.

Q: What is a function?
A: It's something that sets up a mathematical relationship between inputs and outputs.

Q: BEFORE you see any of the inputs, can you tell what the output will be?
A: No, of course not.

Q: So a function is undecidable?
A: Yes, that is by definition one of the properties of a mathematical relationship. (Note: the reader may look this up.)

Q: If you were to combine two functions, could you create a single function that is equivalent?
A: Yes.

Q: So even if you pass a function to another function, the aggregate would remain undecidable?
A: Yes, because compound functions are still functions.

In order to 'prove' that it's impossible to have a Result Oracle, I'm going to create a deceiver program P that calls Q (the Result Oracle) and asks what P will return. So whatever Q returns, P will add 1 and return that. This will mean that no matter what Q returns, it will always be wrong by one. Therefore the Result Oracle cannot exist. End of 'proof'.

We know for a fact that this is bogus. We can just run any function with its input and get a result. So why aren't we getting a valid result here? Well, we took advantage of the fact that functions are undecidable and made sure we provided no input that was decidable.

Basically, we end up with a compound function. What part of Q(P,Q) is decidable? None. They are all functions. A compound function is still a function and is undecidable. So all we did was refuse to produce a decidable input. A function without an actual input value can only produce another function. Otherwise, it doesn't have enough information and cannot execute.

And that's why the Halting Problem is bogus (undecidable inputs and forcing true/false as output). We just tackled a MUCH easier problem. One that we KNOW exists. The Result Oracle is today known as an Operating System (edit: or a CPU or a Universal Turing Machine).

The Halting Problem is unfortunately setting up its own answer from its formulation. A premise that gives its own answer is circular logic. In 350BC, this is what Aristotle called begging the question. BTW, you can incorrectly prove that God doesn't exist by this same method. Ask God what you will do and then do the opposite after you've been given an answer. No one or no thing can give you a correct answer as to what you will do, therefore there can be no God.

Not only is this patently absurd, but it's sad that it has been accepted as a genuine proof in computing since 1936.

The Halting Proof has a few other complications, but the essentials are that you are trying to convert undecidable inputs (P,Q) into a decidable output of true/false. This has nothing to do with halting, but rather with composability.

It's like connecting tubes to other tubes and asking if the water that comes out is hot or cold. There is no water. So there cannot be a valid answer. That's what's happening with programs composed in this manner. Composability breaks down when there is no actual input to match to output.

Some may say that P is never actually executed. It could be sent as text. The problem is that it's still undecidable because P is treated as a function. Q is interested in the BEHAVIOUR of P as a function. But even if it was a decidable input, you could merge it into Q and produce a new equivalent function R. So now you have R(Q). Here, you want to map a function Q to true/false. Can't be done because there is no decidable input to Q. Q is itself the input.

One important point!

Decidability is dependent on the interpretation of the input. If you treat it as a function where you want to know about its behaviour (especially its output), then it's undecidable (assuming you don't provide it any decidable input, and even then there is no guarantee). However, a function may be treated as decidable input if the entirety of it is used without regard to its behaviour. For example, a compiler taking text input and producing binary output. So the format is irrelevant. It's the interpretation that is paramount.

This is a mistake that many mathematicians make. The execution is irrelevant. So just because neither inputs to the Halting Oracle are executed does not change the fact that both inputs are treated as undecidable functions according to the definition of the Halting Oracle.

More than that, the deceiver program in the halting problem is impossible to execute. Sure, you can write the code for it. But you'll never be able to create ANY function that the deceiver can invoke. It's impossible to write a function that takes a function as input (and treats it as such) and gives out true/false. This has nothing to do with Oracles.

True that this conversion can be done in SOME cases where the input is not needed to make the determination. For example, we know that "return a+1;" halts regardless what the input is. But in the cases where the input is needed to make that determination, it's impossible to do since no decidable input is provided.

What the Halting Problem Proof does is create an incomplete program. It creates a compound function and then says, "Look, no input. Since you can't produce output without input, the Oracle can't exist". That's ALL the Halting Problem Proof says. Nothing more. Nothing less.

The Halting Problem Proof is, and always has been, a hoax. Circular logic can be VERY difficult to notice and the greatest minds of the past century have failed to notice it. It erroneously asks you to treat the input as decidable input. That error is the cause of circular logic. In other words, the Halting Proof is nothing more than a demonstration of this error. It is in effect eating its own tail.

Subpixel Text RenderingHalting Problem Diagonalization

Comments

Vladas 12. December 2008, 07:12

These are short questionables that came to my mind in random order:

1. The result of any function depends on the grammar which will be used for function interpreting. Do we know that? We even cannot predict the grammar which will be used for executing our program!!! So what's the point of prediction at all? It's like predicting the thing which was never be existing yet. (This is for your remark about the Result Oracle must be a whole OS).

2. If function results could be predictable, there would be no need of functions at all. Just use a predicted result instead of calling the function. Otherwise the function would be just a bunch of commands set out apart (which is really a case in most of real-life "function" uses).

3. The halting problem really exists and still having a sence. The sence is in the question - why do we need to compute this or that?

I suspect that you really faced the Halting Problem while you work with dataflow. So you are revisiting this problem from time to time. I can tell you - I faced it too. Just see my work ( http://www.prodata.lt/EN/Programming/OPU_computing_model.pdf ), and the section called "The Timeout Problem". It's a paraphrased Halting Problem. I've set this problem and left it, waiting for forthcoming solutions. The obvious and easiest solution is - to set timer and poll until it expires. Then decide. I see no other way around (by now).

Vorlath 12. December 2008, 15:04

If it's ok, I'm going to reply about a few other things as well. So the stuff below the first three points aren't directed specifically to you, but to everyone who is interested in this extra information.

About #1, I don't say that the Result Oracle MUST be an OS. Simply that this is an example of one to show that any proof that says it can't exist is flatly wrong. A better example would be the CPU itself. But yeah, the result does matter on the grammar (textual or binary) along with its input.

About #2, most commands take an input and I only considered those. The others have implied inputs and can be replaced with the other type of function. Anything that doesn't take an input (NOP) can be removed without affecting the program.

About #3, I have to disagree. The halting problem doesn't exist as currently accepted. It'd be fine if people followed the rules of computing, but the currently accepted proof confuses the representation of a function (the grammar) with the actual physical machine of that function (the logic gates).

An analogy would be proving something on array indexes and saying that it applied to array elements. You can't do that. Array indexes and array elements have different properties. And any means of representing a function (like grammars) have different properties than the function itself.

Lastly, the halting problem doesn't make sense in dataflow. Dataflow has no obligation to ever halt. It can even produce a result and go into an infinite loop. In fact, never ending looping constructs are perfectly normal in dataflow. Loops in dataflaw don't have the catastrophic effects that they do in imperative, OO or functional. Take memory flipflops. Dataflow can use flipflops directly and be a component. IOW, memory and software are one and the same in dataflow. But if you had infinite looping (or recursive) constructs in imperative, OO or functional, the software would hang (not halt) because nothing else can get evaluated. That problem simply doesn't exist in dataflow.

BTW, I do revisit the halting problem now and again because I'm amazed how many people believe it and keep seeing articles about it like there's something profound there. Most people that see the halting problem know there is something wrong with it right away, but can't put their finger on it. Then mathematicians come in and say that intuition can't be relied on and this is why the person is wrong. That's a strawman argument. Intuition can be correct. The reason that most people can't put their finger on it is because the question of halting unnecessarilly complicates matters. For some functions, you don't need the input to see if it halts or not. But take away the halting question, and replace it with a question that requires the input every time and the problem is the same, only without the unnecessary complications. The erroneous 'proof' is likewise still the same, but is clearly wrong since there are real world examples of the Result Oracle.

Representations are very dangerous. For example, I can say that 1+1 = 2. But in the real world, I can say 1+1=1 since I can melt both objects into one like melting 2 gold pieces and then pour them together into a single coin. The point is again that representations have different properties than what they represent. That's what the halting problem gets wrong and what it tries to get us to incorrectly assume. The Halting Proof only demonstrates this initial error. It doesn't actually prove anything.

Actually, a simple example of this error known to all programmers is that the text "1" is very different than the actual number 1. Yet we use the same symbol in both places. But the interpretation is different in each case.

Vladas 12. December 2008, 18:17

I intentionally referred to my work, because surprisingly, in disconnected execution environmens, some variations of Halting Problem still may be very actual:


The Timeout Problem

One of the main possible problems in our proposed Object Flow Model (this is another name for the proposing parallel computing model), which stands in front of all other - is a Timeout problem. This problem plays intact with well known Halting problem, the paraphrased version of which could be following:

“Given a program and an input to the program, determine how long the
program will be executed
when it is given that input”.

For our parallel model this question becomes very important. How long any variable should wait for the result? What time is to be set to finally ensure that the variable cannot be completed because of possible fault, cycling, connection lost or whatever else? This is also important for choosing alternative paths in case of errors.
One possible solution is to make parallel operations so smooth that ever
happening long timeouts could mean an inevitable fault. However, this solution stops working when a high level of parallelisation hierarchy is reached. Another possible solution is a prediction by fact mechanism. We can set predicted and/or predefined timeout values basing on previous execution times of similar or same operations. Anyway, the Timeout problem is still an open question and may be qualified as the most important problem.

Vladas 12. December 2008, 18:27


Lastly, the halting problem doesn't make sense in dataflow. Dataflow has no obligation to ever halt. It can even produce a result and go into an infinite loop.


I may argue with you on this point, because we all know to what consequences may an infinite loop lead in a sence of consuming resources (uncontrolled or dynamic resource allocations, dataflow paths resources (actually recursed), etc...). This is true that it could be not an issue in most cases, but not in general.

Vorlath 12. December 2008, 23:49

The timeout problem is very real. But it's different than the halting problem. In the halting problem, the time isn't an issue even if it's extremely long. In concurrent programming, timeouts are a real pain and you can never get a perfect answer.

And point taken on your last comment.

How to use Quote function:

  1. Select some text
  2. Click on the Quote link

Write a comment

Comment
(BBcode and HTML is turned off for anonymous user comments.)

If you can't read the words, press the small reload icon.


Smilies

December 2009
S M T W T F S
November 2009January 2010
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31