Homework 4 - Axiomatic Semantics

Due: Oct 04 2PM in class or by email to instructor

Problem 1 (10%)

The standard Hoare rule for assignment is a backward rule, in the sense that it substitutes into the postcondition to get the precondition.  It may seem to be intuitively more obvious to make a forward version of the assignment rule, and the obvious candidate is:
       true
-------------------
{P} I := E {P[E\I]}
Give a counterexample explaining why this rule does not work.
Hint: as usual when approaching such problems, you should try a few different types of assignment statements and assertions to get an intuitive feel of what happens.

Problem 2 (10%)

Suppose S is a non-terminating program.
  1. Identify the set of assertions P,Q for which {P}S{Q} must hold
  2. Repeat for [P]S[Q]

Problem 3 (20%)

Consider the following program:
if x-2 then
  y := x-5
else
  y := x+3
fi

For each of the following program postconditions, write a proof outline to determine the weakest precondition of the program. 
  1. y > 7
  2. y > 0
  3. y = u
  4. y = x

Problem 4 (50%)

Consider the following program:
n := m;
while -m do
  if m then
    n := n+1;
  else
    m := m+2;
  fi;
  n := n*3;
  n := n*4;
od;
n := n+5;

Prove the program correct using axiomatic semantics (recall that we did this by writing proof outlines that had at least one assertion after every line of code). Also, give a brief discussion, explaining how you are using the iteration and selection rules correctly (this means stating exactly what P and E are being instantiated to).

You may select appropriate preconditions as long as you don't trivialize your proof (I think we can all agree that anything that doesn't iterate a variable number of times is trivial). I suggest that you restrict an input variable to be a multiple of something.

Problem 5 (10%)

In the previous problem, you were allowed to simplify your proof by picking appropriate preconditions.  Now, lets assume that m and n may be any integers, so that your program precondition is "true".  Write an appropriate postcondition for the program now - i.e., a postcondition that holds regardless of the values of m and n.  For example, the postcondition might capture in FOL all possible cases of the input variable.

You do not need to do any proofs here.

Homework Corrections, Clarifications, and Common Errors

  1. Note that we did not follow Louden for axiomatic semantics.  You should do the problems the way we did it in class.
  2. Preconditions only express properties of 'input' variables (and, of course, any auxiliary variables that you might need to store the values of the input variables).  It would be nonsense to have a precondition that talks about a temporary variable in the program.  
  3. Postconditions should only express properties of 'output' variables.  While it is not wrong to also include facts about temporary program variables, it is irrelevant and meaningless.  After all, why would the user of a program care what the program does to some temporary variable t?  We can use postcondition weakening to get rid of all these irrelevant parts of the postcondition.
  4. As mentioned in class, a Hoare triple is a string of the form {A1}S{A2}and is indivisible (as far as proofs go) - it does not make sense to write something like {A1} --> P.  For one, this wouldn't parse since --> requires its operands to be predicates and {A1} isn't a predicate.  If you mean "A1 implies P", you should write A1-->P.  If you mean statement S would lead to a postcondition P if the precondition is A1, then you should write {A1}S{P}.
  5. If you aren't sure whether your assertions are correct, a good way to check (while learning) is to hand-execute your program for a small value and see if each assertion actually holds.  If one doesn't, you should be able to fix it.  After fixing it, check that the assertions are actually provable from the Hoare rules. Of course, once you get comfortable with axiomatic semantics, you shouldn't be hand-executing programs to figure out assertions - I only suggest it as a way to check your own work.