A Hybrid Approach to Applying Mathematical Reasoning in Computer Science Courses

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