CSE 311: Foundations of Computing

Slides:



Advertisements
Similar presentations
Lecture 19. Reduction: More Undecidable problems
Advertisements

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.
Finite Automata Great Theoretical Ideas In Computer Science Anupam Gupta Danny Sleator CS Fall 2010 Lecture 20Oct 28, 2010Carnegie Mellon University.
CPSC 411, Fall 2008: Set 12 1 CPSC 411 Design and Analysis of Algorithms Set 12: Undecidability Prof. Jennifer Welch Fall 2008.
Lecture 8 Recursively enumerable (r.e.) languages
Decidable and undecidable problems deciding regular languages and CFL’s Undecidable problems.
1 CSE 417: Algorithms and Computational Complexity Winter 2001 Lecture 15 Instructor: Paul Beame.
Fall 2006Costas Busch - RPI1 Non-Deterministic Finite Automata.
1 CSE 417: Algorithms and Computational Complexity Winter 2001 Lecture 18 Instructor: Paul Beame.
Costas Busch - LSU1 Non-Deterministic Finite Automata.
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.
1 Unit 1: Automata Theory and Formal Languages Readings 1, 2.2, 2.3.
MA/CSSE 474 Theory of Computation More Reduction Examples Non-SD Reductions.
Great Theoretical Ideas in Computer Science for Some.
Great Theoretical Ideas in Computer Science about AWESOME Some Generating Functions Probability Infinity Computability With Alan! (not Turing) Mind-
TRANSITION DIAGRAM BASED LEXICAL ANALYZER and FINITE AUTOMATA Class date : 12 August, 2013 Prepared by : Karimgailiu R Panmei Roll no. : 11CS10020 GROUP.
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.
CSE 311 Foundations of Computing I Lecture 27 FSM Limits, Pattern Matching Autumn 2012 CSE
 2005 SDU Lecture13 Reducibility — A methodology for proving un- decidability.
CS 208: Computing Theory Assoc. Prof. Dr. Brahim Hnich Faculty of Computer Sciences Izmir University of Economics.
CSE 311 Foundations of Computing I Lecture 28 Computability: Other Undecidable Problems Autumn 2011 CSE 3111.
CSE 311 Foundations of Computing I Lecture 25 Pattern Matching, Cardinality, Computability Spring
CSE 311: Foundations of Computing Fall 2013 Lecture 26: Pattern matching, cardinality.
CSE 311: Foundations of Computing Fall 2014 Lecture 27: Cardinality.
CSE 311 Foundations of Computing I Lecture 24 FSM Limits, Pattern Matching Autumn 2011 CSE 3111.
Finite Automata Great Theoretical Ideas In Computer Science Victor Adamchik Danny Sleator CS Spring 2010 Lecture 20Mar 30, 2010Carnegie Mellon.
CompSci Today’s Topics Computer Science Noncomputability Upcoming Special Topic: Enabled by Computer -- Decoding the Human Genome Reading Great.
Recursively Enumerable and Recursive Languages. Definition: A language is recursively enumerable if some Turing machine accepts it.
Fall 2013 Lecture 27: Turing machines and decidability CSE 311: Foundations of Computing.
CSE 311: Foundations of Computing Fall 2014 Lecture 28: Undecidability.
Decidability and Undecidability Proofs
CSE 105 theory of computation
Introduction to Computing Science and Programming I
CSE 105 theory of computation
CSE 311 Foundations of Computing I
CSE 311 Foundations of Computing I
CSE 105 theory of computation
CS154, Lecture 7: Turing Machines.
CSE 105 theory of computation
HIERARCHY THEOREMS Hu Rui Prof. Takahashi laboratory
Intro to Theory of Computation
CSE 105 theory of computation
Busch Complexity Lectures: Undecidable Problems (unsolvable problems)
CSE 105 theory of computation
CS154, Lecture 8: Undecidability, Mapping Reductions
CS154, Lecture 8: Undecidability, Mapping Reductions
More on DFA minimization and DFA equivalence
Non-Deterministic Finite Automata
CSE 311 Foundations of Computing I
Decidable Languages Costas Busch - LSU.
Proposed in Turing’s 1936 paper
CSE 311 Foundations of Computing I
CSE 105 theory of computation
Instructor: Aaron Roth
CSE 311: Foundations of Computing
Instructor: Aaron Roth
CSE 105 theory of computation
CSE 105 theory of computation
Automata, Grammars and Languages
More Undecidable Problems
Algorithms CSCI 235, Spring 2019 Lecture 37 The Halting Problem
MA/CSSE 474 Theory of Computation
Intro to Theory of Computation
CSE 105 theory of computation
CSE 105 theory of computation
Presentation transcript:

CSE 311: Foundations of Computing Fall 2014 Lecture 26: Pattern matching, Halting problem

DFAs ≡ Regular Expressions highlights DFAs ≡ Regular Expressions No need to know details of NFAs→RegExpressions Method for proving no DFAs for languages e.g. {0n1n : n ≥ 0}, {Binary palindromes}

pattern matching Given Find a string, s, of n characters a pattern, p, of m characters usually m<<n Find all occurrences of the pattern p in the string s Obvious algorithm: try to see if p matches at each of the positions in s stop at a failed match and try the next position

string s = x y x x y x y x y y x y x y x y y x y x y x x pattern p = x y x y y x y x y x x

string s = x y x x y x y x y y x y x y x y y x y x y x x

string s = x y x x y x y x y y x y x y x y y x y x y x x

string s = x y x x y x y x y y x y x y x y y x y x y x x

string s = x y x x y x y x y y x y x y x y y x y x y x x

string s = x y x x y x y x y y x y x y x y y x y x y x x

string s = x y x x y x y x y y x y x y x y y x y x y x x

string s = x y x x y x y x y y x y x y x y y x y x y x x

string s = x y x x y x y x y y x y x y x y y x y x y x x

string s = x y x x y x y x y y x y x y x y y x y x y x x

string s = x y x x y x y x y y x y x y x y y x y x y x x

string s = x y x x y x y x y y x y x y x y y x y x y x x

string s = x y x x y x y x y y x y x y x y y x y x y x x

string s = x y x x y x y x y y x y x y x y y x y x y x x x y x y x x y Worst-case time O(mn) x y x x x x y x y y x x y x y y x y x y x x

string s = x y x x y x y x y y x y x y x y y x y x y x x x y x y Lots of wasted work x y x y y x y x y x x

better pattern matching via finite automata Build a DFA for the pattern (preprocessing) of size O(m) Keep track of the ‘longest match currently active’ The DFA will have only m+1 states Run the DFA on the string n steps Obvious construction method for DFA will be O(m2) but can be done in O(m) time. Total O(m+n) time

building a DFA for the pattern pattern p=x y x y y x y x y x x

preprocessing the pattern pattern p=x y x y y x y x y x x

preprocessing the pattern pattern p=x y x y y x y x y x x

preprocessing the pattern pattern p=x y x y y x y x y x x

preprocessing the pattern pattern p=x y x y y x y x y x x

generalizing Can search for arbitrary combinations of patterns Not just a single pattern Build NFA for pattern then convert to DFA ‘on the fly’. Compare DFA constructed above with subset construction for the obvious NFA.

Languages and Machines! All Are there things Java can’t do? Java Context-Free Binary Palindromes Regular DFA NFA Regex 0* Finite {001, 10, 12}

An Assignment Too Simple for 142. Students should write a Java program that… Prints “Hello” to the console Eventually exits GradeIt, PracticeIt, etc. need to grade the students. How do we write that grading program?

Follow Up Question What does this program do? _(__,___,____){___/__<=1?_(__,___+1,___ _):!(___%__)?_(__,___+1,0):___%__==___ / __&&!____?(printf("%d\t",___/__),_(__,_ __+1,0)):___%__>1&&___%__<___/__?_( __,1+ ___,____+!(___/__%(___%__))):___<__*__ ?_(__,___+1,____):0;}main(){_(100,0,0);}

Follow Up Question What does this program do? …on n=5? public static void collatz(n) { if (n == 1) { return 1; } if (n % 2 == 0) { return collatz(n/2) else { return collatz(3n + 1) What does this program do? …on n=5? …on n=10000000000000000001?

Sneak Peak It turns out the simple autograder is impossible to write… And we’ll prove it!

Some Notation and Starting Ideas We’re going to be talking about Java code a lot. CODE(P) will mean “the code of the program P” So, consider the following function: public String P(String x) { return new String(Arrays.sort(x.toCharArray()); } What is P(CODE(P))? “((()))..;AACPSSaaabceeggghiiiilnnnnnooprrrrrrrrrrrsssttttttuuwxxyy{}”

The Halting Problem Given: - CODE(P) for any program P - input x Output: true if P halts on input x false if P does not halt on input x

The Halting Problem Given: - CODE(P) for any program P - input x Output: true if P halts on input x false if P does not halt on input x It turns out that it isn’t possible to write a program that solves the Halting Problem.

Proof by contradiction Suppose that H is a Java program that solves the Halting problem. Then we can write this program: public static void D(x) { if (H(x,x) == true) { while (true); /* don’t halt */ } else { return; /* halt */ Does D(CODE(D)) halt?

public static void D(x) { if (H(x,x) == true) { while (true); /* don’t halt */ } else { return; /* halt */ Does D(CODE(D)) halt? H solves the halting problem implies that H(CODE(D),x) is true iff D(x) halts, H(CODE(D),x) is false iff not Suppose D(CODE(D)) halts. Then, we must be in the second case of the if. So, H(CODE(D), CODE(D)) is false Which means D(CODE(D)) doesn’t halt Suppose D(CODE(D)) doesn’t halt. Then, we must be in the first case of the if. So, H(CODE(D), CODE(D)) is true. Which means D(CODE(D)) halts.

public static void D(x) { if (H(x,x) == true) { while (true); /* don’t halt */ } else { return; /* halt */ Does D(CODE(D)) halt? H solves the halting problem implies that H(CODE(D),x) is true iff D(x) halts, H(CODE(D),x) is false iff not Suppose D(CODE(D)) halts. Then, we must be in the second case of the if. So, H(CODE(D), CODE(D)) is false Which means D(CODE(D)) doesn’t halt Suppose D(CODE(D)) doesn’t halt. Then, we must be in the first case of the if. So, H(CODE(D), CODE(D)) is true. Which means D(CODE(D)) halts.

public static void D(x) { if (H(x,x) == true) { while (true); /* don’t halt */ } else { return; /* halt */ Does D(CODE(D)) halt? H solves the halting problem implies that H(CODE(D),x) is true iff D(x) halts, H(CODE(D),x) is false iff not Suppose D(CODE(D)) halts. Then, we must be in the second case of the if. So, H(CODE(D), CODE(D)) is false Which means D(CODE(D)) doesn’t halt Suppose D(CODE(D)) doesn’t halt. Then, we must be in the first case of the if. So, H(CODE(D), CODE(D)) is true. Which means D(CODE(D)) halts.

public static void D(x) { if (H(x,x) == true) { while (true); /* don’t halt */ } else { return; /* halt */ Does D(CODE(D)) halt? H solves the halting problem implies that H(CODE(D),x) is true iff D(x) halts, H(CODE(D),x) is false iff not Suppose D(CODE(D)) halts. Then, we must be in the second case of the if. So, H(CODE(D), CODE(D)) is false Which means D(CODE(D)) doesn’t halt Suppose D(CODE(D)) doesn’t halt. Then, we must be in the first case of the if. So, H(CODE(D), CODE(D)) is true. Which means D(CODE(D)) halts. Contradiction!

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

What’s next? We showed: If some “hypothetical” subroutine H existed that solved the Halting Problem then it would let us build a program D that cannot possibly exist We will use the same idea to show that programs solving other problems are impossible, but we now will be able to use that H cannot exist A key piece of the proof was considering what a program does when given its own code as input This was inspired by a method to compare the sizes of infinite sets call diagonalization that we will study next class