1 / 81

810 likes | 1.03k Views

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

**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;

More Related