CS 3261 Computability Course Summary

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 hw’s. • I will hold daily OH’s 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: • What sorts of problems can be solved by each computer model? • What languages does each model accept? • What are the practical limits on what a computer can do?

6. 2 Abstract Machine ModelsDFA’s DFA’s model computers with strictly bounded memory. b a b 1 a a,b 3

7. 2 Abstract Machine ModelsDFA’s Q: What’s the accepted language? b a b 1 a a,b 3

8. 2 Abstract Machine ModelsDFA’s A: a*b+ b a b 1 a a,b 3

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

10. 2 Abstract Machine ModelsNFA’s Q: What’s the accepted language? b a a 1 a a,b 3

11. 2 Abstract Machine ModelsNFA’s A: a+b* b a a 1 a a,b 3

12. 3 Abstract Machine ModelsPDA’s By allowing a pushdown stack, increase flexibility and accept more languages. a,eX b,Xe e,ee 1 2 e,e$ e,$e 0

13. 3 Abstract Machine ModelsPDA’s Q: What’s the accepted language? a,eX b,Xe e,ee 1 2 e,e$ e,$e 0

14. 3 Abstract Machine ModelsPDA’s A: {an bn | n 0} a,eX b,Xe e,ee 1 2 e,e$ e,$e 0

15. Abstract Machine ModelsTM’s By allowing a read-write tape, amazingly get most general possible computer model! XR XR 1R 1 2 1X,R 1$,R L acc 0 $R $L 5 4 3 1L 1L XL 1|XL XL

16. Abstract Machine ModelsTM’s Q: What’s the accepted language? XR XR 1R 1 2 1X,R 1$,R L acc 0 $R $L 5 4 3 1L 1L XL 1|XL XL

17. Abstract Machine ModelsTM’s A: Unary powers of 2. XR XR 1R 1 2 1X,R 1$,R L acc 0 $R $L 5 4 3 1L 1L XL 1|XL 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 e’s) • Context free: (didn’t study any) • “Compilers”: Input is a string, output is a parse-tree (or even executable code) • Turing Machines: • I/O TM’s

19. Robust Formal Language Classes Turns out these models are very robust • Many equivalent ways to generate same classes: • Regular languages • FA’s, NFA’s, Regular Expressions, Right-Linear Grammars • Context Free Languages • PDA’s, Context Free Grammars • Recognizable languages –Church-Turing thesis • TM’s, k-tape machines, k-track machinesNTM’s, Queue Machines, 2-Stack PDA’s, RAM’s, Unrestricted Grammars • Complexity classes P and NP • For NP: Poly. NTM’s, 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 that’s seems like regular language. Could then show that it isn’t 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:

23. Language Design

24. Language Class Hierarchy All REC = accepted by TM DEC = decided by TM Context Free Deterministic Context Free Regular = accepted by FA’s Finite languages

25. KnownComplexity Hierarchy Get the following RAM hierarchy diagram: REC DEC EQREX P TIME(n3) CFL REG TIME(n)

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

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

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!