Reasoning about programs

Similar documents
Last time. Reasoning about programs. Coming up. Project Final Presentations. This Thursday, Nov 30: 4 th in-class exercise

Backward Reasoning: Rule for Assignment. Backward Reasoning: Rule for Sequence. Simple Example. Hoare Logic, continued Reasoning About Loops

CS 161 Computer Security

Hoare Logic: Proving Programs Correct

Lecture Notes: Hoare Logic

Outline. Introduction. 2 Proof of Correctness. 3 Final Notes. Precondition P 1 : Inputs include

Specifications. Prof. Clarkson Fall Today s music: Nice to know you by Incubus

Lecture 1 Contracts. 1 A Mysterious Program : Principles of Imperative Computation (Spring 2018) Frank Pfenning

CS 520 Theory and Practice of Software Engineering Fall 2018

An Annotated Language

Review: Hoare Logic Rules

Lecture 1 Contracts : Principles of Imperative Computation (Fall 2018) Frank Pfenning

introduction to Programming in C Department of Computer Science and Engineering Lecture No. #40 Recursion Linear Recursion

AXIOMS OF AN IMPERATIVE LANGUAGE PARTIAL CORRECTNESS WEAK AND STRONG CONDITIONS. THE AXIOM FOR nop

SEQUENCES, MATHEMATICAL INDUCTION, AND RECURSION

15-122: Principles of Imperative Computation (Section G)

Algorithms 1 / 24. Algorithms Sequential Search

Correctness of specifications. Correctness. Correctness of specifications (2) Example of a Correctness Proof. Testing versus Correctness Proofs

Harvard School of Engineering and Applied Sciences CS 152: Programming Languages

Algorithms. Notations/pseudo-codes vs programs Algorithms for simple problems Analysis of algorithms

Advances in Programming Languages

Recursively Enumerable Languages, Turing Machines, and Decidability

Hardware versus software

Program Verification. Program Verification 307/434

12/30/2013 S. NALINI,AP/CSE

Mathematical Induction

Cardinality of Sets MAT231. Fall Transition to Higher Mathematics. MAT231 (Transition to Higher Math) Cardinality of Sets Fall / 15

Abstract Interpretation

Lecture Notes on Linear Search

6. Hoare Logic and Weakest Preconditions

Program Static Analysis. Overview

EXAMINATIONS 2009 END-OF-YEAR. COMP 202 / SWEN 202 Formal Methods of Computer Science / Formal Foundations of Software Engineering

Semantics. There is no single widely acceptable notation or formalism for describing semantics Operational Semantics

Analyzing Complexity of Lists

Comparing procedure specifications

Chapter 3 (part 3) Describing Syntax and Semantics

A short manual for the tool Accumulator

Testing. UW CSE 160 Winter 2016

ASYMPTOTIC COMPLEXITY

Foundations, Reasoning About Algorithms, and Design By Contract CMPSC 122

Recall our recursive multiply algorithm:

Verification and Validation. Verification and validation

STUDENT LESSON A12 Iterations

Lecture 10 Design by Contract

Steps for project success. git status. Milestones. Deliverables. Homework 1 submitted Homework 2 will be posted October 26.

Handout 9: Imperative Programs and State

Chapter 3. Describing Syntax and Semantics ISBN

CS 4349 Lecture August 21st, 2017

Lecture 7 Quicksort : Principles of Imperative Computation (Spring 2018) Frank Pfenning

Arguing for program correctness and writing correct programs

Violations of the contract are exceptions, and are usually handled by special language constructs. Design by contract

Linked lists. A linked list is considered a recursive data structure because it has a recursive definition.

Softwaretechnik. Program verification. Albert-Ludwigs-Universität Freiburg. June 28, Softwaretechnik June 28, / 24

CS264: Homework #1. Due by midnight on Thursday, January 19, 2017

Lecture 7: General Loops (Chapter 7)

Lecture 4 Searching Arrays

Proving Programs Correct

6.170 Lecture 6 Procedure specifications MIT EECS

Lecture Notes on Quicksort

How invariants help writing loops Author: Sander Kooijmans Document version: 1.0

CSE 331 Summer 2016 Final Exam. Please wait to turn the page until everyone is told to begin.

Softwaretechnik. Program verification. Software Engineering Albert-Ludwigs-University Freiburg. June 30, 2011

CSE 331 Midterm Exam Sample Solution 2/18/15

Programming Languages Third Edition

Assertions. Assertions - Example

Static Program Analysis

Assertions, pre/postconditions

SEQUENCES, MATHEMATICAL INDUCTION, AND RECURSION

Program Verification (6EC version only)

0.1 Welcome. 0.2 Insertion sort. Jessica Su (some portions copied from CLRS)

Chapter 10 Recursion

SFWR ENG 3S03: Software Testing

(a) (4 pts) Prove that if a and b are rational, then ab is rational. Since a and b are rational they can be written as the ratio of integers a 1

Prof. Dr. A. Podelski, Sommersemester 2017 Dr. B. Westphal. Softwaretechnik/Software Engineering

Repetition Through Recursion

Chapter 3. Describing Syntax and Semantics

Hoare Logic. COMP2600 Formal Methods for Software Engineering. Rajeev Goré

Lecture 3.4: Recursive Algorithms

Lecture Notes on Contracts

Midterm I Exam Principles of Imperative Computation Frank Pfenning. February 17, 2011

Lectures 20, 21: Axiomatic Semantics

Testing. CMSC 433 Programming Language Technologies and Paradigms Spring A Real Testing Example. Example (Black Box)?

Reasoning About Imperative Programs. COS 441 Slides 10

Assignment 2 Due Thursday 7/3 at 10:00 AM

CS158 Section B Exam 1 Key

Lecture Notes on Arrays

Formal Methods. CITS5501 Software Testing and Quality Assurance

CS 1110, LAB 10: ASSERTIONS AND WHILE-LOOPS 1. Preliminaries

Thread Safety. Review. Today o Confinement o Threadsafe datatypes Required reading. Concurrency Wrapper Collections

The Rule of Constancy(Derived Frame Rule)

CSSE 304 Assignment #13 (interpreter milestone #1) Updated for Fall, 2018

MergeSort, Recurrences, Asymptotic Analysis Scribe: Michael P. Kim Date: April 1, 2015

Computer Science 136. Midterm Examination

Trees. 3. (Minimally Connected) G is connected and deleting any of its edges gives rise to a disconnected graph.

Programming and Data Structure

CMPSCI 187 / Spring 2015 Postfix Expression Evaluator

Principles of Program Analysis. Lecture 1 Harry Xu Spring 2013

Software Development. Modular Design and Algorithm Analysis

CS 1110: Introduction to Computing Using Python Loop Invariants

Lecture 18 Restoring Invariants

Transcription:

Reasoning about programs

Last time

Coming up This Thursday, Nov 30: 4 th in-class exercise sign up for group on moodle bring laptop to class Final projects: final project presentations: Tue Dec 12, in CS 150 final submission due: Fri Dec 15, 11:55 PM

Project Final Presentations December 12, 10AM-11:15AM CS 150 (in the CS building) Think of this as a science fair. Each team will get an easel. Bring a poster or printed slides. And laptop for demo. Describe and discuss the solution, and demo the implementation. Will see (at least) 2 separate judges. Chance to see other projects too!

Reasoning about programs

Ways to verify your code The hard way: Make up some inputs If it doesn't crash, ship it When it fails in the field, attempt to debug The easier way: Reason about possible behavior and desired outcomes Construct simple tests that exercise that behavior Another way that can be easy Prove that the system does what you want Rep invariants are preserved Implementation satisfies specification Proof can be formal or informal (we will be informal) Complementary to testing

Reasoning about code Determine what facts are true during execution x > 0 for all nodes n: n.next.previous == n array a is sorted x + y == z if x!= null, then x.a > x.b Applications: Ensure code is correct (via reasoning or testing) Understand why code is incorrect

Forward reasoning You know what is true before running the code What is true after running the code? Given a precondition, what is the postcondition? Applications: Representation invariant holds before running code Does it still hold after running code? Example: // precondition: x is even x = x + 3; y = 2x; x = 5; // postcondition:??

Backward reasoning You know what you want to be true after running the code What must be true beforehand in order to ensure that? Given a postcondition, what is the corresponding precondition? Applications: (Re-)establish rep invariant at method exit: what s required? Reproduce a bug: what must the input have been? Example: // precondition:?? x = x + 3; y = 2x; x = 5; // postcondition: y > x How did you (informally) compute this?

Forward vs. backward reasoning Forward reasoning is more intuitive for most people Helps understand what will happen (simulates the code) Introduces facts that may be irrelevant to goal Set of current facts may get large Takes longer to realize that the task is hopeless Backward reasoning is usually more helpful Helps you understand what should happen Given a specific goal, indicates how to achieve it Given an error, gives a test case that exposes it

Forward reasoning example assert x >= 0; i = x; // x 0 & i = x z = 0; // x 0 & i = x & z = 0 while (i!= 0) { Ü What property holds here? z = z + 1; i = i 1; Ü What property holds here? } // x 0 & i = 0 & z = x assert x == z;

Backward reasoning Technique for backward reasoning: Compute the weakest precondition (wp) There is a wp rule for each statement in the programming language Weakest precondition yields strongest specification for the computation (analogous to function specifications)

Assignment // precondition:?? x = e; // postcondition: Q Precondition: Q with all (free) occurrences of x replaced by e Example: // assert:?? x = x + 1; // assert x > 0 Precondition = (x+1) > 0

Method calls // precondition:?? x = foo(); // postcondition: Q If the method has no side effects: just like ordinary assignment If it has side effects: an assignment to every variable it modifies Use the method specification to determine the new value

If statements // precondition:?? if (b) S1 else S2 // postcondition: Q Essentially case analysis: wp( if (b) S1 else S2, Q) = ( b Þ wp( S1, Q) b Þ wp( S2, Q) )

If: an example // precondition:?? if (x == 0) { x = x + 1; } else { x = (x/x); } // postcondition: x ³ 0 Precondition: wp( if (x==0) {x = x+1} else {x = x/x}, x ³ 0) = = ( x = 0 Þ wp( x = x+1, x ³ 0) & x ¹ 0 Þ wp( x = x/x, x ³ 0) ) = (x = 0 Þ x + 1 ³ 0) & (x ¹ 0 Þ x/x ³ 0) = 1 ³ 0 & 1 ³ 0 = true

Reasoning About Loops A loop represents an unknown number of paths Case analysis is problematic Recursion presents the same issue Cannot enumerate all paths That is what makes testing and reasoning hard

Loops: values and termination // assert x ³ 0 & y = 0 while (x!= y) { y = y + 1; } // assert x = y 1) Pre-assertion guarantees that x ³ y 2) Every time through loop x ³ y holds and, if body is entered, x > y y is incremented by 1 x is unchanged Therefore, y is closer to x (but x ³ y still holds) 3) Since there are only a finite number of integers between x and y, y will eventually equal x 4) Execution exits the loop as soon as x = y

Understanding loops by induction We just made an inductive argument Inducting over the number of iterations Computation induction Show that conjecture holds if zero iterations Assume it holds after n iterations and show it holds after n+1 There are two things to prove: Some property is preserved (known as partial correctness ) loop invariant is preserved by each iteration The loop completes (known as termination ) The decrementing function is reduced by each iteration

Loop invariant for the example // assert x ³ 0 & y = 0 while (x!= y) { y = y + 1; } // assert x = y So, what is a suitable invariant? What makes the loop work? Loop Invariant (LI) = x ³ y 1) x ³ 0 & y = 0 Þ LI 2) LI & x ¹ y {y = y+1;} LI 3) (LI & (x ¹ y)) Þ x = y

Is anything missing? // assert x ³ 0 & y = 0 while (x!= y) { y = y + 1; } // assert x = y Does the loop terminate?

Total Correctness via Well-Ordered Sets We have not established that the loop terminates Suppose that the loop always reduces some variable s value. Does the loop terminate if the variable is a Natural number? Integer? Non-negative real number? Boolean? ArrayList? The loop terminates if the variable values are (a subset of) a well-ordered set Ordered set Every non-empty subset has least element

Decrementing Function Decrementing function D(X) Maps state (program variables) to some well-ordered set This greatly simplifies reasoning about termination Consider: while (b) S; We seek D(X), where X is the state, such that 1. An execution of the loop reduces the function s value: LI & b {S} D(X post ) < D(X pre ) 2. If the function s value is minimal, the loop terminates: (LI & D(X) = minval) Þ b

Proving Termination // assert x ³ 0 & y = 0 // Loop invariant: x ³ y // Loop decrements: (x-y) while (x!= y) { y = y + 1; } // assert x = y Is x-y a good decrementing function? 1. Does the loop reduce the decrementing function s value? // assert (y!= x); let d pre = (x y) y = y + 1; // assert (x post y post ) < d pre 2. If the function has minimum value, does the loop exit? (x >= y & x y = 0) à (x = y)

Choosing Loop Invariant For straight-line code, the wp (weakest precondition) function gives us the appropriate property For loops, you have to guess: The loop invariant The decrementing function Then, use reasoning techniques to prove the goal property If the proof doesn't work: Maybe you chose a bad invariant or decrementing function Choose another and try again Maybe the loop is incorrect Fix the code Automatically choosing loop invariants is a research topic

In practice I don t routinely write loop invariants I do write them when I am unsure about a loop and when I have evidence that a loop is not working Add invariant and decrementing function if missing Write code to check them Understand why the code doesn't work Reason to ensure that no similar bugs remain

More on Induction Induction is a very powerful tool n k=1 2 n =1+ 2 k 1 Proof by induction: Base Case For n=1, 1 1+ 2 k 1 =1+ 2 0 =1+1= 2 = 2 1 k=1

Inductive Step Assume m 2 m =1+ 2 k 1 and show that 2 m+1 =1+ 2 k 1 k=1 m+1 k=1 m+1 m 2 m+1 =1+ 2 k 1 =1+ 2 k 1 + 2 m = 2 m + 2 m = 2 2 m = 2 m+1 k=1 k=1

Is Induction Too Powerful?

Next time Using theorem provers to reason about programs We ll use Z3 Take a look at the tutorial before class: https://rise4fun.com/z3/tutorial/guide