CS 641 meeting -*- Outline -*-

* motivation for program verification section 

** the correctness problem
	def: (informally) a specification says what a program (procedure) does.
		formally, a specifictation is a relation between states,
		which may be presented as a pair of predicates (cf. Hoare).

	def: software is correct if it meets is specification
		verification is one way to ensure correctness

*** why
	Q: Why should software be correct?
		make a list of the reasons

**** software is important, money and lives depend on it
	if you're selling software, bugs hurt sales
	Q: name a company whose financial existence depends on software?
		american airlines? united? at&t?
	Q: name an application of software on which human lives depend?
		air traffic control, medical implants, 
**** safety may be jepordized by bugs

	def: safety means that the design takes into account the limitations
		of hardware and software, humans, prevents bad things
		from happening

	Q: can a system be incorrect and still safe?
		Yes,

	We won't be studying safety. But ...
	Q: if a system designed for safety, should it be implemented correctly?
		yes, it's difficult (impossible?) to make a design that
		takes into account potential problems
			in carrying out the design
**** pride in work, quality
**** intellectual challenge

*** why not?
	Q: any reasons why you might choose not to worry about correctness?
		when prototyping
		when time to market is more important
		when financial resources don't allow it???

	Note: correctness of code to specs is only part of
		the problem in software engineering,
		perhaps not even the most difficult,
		and already one of the best understood.
	more important are how to design and specify
	we study correctness because of our interests in:
		understanding how to code (programming), safe coding practice
		semantics
		language design
		specification languages

*** how
**** verification
	def: verification is proving that a procedure meets its specification
		connotation is formally, using a logic (as Hoare did)
		but it could also be using any
			convincing mathematically sound means (proof)
**** testing
	similar to verification, in that requires a specification
		(contrary to common practice!)

	Q: how does verification differ from testing?

***** black box testing vs. clear box testing
	black box doesn't look at program
	clear box makes test using knowledge of program
***** testing vs. verification
	
	Dijkstra remarked that "testing can only reveal the presence of bugs,
				not their absence".

	Q: did he mean black box or clear box testing?  Why?

	Q: Could there be a way that you could use testing in verification?
		Yes, instead of formally proving something assertion,
			you might be able to test it.
		Hybrid test and verification
			see Matthew Geller,
			 "Test Data as an Aid in Proving Program Correctness",
			CACM, Volume 21, Number	5, (May	1978), Pages 368-375.

**** other ways?
	Q: Are there other ways of assuring correctness?


** careful development (engineering) vs. guessing and intuition (craft)

	If you compare software to other engineering disciplines
		you'll see that in many ways software is more of a craft

		each program hand made, no standard way to do things,
			no handbooks of accepted solutions,
			no standards for how to write programs
			no mathematical basis used in programming

	Want to be able to have standard techniques,
		and some mathematical basis for programming
			not just guessing and testing
		this will also help (Cohen says) explain and teach

	Ref: Cohen, Chapter 0.

	Q: what did you think of Cohen's exercise 0.0 (cake problem)?

	If not, explain it.  If so, have them do more of the following.

	Consider the following problem (compare Cohen's section 0.1)

	Imagine a circular cake and a number of distinct points
	on its circumference.
	From each point draw another circle, smaller than the original,
	but going over the center of the cake, such that
	any internal intersection is of exactly 2 such circles (no more).

	Q: Is this well-specifed?
		I.e., is it possible to draw
		the circles so that the number of pieces is not a function
		of the number of points?  Why?

	Q: What's the number of pieces of the cake made by N points?
		play with it then show the calculation

	N = number of points, P(N) = number of pieces

	P(0) = 1
	P(1) = 2
	P(2) = 5
	P(3) = 10
	Q: What is P(4)?
	P(4) = 17

-------------------
  increase in number of pieces
	by adding a circular cut
= <a circular cut divides a piece
	wherever it crosses through that piece>
  number of pieces divided by circular cut
= <a piece is divided when an arc of the circular
	cut passes through it>
  number of arcs of the circular cut
= <an arc is determined by the point on
	the circumference and the internal
	intersection points>
  1 + number of internal intersection points
	on the circular cut
-------------------

	Let I(N) = number of internal intersection points on circular cut
			from the Nth point
	So...
-------------------
(0)    P(N) = P(N-1) + (1 + I(N))
-------------------

	Now to compute P(N)

------------------
  P(N)
= <by (0)>
  P(N-1) + 1 + I(N) 
= <each circular cut intersects each other circle twice,
    because they go around the center, and can't be
    multiple intersections>
  P(N-1) + 1 + 2(N-1)
------------------

	Q: Can you solve this to get a non-recursive form for P(N)?
		It's N^2 + 1.
	Q: Can you prove that by induction?
		use a calculation.
	
	idea of the calculational format:
		no big steps (no rabbits out of the hat, makes convincing)
		reasons for each step (increases precision)

		mainly want to use equality, but also can use inequalities
			(or implication) if goes in only one direction.

	Q: What's the role of playing (creativity, guessing) in solution?
		What is the role of calculation?
		Do you think that calculation can guide creativity.