1. CIS 260 Mathematical Foundations of Computer Science

2. Course Staff Instructor Ani Nenkova nenkova@seas.upenn.edu Levine 505 TAs Joy Xu joyyxu@wharton.upenn.edu Gaoxiang (Gary) Hu gaoxiang@seas.upenn.edu Shilpi Bose sbose@seas.upenn.edu

3. Lectures and recitations Lectures TT 1:30—3:00 Recitations on Fridays 12—1(Moore 212) Joy 1—2 (Towne 305) Gary 2—3 (Towne 305) Shilpi For both lectures and recitations, regular attendance is expected. Necessary in order to insure you keep up with the class

4. Cancelled recitation sections Please note: If you are still signed up for section 203 or 204, you would have to choose another section. These two have been cancelled! No recitations tomorrow (Jan 16)

5. Office hours Monday 4:30—6 Joy Friday 2—3 Gary Friday 3—4 Shilpi –Locations to be determined by next week Ani: Wed 10am—11am in Levine 505

6. Website and bulletin board Will be up by early next week Use the bulletin board! If you have problems with understanding the wording of homework problems, it is likely others in the class will have the exact same question. Post to the board. DO NOT send partial solutions!

7. Grades 10 HW assignments: 20% of the grade 2 exams: 25% of the grade Final: 30% of the grade Extra credit for class and recitations participation will be assigned and used to decide the grade when your scores fall in between grade “bins”

8. Late policy All homeworks have to be submitted before the end of class the day they are due No late homeworks will be accepted! You can submit early if for some reason you cannot make it to class that day

9. Midterms Midetrm 1: Feb 19 Midterm 2: Mar 26 If there are any holidays or other days that need to taken into account when setting due dates, you should let me know by the END OF NEXT WEEK

10. Collaboration + Cheating You may NOT share written work You may NOT use Google, or solutions to previous years’ homework You MUST write the names of people you discussed the homework with

11. Textbook Discrete Mathematics and Its Applications, Kenneth H. Rosen, sixth edition

12. ((( ))) Feel free to ask questions

13. Bits of Wisdom on Solving Problems, Writing Proofs, and Succeeding in This Class

14. Do not panic Make sure you understand what you are being asked Make sure that you understand and remember definitions (the smallest building blocks of all we do in this class)

15. Exemplification: Try out a problem or solution on small examples. Look for the patterns.

16. A volunteer, please

17. Relax I am just going to ask you a Microsoft interview question

18. Four guys want to cross a bridge that can only hold two people at one time. It is pitch dark and they only have one flashlight, so people must cross either alone or in pairs (bringing the flashlight). Their walking speeds allow them to cross in 1, 2, 5, and 10 minutes, respectively. Is it possible for them to all cross in 17 minutes?

19. Get The Problem Right! Given any context you should double check that you read/heard it correctly! You should be able to repeat the problem back to the source and have them agree that you understand the issue

20. Four guys want to cross a bridge that can only hold two people at one time. It is pitch dark and they only have one flashlight, so people must cross either alone or in pairs (bringing the flashlight). Their walking speeds allow them to cross in 1, 2, 5, and 10 minutes, respectively. Is it possible for them to all cross in 17 minutes?

21. Intuitive, But False “10 + 1 + 5 + 1+ 2 = 19, so the four guys just can’t cross in 17 minutes” “Even if the fastest guy is the one to shuttle the others back and forth – you use at least 10 + 1 + 5 + 1 + 2 > 17 minutes”

22. Vocabulary Self-Proofing As you talk to yourself, make sure to tag assertions with phrases that denote degrees of conviction

23. Keep track of what you actually know – remember what you merely suspect “10 + 1 + 5 + 1 + 2 = 19, so it would be weird if the four guys could cross in 17 minutes” “even if we use the fastest guy to shuttle the others, they take too long.”

24. If it is possible, there must be more than one guy doing the return trips: it must be that someone gets deposited on one side and comes back for the return trip later!

25. Let’s try another one Pairs of primes separated by a single number are called prime pairs. Examples are 17 and 19. Prove that the number between a prime pair is always divisible by 6 (assuming both numbers in the pair are greater than 6). Now prove that there are no 'prime triples.'

26. How did we think about the solution? Possible answer: “I am smart and I thought about it”. Truth: “Practice! Have seen many other similar problems”.

27. In this course you will have to write a lot of proofs!

28. Think of Yourself as a (Logical) Lawyer Your arguments should have no holes, because the opposing lawyer will expose them

29. ProverVerifier Statement 1 Statement 2 Statement n … There is no sound reason to go from Statament 1 to Statement 2

30. Verifier The verifier is very thorough, (he can catch all your mistakes), but he will not supply missing details of a proof A valid complaint on his part is: I don’t understand The verifier is similar to a computer running a program that you wrote!

31. Undefined term Syntax error Writing Proofs Is A Lot Like Writing Programs You have to write the correct sequence of statements to satisfy the verifier Infinite Loop Output is not quite what was needed Errors than can occur with a program and with a proof!

32. Good code is well-commented and written in a way that is easy for other humans (and yourself) to understand Similarly, good proofs should be easy to understand. Although the formal proof does not require certain explanatory sentences (e.g., “the idea of this proof is basically X”), good proofs usually do

33. The proof verifier will not accept a proof unless every step is justified! Writing Proofs is Even Harder than Writing Programs It’s as if a compiler required your programs to have every line commented (using a special syntax) as to why you wrote that line

34. ProverVerifier A successful mathematician plays both roles in their head when writing a proof

35. Prove techniques you should avoid

36. Proof by Throwing in the Kitchen Sink (Mental Dump) The author writes down every theorem or result known to mankind and then adds a few more just for good measure When questioned later, the author correctly observes that the proof contains all the key facts needed to actually prove the result Very popular strategy on exams Believed to result in partial credit with sufficient whining. To avoid this, 10% of the question points will be given for a simple “I don’t know”.

37. Proof by Throwing in the Kitchen Sink The author writes down every theorem or result known to mankind and then adds a few more just for good measure When questioned later, the author correctly observes that the proof contains all the key facts needed to actually prove the result Very popular strategy on 251 exams Believed to result in extra credit with sufficient whining Like writing a program with functions that do almost everything you’d ever want to do (e.g. sorting integers, calculating derivatives), which in the end simply prints “hello world”

38. Proof by Example The author gives only the case n = 2 and suggests that it contains most of the ideas of the general proof. Like writing a program that only works for a few inputs

39. Proof by Cumbersome Notation Best done with access to at least four alphabets and special symbols. Helps to speak several foreign languages. Like writing a program that’s really hard to read because the variable names are confusing

40. Proof by Lengthiness An issue or two of a journal devoted to your proof is useful. Like writing 10,000 lines of code to simply print “hello world”

41. Proof by Switcharoo Concluding that p is true when both p  q and q are true If (PRINT “X is prime”) { PRIME(X); } Makes as much sense as:

42. Proof by “It is Clear That…” “It is clear that the worst case is this:” Like a program that calls a function that you never wrote

43. Proof by Assuming The Result Assume X is true Therefore, X is true! … RECURSIVE(X) {: return RECURSIVE(X); } Like a program with this code:

44. Not Covering All Cases Usual mistake in inductive proofs: A proof is given for N = 1 (base case), and another proof is given that, for any N > 2, if it is true for N, then it is true for N+1 RECURSIVE(X) { if (X > 2) { return 2*RECURSIVE(X-1); } if (X = 1) { return 1; } } Like a program with this function:

45. Incorrectly Using “By Definition” “By definition, { a n b n | n > 0 } is not a regular language” Like a program that assumes a procedure does something other than what it actually does

46. Here’s What You Need to Know… Solving Problems Always try small examples! Use enough paper Writing Proofs Writing proofs is sort of like writing programs, except every step in a proof has to be justified Be careful; search for your own errors