Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
Math

Journal tomhudson's Journal: A Turing machine that can solve for the halting problem ... 25

The halting problem is simple enough to describe: Is there any way to determine whether a program will eventually come up with a solution (and halt) or just keep on and on.

http://artzia.com/History/Biography/Turing/
http://kosmoi.com/Computer/Science/Entscheidungsproblem/

The problem with the turing machine is the infinite tape. Just as I can always create a number 1 larger than any number before it, so a tape with an infinite size can always create a program of size+1 greater than that which we've already investigated.

So here's a thought experiment that allows the infinite tape, and yet solves for the halting problem in every case ...

MY magic turing device has the following property - for every calculation it performs, after completion, it goes back in time to when it started, and continues from where it left off. (hey, if you can have an infinite tape, I can have non-linear time loops :-). Check out what happens ...

For example, if its a really slow machine, doing 1 calculation/sec, at the end of every calculation, it goes back one second in time. When it finishes the calculation, it stops going back in time, so all I have to do is see what its doing at T+2 seconds.

The interesting part is that now EVERY problem you can conceive that can halt is calculated by the machine within 1 subjective second. If the machine even exists at T+2 seconds, the program has halted; if not, then its non-halting. Your machine just seems to "disappear", since it's stuck forever shuttling between T and T+1.

Hope you all have a nice weekend, and that this gives some food for thought. --

Update 1

Part of the problem is that people have confused proofs with the actual problem itself.

The problem is to define a series of steps that will always determine whether a problem halts at some point or not. The Chrono Turing Machine (CTM) succeeds.

The "counter-proofs" involve trying, and failing, to prove the contrary, because they cause contradictions. So what? My counter-example, which solves for the alting problem, shows te "proofs" to be less than complete.

For example: http://www.cs.auckland.ac.nz/CDMTCS/chaitin/unknowable/ch4.html

So here is how we'll show that the halting problem cannot be solved. We'll derive a contradiction by assuming that it can be solved, i.e., that there's a LISP subroutine (halts? s-exp) that returns true or false depending on whether the S-expression s-exp has a value.

Then using this hypothetical solution to the halting problem, we construct a self-referential S-expression the same way that we did in Chapter III. We'll define ``turing'' to be the lambda expression for a function of x that makes x into (('x)('x)) and then halts iff (('x)('x)) doesn't. I.e., the function ``turing'' of x halts iff the function x applied to x doesn't halt. But then applying this function to itself yields a contradiction! Because applying it to itself halts iff applying it to itself doesn't halt!

This technique is all very well and good, except it is NOT the original problem ... The user of the Chrono Turing Machine can in 100% of the cases, determine whether a given problem continues forever, or eventually halts. Just as it has an infinite tape (as the original problem does) it has infinite time within that 1-second loop.

For example, it could prove or disprove the Riemann Hypothesis by either halting at T+1 if it finds a counter-example, or disappearing at T+1 if there is no counter-example. Remember, it has an infinity of time and tape with which to work in that 1 second, so if there IS a counter-example, it always finds it and halts.

Same with any problem that generates a series of number. Either, at some point, it generates every possible result and halts at T+1, or it doesn't, and disappears at T+1.

This discussion has been archived. No new comments can be posted.

A Turing machine that can solve for the halting problem ...

Comments Filter:
  • by Talinom ( 243100 ) * on Friday April 28, 2006 @06:14PM (#15224355) Homepage Journal
    You can easily check to see if your Turing engine works properly by feeding it the source code for Windows.

    If it says it will run forever then you need to check your code. If it says it will halt then you have written good code. If, after feeding it the code, the engine halts you patent it.

    I'd wait for quantum computers to become available. Feed it your code and it will execute every possible option and give you the answer.
    • You know, if you close one eye, squint the other, and look sideways a bit, the Chrono Turing Machine and the quantum computer are equivalent.

      The quantum computer encodes for all possible states, then collapses into the answer.

      If the problem does halt, the CTM goes through all possible states, then gives the answer; or it disappears (it's sort of like a Cheshire Shrodingers' cat).

      In other words, if the CTM is, in theory, able to solve the halting problem one way or another in all cases, then a quantu

  • Debugging would be a bitch. Before, if you had an infinite loop you just had to, at worst, power cycle the machine. Now, the whole damn computer vanishes in a puff of logic.

    "Dammit! I lost another computer to a typo today!"
    • Think of ALL the consequences.

      You know how people have been wondering about the Fermi Paradox - how we seem to be all alone, even though there should, in theory, be lots of other civilizations out there?

      Think what happens if you give this Chrono-Turing Device a non-halting problem ... it keeps going back 1 second in the past, expanding its dataset, etc. Drawing more and more power from the environment, getting more and more massive, until, a second after you started it, everything gets sucked into a bl

      • Hmm. Maybe that's what happens at the Singularity that Vernor Vinge keeps going on about.

        (Except, of course, that "Marooned in Realtime" would be a pretty dull book if Earth no longer existed after the Singularity.)
  • Gave you an informative mod today - and I know how you're trying to burn some karma. Sorry 'bout that.

    The perils of moderating while tired....

    • That's okay, there's other opportunities.

      Don't feel so bad - look what happened to this First Post:http://politics.slashdot.org/article.pl?sid= 0 6/04/25/1220231 [slashdot.org] - a total troll, and it still got a +4 Insightful.

      Further down, I get into

      1. kitten stomping
      2. asteriod strikes wiping out humantiy being a good thing,
      3. thumbs in Wendy's chili
      4. Who Killed John Kennedy
      5. Total Information Awareness,
      6. Bush+cocaine+booze
      7. My Pet Goat
      8. Medicare
      9. the debt
      10. Iraq == Vietnam
      11. Intelligent Design
      12. Hurricane Katrina,
      13. how its all OJ Sim
  • You state after every calc (T+1), you return to T=0 - later, you refer to T-1, which it should never get to? Flow would go:
    T=0
    calc 1, T=T+1, (T=1)
    compare current to T=0
    calc 2, T=T+1, (T=2)
    etc...,

    Where does T=-1 enter into it?
    • There's no T=-1.

      Start: At T, do a calculation

      At T+1: Are we finished?
      - Yes: Halt
      - No: Return to T

      The only way the machine makes it to T+2 is if it has completed the calculation. In other words, the program halts.

      So, we have a 2-second (to an independent observer) solution.

  • If I create a machine that exhibits the following behaviour:
    • Call your machine with the program under test (PUT)
    • If your machine exists at T+2 (ie, the PUT halts) then loop foorever
    • If your machine doesn't exist at T+2 (ie, the PUT doesn't halt) then halt

    Now, feed my machine into itself. If my machine operating on itself halts, it will loop forever - if it doesn't halt, then it halts. There's you basic paradox that invalidates the existence of your ultimate Turing machine halt-tester.

    Sorry to burst your bubbl

    • Comparing apples and oranges.

      Feed your problem into the Chrono-Turing Machine, not your mod of it.

      It will do one of two things - either reach T+2, or not. That your mod of it won't doesn't invalidate it.

      That would be like saying that since you modified a program, and it broke, the original program was broken.

      • It is quite trivial to construct a machine that will invalidate your Chrono-Turing machine. Smarter minds than ours have already probed this problem from every angle and it has been proven impossible.

        Build a machine that calls your machine and does the opposite. Create a machine that simply feeds the previous machine into itself. Feed this new machine in your Chrono-Turing machine. Ain't gonna work.

        The original problem doesn't use while loops. Find a copy of Tring's paper and read it - it is a very interest
        • This the the problem between code as data and code executing. It doesn't matter what code you feed the Chrono Turing Machine - it works independent of how you arrange the data. The data doesn't affect the principle of how the Chrono Turing Machine operates - it won't alter the "code" it runs.

          So why would I bother building a machine that calls my machine? Once you've shown even 1 instance where it is possible to, in every case, determine whether a program halts or not, the fact that some other construct fa

          • The problem is actually about algorithms - the actual implementation is irrelevant. The problem states that there is no algorithm capable of determining whether any other arbitrary algorithm halts or not. While it is quite possible to find an algorithm capable of solving the halting problem for a subset of all algorithms, Turing's ingenious creation of the Turing Machine greatly simplified the proof that a "halt tester" is impossible.

            For any mathematical system, there will always be classes of problems that
            • The problem is actually about algorithms - the actual implementation is irrelevant. The problem states that there is no algorithm capable of determining whether any other arbitrary algorithm halts or not.

              The algorithm (the series of steps involved) is quite simple, and it solves for all cases:

              1. T=0 - Start calculating
              2. T=1 - If we're still calculating, loop back in time to T=0 and continue calculating

              This is a general solution, a description of the steps necessary (algorithm) that solves for all cases.

              • It is pointless arguing this case with you - you fail to see that your own machine can be used to create a paradox which invalidates your argument. I've studied algorithms in enough detail to know that the Halting Problem [wikipedia.org] is not solvable. Smarter minds than you or I have spent over a hundred years and have proven this again and again.
                • The paradox only arises in your encapsulation/modification of the functioning of the machine. By the time it gets to YOUR endless loop, it has already completed its work. The only thing that is disallowed is your application, since it is where the paradox arises.

                  That you can modify the situation to create a paradox is irrelevant to whether the machine as posited works or not, especially since it solves the problem without creating a paradox.

                  The original "proof" of the halting problem posits someth

                  • So you are avoiding the paradox by closing your eyes and saying "I can't see it"? You cannot rewrite the rules. You cannot disallow machines that break your machine by disallowing infinite loops - infinite loops are integral to the problem.

                    When you understand the halting problem better we can continue this discussion.
                    • I'm not disallowing machines that you think break my machine. I'm just pointing out that they are broken, not mine.

                      Your position is the argumentive equivalent to saying typewriters can't exist because its possible to generate a paradoxical statement: "THIS SENTENCE IS FALSE"

                      Infinite loops are integral to the problem - I use one to make the machine disappear if the problem never halts. That nobody else thought of it that way in the last 70 years isn't my fault, or my problem.

                      That they were so unimagin

                    • If you actually care to read any of the proofs out there, you would know that you feed the paradox-generating machine back into the halt tester. What is the output of the halt tester then? If it halts, it loops forever; if it loops forever it halts.

                      Find a good text on computability, complexity and completeness. We can continue to discuss why you are wrong when you actually understand the theory.
                    • And if you thought for 2 seconds, you'd realize that the "paradoxical" one always loops forever, on any input.
                      1. If it halts - then it hits the command to loop forever: result == loops forever
                      2. if it loops forever, it never gets to the instruction to halt : result == loops forever

                      Where's the paradox? There is none.

                      Come on - don't tell me that in the last 70 years nobody actually noticed this.

                      And this result applies no matter what program you feed your version. Whether the original program would have h

                    • Open your eyes! The paradox is there, even if you choose to ignore it. It is trivial to create a machine that will invalidate your claim - that is the basis of the proof. By refusing the accept that your idea is flawed, you are showing yourself to be ignorant of the theory of algorithms and computability.

                      Maybe I haven't explained my argument properly: Your machine can be quite easily broken by engineering a paradox - just as every other proof of this does.

                      You have not come up with a magic solution to this p
    • Oh, on a side note ...

      if you look at the code in the original proble, it used a "while(1) {}" construct.

      An optimizing compiler would realize this is an expression with no side-effects, and replace it with a semicolon; you'd need to have at least one variable declared volatile, as well as a function to be invoked on an interrupt, to prevent the busy-loop from disappearing.

      Saw this back in the early '90s. A guy from Matrox was explaining why they switched from BC3.1 to VCwhatever, because their loops j

If it wasn't for Newton, we wouldn't have to eat bruised apples.

Working...