Lecture #19
Wed 27 Feb 2002
NEC

Read beginning of Harel, Chapter 8,
I'll post a reading assignment this afternoon.

Pass back homeworks.
Solutions will be posted this afternoon.

0.  NP, one last time . . .
1.  Tiling Problem
2.  Undecidability
3.  Halting Problem
4.  Beyond Undecidability


0.  NP, one last time . . .

    IAH-JFK 2 . . .    

    Draw Complexity Classes diagram . . .

    What makes a problem in NP?

    What makes a problem NP-Complete?

    Ask about problems that aren't in NPC, but in NP -- primes?, composite?

1.  Tiling Problem

    Recall the monkey puzzle problem.  This problem is somewhat similar in that
    we are trying to arrange two dimensional square pieces to cover an area,
    but still a bit different.

    Say we are trying to tile a room with square tiles.  Each tile is partitioned
    into four right-triangular sections, the side of the square being the hypotenuse
    of each triangle.  These triangles may be different colors.  If we are given
    an infinite number of tiles, but a finite number of types of tiles, we want
    to know if we can cover any room with them, no matter how large, with the
    restriction of having only same-color sides touch.

    How can we know if, no matter how large the room is (it could be infinitely
    large), there exists an arrangement in which only same-color sides touch?

    Is there an algorithm that can do this?

    It turns out there is; similar to the monkey puzzle, we can ennumerate
    possibilities till we find if it will fit or not.  The bad news is, it may
    never terminate.  (Aside: So, is this an algorithm?)

    This problem is then in a class beyond both NP and EXP.  It is UNDECIDABLE.
    This is because it's an algorithmic decision problem that yields no
    possible algorithm to solve it.  The more generic term, applied to problems
    that aren't necessarily decision ("yes/no") problems, is NONCOMPUTABLE.

2.  Undecidability

    So undecidable problems, or problems that are essentially unsolvable, or,
    at least algorithmically unsolvable, make up yet another class of problems.

    We have tractable problems, that yield polynomial-time algorithms;
    intractable, that yield only exponential-time algorithms; and now we have
    undecidable (noncomputable) problems that do not yield (non-terminating)
    algorithms, at all!  That is, it is impossible to compute the answer to
    these problems.

    (draw graph)

3.  The Halting Problem

    An good question to ask of any program is whether it will halt or not.

    Here's an example of a program that never halts, for any input:

    (define (f n)
       (add1 (f (- n 1)))

    We say it enters an infinite loop.  A simpler infinite loop would be:

    (define (inf-loop)
        (inf-loop))

    But let's say these functions were just "black boxes" and we couldn't
    analyze what was inside them.

    A very famous undecidable problem:  Given a program and an input to that
    program, will the program eventually halt and return an answer?  (or will
    it continue forever?)

    Well, it's fairly easy to see that we can't write an algorithm to solve
    this, right?  Well, if we run the input program with the input and it halts
    we return "yes", it's the no case that's the problem.  How do we know
    if it's going to go on forever, or if it's still just computing?    

    We can formalize the undecidability of this problem with a proof:

    Let's say we do have a function halts?, that takes in a program, and a valid
    input for that program:

    ;; halts?: program input --> boolean
    ;; Returns true if (P I) returns an answer, that is, halts; and false 
    ;; otherwise
    (define (halts? P I)
       ... code ...)

    Now we can write another program, that does some crazy stuff:

    ;; twisted: program --> (or false loop-forever)
    ;;    If (P P) halts, then we loop forever;
    ;;    If (P P) runs forever, we'll halt and return "false".
    ;;
    (define (twisted P)
      (if (halts? P P)
          (inf-loop)
          false))

    So, this is to say:

    (twisted P) runs forever if (P P) halts. 
    (twisted P) = false if (P P) runs forever
     
    Now, let's ask, what is (twisted twisted)?

    Suppose (twisted twisted) halts: 
    By the header for twisted, we see then that would mean (twisted twisted) 
    runs forever. A Contradiction! 

    Suppose (twisted twisted) runs forever: 
    By the header for twisted, we see then that would mean (twisted twisted)
    halts. Another Contradiction!


    Therefore, the fucntion halts? cannot exist!  We could never write it!!!!
    (We call this PROOF BY CONTRADICTION.  Since the only assumption we made
    was that halts? existed, we can only conclude that halts? cannot exist!)

    Therefore, the hatling problem is indeed undecidable.

    Point of interest:  We can actully reduce other problems to and from the
    halting problem, similar to our NP reduction of HamPath to TSP.  We could
    effectively reduce halt? to halt-on-8? in which we convert a given input
    I from halt to the input 8, while modifying our program slightly--in such
    a way that if our program halted on the input I, this new program P' would
    halt on 8.

4.  Beyond Undecidability 

    Remember our function threes, from homework 2?

    ;;threes: number --> 1?
    (define (threes n)
       (if (<= n 1)
           1
           (if (even? n)
               (threes (/ n 2))
               (threes (add1 (* 3 n))))))

    It is unknown as to whether this halts for ALL inputs.  So far, it halts
    on any input that anyone has ever tested it with, but no-one has been able
    to prove that it halts for all positive integers.

    What we'd like is a function halts-on-all-inputs?, which takes only a program
    P and returns true if it halts for all possible inputs, and false otherwise.

    Although halts? can reduce to halts-on-all-inputs?, halts-on-all-inputs?
    does not reduce to halts?  This means that the halts-on-all problem is 
    EVEN HARDER than the undecidable halting problem.  We call these 
    problems HIGHLY UNDECIDABLE.

    And we could go on and on . . . but you probably get the picture.

    Have a good break and I'll see you when we get back.