# 1 CS 3261 Computability Course Summary Zeph Grunschlag.

## Presentation on theme: "1 CS 3261 Computability Course Summary Zeph Grunschlag."— Presentation transcript:

1 CS 3261 Computability Course Summary Zeph Grunschlag

2 Announcements Last hw due now Look out for a final exam practice problems coming out over the weekend I will hold final review session on Tuesday 12/11, 3-5 pm, 833 Mudd. Pick-up final hws. I will hold daily OHs next week and Monday 12/17, 12:00-1:30 except Thursday, 12/13 Final exam: Tuesday 12/18, 9-12, 833 Mudd

3 Computability Concepts AIM: Reduce Computer Science to its bare theoretical essentials. APPROACH: Algorithmic Problems Formal Languages

4 Formal Languages Fundamental insight of Theoretical CS: By understanding how formal languages can be computed, will understand how any algorithmic problem can be solved. Algorithmic input/output problems involve creating procedures for procuring outputs from given inputs. Can be turned into a formal languages by re-writing as yes/no questions. EG: Find the shortest path… becomes Is there a path shorter than…

5 Computability Concepts AIM: Reduce Computer Science to its bare theoretical essentials. Algorithmic Problems Formal Languages Computers Graph based machine models Questions to investigate: 1) What sorts of problems can be solved by each computer model? 2) What languages does each model accept? 3) What are the practical limits on what a computer can do?

6 Abstract Machine Models DFAs DFAs model computers with strictly bounded memory. 1 3 2 a b b a a,b

7 Abstract Machine Models DFAs Q: Whats the accepted language? 1 3 2 a b b a a,b

8 Abstract Machine Models DFAs A: a*b + 1 3 2 a b b a a,b

9 Abstract Machine Models NFAs Nondeterminism is a powerful concept. Often 1 st view of a problem is nondeterministic. 1 3 2 a a b a a,b

10 Abstract Machine Models NFAs Q: Whats the accepted language? 1 3 2 a a b a a,b

11 Abstract Machine Models NFAs A: a + b* 1 3 2 a a b a a,b

12 Abstract Machine Models PDAs By allowing a pushdown stack, increase flexibility and accept more languages. 12 3 a, X b,X 0 \$ \$

13 Abstract Machine Models PDAs Q: Whats the accepted language? 12 3 a, X b,X 0 \$ \$

14 Abstract Machine Models PDAs A: {a n b n | n 0} 12 3 a, X b,X 0 \$ \$

15 Abstract Machine Models TMs By allowing a read-write tape, amazingly get most general possible computer model! 12 X R 0 1 \$,R L acc 34 X L \$ L 1 L \$ R 1 X,R 1 R X R X L 5 1 L 1|X L

16 Abstract Machine Models TMs Q: Whats the accepted language? 12 X R 0 1 \$,R L acc 34 X L \$ L 1 L \$ R 1 X,R 1 R X R X L 5 1 L 1|X L

17 Abstract Machine Models TMs A: Unary powers of 2. 12 X R 0 1 \$,R L acc 34 X L \$ L 1 L \$ R 1 X,R 1 R X R X L 5 1 L 1|X L

18 I/O Versions Each class of languages has its own I/O version. Regular: Finite State Transducers More powerful models exist (e.g. with s) Context free: (didnt study any) Compilers: Input is a string, output is a parse-tree (or even executable code) Turing Machines: I/O TMs

19 Robust Formal Language Classes Turns out these models are very robust Many equivalent ways to generate same classes: Regular languages FAs, NFAs, Regular Expressions, Right-Linear Grammars Context Free Languages PDAs, Context Free Grammars Recognizable languages –Church-Turing thesis TMs, k-tape machines, k-track machines NTMs, Queue Machines, 2-Stack PDAs, RAMs, Unrestricted Grammars Complexity classes P and NP For NP: Poly. NTMs, Poly. Verifiers, Poly. Proofs We learned algorithms for converting between most of the different views Language classes closed under natural operations.

20 System Design Often computer system creation involves designing a formal language to describe system communication. Components receive communication streams and have to effect actions based on these. Computability theory can help drive design at a high level. EG: Might come up with a communication stream thats seems like regular language. Could then show that it isnt using pumping lemma. With this knowledge, final design tweaks original to obtain a regular language and therefore DFA based ultra-fast and super-reliable system components!

21 Negative Examples As above, it is very important to be able to tell when particular languages cannot be accepted by a certain model of computation. We have several tools at our disposal: Irregularity: pumping lemma (PL) Non-Context-Freeness: CFPL Undecidability: Reductions from undecidable languages Intractability: Poly-time reduction from NP- hard languages

22 System Design Learned useful concepts that can help modularization when designing systems. Often can express a language as a union, intersection, negation, concatenation or Kleene-* of simpler languages. More complex language may be put together by using simple components along with off the shelf reconstruction techniques:

Language Design Class Negate Concat. Kleene- * DFAs Cartesian Product Accept Non-accepts NFAs Parallel Cartesian Product SerialLoop PDAs Parallel SerialLoop Deciders Run in parallel Accept Non-accepts Break string up Recursive algorithm Recognizers Run in parallel

24 Language Class Hierarchy All REC = accepted by TM DEC = decided by TM Context Free Deterministic Context Free Regular = accepted by FAs Finite languages

25 Known Complexity Hierarchy Get the following RAM hierarchy diagram: REC DEC P TIME(n) CFL TIME(n 3 ) REG EQ REX

26 Unknown Complexity Hierarchy Decidable NP NP but not NP-hard P Finite languages Does anything exist here?

27 Conjectured Hierarchy Inside of DEC most conjecture: DEC NP P co-NP NP complete PRIME SAT

28 Follow-ups to Computability Related Electives: Analysis of Algorithms 4231 (fall) Computational Complexity 4236 (spring) Cryptography –generic course no. 4995 (this Spring with Michael Rabin!!!) Courses Requiring Computability: Programming Languages and Translators 4115 (every semester) Compilers 4117 (this Spring with Al Aho!!!) Portions of several other courses

29 Final Remarks With the horrors at the beginning of the semester….

30 Final Remarks Thanks for putting in the effort and helping make this my best semester thus far!