When do I need an invariant? CS 5010 Program Design Paradigms “Bootcamp” Lesson 7.4 TexPoint fonts used in EMF. Read the TexPoint manual before you delete.

Slides:



Advertisements
Similar presentations
Depth-First and Breadth-First Search CS 5010 Program Design Paradigms “Bootcamp” Lesson 9.2 TexPoint fonts used in EMF. Read the TexPoint manual before.
Advertisements

Binary Search CS 5010 Program Design Paradigms “Bootcamp” Lesson 8.3 TexPoint fonts used in EMF. Read the TexPoint manual before you delete this box.:
Contracts, Purpose Statements, Examples and Tests CS 5010 Program Design Paradigms “Bootcamp” Lesson 1.6 TexPoint fonts used in EMF. Read the TexPoint.
Sometimes Structural Recursion Isn't Enough CS 5010 Program Design Paradigms “Bootcamp” Lesson 8.1 TexPoint fonts used in EMF. Read the TexPoint manual.
Two Draggable Cats CS 5010 Program Design Paradigms “Bootcamp” Lesson 3.4 TexPoint fonts used in EMF. Read the TexPoint manual before you delete this box.:
Real State vs. Simulated State CS 5010 Program Design Paradigms "Bootcamp" Lesson 11.3 © Mitchell Wand, This work is licensed under a Creative.
Reviewing your Program CS 5010 Program Design Paradigms “Bootcamp” Lesson 2.4 © Mitchell Wand, This work is licensed under a Creative Commons.
Lists vs. Structures CS 5010 Program Design Paradigms “Bootcamp” Lesson 6.1 © Mitchell Wand, This work is licensed under a Creative Commons Attribution-NonCommercial.
The 8-queens problem CS 5010 Program Design Paradigms “Bootcamp” Lesson 9.3 TexPoint fonts used in EMF. Read the TexPoint manual before you delete this.
Foldr and Foldl CS 5010 Program Design Paradigms “Bootcamp” Lesson 7.5 TexPoint fonts used in EMF. Read the TexPoint manual before you delete this box.:
Draggable Cat CS 5010 Program Design Paradigms “Bootcamp” Lesson 3.3 TexPoint fonts used in EMF. Read the TexPoint manual before you delete this box.:
Patterns of Interaction 2: Publish-Subscribe CS 5010 Program Design Paradigms "Bootcamp" Lesson 11.6 © Mitchell Wand, This work is licensed under.
The Function Design Recipe CS 5010 Program Design Paradigms “Bootcamp” Lesson 1.1 TexPoint fonts used in EMF. Read the TexPoint manual before you delete.
Midterm Review CS 5010 Program Design Paradigms “Bootcamp” Lesson 9.4 TexPoint fonts used in EMF. Read the TexPoint manual before you delete this box.:
Linear Search CS 5010 Program Design Paradigms “Bootcamp” Lesson 9.1 TexPoint fonts used in EMF. Read the TexPoint manual before you delete this box.:
Lists CS 5010 Program Design Paradigms “Bootcamp” Lesson 4.1 TexPoint fonts used in EMF. Read the TexPoint manual before you delete this box.: AAA 1 ©
Case Study: Free Variables CS 5010 Program Design Paradigms “Bootcamp” Lesson 7.3 TexPoint fonts used in EMF. Read the TexPoint manual before you delete.
Ormap, andmap, and filter CS 5010 Program Design Paradigms “Bootcamp” Lesson 5.3 TexPoint fonts used in EMF. Read the TexPoint manual before you delete.
Rewriting your function using map and foldr CS 5010 Program Design Paradigms “Bootcamp” Lesson 5.5 TexPoint fonts used in EMF. Read the TexPoint manual.
Introducing General Recursion CS 5010 Program Design Paradigms “Bootcamp” Lesson 8.2 TexPoint fonts used in EMF. Read the TexPoint manual before you delete.
Mutually-Recursive Data Definitions CS 5010 Program Design Paradigms “Bootcamp” Lesson 6.4 © Mitchell Wand, This work is licensed under a Creative.
Foldr CS 5010 Program Design Paradigms “Bootcamp” Lesson 5.4 TexPoint fonts used in EMF. Read the TexPoint manual before you delete this box.: AAA © Mitchell.
Solving Your Problem by Generalization CS 5010 Program Design Paradigms “Bootcamp” Lesson 7.1 © Mitchell Wand, This work is licensed under a.
Invariants and Performance CS 5010 Program Design Paradigms “Bootcamp” Lesson 7.6 TexPoint fonts used in EMF. Read the TexPoint manual before you delete.
The Function Design Recipe CS 5010 Program Design Paradigms “Bootcamp” Lesson 1.1 TexPoint fonts used in EMF. Read the TexPoint manual before you delete.
Generalizing Similar Functions CS 5010 Program Design Paradigms “Bootcamp” Lesson 5.1 TexPoint fonts used in EMF. Read the TexPoint manual before you delete.
Rewriting your function using map and foldr CS 5010 Program Design Paradigms “Bootcamp” Lesson TexPoint fonts used in EMF. Read the TexPoint manual.
Case Study: Free Variables CS 5010 Program Design Paradigms “Bootcamp” Lesson TexPoint fonts used in EMF. Read the TexPoint manual before you delete.
Invariants and Performance CS 5010 Program Design Paradigms “Bootcamp” Lesson TexPoint fonts used in EMF. Read the TexPoint manual before you delete.
More examples of invariants CS 5010 Program Design Paradigms “Bootcamp” Lesson © Mitchell Wand, This work is licensed under a Creative.
Generalizing Over Functions CS 5010 Program Design Paradigms “Bootcamp” Lesson TexPoint fonts used in EMF. Read the TexPoint manual before you delete.
Lists of Structures CS 5010 Program Design Paradigms “Bootcamp” Lesson TexPoint fonts used in EMF. Read the TexPoint manual before you delete this.
Solving Your Problem by Generalization CS 5010 Program Design Paradigms “Bootcamp” Lesson 7.1 © Mitchell Wand, This work is licensed under a.
Linear Search CS 5010 Program Design Paradigms “Bootcamp” Lesson TexPoint fonts used in EMF. Read the TexPoint manual before you delete this box.:
Introducing General Recursion CS 5010 Program Design Paradigms “Bootcamp” Lesson TexPoint fonts used in EMF. Read the TexPoint manual before you.
Halting Measures and Termination Arguments CS 5010 Program Design Paradigms “Bootcamp” Lesson TexPoint fonts used in EMF. Read the TexPoint manual.
Non-Empty Lists CS 5010 Program Design Paradigms “Bootcamp” Lesson TexPoint fonts used in EMF. Read the TexPoint manual before you delete this box.:
Using the List Template CS 5010 Program Design Paradigms “Bootcamp” Lesson TexPoint fonts used in EMF. Read the TexPoint manual before you delete.
Using the List Template CS 5010 Program Design Paradigms “Bootcamp” Lesson 4.2 TexPoint fonts used in EMF. Read the TexPoint manual before you delete this.
Sometimes Structural Recursion Isn't Enough CS 5010 Program Design Paradigms “Bootcamp” Lesson 8.1 TexPoint fonts used in EMF. Read the TexPoint manual.
More linear search with invariants CS 5010 Program Design Paradigms “Bootcamp” Lesson TexPoint fonts used in EMF. Read the TexPoint manual before.
Midterm Review CS 5010 Program Design Paradigms “Bootcamp” Lesson TexPoint fonts used in EMF. Read the TexPoint manual before you delete this box.:
Solving Your Problem by Generalization CS 5010 Program Design Paradigms “Bootcamp” Lesson © Mitchell Wand, This work is licensed under.
Generalizing Similar Functions
More About Recursive Data Types
CS 5010 Program Design Paradigms “Bootcamp” Lesson 4.3
CS 5010 Program Design Paradigms "Bootcamp" Lesson 9.4
Introduction to Invariants
More Recursive Data Types
CS 5010 Program Design Paradigms “Bootcamp” Lesson 8.7
Halting Functions for Tree-Like Structures
CS 5010 Program Design Paradigms “Bootcamp” Lesson 4.1
From Templates to Folds
CS 5010 Program Design Paradigms “Bootcamp” Lesson 3.4
CS 5010 Program Design Paradigms “Bootcamp” Lesson 3.2
Case Study: Undefined Variables
CS 5010 Program Design Paradigms “Bootcamp” Lesson 7.5
Solving Your Problem by Generalization
CS 5010 Program Design Paradigms “Bootcamp” Lesson 6.5
More examples of invariants
ormap, andmap, and filter
Generalizing Similar Functions
The Iterative Design Recipe
Rewriting your function using map and foldr
Examining Two Pieces of Data
CS 5010 Program Design Paradigms “Bootcamp” Lesson 4.1
When do I need an invariant?
CS 5010 Program Design Paradigms “Bootcamp” Lesson 8.3
CS 5010 Program Design Paradigms “Bootcamp” Lesson 3.4
Presentation transcript:

When do I need an invariant? CS 5010 Program Design Paradigms “Bootcamp” Lesson 7.4 TexPoint fonts used in EMF. Read the TexPoint manual before you delete this box.: AAA © Mitchell Wand, This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License. Creative Commons Attribution-NonCommercial 4.0 International License 1

Learning Objectives At the end of this lesson, the student should be able to – decide whether a purpose statement needs an invariant or not. 2

When do I need an invariant? It all depends on the purpose statement. If your code fulfills the purpose statement for any arguments of the types listed in the contract, you don't need an invariant. If the function only works for certain values or combinations of values of the arguments, then you must document that restriction with a WHERE-clause. 3

What kind of things belong an invariant? It all depends on your purpose statement! If the function needs additional information that is not in the arguments, then you need an invariant to document the needed information What kind of information might you want? – context information (e.g. we are position n in the list) – other knowledge that isn't expressed in the contract (e.g. we've figured out the ball isn't going to bounce). It is up to each caller of the function to make sure that the invariant is true at every call. 4

Whose responsibility is it? What kind of information might you want? – context information (e.g. we are position n in the list) – other knowledge that isn't expressed in the contract (e.g. we've figured out the ball isn't going to bounce). It is up to each caller of the function to make sure that the invariant is true at every call. 5

Whose responsibility is it? The invariant, along with the contract, sets down the assumptions that each function makes about the arguments that it processes It is up to each caller of the function to make sure that the invariant is true at every call. 6

Example: ;; ball-normal-motion : Ball -> Ball ;; GIVEN: a Ball ;; WHERE: the Ball is not going to ;; collide with a wall on this tick ;; RETURNS: the state of the ball after a ;; tick. (define (ball-normal-motion b) (make-ball (+ (ball-x-pos b) BALLSPEED))) Doesn't work for every Ball!.. Needs more information Invariant provides the necessary information 7

Example ;; number-list-from : ListOf Number -> NumberedListOf ;; RETURNS: a list with same elements as lst, but numbered ;; starting at n. ;; EXAMPLE: (number-list-from (list 88 77) 2) ;; = (list (list 2 88) (list 3 77)) ;; STRATEGY: Structural Decomposition on lst : ListOf (define (number-list-from lst n) (cond [(empty? lst) empty] [else (cons (list n (first lst)) (number-list-from (rest lst) (+ n 1)))])) Works for any lst and n, so no invariant necessary. 8

;; number-list-from : ;; ListOf Number -> NumberedListOf ;; GIVEN: a sublist slst of some list lst0 ;; WHERE: slst is the n-th sublist of lst0 ;; RETURNS: a copy of slst numbered according to its ;; position in lst0. ;; STRATEGY: struct decomp on slst : ListOf (define (number-sublist slst n) (cond [(empty? slst) empty] [else (cons (list n (first slst)) (number-sublist (rest slst) (+ n 1)))])) Example: Same Code, different purpose statement Function can't fulfill its purpose unless it knows where slst is in lst0 Invariant supplies the extra information 9

Wait, weren't those functions very similar? Yes. In fact they were identical (except for their names). The moral of the story is that it is the purpose statement that determines whether you need an invariant. 10

Once more: When do I need an invariant? If your code fulfills the purpose statement for any arguments of the types listed in the contract, you don't need an invariant. If the function only works for certain values or combinations of values of the arguments, then you must document the assumptions that it needs with a WHERE-clause (i.e. an invariant). 11

What needs to be in my purpose statement? The purpose statement must account for all the parameters. – if it doesn't then either you are passing more parameters than you need, or there's something going on that you haven't described. The RETURNS clause must describe the value returned by the function for all possible values of the parameters. If the RETURNS clause describes the value returned by the function only for some values of the arguments or some combination of arguments, then that restriction must be stated in a WHERE clause. It becomes the responsibility of the caller to guarantee that the restriction is satisfied. 12

Another example ;; add-remaining-length : LoN -> LoN ;; RETURNS: a list like the original, but with each ;; element increased by the length of the sublist ;; starting at that element. ;; ( ) => ( ) ;; Strategy: SD on lst (define (add-remaining-length lst) (cond [(empty? lst) empty] [else (cons (+ (first lst) (length lst)) (add-remaining-length (rest lst)))])) Yuck! 13

Let's help the function along by giving it the length of the list as an argument ;; add-remaining-length-1 : LoN Number-> LoN ;; GIVEN: a Lon lst and a number n ;; WHERE: n = (length lst) ;; RETURNS: a list like the original, but with each ;; element increased by the length of the sublist ;; starting at that element. ;; ( ) 3 => ( ) ;; Strategy: SD on lst (define (add-remaining-length-1 lst n) (cond [(empty? lst) empty] [else (cons (+ (first lst) n) (add-remaining-length-1 (rest lst) (- n 1)))])) Doesn't give the right answer unless invariant is satisfied 14

Summary: When do I need an invariant? It all depends on your purpose statement! If the function needs additional information that is not in the arguments, then you need an invariant to document the needed information It is up to each caller of the function to make sure that the invariant is true at every call. 15

Summary The student should now be able to – decide whether a purpose statement needs an invariant or not. 16

Next Steps If you have questions about this lesson, ask them on the Discussion Board Go on to the next lesson 17