Create Presentation
Download Presentation

Download Presentation

Making Mathematical Reasoning Fun: A Workshop for Educators

Download Presentation
## Making Mathematical Reasoning Fun: A Workshop for Educators

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -

**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**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**Continuing List of Partners**• Alabama • Clemson • Cleveland State • Denison • Depauw • IU Southeast • NC State • Ramapo College • Virginia Tech NVC • Western Carolina**What reasoning skills are necessary?Concept Inventory**http://www.cs.clemson.edu/resolve/teaching/inventory.html**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.**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**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**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**All Levels**• Collaborative Approach • Pairs or small groups • In class or homework**Collaborative Method**• Pairs or small groups • With or without tools • Each team presents their findings • Collaboration both within teams and among teams**Selective Adaptation**• Pick and choose appropriate reasoning concepts and/or tools • Faculty expertise • Student background**One Example: Software Engineering Course**• Usual Topics • Requirements analysis • Design and specification • Component-based implementation • Quality assurance • Formal Reasoning**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**Methods**• Collaborative learning • Teams of 2 to 4 members • Read specs • Implement specs • Verify implementations • Build larger systems.**Using the Tools**http://resolve.cs.clemson.edu/interface**Summary**• Importance of Reasoning across the Curriculum • Tools to Support Reasoning • Collaborative Pedagogy includes collaboration between students and between students and faculty**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**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?**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;**Simplify**Confirm i – 1 = 17; • Becomes: Confirm i = 18**Final Result**… Confirm i = 18 i := i – 1; Confirm i = 17;**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**Proof Setup**Assume i = #i; i := i + 1; i := i – 1; Confirm i = #i;**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**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**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**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**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;**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;**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;**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**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**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;**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**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**Mathematical modeling**• Type Integer is modeled by Z; • Constraintsfor all i: Integer, • min_int <= i <= max_int;**Alternatively…**• Type Integer is modeled by Z; • Let i be an example Integer; • Constraints • min_int <= i <= max_int;**Initial value specification…**• Type Integer is modeled by Z; • exemplar i; • Constraints • min_int <= i <= max_int; • initialization ensures i = 0;**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;**More examples …**• What is a suitable way to model the state of a light bulb? • …**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**More examples …**• How would you model the state of a traffic light? • … • Alternative models and discussion**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?**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**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;**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;