CSC195, Class 49: Program Development, Gries Style

Overview:
* Overview of the Week
* Issues in Developing Programs
* Quick example: Capping two values
* Some Design Principles
* A Problem: 14 (d)

Notes:
* Food: Leftovers from 151 presentations
* Dr. Freda Rebelsky visits.
* Expect exam 2 tomorrow.

----------------------------------------

Goal: Learn why we learned all the formalisms
Today:
* Overview
* Look at simple examples
Tomorrow:
* Loops
  Invariants
  + How to write them
  + How to use them to develop programs
Wednesday:
* More Loops
* Larger program

----------------------------------------

Gries says: The normal way programmers develop
programs is bad.
* The Gries theory: Programmers start with examples,
  write programs to solve those example, build new
  examples, fix their code, repeat ad infinitem.
* Gries suggests that you should use a more careful
  process.
  (1) Make sure you understand the problem
      (mostly postconditions, some preconditions)
  (2) Develop your program and a proof of its correctness
      hand in hand
      (a) Proofs are usually Gries-style wp analyses
      (b) The proofs need not be formal!
  Like all good tools, this tool need not be used everywhere.
  Where should you use it?
  * To identify dangling participles. (That was a joke.)
  * To make sure that our loops are correct.
  * Often, when we worry about off-by-one errors.
  * Any place in which you're confused or otherwise unsure
    about what you're doing.

Given that this process is comparatively informal, why have
we spent twelve weeks on a relatively formal model?
* To give us a more powerful vocabulary for talking about
  these things and thinking about these things.
  + E.g., map changes many peoples way of thinking about
    programming.
  + Similarly, wp should change your way of thinking about
    designing programs
  + That is, working backwards may be good.
* New exam question: Reflect on Gries style programming as
  reflecting the induction/deduction dichotomy in a 
  Post-Modern context.   (This was a joke, too.)
* "Know the rules before you break them." [Kuper 2003]

A Simple Example:

  What program (single statement or a few statements) should 
  we write to guarantee that "z caps the values of x and y"?
  P: { cap(x, y, z) }
  Formal definition:
  P : { z > x and z > y }

  S : z := x + y;

  wp(S, P) = { (x + y > x) and (x + y > y) }
           = { y > 0 and x > 0 }

  Idea from Gries: Choose a solution that works some of the
    time and then shove it into a conditional

  S1:  z := x+1;

  wp(S1, P) = { (x + 1 > x) and (x + 1 > y) }
            = { true and x > y - 1 }
            = { x >= y }

  S2: z := y+1;

  WP(S2, P) = { y >= x }

  if
    x >= y; z := x+1;
    y >= x; z := y+1:
  fi

Gries suggests that we try this technique regularly
(find a condition in which we might get the result, do
so repeately until you cover all the cases).

----------------------------------------

Suppose 
Q: 0 < a+1 < b
  We don't want a is 2 and b is 3
  We want at least three elements in the interval!
P: a^2 <= n and b^2 > n
a and b and n are integers

Can we halve (or approximately halve) the interval [a .. b] 
while maintaining P? (and Q?)

Questions:
* Why might you do so?
  Repeated application gives you the square root of n 
  
* How might you do so?
  Find the midpoint (a + b) / 2

if
  ((a + b) / 2)^2 <= n: a = ....
  ((a + b) / 2)^2 > n: b = ....
fi

wp(a = ((A + B)/2) ; a^2 <= n and b^2 > n ) =
  { ((A+B)/2)^2 <= n and b^2 > n }