Making Mathematical Reasoning Fun: A Workshop for Educators

1. Making Mathematical Reasoning Fun: A Workshop for Educators Jason Hallstrom (Clemson) Joan Krone (Denison) Joseph E. Hollingsworth (IU Southeast) Murali Sitaraman(Clemson) This workshop is funded in part by NSF grant DUE-1022941

2. Part I: Overview

3. Goals • Reasoning Across the Curriculum • Not just in Discrete Math • Fundamental part of CS • Motivating example: binary search “proven” correct • Supporting Tools • Supporting Methods • Applicable to both large universities and small colleges • Students who can write reliable software

4. Continuing List of Partners • Alabama • Clemson • Cleveland State • Denison • Depauw • IU Southeast • NC State • Ramapo College • Virginia Tech NVC • Western Carolina

5. What reasoning skills are necessary?Concept Inventory http://www.cs.clemson.edu/resolve/teaching/inventory.html

6. Why? • Current software is too large for one person to understand. • Students need tools for dealing with all sizes of projects. • Maintenance makes up the majority of jobs. • Students need to separate specifications from implementations.

7. Courses at All Levels • Beginning level: CS110 – Intro to Programming, CS174 – Discrete math at Denison • Use of collaborative approach • Use of specifications • Reasoning assistant tool

8. Intermediate level: CPSC215 – Software Foundations at Clemson • Contract specifications – comparing informal specs with formal specs • Mathematical modeling – abstraction • Generating test data from specs • Reasoning assistant tool

9. Advanced level: CS373 –Programming Languages and CS349 – Software Engineering at Denison, CP372 – Software Engineering at Clemson • Formal specifications • Proofs • VC generator tool • Contract-based team development using RESOLVE compiler

10. All Levels • Collaborative Approach • Pairs or small groups • In class or homework

11. Collaborative Method • Pairs or small groups • With or without tools • Each team presents their findings • Collaboration both within teams and among teams

12. Selective Adaptation • Pick and choose appropriate reasoning concepts and/or tools • Faculty expertise • Student background

13. One Example: Software Engineering Course • Usual Topics • Requirements analysis • Design and specification • Component-based implementation • Quality assurance • Formal Reasoning

14. Objectives • Read formal specifications • Create test points from the specs • Use component specifications to build larger systems • Work in teams • Carry out formal verification of components • Use automated rules

15. Methods • Collaborative learning • Teams of 2 to 4 members • Read specs • Implement specs • Verify implementations • Build larger systems.

16. Using the Tools http://resolve.cs.clemson.edu/interface

17. Summary • Importance of Reasoning across the Curriculum • Tools to Support Reasoning • Collaborative Pedagogy includes collaboration between students and between students and faculty

18. Part II: Introduction to Reasoning

19. Mathematical Reasoning Goal: To prove correctness Method: Use a reasoning technique from the logic & proofs section of discrete math Prove correctness on all valid inputs

20. Simple Example: Prove Correctness Code: … i := i – 1; Confirm i = 17; What should i be prior to the assignment statement so that we can confirm that i = 17 after the assignment?

21. Sweep Confirm Backwards … i := i – 1; Confirm i = 17; • Drive the Confirm statement backwards through the code, using substitution. • In this case substitute for variable i in the Confirm statement, then simplify • … Confirm i - 1 = 17;

22. Simplify Confirm i – 1 = 17; • Becomes: Confirm i = 18

23. Final Result … Confirm i = 18 i := i – 1; Confirm i = 17;

24. 2nd Example: Prove Correctness Spec: OperationDo_Nothing(i: Integer); ensuresi = #i; Code: i := i + 1; i := i – 1; Note: • #i represents the incoming value • i represents the outgoing value

25. Proof Setup Assume i = #i; i := i + 1; i := i – 1; Confirm i = #i;

26. Sweep Backward Through Decrement Assume i = #i; i := i + 1; Confirm ??? i := i – 1; Confirm i = #i; After sweep: Assume i = #i; i := i + 1; Confirm i – 1 = #i

27. Sweep Backward Through Increment Assume i = #i; Confirm ??? i := i + 1; Confirm i - 1 = #i; After sweep: Assume i = #i; Confirm (i + 1) – 1 = #i

28. Simplify & Use Logic Assume i = #i; Confirm (i + 1) – 1 = #i After simplification: Assume i = #i; Confirm i = #i Rewrite using logical implication: Implication statement format: p -> q p – represents Assume statement q – represents Confirm statement Result: i = #i -> i = #i

29. Proof The following implication is always true: p -> p Therefore this logical expression is true: i = #i -> i = #i Or, do the proof using the facts: • Use facts from left hand side of implication • Substitute into the right hand side • Fact from left hand side: • i = #i • Substitute so the right hand side becomes: • #i= #i

30. What did we just prove? We proved that the implementation for the Do_Nothing operation satisfied its ensures clause OperationDo_Nothing (i: Integer); ensuresi = #i; Code: i := i + 1; i := i- 1;

31. 3rd Example: Prove Correctness Spec: OperationDo_Nothing(i: Integer); requires(i >= min_int) and (i < max_int); ensuresi = #i; Code: i := i + 1; i := i – 1;

32. Prove it is OK to subtract 1 from i Assume (i >= min_int) and (i < max_int); i := i + 1; Confirmi > min_int; i := i – 1; • We must confirm that i > min_intjust prior to subtracting 1 from i • So we introduce a “Confirm” statement just prior to the line of code: i := i – 1;

33. Prove it is OK to subtract 1 from i Assume (i >= min_int) and (i < max_int); Confirm ??? i := i + 1; Confirmi > min_int; i := i – 1; • Use backwards sweep method again

34. Prove it is OK to subtract 1 from i Assume (i >= min_int) and (i < max_int); Confirmi + 1 > min_int; i := i – 1; • Rewrite using logic’s implication: p -> q • (i >= min_int) and (i < max_int) ->i+ 1 > min_int • Use left hand side facts to prove right hand side: • Fact: i >= min_int • Therefore: i + 1 > min_int

35. Prove it is OK to add 1 to i Assume (i >= min_int) and (i < max_int); • Confirmi < max_int; i := i + 1; i := i – 1; • We must confirm that i < max_intjust prior to adding 1 to i • So we introduce a “Confirm” statement just prior to the line of code: i := i + 1;

36. Prove it is OK to add 1 to i Assume (i >= min_int) and (i < max_int); Confirmi < max_int; i := i + 1; • Rewrite using logic’s implication: p -> q • (i >= min_int) and (i < max_int) ->i < max_int • Use left hand side facts to prove right hand side: • Fact: i < max_int • Therefore: i < max_int

37. Part II: Mathematical Modeling

38. Some mathematics is implicit • We view programming integers as though they are mathematical integers (subject to bounds, of course) • We associate mathematical operators (e.g., +) with operations we can do on integers in programs (e.g., +) • This can be made explicit

39. Mathematical modeling • Type Integer is modeled by Z; • Constraintsfor all i: Integer, • min_int <= i <= max_int;

40. Alternatively… • Type Integer is modeled by Z; • Let i be an example Integer; • Constraints • min_int <= i <= max_int;

41. Initial value specification… • Type Integer is modeled by Z; • exemplar i; • Constraints • min_int <= i <= max_int; • initialization ensures i = 0;

42. Specification of operations … • Type Integer is modeled by Z; • … • specification of operations, e.g., i++ • Operation Increment • (updates i: Integer); • requires i < max_int; • ensures i = #i + 1;

43. More examples … • What is a suitable way to model the state of a light bulb? • …

44. More examples … • Type Light_Bulb_State • is modeled by B; • exemplar b; • Initialization ensures b = false; • Exercises: specification of operations Turn_On, Turn_Off, and Is_On

45. More examples … • How would you model the state of a traffic light? • … • Alternative models and discussion

46. Data abstraction examples … • How would you mathematically model a the contents of a stack? • Is a set model appropriate? • Why or why not? • What about a queue?

47. Mathematical Modeling Summary • To write formal specifications, we need to model the state mathematically • Some objects we use in programming, such as Integers and Reals, have implicit models • For others, such as stacks, queues, lists, etc., we need to conceive explicit mathematical models

48. Part IV: Mathematical Reasoning with Objects

49. Example Specification: Operation Do_Nothing (restores S: Stack); Goal: Same as ensures S = #S; Code: Procedure Do_Nothing (restores S: Stack); Var E: Entry; Pop(E, S); Push(E, S); end Do_Nothing;

50. Mathematical Modeling of Stacks Concept Stack_Template(type Entry; Max_Depth: Integer); uses String_Theory; Type Family Stack is modeled by … Operation Push… Operation Pop… … end Stack_Template;