1 / 97

A Hybrid Approach to Applying Mathematical Reasoning in Computer Science Courses

A Hybrid Approach to Applying Mathematical Reasoning in Computer Science Courses. Addressing the Challenges of Current Software. Questions to Address. Why? What? Where? How? What do we mean by hybrid?. Some Work. Binary search specifications Java C++ Any other language

zonta
Download Presentation

A Hybrid Approach to Applying Mathematical Reasoning in Computer Science Courses

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. A Hybrid Approach to Applying Mathematical Reasoning in Computer Science Courses Addressing the Challenges of Current Software

  2. Questions to Address • Why? • What? • Where? • How? • What do we mean by hybrid?

  3. Some Work • Binary search specifications • Java • C++ • Any other language • Are the algorithms correct? • Do the implementations work? • What’s the difference?

  4. 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.

  5. What reasoning skills are necessary?Concept Inventory

  6. What do we need to prove? • Algorithm analysis of performance? • Example: Does this algorithm find the minimal spanning tree? • Implementation of specifications • Example: Does this program implement the specifications for finding the minimal spanning tree?

  7. Reasoning about Implementations • Extending mathematics with proof rules • Generating verification conditions (VC’s)

  8. Typical discrete math proof set up • P  Q • Same as • AssumeP • Confirm Q

  9. Software Correctness • Code is correct if it meets its specifications. • Specification of an operation involves pre- and post-conditions, which are logical assertions • Basic set up • Assumepre-conditions • Code • Confirmpost-conditions

  10. Software Correctness • Pre-conditions are givens or facts that you can assume • Post-conditions are guarantees or obligations that you must confirm (prove) • Basic set up • Assumepre-conditions • Code • Confirmpost-conditions

  11. Software Correctness • Assuming the pre-conditions, if you execute the code that follows, would you be able to confirm the logical assertions at the end of the code? • For now: Assume that nothing goes wrong during the execution of the code.

  12. Example #1: Is Code Correct? • Example #1 (b is a Boolean variable) Assume b; b := not b; // := is assignment Confirm b; • C code corresponding to the above Assume b; b = !b; // = is assignment Confirm b; • We will use := for assignment, etc.

  13. Example #1: Is Code Correct? • Example #1 (b is a Boolean variable) Assume b; b := not b; Confirm b; • The code above means: Assume b = true; b := not b; Confirm b = true;

  14. Example #2: Is Code Correct? • Example #1 (b is a Boolean variable) Assume b; b := not b; Confirmnot b; • Same as: Assume b = true; b := not b; Confirm b = false;

  15. Correctness: Method • Code is reduced to a logical assertion (starting with the last statement in the method used here) • Code is correct if and only if the logical assertion is provable • We will use various techniques and results from discrete math to complete the proofs

  16. A Slightly Larger Example • Software is correct if it meets its specifications. • Is the following code segment correct? Assume all variables are Integers. Assume I = #I and J = #J; Temp := I; I := J; J := Temp; Confirm I = #J and J = #I;

  17. Proof Assume I = #I and J = #J; Temp := I; I := J; J := Temp; Confirm J = #I; • Replace J in the Confirm assertion with the effect of the highlighted statement

  18. Simplify Assume I = #I and J = #J; … J := Temp; Confirm J = #I; • Becomes (J is replaced with Temp in the confirm assertion) Assume I = #I and J = #J; Temp := I; I := J; ConfirmTemp = #I;

  19. Simplify again Assume I = #I and J = #J; Temp := I; I := J; Confirm Temp = #I; • becomes (no I in confirm assertion) Assume I = #I and J = #J; Temp := I; ConfirmTemp = #I;

  20. Simplify one more time Assume I = #I and J = #J; Temp := I; ConfirmTemp = #I; • Becomes (Temp is replaced with I in the confirm assertion) Assume I = #I and J = #J; ConfirmI = #I;

  21. Correctness Established • Simplify one more time. Assume I = #I and J = #J; Confirm J = #J; • The above is the same as: (I = #I and J = #J)  (J = #J); • true, because P and Q Q;

  22. Correctness Summary • What did we just do? • Mathematically prove that a piece of code is correct using integer theory and logic. • The process is mechanical. You can do both parts in the proof simultaneously; we did it separately to make it easier. • This is unlike testing where we can only show presence of errors, but not their absence.

  23. Automating the Process • Automated generation of verification conditions (VC’s)

  24. Assume y  0; • z = w/y; • if z >= 0 thenabs := z • else abs := -z • endif; • Confirm abs = |w/y|;

  25. if then else statements: • code: Assume B; code1; Confirm Q; • code; Assume B; code2; Confirm Q; • --------------------------------------code; If B then code1 else code2; endif;ConfirmQ;

  26. (1) Assume y  0; • z = w/y; • Assume z ≥ 0; • abs := z; • Confirm abs = |w/y|; • (2) Assume y  0; • z = w/y; • Assume z < 0; • abs := z; • Confirm abs = |w/y|;

  27. code; Confirm Q ; • --------------------------------------code; x := exp; Confirm Q;

  28. (1) Assume y  0; • z := w/y; • Assumez ≥ 0; • Confirmabs = |w/y|; • (2) Assumey  0; • z := w/y; • Assumez < 0; • Confirmabs = |w/y|;

  29. Q; • We now need a rule for Assume statements: • code; Confirm P Q; • ------------------------------------ • code; Assume P; Confirm Q;

  30. (1) Assume y  0; • z := w/y; • Confirm z ≥ 0 => z = |w/y|; • (2) Assume y  0;; • z := w/y; • Confirm z < 0 => -z = |w/y|;

  31. (1) Assume y  0; • Confirmw/y ≥ 0 => w/y = |w/y|; • (2) Assume y  0; • Confirm w/y <0 => w/y = |w/y|;

  32. y  0 => w/y ≥ 0 => w/y = |w/y|; • y  0 => w/y <0 => w/y = |w/y|;

  33. Automated generation of VC’s • Clemson website http://resolve.cs.clemson.edu/interface • example

  34. Concept Stack_Template(type Entry; Max_Depth: Integer); uses String_Theory; Type Family Stack is modeled by Str(Entry); exemplar S; constraints |S| <= Max_Depth; initialization ensures S = empty_string; … end Stack_Template; Mathematical Modeling of Stacks

  35. Demonstration • Demo site: www.cs.clemson.edu/group/resolve/ • Click on Components Tab at the top • Click on Facilities in the Finder • Click on Int_Swap_Example_Fac • Comment out operations Exchange2 and Main and their procedure using (* … *) • Click on Verify

  36. Demonstration • Specifications have the form • Operation … • requires pre-conditions • ensures post-conditions • Given a piece of code to implement the above specification, we get: • Assume pre-conditions • Code • Confirm post-conditions • This is the starting point

  37. Demonstration • Specification • Operation Exchange (updates I, J: Integer); • ensures I = #J and J = #I; • Values of parameters I and J are updated or modified by the operation • Operation has no requires clause (pre-condition) • In the ensures clause (post-condition), #I and #J denote input values

  38. Demonstration • Specification • Operation Exchange (updates I, J: Integer); • ensures I = #J and J = #I; • Implementation code (procedure) Temp := I; I := J; J := Temp; • Putting it together get: • Assume true; -- no pre-conditions • Code • Confirm I = #J and J = #I;

  39. Demonstration • Actually putting it together get: • Assume I = #I and J = #J; --system knows! • Assume true; --no pre-conditions • Code • Confirm I = #J and J = #I; • So we have (same as our exercise in class): • Assume I = #I and J = #J; --system knows! Temp := I; I := J; J := Temp; • Confirm I = #J and J = #I;

  40. Demonstration Summary • Correctness proofs can be automated • It is mostly tedious work • Need an integrated specification-programming language like RESOLVE • There are many specifications languages, just like there are many programming languages • ANNA, B, Dafny, Eiffel, JML,…VDM, Z • All of them use discrete math notations!

  41. Arithmetic Example • Example (Ans, I, and J are Integers) Assumetrue; Ans := J - I; Confirm Ans := I - J; • Is the code correct? • Why or why not?

  42. Example: Is Code Correct? • Example (Ans, I, and J are Integers) Assumetrue; Ans := J - I; ConfirmAns = I - J; • Is the code correct? • Substituting J - I for Ans, we have Assumetrue; Confirm J – I = I – J; • After more transformations: false //universal statement

  43. Another Arithmetic Example • Example (Ans, I, and J are Integers) Assumetrue; Ans := J + I; Confirm Ans := I + J; • Is the code correct? • Why or why not?

  44. Example: Is Code Correct? • Example (Ans, I, and J are Integers) Assumetrue; Ans := J + I; ConfirmAns = I + J; • Is the code correct? • Substituting J + I for Ans, we have Assumetrue; ConfirmJ + I = I + J; • After more transformations: true // + is commutative!

  45. From Before: Is Code Correct? • Example (Ans, I, and J are Integers) Assumetrue; Ans := J + I; ConfirmAns = I + J; • Is the code correct? • Substituting J + I for Ans, we have Assumetrue; ConfirmJ + I = I + J; • After more transformations: true // + is commutative!

  46. Example Demonstration • Try the arithmetic example at the demo site • Type this in; comment out other ops; click verify and continue with slides! OperationAns(eval I, J: Integer): Integer; ensuresAns = I + J; Procedure Ans := J + I; -- same as return(J + I); end; • Are we able to prove it automatically? • Why or why not?

  47. Computational vs. Math Integers • Cannot verify because assignment could cause an overflow or underflow! • We really need to confirm two things! Assumetrue; Confirm min_int<= (I + J) and (I + J) <= max_int; -- pre-condition for adding Ans := J + I; ConfirmAns = I + J; • System knows! It puts in the confirm assertion before assignment.

  48. Computational vs. Math Integers • To verify we need to include a bounds pre-condition! Try this. OperationAns(eval I, J: Integer): Integer; requires min_int <= (I + J) and (I + J) <= max_int; ensuresAns = I + J; Procedure Ans := J + I; end;

  49. Computational vs. Math Integers • This is provable because now we get: Assume min_int <= (I + J) and (I + J) <= max_int; Confirm min_int<= (I + J) and (I + J) <= max_int; Ans:= J + I; Confirm Ans = I + J;

  50. Computational vs. Math Integers • This is provable because now we get: Assume min_int <= (I + J) and (I + J) <= max_int;-- pre-condition Confirm min_int<= (I + J) and (I + J) <= max_int; -- system knows Ans:= J + I; -- code Confirm Ans = I + J; -- post-condition

More Related