CSE 311: Foundations of Computing

Slides:



Advertisements
Similar presentations
David Evans cs302: Theory of Computation University of Virginia Computer Science Lecture 17: ProvingUndecidability.
Advertisements

Lecture 19. Reduction: More Undecidable problems
CS 461 – Nov. 9 Chomsky hierarchy of language classes –Review –Let’s find a language outside the TM world! –Hints: languages and TM are countable, but.
1 COMP 382: Reasoning about algorithms Unit 9: Undecidability [Slides adapted from Amos Israeli’s]
1 CSC3130 Formal Languages and Automata Theory Tutorial 9 Undecidable Problem KN Hung SHB 1026.
Nathan Brunelle Department of Computer Science University of Virginia Theory of Computation CS3102 – Spring 2014 A tale.
The Halting Problem Sipser 4.2 (pages ).
CPSC 411, Fall 2008: Set 12 1 CPSC 411 Design and Analysis of Algorithms Set 12: Undecidability Prof. Jennifer Welch Fall 2008.
Fall 2003Costas Busch - RPI1 Decidability. Fall 2003Costas Busch - RPI2 Recall: A language is decidable (recursive), if there is a Turing machine (decider)
1 Undecidability Andreas Klappenecker [based on slides by Prof. Welch]
1 CSE 417: Algorithms and Computational Complexity Winter 2001 Lecture 19 Instructor: Paul Beame.
1 CSE 417: Algorithms and Computational Complexity Winter 2001 Lecture 18 Instructor: Paul Beame.
Lecture 27UofH - COSC Dr. Verma 1 COSC 3340: Introduction to Theory of Computation University of Houston Dr. Verma Lecture 27.
Fall 2006Costas Busch - RPI1 Undecidable Problems (unsolvable problems)
1 Introduction to Computability Theory Lecture11: The Halting Problem Prof. Amos Israeli.
Halting Problem. Background - Halting Problem Common error: Program goes into an infinite loop. Wouldn’t it be nice to have a tool that would warn us.
Cs3102: Theory of Computation Class 18: Proving Undecidability Spring 2010 University of Virginia David Evans.
CSE 311 Foundations of Computing I Lecture 30 Computability: Other Undecidable Problems Autumn 2012 CSE 3111.
MA/CSSE 474 Theory of Computation More Reduction Examples Non-SD Reductions.
Great Theoretical Ideas in Computer Science for Some.
Halting Problem Introduction to Computing Science and Programming I.
CSE 311 Foundations of Computing I Lecture 26 Computability: Turing machines, Undecidability of the Halting Problem Spring
CSE 311 Foundations of Computing I Lecture 29 Computability: Turing machines, Undecidability of the Halting Problem Autumn 2012 CSE 3111.
Halting Problem and TSP Wednesday, Week 8. Background - Halting Problem Common error: Program goes into an infinite loop. Wouldn’t it be nice to have.
CS 3813: Introduction to Formal Languages and Automata Chapter 12 Limits of Algorithmic Computation These class notes are based on material from our textbook,
 2005 SDU Lecture13 Reducibility — A methodology for proving un- decidability.
Computability Universal Turing Machine. Countability. Halting Problem. Homework: Show that the integers have the same cardinality (size) as the natural.
Computation Motivating questions: What does “computation” mean? What are the similarities and differences between computation in computers and in natural.
CSE 311 Foundations of Computing I Lecture 28 Computability: Other Undecidable Problems Autumn 2011 CSE 3111.
CSE 311: Foundations of Computing Fall 2014 Lecture 27: Cardinality.
Donghyun (David) Kim Department of Mathematics and Computer Science North Carolina Central University 1 Chapter 4 Decidability Some slides are in courtesy.
1 Chapter 9 Undecidability  Turing Machines Coded as Binary Strings  Universal Turing machine  Diagonalizing over Turing Machines  Problems as Languages.
Undecidability and The Halting Problem
CompSci Today’s Topics Computer Science Noncomputability Upcoming Special Topic: Enabled by Computer -- Decoding the Human Genome Reading Great.
THE HALTING PROBLEM - PROOF. Review  What makes a problem decidable?  3 properties of an efficient algorithm?  What is the meaning of “complete”, “mechanistic”,
CSC 3130: Automata theory and formal languages Andrej Bogdanov The Chinese University of Hong Kong Undecidable.
Recursively Enumerable and Recursive Languages. Definition: A language is recursively enumerable if some Turing machine accepts it.
Decidability.
Fall 2013 Lecture 27: Turing machines and decidability CSE 311: Foundations of Computing.
CSE 311: Foundations of Computing Fall 2014 Lecture 28: Undecidability.
Complexity nschank Source: xkcd.com/1425.
The Acceptance Problem for TMs
Introduction to Computing Science and Programming I
CIS Automata and Formal Languages – Pei Wang
Automata, Grammars and Languages
CSE 311 Foundations of Computing I
Undecidable Problems Costas Busch - LSU.
CS154, Lecture 11: Self Reference, Foundation of Mathematics
Reducibility The Chinese University of Hong Kong Fall 2010
CS154, Lecture 10: Rice’s Theorem, Oracle Machines
Busch Complexity Lectures: Undecidable Problems (unsolvable problems)
CSE 105 theory of computation
CS154, Lecture 8: Undecidability, Mapping Reductions
Andreas Klappenecker [based on slides by Prof. Welch]
CSCE 411 Design and Analysis of Algorithms
CS154, Lecture 10: Rice’s Theorem, Oracle Machines
CS154, Lecture 8: Undecidability, Mapping Reductions
CSE 311 Foundations of Computing I
Decidable Languages Costas Busch - LSU.
Halting Problem.
CSE 311: Foundations of Computing
Instructor: Aaron Roth
CS154, Lecture 11: Self Reference, Foundation of Mathematics
Instructor: Aaron Roth
Automata, Grammars and Languages
More Undecidable Problems
CSE 105 theory of computation
Algorithms CSCI 235, Spring 2019 Lecture 37 The Halting Problem
Lecture 4: Unsolvable Problems
Intro to Theory of Computation
Presentation transcript:

CSE 311: Foundations of Computing Fall 2013 Lecture 28: Undecidability

highlights Turing machine = Finite control + Recording Medium + Focus of attention Recording Medium Finite Control: program P input x _ 1 _ 1 s1 (1,s3) (1,s2) (0,s2) s2 (H,s3) (R,s1) s3 (R,s3) _ 1 …… output _ 1

P highlights The Universal Turing Machine U Takes as input: (<P>,x) where <P> is the code of a program and x is an input string Simulates P on input x Same as a Program Interpreter P input x output P(x) x output U P(x) P

highlights Program P input x _ 1 s1 (1,s3) (1,s2) (0,s2) s2 (H,s3) 1 s1 (1,s3) (1,s2) (0,s2) s2 (H,s3) (R,s1) s3 (R,s3) _ 1 Universal TM U Program code <P> input x _ 1 ( ) s 2 3 … s1 s2 ( 1 , s 3 ) . . . . _ output ( 1 , s 3 ) . . . . _

programs about program properties The Universal TM takes a program code <P> as input, and an input x, and interprets P on x Step by step by step by step… Can we write a TM that takes a program code <P> as input and checks some property of the program? Does P ever return the output “ERROR”? Does P always return the output “ERROR”? Does P halt on input x?

halting problem Given: The code of a program P and an input x for P, i.e. given (<P>,x) Output: 1 if P halts on input x 0 if P does not halt on input x Theorem (Turing): There is no program that solves the halting problem. “The halting problem is undecidable”

proof by contradiction Suppose that H is a Turing machine that solves the Halting problem Function D(x): if H(x,x)=1 then while (true); /* loop forever */ else no-op; /* do nothing and halt */ endif What does D do on input <D>? Does it halt?

⇔ H outputs 1 on input (<D>,<D>) Does D halt on input <D>? Function D(x): if H(x,x)=1 then while (true); /* loop forever */ else no-op; /* do nothing and halt */ endif D halts on input <D> ⇔ H outputs 1 on input (<D>,<D>) [since H solves the halting problem and so H(<D>,x) outputs 1 iff D halts on input x] ⇔ D runs forever on input <D> [since D goes into an infinite loop on x iff H(x,x)=1]

that’s it! We proved that there is no computer program that can solve the Halting Problem. This tells us that there is no compiler that can check our programs and guarantee to find any infinite loops they might have

SCOOPING THE LOOP SNOOPER A proof that the Halting Problem is undecidable by Geoffrey K. Pullum (U. Edinburgh) No general procedure for bug checks succeeds. Now, I won’t just assert that, I’ll show where it leads: I will prove that although you might work till you drop, you cannot tell if computation will stop.   For imagine we have a procedure called P that for specified input permits you to see whether specified source code, with all of its faults, defines a routine that eventually halts. You feed in your program, with suitable data, and P gets to work, and a little while later (in finite compute time) correctly infers whether infinite looping behavior occurs...

SCOOPING THE LOOP SNOOPER ... Here’s the trick that I’ll use -- and it’s simple to do. I’ll define a procedure, which I will call Q, that will use P’s predictions of halting success to stir up a terrible logical mess. And this program called Q wouldn’t stay on the shelf; I would ask it to forecast its run on itself. When it reads its own source code, just what will it do? What’s the looping behavior of Q run on Q? Full poem at: http://www.lel.ed.ac.uk/~gpullum/loopsnoop.html

another view Suppose that there is a program H that computes the answer to the Halting Problem We will build a table with a row for each program (just like we did for uncountability of reals) If the supposed program H exists then the D program we constructed as before will exist and so be in the table But D must have entries like the “flipped diagonal” D can’t possibly be in the table. Only assumption was that H exists. That must be false.

Some possible inputs x P1 P2 P3 P4 P5 P6 P7 P8 P9 . 0 1 1 0 1 1 1 0 0 0 1 ... 1 1 0 1 0 1 1 0 1 1 1 ... 1 0 1 0 0 0 0 0 0 0 1 ... 0 1 1 0 1 0 1 1 0 1 0 ... 0 1 1 1 1 1 1 0 0 0 1 ... 1 1 0 0 0 1 1 0 1 1 1 ... 1 0 1 1 0 0 0 0 0 0 1 ... 0 1 1 1 1 0 1 1 0 1 0 ... . . . . . . . . . . . . programs P (P,x) entry is 1 if program P halts on input x and 0 if it runs forever

Some possible inputs x P1 P2 P3 P4 P5 P6 P7 P8 P9 . 0 1 1 0 1 1 1 0 0 0 1 ... 1 1 0 1 0 1 1 0 1 1 1 ... 1 0 1 0 0 0 0 0 0 0 1 ... 0 1 1 0 1 0 1 1 0 1 0 ... 0 1 1 1 1 1 1 0 0 0 1 ... 1 1 0 0 0 1 1 0 1 1 1 ... 1 0 1 1 0 0 0 0 0 0 1 ... 0 1 1 1 1 0 1 1 0 1 0 ... . . . . . . . . . . . . programs P (P,x) entry is 1 if program P halts on input x and 0 if it runs forever

Some possible inputs x D behaves like flipped diagonal 1 P1 P2 P3 P4 <P1> <P2> <P3> <P4> <P5> <P6> .... 1 P1 P2 P3 P4 P5 P6 P7 P8 P9 . 0 1 1 0 1 1 1 0 0 0 1 ... 1 1 0 1 0 1 1 0 1 1 1 ... 1 0 1 0 0 0 0 0 0 0 1 ... 0 1 1 0 1 0 1 1 0 1 0 ... 0 1 1 1 1 1 1 0 0 0 1 ... 1 1 0 0 0 1 1 0 1 1 1 ... 1 0 1 1 0 0 0 0 0 0 1 ... 0 1 1 1 1 0 1 1 0 1 0 ... . . . . . . . . . . . . programs P (P,x) entry is 1 if program P halts on input x and 0 if it runs forever

recall: code for D assuming subroutine H that solves recall: code for D assuming subroutine H that solves the halting problem Function D(x): if H(x,x)=1 then while (true); /* loop forever */ else no-op; /* do nothing and halt */ endif If D existed it would have a row different from every row of the table D can’t be a program so H cannot exist!

halting problem x 1 if P(x) halts 0 if P(x) does not halt H P HALT

that’s it! We proved that there is no computer program that can solve the Halting Problem. This tells us that there is no compiler that can check our programs and guarantee to find any infinite loops they might have The full story is even worse

the “always halts” problem Given: <Q>, the code of a program Q Output: 1 if Q halts on every input 0 if not. Claim: the “always halts” problem is undecidable Proof idea: Show we could solve the Halting Problem if we had a solution for the “always halts” problem. No program solving for Halting Problem exists  no program solving the “always halts” problem exists

the “always halts” problem x HALT 1 if P(x) halts 0 if P(x) does not halt H P Suppose we had a TM A for the always halts problem x Convert Q 1 if P(x) halts 0 if P(x) does not halt A P … a←x … Read(a)

the “always ERROR” problem Given: <R>, the code of a program R Output: 1 if R always prints ERROR 0 if R does not always print ERROR

the “always ERROR” problem HALT 1 if Q always halts 0 if Q does not always halt Q A Suppose we had a TM E for the ERROR problem Convert’ R 1 if Q always halts 0 if Q does not always halt E Q Q’s code … end of Q Print ERROR Q’s code … end of Q

pitfalls Not every problem on programs is undecidable! Which of these is decidable? Input <P> and x Output: 1 if P prints “ERROR” on x after less than 100 steps 0 otherwise Input <P> and x Output: 1 if P prints “ERROR” on x after more than 100 steps 0 otherwise