Logo
  • Home
  • Classes
  • Conveying Computing
  • Exams
  • Fractal Gallery
  • Guides
  • Problem Sets
  • Syllabus

Class 36: Halting Problem

Posted by David Evans on 16 Nov 2011 in Classes | 2 comments

Class 36: Slides [PPTX], Notes [PDF]

Here’s the movie from class today:



Mario – Determinism vs. Nondeterminism [video]
by Navid Hosseini, John Koelling, Trung Tran, and Ben Powell

The other movie we didn’t watch:


A Downfall Parody: P = NP [Video]
by Arthur Gordon, Allison Gurlitz, Stephen Lam, Eugene Moy

More conveying complexity submissions are here, including games, comic books, and stories.

Print Friendly Print Get a PDF version of this webpage PDF

2 Responses to “Class 36: Halting Problem”

  1. Deirdre Regan says:
    17 November 2011 at 1:36 pm

    Sorry for commenting twice in one week, but I thought that this poem might help a bit with following the halting problem….

    Scooping the Loop Snooper
    an elementary proof of the undecidability of the halting problem

    Geoffrey K. Pullum, University of Edinburgh

    No program can say what another will do.
    Now, I won’t just assert that, I’ll prove it to you:
    I will prove that although you might work til you drop,
    you can’t predict whether a program will stop.

    Imagine we have a procedure called P
    that will snoop in the source code of programs to see
    there aren’t infinite loops that go round and around;
    and P prints the word “Fine!” if no looping is found.

    You feed in your code, and the input it needs,
    and then P takes them both and it studies and reads
    and computes whether things will all end as they should
    (as opposed to going loopy the way that they could).

    Well, the truth is that P cannot possibly be,
    because if you wrote it and gave it to me,
    I could use it to set up a logical bind
    that would shatter your reason and scramble your mind.

    Here’s the trick I would use – and it’s simple to do.
    I’d define a procedure – we’ll name the thing Q -
    that would take any program and call P (of course!)
    to tell if it looped, by reading the source;

    And if so, Q would simply print “Loop!” and then stop;
    but if no, Q would go right back to the top,
    and start off again, looping endlessly back,
    til the universe dies and is frozen and black.

    And this program called Q wouldn’t stay on the shelf;
    I would run it, and (fiendishly) feed it itself.
    What behaviour results when I do this with Q?
    When it reads its own source, just what will it do?

    If P warns of loops, Q will print “Loop!” and quit;
    yet P is supposed to speak truly of it.
    So if Q’s going to quit, then P should say, “Fine!” -
    which will make Q go back to its very first line!

    No matter what P would have done, Q will scoop it:
    Q uses P’s output to make P look stupid.
    If P gets things right then it lies in its tooth;
    and if it speaks falsely, it’s telling the truth!

    I’ve created a paradox, neat as can be -
    and simply by using your putative P.
    When you assumed P you stepped into a snare;
    Your assumptions have led you right into my lair.

    So, how to escape from this logical mess?
    I don’t have to tell you; I’m sure you can guess.
    By reductio, there cannot possibly be
    a procedure that acts like the mythical P.

    You can never discover mechanical means
    for predicting the acts of computing machines.
    It’s something that cannot be done. So we users
    must find our own bugs; our computers are losers!

    • David Evans says:
      17 November 2011 at 2:53 pm

      This is great!

      There is one important issue that it takes a lot of “poetic license” with, but is commonly misunderstood. For example,

      No program can say what another will do.

      isn’t really correct. It should really be,

      No program can say what any other will do.

      There are programs that can predict what other programs can do — the important point is the there is no program that can predict what every program can do. Indeed, it is easy to write a halts procedure that works correctly on many programs (for example, we know a program with no loops or recursive calls will always halt). Contrary to the last stanza, there are lots of programs that find bugs in programs (I worked on one for my Master’s project). The Terminator Project shows that it is possible to solve the HALTING problem for many complex programs also. But, as Turing proved, it is impossible to produce an algorithm that solves it correctly for all input programs. So, these tools can find some bugs in some programs, but there is no program that can find all bugs in all programs.


Fall 2011

Register
Login

Help Schedule

(all in Davis Commons, except Dave's office hours in Rice 507)
Sundays, 1-6pm (Valerie/Joseph/Kristina)
Mondays, noon-1:30pm (Kristina)
Mondays, 1:15-2:00pm (Dave, Rice 507)
Tuesdays, 11am-noon (Dave, Rice 507)
Tuesdays, 5-8pm (Valerie/Jonathan)
Wednesdays, 5-6:30pm (Jiamin)
Thursdays, 9:45-11am (Dave, Rice 507)
Thursdays, 1-2:30pm (Joseph)
Thursdays, 4:30-7:30pm (Jonathan/Jiamin)
Fridays, noon-1:30pm (Peter)

Recent Posts

  • Course Wrap-Up
  • Class 41: The Cake of Computing
  • PS8 Submissions
  • Class 40: GuardRails, Big Data, and Secure Computation
  • Exam 2 Solutions

Recent Comments

  • David Evans on Problem Sets
  • jacob777 on Problem Sets
  • Prof. K.R. Chowdhary on Class 41: The Cake of Computing
  • Anon on Exams
  • Anon on Exams

Index

  • Classes
    • Class 1: Computing
    • Class 2: Language
    • Class 3: Rules of Evaluation
    • Class 4: Constructing Procedures
    • Class 5: Procedures Practice
    • Class 6: Programming with Data
    • Class 7: Programming with Lists
    • Class 8: Recursive List Procedures
    • Class 9: Consistent Hashing
  • Conveying Computing
  • Exams
  • Fractal Gallery
  • Guides
    • DrRacket Guide
    • Schemer’s Guide to Python
  • Problem Sets
    • Problem Set 0: Course Registration, Racket
    • Problem Set 1: Making Mosaics
      • PS1 Comments
    • Problem Set 2: Sequence Alignment
      • PS2 Comments
    • Problem Set 3: Limning L-System Fractals
      • PS3 – Comments
    • Problem Set 4: Constructing Colossi
      • PS4 – Comments
    • Problem Set 5: Wahoo! Auctions
      • PS5 Comments
    • Problem Set 6: Adventures in Charlottansville
      • PS6 Comments
    • Problem Set 7: Charming Snakes with Mesmerizing Memoizers
      • PS7 Comments
      • PS7 Responses
    • Problem Set 8 (Part 2): Typed Aazda
    • Problem Set 8: From Aazda to aaZda (Part 1)
      • PS8 Part 1 Comments
  • Syllabus
    • Course Pledge
  • Using These Materials

RSS BA Computer Science

RSS Jefferson’s Wheel

  • MICO Challenge in Membership Inference
  • Voice of America interview on ChatGPT
  • Uh-oh, there's a new way to poison code models
  • Trojan Puzzle attack trains AI assistants into suggesting malicious code

RSS Hacker News

  • Epic’s new motion-capture animation tech has to be seen to be believed
  • Hindenburg Research Outs Block Inc as Fraud
  • Mathematicians discover shape that can tile a wall and never repeat
  • F-150 Lightning Recall Due to SK Cells
  • Nvidia Tackles Chipmaking Process, Claims 40X Speed Up with CuLitho

RSS Babbage

  • And it’s goodnight from us
  • Why 10, not 9, is better than 8
  • Future, imperfect and tense
  • The paperless dilemma
  • How to judge a ’bot; why it’s covered
cs1120 | RSS | Comments RSS | Book | Using These Materials | Login | Admin | Powered by Wordpress