1 / 81

Making Mathematical Reasoning Fun: A Workshop for Educators

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. Part I: Overview. Goals. Reasoning Across the Curriculum

Download Presentation

Making Mathematical Reasoning Fun: A Workshop for Educators

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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;

More Related