1 / 21

Announcements

Announcements. We are done with homeworks Second coding exam this week, in recitation Times will be posted later today If in doubt, show up for your regular recitation time. Invariants. Invariants: properties which must always hold

pascha
Download Presentation

Announcements

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. Announcements • We are done with homeworks • Second coding exam this week, in recitation • Times will be posted later today • If in doubt, show up for your regular recitation time

  2. Invariants • Invariants: properties which must always hold • Class invariants hold between (but not necessarily during) method invocations • Loop invariants hold before, during and after execution of a loop • Pre/post conditions • Post-conditions of a method spell out what must be true after a method execution completes, if preconditions are satisfied • Pre-conditions of a method spell out what must be true at method invocation in order for method to perform as promised

  3. Class invariant Recall our Bag<E> implementation: publicclass Bag<E> implements Collection<E> { private E [] _values; /* CLASS INVARIANTS * _size denotes the number of elements in the bag, and also * the first available position within the array _values */ privateint_size; public Bag() { _values = (E[]) (new Object[10]); _size = 0; } // POST: _values is initialized, _size is zero publicbooleanadd(E item) { … } // POST: item is in Bag publicvoid clear() { … }// POST: _size is zero publicbooleanremove(Object item){ … }// POST: one fewer item is in Bag … }

  4. Axiomatic semantics • Basic idea: you make assertions about statements in a program. • A precondition is an assertion about what is true prior to execution of a statement. • A postcondition is an assertion about what is true after execution of a statement. For example: sum = 2*sum + 1 {sum > 1} • Quotes on upcoming slides are from Concepts of Programming Languages, by Robert Sebesta.

  5. Weakest precondition • “The weakest precondition is the least restrictive precondition that will guarantee the validity of the associated postcondition.” [p. 151] • In example above {sum>10} is a valid precondition but {sum>0} is the weakest precondition: {sum > 0} sum = 2*sum + 1 {sum > 1}

  6. Correctness proofs • “If the weakest precondition can be computed from the given postconditions for each statement of a language, then correctness proofs can be constructed for programs in that language.” [p. 151] • To do this, start with output specifications for the program as the postcondition for the program as a whole.

  7. Next, work backwards, computing weakest preconditions one statement at a time, to derive the weakest precondition for the program as a whole: stmt1 {c0} stmt1 {c1} stmt2 {c1} stmt2 {c2} . . .  . . . stmtN {cN} {cN-1} stmtN {cN}

  8. If the input specification for the program satisfies the program’s weakest precondition, then the program will (provably) produce the correct result.

  9. Assignment statements • The axiomatic semantics of an assignment statement x=E is written as P=QxE • This means that the precondition is the postcondition with all instances of x replaced by E. • Example: a = b/2-1 {a<10} To compute precondition, replace all instances of a in postcondition a<10 by b/2–1: b/2-1 < 10, or b < 22 • Semantics: {b<22} a = b/2-1 {a<10} • In general: {QxE} x=E {Q}

  10. Inference • Suppose we wanted to prove the following: {sum > 5} sum = 2*sum + 1 {sum > 3} • Starting with the postcondition, we derive as the weakest precondition something different: 2*sum + 1 > 3 2*sum > 2 sum > 1 (weakest precondition) • Clearly this is OK, because the actual precondition {sum>5} implies the weakest precondition {sum>1}: sum>5 => sum>1 • We use an inference rule, the rule of consequence, to prove this.

  11. Rule of consequence • General form: S1, S2, …, Sn S • Precondition strengthening: P=>P’, {P’} C {Q} {P} C {Q} • Postcondition weakening: Q’=>Q, {P} C {Q’} {P} C {Q}

  12. Precondition strengthening applied • Recall our example. We want to prove the following: {sum > 5} sum = 2*sum + 1 {sum > 3} • The weakest precondition we derive is: sum > 1 • Apply precondition strengthening to finish proof: P=>P’, {P’} C {Q} {P} C {Q} sum>5 => sum>1, {sum>1} sum=2*sum+1 {sum>3} {sum>5} sum=2*sum+1 {sum>3}

  13. Hang on! • Why get so formal? • Because this way correctness proofs can be (partially) automated.

  14. {P} S1 {Q}, {Q} S2 {R} • {P} S1 S2 {R} Sequences:S1 S2 Start with a sequence of statements: y = 3*x+1; x = y+3; {x<10} Compute weakest precondition for 2nd stmt: {y+3<10} or {y<7}, use as postcondition for 1st stmt: y = 3*x+1; {y<7} {y<7} x = y+3; {x<10} Compute weakest precondition for 1st stmt: {3x+1<7} or {x<2} {x<2} y = 3*x+1; {y<7} {y<7} x = y+3; {x<10} Conclude, applying sequence rule: {x<2} y = 3*x+1; x = y+3; {x<10}

  15. {B & P} S1 {Q}, {!B & P} S2 {Q} • {P} if B then S1 else S2 {Q} Selection:if B then S1 else S2 Start with a conditional statement: if (x>0) then y=y-1 else y=y+1 {y>0} Deal with arms of the conditional one at a time, first the then-arm: y = y-1 {y>0}  {y>1} y = y-1; {y>0} Now the else-arm: y = y+1 {y>0}  {y>-1} y = y+1; {y>0} Use rule of precondition strengthening on the else-arm result (to make both arms uniform): {y>1} y = y+1; {y>0} Now strengthen both arms’ preconditions by imposing a constraint on x: { x>0 & y>1} y = y-1; {y>0} {!(x>0) & y>1} y = y+1; {y>0} Conclude, applying selection rule: {y>1} if (x>0) then y=y-1 else y=y+1 {y>0}

  16. {B & I} S {I} _ • {I} while B do S end {I and !B} While:while B do S end Let’s prove the following: {true} r=x; q=0; while y<=r do r=r-y; q=q+1; end {y>r & x=r+y*q} Start by proving loop body: {y<=r & x=r+y*q} r=r-y; q=q+1;{x=r+y*q} Start with last statement: q=q+1 {x=r+y*q}  {x=r+y*(q+1)} q=q+1 {x=r+y*q} {x=r+y+y*q} q=q+1 {x=r+y*q} Continue with second-to-last statement: r=r-y {x=r+y+y*q}  {x=r-y+y+y*q} r=r-y {x=r+y+y*q} {x=r+y*q} r=r-y {x=r+y+y*q} Use rule for sequence to get: {x=r+y*q} r=r-y; q=q+1; {x=r+y*q} Now strengthen precondition to conclude proof of loop body: {y<=r & x=r+y*q} r=r-y; q=q+1; {x=r+y*q} This lets us derive a weakest precondition for the while loop: {x=r+y*q} while y<=r do r=r-y; q=q+1; end {x=r+y*q & !(y<=r)}

  17. {B & I} S {I} _ • {I} while B do S end {I and !B} While:while B do S end The next step is to prove the sequence {true} r=x; q=0; while y<=r do r=r-y; q=q+1; end {x=r+y*q & y>r)} Start by moving backwards from the while loop (since we derived a weakest precondition from its postcondition already): {true} r=x; q=0; {x=r+y*q} Start with last statement: q=0; {x=r+y*q}  {x=r+y*0} q=0 {x=r+y*q} {x=r} q=0 {x=r+y*q} Continue with second-to-last statement: r=x {x=r}  {x=x} r=x {x=r} Precondition strengthening: {true} r=x {x=r} Sequence rule (applied in general form): {true} r=x; q=0; while y<=r do r=r-y; q=q+1; end {x=r+y*q & !(y<=r)} Finally, postcondition weakening because !(y<=r) => y>r : {true} r=x; q=0; while y<=r do r=r-y; q=q+1; end {x=r+y*q & y>r} We're done!

  18. Loop invariant • Recall the While rule: {B & I} S {I} _ {I} while B do S end {I and !B} • I is called the loop invariant: • "…if executing [the body] once preserves the truth of [the invariant], then executing [the body] any number of times also preserves the truth of [the invariant]." [Gordon, Programming Language Theory and its Implementation, paraphrased from page 24]

  19. Importance of loop invariants • Developing loop invariants are a powerful way to design and understand algorithms. • Consider selection sort: selectionSort(int[] array) { int min, temp, bar=0; while (bar < array.length - 1) { min = indexOfSmallest(array, bar); // find min temp = array[bar]; // swap array[bar] = array[min]; array[min] = temp; bar = bar + 1; // Loop invariant: region before bar is sorted: // for all i,j<=bar, i<jarray[i] <= array[j]} }

  20. Example [ 7 4 6 8 3 2 ] [ 24 6 8 3 7 ] [ 2 36 8 4 7 ] [ 2 3 48 6 7 ] [ 2 3 4 68 7 ] [ 2 3 4 6 7 8 ] region not known to be sorted region known to be sorted

  21. Priority queues • Queue • Ordered by some priority • Regular queue – ordered by time of arrival • Think of ER queue • Implementation • List • Heap (a heap-ordered tree)

More Related