380 likes | 557 Views
Quiz Friday 8-29 Lectures: introduction and methods of proof Text: pp 1-26. Methods of Proof. Deductive proof: Used extensively in geometry & trigonometry Not very important in this class Inductive proof: Basis of most automata theory
E N D
Quiz Friday 8-29 Lectures: introduction and methods of proof Text: pp 1-26
Deductive proof: • Used extensively in geometry & trigonometry • Not very important in this class • Inductive proof: • Basis of most automata theory • Proficiency in induction is a primary objective of this class
Deductive proof • Step-by-step argument from given information to a conclusion • “from the information that you gave me, I deduce that ….” • No internal assumptions are allowed • Example: proving that sets are equivalent
Proving equivalences about sets • In automata theory frequently ask “Are sets constructed in different ways actually the same set?” • Elements of sets are usually strings; hence sets are called “languages” • Statement “set E = set F” means every element in E is in F and every element in F is in E
Equivalent sets 2 • set E = set F is example of “if and only if” • Element x is in E if and only if x is in F • To prove E = F must prove 2 if…then statements • If x is in E then x is in F • If x is in F then x is in E
Background on sets • If xA implies xB, then A is a subset of B (written AB) • If, in addition, AB then A is a proper subset of B (written AB) • AB = intersection of sets A and B defined by {x: xA and xB } • AB = union of sets A and B defined by {x: xA or xB }
Background on sets 2 • A - B = difference of sets A and B defined by {x: xA and xB } • Let T be complement of S with respect to U then SU, TU, ST = U, and ST = null • Sets obey laws similar to numbers (commutative, associative, distributive, etc)
Proof of distributive law of sets • R(ST) = (RS)(RT) • Let E = R(ST) • Let F = (RS)(RT) • Must prove • if x is in E then x is in F • if x is in F then x is in E
Proof of distributive law of sets 2 if x R(ST) then x R or x (ST) (def. of union) x R or x S and x T (def. of intersection) x RS (def. of union) x RT (def. of union) x (RS)(RT) (def. of intersection)
Proof of distributive law of sets 3 if x (RS)(RT) then x RS (def. of intersection) x RT(def. of intersection) x R or x S and x T(why?) x R or x (ST) (def. of intersection) x R(ST) (def. of union)
Contrapositives • Given hypothesis H and conclusion C, one of following cases is true • 1. H and C are both true • 2. H is true and C is false • 3. H is false and C is true • 4. H and C are both false • Only (2) makes “if H then C” false • (3) does not apply to “if H then C” • In both (1) and (4) “if H then C” is true
Contrapositives 2 • Contrapositive of “if H then C” is “if not C then not H” • Hypothesis is “not C” • Conclusion is “not H” • 4 cases of previous slide still apply • Only (2) makes “if not C then not H” false • (3) does not apply to “if not C then not H” • In (1) and (4) “if not C then not H” is true • hence “if not C then not H” is equivalent to “if H then C” and may be easier to prove
Contrapositive 3 • Contrapositive of “if x > 4 then 2x > x2” is “if 2x < x2 then x < 4” • Sometimes contrapositive is easier to prove. • Can this contrapositive be proved by algebra?
Proof by contradiction Proving “if H and not C -> falsehood” is equivalent to proving “if H then C” Example using complement of a set
Proof by contradiction 2 • T is the complement of S with respect to U then SU, TU, ST = U, and ST = null • If S is finite and U is infinite, then T is infinite • Hypothesis has 3 parts • T is complement of S • S is finite • U is infinite • Conclusion is “T is infinite” • not C is “T is finite”
Proof by contradiction 3 • If T is finite, then ||T||=some integer m • S is finite; therefore ||S||=some integer n • T is complement of S with respect to U; therefore; ST = U and ST = null • Hence, ||U||=m+n • By definition, this means U is finite • H and not C contradicts part of H • This proves “if H then C”
Inductive proof • Many types of induction • Induction on integers is most familiar
Induction on integers • S(n) is statement about integers we want to prove • Base case establishes truth of the statement for n=is typically the smallest integer where statement is true • Inductive step proves statement for n>is typically by “if S(n) then S(n+1)” • “if S(n)” is called the “inductive hypothesis”
How I grade inductive proofs • Proof of base case • Statement of inductive hypothesis • How inductive hypothesis is used • Basis for algebra that completes the proof • All algebraic operations are on the rhs of equals sign
Assignment #1 Due 9-3-14 Prove by induction on integers that k=1 to n k = n(n+1)/2 Your proof must include the following: (1) truth of base case (2) statement of inductive hypothesis (3) correct application of inductive hypothesis
Exceptions to typical approach • Basis can consist of a range of i values, all of which must be used in the inductive step. • “if S(n-1) then S(n)” is equivalent to “if S(n) then S(n+1)” • Example: if S(n-1) then S(n) applied to assignment 1
Prove j=1 to n j = n(n+1)/2 Base case n=1 j=1 to 1 j = 1(1+1)/2
Review Induction used 2 ways in the class recursive definitions proofs Both have 3 parts base case assumption (IH) induction Example: definition of tree and proof that n=e+1
Structural Induction • Automata theory involves recursive definitions that become the subject of inductive proofs. • Example: recursive definition of a tree • Basis: single node is a tree • IH: assume that T1, … Tk are trees • Induction: connect then to the node that is root of a recursively defined tree
Structural induction 2 • Prove: in every tree n = e +1, where n is the number of nodes and e is the number of edges • Basis: true for single-node tree • IH: assume ni=ei+1 true for trees T1, …, Tk • Induction: • n=1+n1+n2+…+nk = 1+(e1+1)+…+(ek+1) • n=1+k+e1+…+ek = 1+e
Switch automaton push • Nodes are states; Arcs are transitions • Arcs labeled by strings that induce the indicated transitions • Arrow indicates the start state off on Start push
Data transfer automaton • Data induces transition to sending • Loop keeps automaton in sending state until transmission is done • “Ready” and “Sending” are complex states • Many conditions must be met for automaton to be in these states timeout data in Ready Sending Start done
Mutual Induction • An inductive hypothesis may have several facets • Example: all the conditions necessary to put an automaton in a certain state • If all facets depend on a common value of an integer, then we have “mutual induction”
Example of Mutual Induction Prove the following about the “switch” automaton push • S1(n): automaton in the off state after n pushes iff n is even • S2(n): automaton is in the on state after n pushes iff n is odd off on Start push
Both S1(n) and S2(n) are iff Given that switch starts in “off” we must prove that after n pushes … push • If n is even, then switch is off • If switch is off, then n is even • If n is odd, then switch is on • If switch is on, then n is odd off on Start push
Prove : if n is even then switch is off Basis: n=0 true zero even by definition and switch starts in off push • IH: if k is odd then switch is on • If n is even then n-1 is odd • By IH, switch is on after n-1 pushes • One more push tunes switch off • Similar proof for other 3 statements off on Start push
Mutual Induction 3 push • “switch” automata is always in exactly one state. Not generally true • one-state character of switch makes this example of mutual induction artificial • Proof of S1(n) implies the truth of S2(n) • Text treats as mutual induction off on Start push
Loop invariant and induction • Loop invariant is statement about iterative algorithm • Prove the statement is true by induction • Show true before 1st iteration (base case or initialization) • If true on ith iteration (inductive hypothesis) remains true before i+1 iteration (maintenance)
Loop invariant Termination • Aspect of loop invariant analysis that goes beyond general inductive proof • Having establish that the loop invariant is true, statement of the loop invariant when looping terminates proves the correctness of the iterative algorithm
Validation is usual approach in code development • Test code for some simple cases were hand calculation is practical • If a “validated” code fails, usually learn something important • In CS 317 get some practice with formal proofs