Mathematically Rigorous Software Design

Size: px
Start display at page:

Download "Mathematically Rigorous Software Design"

Transcription

1 Mathematically Rigorous Software Design an electronic textbook by 2002 September 9 McMaster University Department of Computing and Software SFWR ENG/COMP SCI 4/6L03 Table of Contents 1. Introduction General Overview of this book Exercises 7 2. Mathematical model of a program and its execution Program variables Data environments Values of variables and expressions in the context of a data environment The value of an ordinary variable in a data environment The value of an expression in a data environment The value of an array variable in a data environment Boolean expressions and sets of data environments Program statements and constructs as functions on ID to ID The assignment statement Assignment to an ordinary variable Assignment to an array variable Multiple assignment statement The exchange statement The declare statement The release statement The null (empty) statement The sequence of statements The if statement The while loop The subprogram call without formal parameters Basic vs. compound program statements Other loop structures The subprogram call with formal parameters Input/output Preconditions and postconditions Ordinary preconditions

2 3.2 Strict preconditions Partial and total correctness Complete preconditions Summary of the lemmata for preconditions Referring in the postcondition to values of variables prior to execution Proof rules The several proof related tasks Rule P1: strengthening a precondition and weakening a postcondition Divide and conquer rules Rule DC Rule DC Rule DC Rule DC Rules for the assignment statement Rule A Rule A Rules for sequences of statements Rule S1 for the sequence of statements Rule S2 for the sequence of assignment statements Rules for the if statement Rule IF1 for verifying a correctness proposition about an if statement Rule IF2 for deriving a precondition with respect to an if statement Rules for the while loop Rule W1 for the while loop without initialization Rule W2 for the while loop with initialization Loop termination Rules for the subprogram Rule SP Rule SP Rule SP Rules for the declare statement Applying rules for the assignment statement to the declare statement Rule D Rule D Applying rules to other types of program statements Rules applicable to the release statement The null statement Applying the rules in proofs of correctness: examples Proof of correctness of the linear search Strengthening the postcondition of the body of a loop Proof of correctness of the merge External view of the subprogram merge Internal view of the subprogram merge

3 6. Designing correct programs General The interface specification Applying the rules to deduce the program statement types Assignment and declare statements Sequence of program segments If statement While loop The loop invariant The initialization The while condition The loop body The subprogram call Design example: a program segment to sum the elements of an array An informal design approach A more formal design approach Design example: partitioning with pointers, deriving a program from its specification Specification for the subprogram twopartition Overview of the design steps The loop invariant The initialization of the loop The loop condition The body of the loop Other required parts of twopartition The complete subprogram twopartition Termination Rules for strict preconditions Rules for the assignment statement Rule AS Rule AS Rules for the declare statement Rule DS Rule DS Rules for the release statement Rule RS Rule RS Rule NS for the null statement Rule SS for the sequence of statements Rules for the if statement Rule IFS Rule IFS Rules for the while loop Rule WS Rule WS Applying the rules for strict and semistrict preconditions

4 8. Guidelines for specifications, conditions and proofs Contents of an interface specification Specifying a non-terminating program References to sets in preconditions and postconditions Guidelines for formulating a loop invariant Formulating a postcondition for a given precondition Variables marking boundaries of regions in arrays Presenting a proof of correctness Stating the theorems to be proved Presenting the proof Proof schemes The detailed proof Rules for preconditions and postconditions referring to hidden variables Notation for referring to hidden variables Rules for the declare statement Rule DHS Rule DHS Rules for the release statement Rule RHS Rule RHS Proofs of the above rules Rules for hidden variables and statements other than declare and release statements Conclusion 99 Appendix A. Bibliography 101 Appendix B. Exercises

5 1. Introduction 1.1 General Characteristic of every engineering field is a theoretical, scientific foundation upon which most of the engineer s work is based. Engineers continually, systematically, consciously and even subconsciously use mathematical models when designing and analyzing artifacts. This basis for engineering work is a prerequisite for achieving the reliability of designs to which engineers, their clients and society have become accustomed. This electronic book presents such a theoretical, scientific foundation for designing software and for proving mathematically that it is correct, i.e. that it satisfies its specification. In particular, this book presents a mathematical model of a program and its execution which enables one to design a program to satisfy a given specification and to prove that the program does, in fact, satisfy that specification. Today s engineering disciplines did not always have such scientific foundations and mathematical models for designing and analyzing their machines, devices and systems. The magnificent new warship Wasa sank on her maiden voyage in 1628 primarily because her designers did not know how to analyze her proposed hull shape and weight distribution in order to determine before construction whether or not she would be stable in the water. In the 1800s many bridges in Europe collapsed under the weight of the new locomotives, mainly because their designers did not know how to verify in advance that the bridge s proposed structure was capable of carrying the planned loads. In 1858 the first successfully laid transatlantic telegraph cable was destroyed by an excessively high input voltage. In all of these cases, the designers lacked predictive models of the artifacts they were designing, models which would enable them to determine with confidence and before construction whether or not their designs would satisfy the requirements placed on them. At those times, the several fields were in their pre-engineering phase. In today s software development practice, similar failures occur for similar reasons, e.g. the explosion of the Ariane 5 in Software development practice is currently in its preengineering phase. As with the Wasa, large bridges in the 1800s, early electrical communication systems, etc., today s software developers are constructing wonderful, impressive systems, but too often those systems fail with spectacular consequences. Software developers do not yet have and regularly use predictive mathematical models of the software they design. Sooner or later, this situation will change and software development will enter its engineering phase. You, the students of today, will bring about and experience this transition during your professional careers. The material you learn from this book will help you do this. In the now classical engineering disciplines, engineers regularly base their work on mathematical models and laws relating the various relevant variables. In the future, the same will apply in software engineering. The relevant mathematical models include variables such as the following: - 5 -

6 Electrical engineering Wasa/nautical engineering Software engineering voltage angle of heel precondition current righting torque postcondition resistance heeling torque (wind on sails) loop invariants inductance rotational energy intermediate conditions capacitance program segment Another prerequisite for designing large systems that work is precisely defined interfaces between the various subsystems and components. This book will identify the information required in interface specifications for software systems. 1.2 Overview of this book The goals of this course and book are: to familiarize the student and reader with the basic concepts underlying correctness proofs for computer software, to illustrate how they can be applied to designing software, to show how they can be practically used to verify the correctness of a program, i.e. that the program fulfills its specification and to develop the student s ability to apply these concepts and techniques to practical software design problems. The topics covered in this book are: A mathematical model of a program and its execution, consisting of: program variable, data environment, value of an ordinary variable, of an array variable and of an expression in the context of a data environment, the correspondence between Boolean expressions and sets of data environments, program statements and constructs (assignment statement, declaration statement, release statement, sequence of statements, if construct, while loop, subprogram call without formal parameter passing, other loop structures) as functions on the set of data environments and the domains of these functions Preconditions (ordinary, semistrict, strict and complete), postconditions, partial, semitotal and total correctness Proof rules (lemmata) for the various program statements and constructs Handling other program constructs (e.g. input and output, files, subprogram calls with formal parameter passing) in correctness proofs Proving the correctness of a program: decomposing a correctness statement (theorem) to be proved by applying the proof rules systematically and iteratively, verifying the universal truth of the resulting (decomposed) propositions Designing a correct program: implication of the proof rules for the design task, design guidelines following from the proof rules and the requirements of a proof of correctness - 6 -

7 Summary The scientific foundation and mathematical models for the artifacts we will be designing and analyzing computer programs can, like their counterparts in the classical engineering disciplines, be used informally and intuitively to provide general guidelines for designing the program, more formally to derive mathematically many parts of the program being designed and mathematically rigorously to verify formally that the design (the program) satisfies the specification. This material both contributes to a better general understanding of the design task and provides a method for formally calculating the correctness of the final program. 1.3 Exercises This book does not contain exercises for the reader to solve. See Appendix B below for sources of appropriate exercises

8 2. Mathematical model of a program and its execution 2.1 Program variables A program variable is a triple consisting of a name, a set, and an element of that set. The element is called the value of the program variable. A program variable is often called simply a variable. Note that the set may not be empty, because the value must be an element of it. Example: (x, Z, 4) 2.2 Data environments A data environment is a sequence of program variables. Example: [(x, Z, 4), (y, R, 5.77), (z, Strings, abc ), (x, Z, 6), (x, Z, 4)] Note that a data environment may contain more than one program variable with the same name. Even identical program variables may appear in a data environment. We write ID for the set of all data environments. We assume that this set exists (cf. Russell s paradox). In practice this assumption is not problematic. The existence of this set can be ensured by restricting the sets allowed in the program variables to eliminate the possibility of recursive definitions and by limiting the length of allowed data environments, for example. The state of execution of a program is represented by a data environment. Two data environments are equal when they are identical in every respect. Two data environments are structurally equal when they are identical in every respect except the values of their program variables. A data environment d contains the variable x when there is some program variable in d with the name x, i.e. when at least one term in d is a program variable whose name is x. Example: d0 [(x, Z, 4), (y, R, 5.77), (z, Strings, abc ), (x, Z, 6), (x, Z, 4)] d1 [(x, Z, 4), (y, R, 5.77), (z, Strings, abc ), (x, Z, 6), (x, Z, 4)] d2 [(x, Z, 4), (y, R, 5.77), (z, Strings, xyz ), (x, Z, 6), (x, Z, 4)] The data environments d0 and d1 are equal. The data environments d1 and d2 are not equal, but they are structurally equal. Each of the above data environments contains the variables x, y and z. None of the above data environments contains the variable a. 2.3 Values of variables and expressions in the context of a data environment The value of an ordinary variable in a data environment The value of the variable x in the data environment d is defined to be the value of the first program variable in d whose name is x. If the data environment d does not contain a program variable with the name x, then the value of x in d is undefined. Example: d [(x, Z, 4), (y, R, 5.77), (z, Strings, abc ), (x, Z, 6)] - 8 -

9 The value of x in d is 4 (not 6). The value of y in d is The value of z in d is abc. The value of w in d is undefined. A variable name can be viewed as a function on ID which maps a data environment to a value. I.e., x.d4, y.d5.77, z.d abc and w.d is undefined where d is as defined in the example above. Alternatively, a data environment can be viewed as a function on the set of variable names that maps the variable name to a value The value of an expression in a data environment To determine the value of an expression E in a data environment d, every variable name in E standing for the value of the named variable is replaced by the value of that variable in d (see definition above) and the resulting expression is evaluated in the usual mathematical way. The resulting value is the value of E in d. An expression can be viewed as a function on ID which maps a data environment to a value. Correspondingly, the value of an expression E in a data environment d is often written E.d. Example: d [(x, Z, 4), (y, R, 5.77), (z, Strings, abc ), (x, Z, 6)] The value of the expression (2*x+y) in d is (2*x+y).d (2*x.d+y.d) 2* The value of an array variable in a data environment References to an array variable are typically of the form x(ie), where ie is an expression evaluating to an integer. The name of an array variable is not of the form x(ie), but rather x(1), x(2), etc. To determine the value of an array variable x(ie) in the data environment d, the index expression ie is first evaluated (in d) and then the value of the array variable with the corresponding index is determined as defined above. Formally, we define the value of an array variable in a data environment as follows: x(ie).d x(ie.d).d Example: d [(x(1), Z, 5), (x(2), Z, 6), (j, Z, 3), (k, Z, 4)] The value of x(k-j) in d is x(k-j).d x((k-j).d).d - 9 -

10 x(k.d-j.d).d x(4-3).d x(1).d Boolean expressions and sets of data environments Often we will consider those data environments d for which some Boolean expression (function, condition) B is true, i.e. data environments d in the set ( d : d ID B.d : {d}). (Note that this set is the preimage of the singleton set {true} under B.) Because of the canonical relationship between a condition and such a set, we will often use the same name (here B) for both the condition and the set. It will be clear from the context which is meant mathematically. Conversely, we will refer to any condition which is true on a given set B and either false or undefined elsewhere by the same name B. For a given condition the corresponding set is uniquely determined. For a given set, the corresponding condition is not uniquely determined: whether the condition is false or undefined for any particular element not in the set is left open. 2.5 Program statements and constructs as functions on ID to ID The execution of a program statement or segment upon a program execution state is viewed below mathematically as the application of a function corresponding to the program statement or segment in question to the data environment representing the state in question The assignment statement Assignment to an ordinary variable Informally we define the effect of executing the assignment statement x:e (where x is a variable name and E is an expression) on the data environment d in the following way. The expression E is evaluated in d and the result becomes the new value of the first variable in d whose name is x. Formally, this is defined as follows: (x:e).d0 d1, where d0 [(N 0,1, S 0,1, V 0,1 ), (N 0,2, S 0,2, V 0,2 ),...] d1 [(N 1,1, S 1,1, V 1,1 ), (N 1,2, S 1,2, V 1,2 ),...] N 1,i N 0,i for all i1, 2,... S 1,i S 0,i for all i1, 2,... j (min k : k N 1 N 0,k x : k) [j is the index of the first variable named x]

11 V 1,i V 0,i for all i j V 1,j E.d0 provided that E.d0 S 1,j (S 0,j ) otherwise (N 1,j, S 1,j, V 1,j ) would not satisfy the definition of a program variable and d1 would not, therefore, satisfy the definition of a data environment. Note also that the above definition leads to a result only if d contains a program variable with the name x. Note also that the above definition does not permit side effects, i.e. the modification of the value of any variable other than x. In the following, we will refer often to the set associated with a particular program variable. We define, therefore, (Set. x ).d to be the set associated with the first program variable in d with the name x. If d contains no variable with the name x, we define the value of (Set. x ).d to be the empty set. (Note that no set associated with a program variable may be empty, since the value of the variable must be an element of the set.) The domain of the function x:e is the set of all data environments d such that (1) d contains at least one variable with the name x, (2) E.d is defined and (3) E.d is an element of (Set. x ).d. These requirements can be combined into the condition that E.d (Set. x ).d be true or, equivalently, that (E (Set. x )).d be true Assignment to an array variable The effect of executing the assignment statement x(ie):e on the data environment d, where ie and e are expressions, is defined informally as follows: First the expression ie is evaluated in d to determine the index of the array variable to which a new value is to be assigned. Then the assignment statement is executed as described above. Formally, we define (x(ie):e).d to be (x(ie.d):e).d Multiple assignment statement When the multiple assignment statement (x1, x2,...):(e1, e2,...) is executed, each expression e1, e2, etc. is evaluated in the same initial data environment. The results are assigned to the variables x1, x2,... respectively as in the case of the single assignment statement as defined above. If the same variable name appears more than once on the left hand side of the multiple assignment statement, we require that the values of the corresponding expressions on the right hand side be equal, otherwise the effect of executing the multiple assignment statement is undefined. The same variable can appear more than once on the left hand side, for example, when array variables are referenced whose index expressions have the same value in the data environment in question

12 The exchange statement The exchange statement x::y is defined to have the same effect as the multiple assignment statement (x, y):(y, x) The declare statement The execution of the statement declare (x, S, E) on the data environment d has the effect of creating a new program variable and prefixing it to d. Formally, we define (declare (x, S, E)).d [(x, S, E.d)] & d where & is the concatenation operator, which combines two sequences into a single sequence. In principle, one could also allow S to be an expression, in which case one would rewrite the right hand side of the above definition to read [(x, S.d, E.d)] & d. We will not make use of this possibility in this book. If the variable to be declared is an array variable, the index expression is first evaluated as mentioned earlier. I.e. formally, (declare (x(ie), S, E)).d (declare (x(ie.d), S, E)).d, which, in turn, equals [(x(ie.d), S, E.d)] & d. If the data environment d already contains a variable named x and the statement declare (x, S, E) is executed on d, the resulting data environment will contain two variables named x. By executing still more declare statements, a data environment containing many variables with the same name can be formed. Subsequent references to x will pertain only to the most recently declared variable named x. The other variables with the same name are hidden (or covered). A hidden variable will become active again only when the more recently declared variables of the same name are released. The more recently declared variables of the same name are sometimes called covering variables. The domain of the declare statement is comparable to that of the corresponding assignment statement with the exception that a variable with the name x need not be already contained in d. The domain of the above declare statement is the set of all data environments d such that E.d S or, equivalently, (E S).d. If the variable being declared is an array variable, i.e. if the declare statement declare (x(ie), S, E) is being applied to the data environment d, then the value of ie in d must be an element of an appropriate set Siv (the set of index values, typically ( i : i Z 1 i : Z i ), the set of all tuples of one or more integers). The domain of such a declare statement is, then, the set of all data environments d such that (E S and ie Siv).d. The above expressions for the domains of declare statements for ordinary and array variables are different. This gives rise to no difficulty in manual proofs of program correctness, but mechanizing such proofs would be simpler if the need to distinguish between the two cases were eliminated. This can be done by considering an ordinary variable to be an array variable with an

13 empty tuple as its index and redefining Siv above to include the empty tuple. Then, Siv would typically be the set ( i : i Z 0 i : Z i ) The release statement Executing the statement release x on the data environment d removes the first program variable with the name x from the data environment. Formally, (release x).d0 d1, where d0 [(N 0,1, S 0,1, V 0,1 ), (N 0,2, S 0,2, V 0,2 ),...] d1 [(N 1,1, S 1,1, V 1,1 ), (N 1,2, S 1,2, V 1,2 ),...] j (min k : k N 1 N 0,k x : k) [j is the index of the first variable named x] N 1,i N 0,i for all i<j N 1,i N 0,i+1 for all i j S 1,i S 0,i for all i<j S 1,i S 0,i+1 for all i j V 1,i V 0,i for all i<j V 1,i V 0,i+1 for all i j If the variable to be released is an array variable, the index expression is first evaluated as mentioned earlier. I.e. formally, (release x(ie)).d (release x(ie.d)).d. The declare and release statements are, in effect, push and pop operations on a stack of program variables of the same name embedded in the data environment. The above definition yields a result for every d which contains a variable named x. I.e., the domain of release x is the set of all data environments d such that (Set. x ).d or, equivalently, (Set. x ).d. Therefore, the Boolean condition characterizing the domain of the statement release x is Set. x. If the variable being released is an array variable, then the value of the index expression in d must, of course, be an element of the set Siv (see section above). The domain of the statement release x(ie) would, then, be (Set. x(ie) and ie Siv). But if the variable x(ie) is contained in the data environment in question, the value of its index ie must be an element of the permitted set of index values, so that Set. x(ie) ie Siv. Thus, the term ie Siv is redundant in the expression for the domain of a statement releasing an array variable

14 2.5.4 The null (empty) statement The null (empty) statement occurs mainly in the form of an empty then or else part of an if statement. It is defined to have no effect, i.e. null.d d for all d ID. The domain of the null statement is ID The sequence of statements When a sequence (S1, S2) of statements is executed on the data environment d, first S1 is executed and then S2 is executed on the result of executing S1. I.e. formally, we define (S1, S2).d S2.(S1.d) Mathematically, the function (S1, S2) is the composition of the functions S1 and S2. Sequencing statements is, therefore, associative. It is not, in general, commutative. The domain of the sequence (S1, S2) of statements is the set of all data environments d such that d is in the preimage of ID under the function (S1, S2), i.e. such that d S1-1.(S2-1.ID). I.e. the domain of the sequence (S1, S2) of statements is S1-1.(S2-1.ID) The if statement When executing the statement if B then S1 else S2 endif the condition B is first evaluated. Depending upon whether its value is true or false, S1 or S2 respectively is executed. Formally, we define (if B then S1 else S2 endif).d S1.d, if B.d true S2.d, if B.d false If B.d is undefined, then (if B then S1 else S2 endif).d is undefined. Note that the above definition excludes side effects arising from evaluating the if condition B. The domain of the if statement above consists of all data environments d such that (1) B.d is true and d is in the domain of S1 or (2) B.d is false and d is in the domain of S2. Expressed more formally, the domain is the set B -1.{true} S1-1.ID B -1.{false} S2-1.ID or, writing Bt for the subset of ID on which B is true and Bf for the subset of ID on which B is false, Bt S1-1.ID Bf S2-1.ID The while loop When the while loop

15 while B do S endwhile is executed, the condition B is first evaluated. If its value is true, the loop body S is executed and the entire while loop is executed again. If the value of B is false, the while loop is equivalent to the null statement; execution proceeds with the following statement, if any. Formally, the execution of the above while loop, abbreviated W below, is defined as follows: W.d (S, W).d, if B.dtrue d, if B.dfalse Note that this definition excludes the possibility of side effects resulting from evaluating the while condition B. While lemma 1: Applying the definition of the sequence of statements to the above definition of the while loop leads to: W.d W.(S.d), if B.dtrue d if B.dfalse While lemma 2: For all n N 0 and all d ID B.(S n.d)false and n-1 j0 B.(Sj.d)true W.dS n.d Proof: induction on n. Base case, n0: reduces to B.(S n.d)false and n-1 j0 B.(Sj.d)true W.dS n.d B.dfalse W.dd which is true by the definition of the while loop above. Inductive step: We assume that the thesis of this lemma is valid for nk 0, i.e. that B.(S k.d)false and k-1 j0 B.(Sj.d)true W.dS k.d is true for all d ID, and must prove that it is true for nk+1. Since the above expression is true for all d, it is true for the data environment S.d: B.(S k.(s.d))false and k-1 j0 B.(Sj.(S.d))true W.(S.d)S k.(s.d) B.(S k+1.d)false and k-1 j0 B.(Sj+1.d)true W.(S.d)S k+1.d

16 B.(S k+1.d)false and k j1 B.(Sj.d)true W.(S.d)S k+1.d [WL2a] By while lemma 1, B.dtrue W.dW.(S.d) [WL2b] Together [WL2a] and [WL2b] imply B.(S k+1.d)false and B.dtrue and k j1 B.(Sj.d)true W.dW.(S.d)S k+1.d B.(S k+1.d)false and k j0 B.(Sj.d)true W.dS k+1.d I.e., the thesis of this lemma is valid for nk+1. Domain of the while statement: The domain of the while loop above can be identified iteratively. Denote the set of data environments for which the while loop terminates after exactly n executions of the loop body by Z n. From the definition of the while loop it is evident that Z 0 Bf where Bf is the set of data environments upon which the while condition B is false (in other words, Bf is the preimage of the singleton set {false} under B). Z 1 is the set of data environments upon which B is true (so that the body of the loop will be executed, cf. the definition of the while loop) and upon which the execution of S will lead to a data environment in Z 0. That is, Z 1 is the intersection of Bt and the preimage of Z 0 under S: Z 1 Bt S -1.Z 0 where Bt is the set of data environments upon which the value of B is true (the preimage of {true} under B). Correspondingly, Z n Bt S -1.Z n-1 for all positive integers n. In closed form, Z n S -n.bf n-1 j0 S-j.Bt or, in the form of a Boolean expression (condition), Z n.d [B.(S n.d)false and n-1 j0 B.(Sj.d)true] Cf. while lemma

17 The domain of the while loop is the union of all Z n : n0 Z n n0 S-n.Bf n-1 j0 S-j.Bt or, in the form of a Boolean expression (condition) or n0 B.(Sn.d)false and n-1 j0 B.(Sj.d)true The subprogram call without formal parameters If a procedure (subprogram) P consists of the program segment S, then the effect of calling P is the same as executing S. Formally, (call P).d S.d for all d ID. The domain of call P is the same as the domain of S. Note that the domain of any program segment S is S -1.ID, the preimage of ID under S Basic vs. compound program statements The above eight program statements fall naturally into two categories: basic statements (assignment, declare, release and null) and the compound statements (sequence, if, while and subprogram call). This distinction will be of some interest later Other loop structures Other loop structures can be defined in terms of the while loop. For example, repeat S until B endrepeat is defined as the sequence of S followed by a corresponding while loop: S, while not B do S endwhile The loop with an internal exit loop S1 if B then exit S2 endloop is defined as

18 S1, while not B do S2, S1 endwhile Still other loop structures, such as the for loop, can be defined in a similar manner, whereby implementational variations must be taken into account The subprogram call with formal parameters Subprogram calls with formal parameter passing will be modelled by equivalent combinations of the program statements already defined above. Details of the mechanisms invoked by formal parameter passing vary somewhat from implementation to implementation in ways which can and do affect the correctness of a program. They must, therefore, be considered explicitly by the software developer responsible for the correctness of the program in which these mechanisms are used. Most implemented schemes for passing formal parameters are either the classical call by value or call by name mechanisms or variants thereof. A call by value causes a new, local variable to be declared whose initial value is the value of the actual parameter. This local variable is released at the end of the subprogram. With the call by name, every reference to the formal parameter in the subprogram is a reference to the corresponding actual parameter in the calling environment. In effect, the name of the formal parameter is changed throughout the subprogram to the actual parameter (the variable name or the expression, not the value of the actual parameter) and the resulting subprogram executed. The original of the subprogram is effectively a template for generating the subprogram to be executed, not the subprogram itself. Naming conflicts are eliminated by changing names of variables in a suitable manner. Consider the following call to the subprogram P. The expressions a1 and a2 are the actual parameters and f1 and f2, the formal parameters. The formal parameter f1 is called by value and f2 is called by name. The subprogram call is call P(a1, a2) and the subprogram P is defined to be subprogram P(f1: Z; value, f2: name) f2:f1/5 end subprogram The call with formal parameters (call P(a1, a2)) is defined to be equivalent to the call without parameters call Pn where the subprogram Pn is declare (f1, Z, a1) a2:f1/5 release f1-18 -

19 Note that in reality there is no program variable f2; all original references to f2 are really references to the actual parameter a2 in the calling environment. Many variants of these two mechanisms for passing parameters between the calling and the called environment will be found in implemented systems. They can be quite convenient in programming practice, but can affect the results of executing the program in which they are used in important ways. The software developer using them remains responsible for the correctness of the program and must, therefore, fully understand the mechanisms invoked Input/output Many programming languages have various statements for performing input and output operations, e.g. read, write, get, put, print, seek, etc. These statements are nothing other than assignment statements and subprograms whose primary functional components are assignment statements in disguise. E.g. the statement print x; y can be viewed as the sequence screen(currentline):str(x)&str(y) currentline:currentline+1 where currentline is an internal system variable and screen is an array whose last several elements are displayed on the video display screen by the hardware (possibly in combination with system software). Fields in direct access files are probably most conveniently modelled as array variables. For example, the sequence of commands seek#1, r; read#1, x may be defined or modelled by the statements pos(1):r; x:filerecord(1, pos(1)) where pos is an array of internal system variables and the array filerecord encompasses the values stored in all files

20 3. Preconditions and postconditions Mathematical theorems have the form: if a specified hypothesis is true, then the specified thesis is true. Theorems about the correctness of a program also have this form. Typically such correctness propositions have the more detailed form: if X is true before the program is executed, then Y will be true afterward. The hypothesis X is called the precondition of the program and the thesis Y, the postcondition. Most frequently, preconditions and postconditions refer to the values of program variables, but statements about the structure of the data environments before and after execution of the program in question are also formulated and proved. In addition, statements about which variables are and are not modified by the execution of a program are of interest. Together, a precondition and a postcondition represent a specification of a program segment a specification of its interface with other parts of the program, in particular, of the interface between the calling program and the called subprogram. If the truth of a condition V before the execution of a program segment S ensures the truth of a condition P afterward, we say that V is a precondition of P with respect to S. This statement is still vague regarding whether the effect of executing S is defined or not and, more particularly, whether the truth of V before execution ensures that that effect is defined or not. The different possibilities lead to the definition of different types of preconditions. 3.1 Ordinary preconditions A subset V of ID is a precondition of a given postcondition P (also a subset of ID) with respect to the statement S if S.d is in P for every d in V and in the domain of S. One writes {V}S{P} for this relationship. Formally, {V}S{P} (A d : d V S -1.ID : S.d P) [formal definition of {V}S{P}] Note that if V and P are viewed as Boolean functions (conditions) instead of as sets (cf. section 2.4 above), this definition becomes {V}S{P} (A d : d S -1.ID V.d : P.(S.d)) A precondition includes (1) arbitrary data environments which the program segment maps to data environments in P and (2) arbitrary data environments which are outside of the domain of the program segments. A precondition does not include any data environments which the program segment maps to data environments outside of P. Thus, the truth of (an ordinary precondition) V before execution of S ensures that the result of executing S if any will satisfy the postcondition P. Expressed somewhat differently, the prior truth of V guarantees that the execution of S will not yield a defined but incorrect result. Lemma for an ordinary precondition: {V}S{P} (V S -1.ID S -1.P) Proof: {V}S{P} [definition of {V}S{P}]

21 (A d : d V S -1.ID : S.d P) [follows from the definition of a preimage] (A d : d V S -1.ID : d S -1.P) [definition of a subset] V S -1.ID S -1.P 3.2 Strict preconditions When the prior truth of a condition V ensures that the execution of S yields both a defined and a correct result (i.e. a result satisfying the postcondition P), then we say that V is a strict precondition of P with respect to S. For this relationship one writes {V}S{P} strictly. This will be the case if V is both an ordinary precondition (see above) and a subset of the domain of S. Formally, {V}S{P} strictly ({V}S{P} V S -1.ID) [formal definition of {V}S{P} strictly] A strict precondition is, of course, also an ordinary precondition. Lemma for a strict precondition: {V}S{P} strictly (V S -1.P) Proof: {V}S{P} strictly [definition of {V}S{P} strictly] {V}S{P} V S -1.ID [lemma for an ordinary precondition] V S -1.ID S -1.P V S -1.ID [V S -1.ID V S -1.ID V] V S -1.P V S -1.ID [P ID, S -1.P S -1.ID] V S -1.P 3.3 Partial and total correctness The literature on proving programs correct distinguishes between partial and total correctness. A program is said to be partially correct if its execution yields a correct result when it yields a result at all, which is not guaranteed. I.e. a program is partially correct if it never yields an incorrect result. A program is said to be totally correct when its execution is guaranteed to yield a defined result which is correct. I.e. a program is totally correct if its execution always yields a correct result. An ordinary precondition as defined above corresponds to partial correctness; a strict precondition, to total correctness. It is useful to distinguish between partial and total correctness or, correspondingly, between ordinary and strict preconditions because the approaches employed to prove the two are often

22 quite different and involve different arguments, especially regarding the termination of loops. Proofs are usually simplified, often considerably, by separating these two concerns. 3.4 Complete preconditions The literature on proving programs correct often refers to weakest preconditions, but does not usually deal with the domains of the various program statements in the detail considered here. As a result, the concept of a weakest precondition in the strict mathematical sense is not particularly meaningful in the present context. The essence of the concept of a weakest precondition is that it encompasses all initial data environments (program states) which the program segment in question maps to data environments satisfying the postcondition. These observations motivate the following definition of a third type of precondition: A subset V of ID is a complete precondition of a given postcondition P with respect to the program segment S if V is an ordinary precondition of P with respect to S and the preimage of P under S is a subset of V. For this relationship one writes {V}S{P} completely. Formally, {V}S{P} completely {V}S{P} S -1.P V [formal definition of {V}S{P} completely] Lemma for a complete precondition: {V}S{P} completely (V S -1.ID S -1.P) Proof: {V}S{P} completely [definition of {V}S{P} completely] {V}S{P} S -1.P V [lemma for an ordinary precondition] V S -1.ID S -1.P S -1.P V [P ID, S -1.P S -1.ID] V S -1.ID S -1.P S -1.P V S -1.P S -1.ID V S -1.ID S -1.P S -1.P V S -1.ID V S -1.ID S -1.P Lemma for a strict and complete precondition: {V}S{P} strictly and completely (VS -1.P) Proof: {V}S{P} strictly and {V}S{P} completely [definition of a complete precondition] {V}S{P} strictly (S -1.P V) [lemma for a strict precondition] (V S -1.P) (S -1.P V) VS -1.P

23 The following diagram shows the relationships between the domain of a statement, an ordinary precondition, a strict precondition, a complete precondition and the preimage of the postcondition. Relationships between the domain of a statement, an ordinary precondition, a strict precondition, a complete precondition and the preimage of the postcondition 3.5 Summary of the lemmata for preconditions The four lemmata for an ordinary, a strict, a complete and a strict and complete precondition are summarized below. The equivalent expression for the proposition {V}S{P} depends upon whether the precondition is ordinary, strict, complete or strict and complete and is as follows: not strict strict not complete V S -1.ID S -1.P V S -1.P complete V S -1.ID S -1.P VS -1.P 3.6 Referring in the postcondition to values of variables prior to execution Sometimes it is desirable to refer in the postconditon to values of variables in the data environment before execution of the program segment in question. There are several ways of looking at such a situation mathematically, one of which is the following

24 When we write {V} S {P(x, x', y)} where the postcondition P(x, x', y) is an expression in which x represents the value of the program variable x after execution of S, x' represents the value of the program variable x before execution of S and y represents the value of another program variable y after execution of S, we mean (A x' : x' M : {V and xx'} S {P(x, x', y)}) where M is a suitable set usually evident from the context. E.g. M is typically the set associated with the variable x in the initial data environment. In this view, x' is a parameter of the correctness proposition {V} S {P(x, x', y)} or {V and xx'} S {P(x, x', y)}. We require that the correctness proposition be true for all values of this parameter. Such a parameter x' is sometimes called a specification variable (see Kaldewaij, Anne, Programming: The Derivation of Algorithms, Prentice-Hall International, 1990, section 2.0). Note that x' is not a program variable. By formulating a postcondition in this manner, relationships between values of variables before and after execution of S can be expressed in the postcondition. This technique can often be used, for example, to prove that the execution of the body of a loop increases or decreases the value of some variable or expression by at least a certain amount, e.g. {I and B and ii'} S {I and i i'-1} which can contribute to proving that the loop terminates. See also section below

25 4. Proof rules A number of relationships between preconditions and postconditions generally apply and are of value in practical applications. Many such relationships, usually called proof rules, or more simply rules, are formulated and proved below. Different rules are formulated for the several proof related tasks and for the several types of program statements. Generally, the rules are used as lemmata to decompose a larger proof or design task into one or more smaller tasks. This process is repeated iteratively until only rather simple, basic tasks remain to be solved, usually by manipulation of Boolean algebraic expressions. 4.1 The several proof related tasks Each proof related task relates to a correctness proposition. The goal is either to determine one of the elements of the correctness proposition or to verify (i.e. prove) that the correctness proposition is true: 1. {V?} S {P} find a precondition for the given postcondition and program segment 2. {V} S? {P} design a program segment for the given precondition and postcondition 3. {V} S {P?} find a postcondition for a given precondition and program segment 4. {V} S {P}? prove that {V} S {P} is true Tasks 2 (program design) and 4 (verifying correctness) are the typical, classical tasks arising in any engineering discipline. In the course of proving the correctness of a program segment (task 4), the need to derive a precondition of a component part of the program segment in question often arises, i.e. task 1. Task 3 does not arise in this process; we will not, therefore, consider rules especially suited for task 3 (finding a postcondition for a given precondition and program segment) although such rules do exist. Furthermore, task 3 seldom arises in practice because engineering is a goal-directed process. That goal is expressed in the postcondition, which must, therefore, be specified before meaningful design or verification work can start. 4.2 Rule P1: strengthening a precondition and weakening a postcondition If then Proof: V V1 and {V1} S {P1} and P1 P {V} S {P} (V V1) ({V1} S {P1}) (P1 P) [Lemma for an ordinary precondition] (V V1) (V1 S -1.ID S -1.P1) (P1 P)

26 (V S -1.ID V1 S -1.ID) (V1 S -1.ID S -1.P1) (S -1.P1 S -1.P) V S -1.ID S -1.P [Lemma for an ordinary precondition] {V} S {P} When working backward (upward) through a program, one may strengthen conditions. When working forward (downward) through a program, one may weaken conditions. 4.3 Divide and conquer rules The following rules permit the software developer to divide and conquer lengthy preconditions and postconditions when proving a program correct. The rules below are formulated for ordinary preconditions, but strict and complete versions can also be formulated and proved. By applying the divide and conquer rules one decomposes a proof task into two or more proof tasks involving shorter preconditions and/or postconditions. While this does not reduce the total amount of work involved, it can contribute significantly to a better organization of the proof, which is typically clearer and easier to understand and follow. The individual steps in the algebraic manipulations become shorter and simpler. Even very long and complex expressions yield to this strategy Rule DC1 If then Proof: {V1} S {P1} and {V2} S {P2} {V1 and V2} S {P1 and P2} {V1} S {P1} and {V2} S {P2} [Lemma for an ordinary precondition] (V1 S -1.ID S -1.P1) (V2 S -1.ID S -1.P2) V1 V2 S -1.ID S -1.P1 S -1.P2 V1 V2 S -1.ID S -1.(P1 P2) [Lemma for an ordinary precondition] {V1 and V2} S {P1 and P2}

27 4.3.2 Rule DC2 If then Proof: {V1} S {P1} and {V2} S {P2} {V1 or V2} S {P1 or P2} {V1} S {P1} and {V2} S {P2} [Lemma for an ordinary precondition] (V1 S -1.ID S -1.P1) (V2 S -1.ID S -1.P2) (V1 S -1.ID V2 S -1.ID) (S -1.P1 S -1.P2) (V1 V2) S -1.ID S -1.P1 S -1.P2 (V1 V2) S -1.ID S -1.(P1 P2) [Lemma for an ordinary precondition] {V1 or V2} S {P1 or P2} Rule DC3 If then {V} S {P1} and {V} S {P2} {V} S {P1 and P2} Proof: This rule (DC3) is rule DC1 with V1V2V. The reverse of this rule also applies (by rule P1). Therefore, the statement of this rule can be strengthened to if and only if. As a result, a postcondition P can be separated in any way into P1 and P2 without introducing the possibility that the proof cannot be completed. For this (as well as other) reasons, DC3 is probably the most useful of the divide and conquer rules Rule DC4 If {V} S {P1} and {V} S {P2}

28 then {V} S {P1 or P2} Proof: This rule (DC4) is rule DC2 with V1V2V. 4.4 Rules for the assignment statement In this section two rules for the assignment statement are formulated and proved. One enables finding a precondition of a given postcondition with respect to a given assignment statement and the other is intended for verifying a given correctness proposition about an assignment statement. The assignment statement x:e, where x is a variable name and E is an expression, is sometimes abbreviated A below. Before stating and proving the rules for an assignment statement, is is useful to note the following consequence of the definition of an assignment statement as a function on ID to ID. Lemma for the assignment statement: Let d1(x:e).d0 (i.e. d1a.d0). Then x.d1e.d0 and y.d1y.d0, for all variable names y other than x. Proof: This lemma follows directly from the definition of an assignment statement as a function on ID, see section above Rule A1 Let the condition P and the assignment statement A (x:e) be given. If one forms the condition V by replacing in P every reference to the value of the variable x by the expression E (in parentheses), then V is a complete precondition of P with respect to the assignment statement x:e. One writes P x E for the expression resulting from replacing x in P by E as described above. We write rule A1 accordingly: {P x E } x:e {P} completely [rule A1] Proof: Consider any data environment d0 in the domain of A, i.e. d0 A -1.ID. The postcondition P is an expression (function) in which the variable x as well as other variables y may appear: P(x, y). The purported precondition P x E is P(E, y). The value of P after execution of the assignment statement is P.d1, where d1a.d0. But P.d1 P(x, y).d1-28 -

29 P(x.d1, y.d1) [lemma for the assignment statement] P(E.d0, y.d0) P(E, y).d0 P x E.d0 Thus, P x E.d0 P.d1 P.(A.d0). From this it follows that d0 Px E A.d0 P. But A.d0 P is equivalent to d0 A -1.P. That is, (A d0 : d0 A -1.ID : d0 P x E d0 A-1.P). But (A d0 : d0 A -1.ID : d0 P x E d0 A-1.P) [(A x : x X : x Y x Z) (Y X Z X)] P x E A-1.ID A -1.P A -1.ID [P ID, A -1.P A -1.ID] P x E A-1.ID A -1.P [lemma for a complete precondition] {P x E } x:e {P} completely Note that only references to the value of the variable x are to be replaced by the expression E (in parentheses). Occurences of the name x that do not refer to the value of x should not modified as described above. In some cases, a meaningless expression would result. A common example is a postcondition containing terms of the form Set. x, i.e. references to the set associated with the variable x, not to the value of x. Note that the expression E should be placed in parentheses before inserting it into the postcondition. Sometimes the parentheses are superfluous, but they are never wrong. It is sometimes wrong not to include them. Rule A1 is used to derive a precondition for a given postcondition and a given assignment statement. Example 1: {V?} sum:sum+z {x+y+z-sum0} completely V [rule A1] (x+y+z-sum0) sum sum+z x+y+z-(sum+z)0-29 -

[Refer Slide Time: 05:10]

[Refer Slide Time: 05:10] Principles of Programming Languages Prof: S. Arun Kumar Department of Computer Science and Engineering Indian Institute of Technology Delhi Lecture no 7 Lecture Title: Syntactic Classes Welcome to lecture

More information

Glossary of Object Oriented Terms

Glossary of Object Oriented Terms Appendix E Glossary of Object Oriented Terms abstract class: A class primarily intended to define an instance, but can not be instantiated without additional methods. abstract data type: An abstraction

More information

Mathematics for Computer Science/Software Engineering. Notes for the course MSM1F3 Dr. R. A. Wilson

Mathematics for Computer Science/Software Engineering. Notes for the course MSM1F3 Dr. R. A. Wilson Mathematics for Computer Science/Software Engineering Notes for the course MSM1F3 Dr. R. A. Wilson October 1996 Chapter 1 Logic Lecture no. 1. We introduce the concept of a proposition, which is a statement

More information

PROPERTECHNIQUEOFSOFTWARE INSPECTIONUSING GUARDED COMMANDLANGUAGE

PROPERTECHNIQUEOFSOFTWARE INSPECTIONUSING GUARDED COMMANDLANGUAGE International Journal of Computer ScienceandCommunication Vol. 2, No. 1, January-June2011, pp. 153-157 PROPERTECHNIQUEOFSOFTWARE INSPECTIONUSING GUARDED COMMANDLANGUAGE Neeraj Kumar Singhania University,

More information

Boolean Algebra Part 1

Boolean Algebra Part 1 Boolean Algebra Part 1 Page 1 Boolean Algebra Objectives Understand Basic Boolean Algebra Relate Boolean Algebra to Logic Networks Prove Laws using Truth Tables Understand and Use First Basic Theorems

More information

DEGREES OF ORDERS ON TORSION-FREE ABELIAN GROUPS

DEGREES OF ORDERS ON TORSION-FREE ABELIAN GROUPS DEGREES OF ORDERS ON TORSION-FREE ABELIAN GROUPS ASHER M. KACH, KAREN LANGE, AND REED SOLOMON Abstract. We construct two computable presentations of computable torsion-free abelian groups, one of isomorphism

More information

Rigorous Software Development CSCI-GA 3033-009

Rigorous Software Development CSCI-GA 3033-009 Rigorous Software Development CSCI-GA 3033-009 Instructor: Thomas Wies Spring 2013 Lecture 11 Semantics of Programming Languages Denotational Semantics Meaning of a program is defined as the mathematical

More information

Chapter 6: Episode discovery process

Chapter 6: Episode discovery process Chapter 6: Episode discovery process Algorithmic Methods of Data Mining, Fall 2005, Chapter 6: Episode discovery process 1 6. Episode discovery process The knowledge discovery process KDD process of analyzing

More information

Automated Theorem Proving - summary of lecture 1

Automated Theorem Proving - summary of lecture 1 Automated Theorem Proving - summary of lecture 1 1 Introduction Automated Theorem Proving (ATP) deals with the development of computer programs that show that some statement is a logical consequence of

More information

Algorithms are the threads that tie together most of the subfields of computer science.

Algorithms are the threads that tie together most of the subfields of computer science. Algorithms Algorithms 1 Algorithms are the threads that tie together most of the subfields of computer science. Something magically beautiful happens when a sequence of commands and decisions is able to

More information

C H A P T E R Regular Expressions regular expression

C H A P T E R Regular Expressions regular expression 7 CHAPTER Regular Expressions Most programmers and other power-users of computer systems have used tools that match text patterns. You may have used a Web search engine with a pattern like travel cancun

More information

WHAT ARE MATHEMATICAL PROOFS AND WHY THEY ARE IMPORTANT?

WHAT ARE MATHEMATICAL PROOFS AND WHY THEY ARE IMPORTANT? WHAT ARE MATHEMATICAL PROOFS AND WHY THEY ARE IMPORTANT? introduction Many students seem to have trouble with the notion of a mathematical proof. People that come to a course like Math 216, who certainly

More information

Formal Languages and Automata Theory - Regular Expressions and Finite Automata -

Formal Languages and Automata Theory - Regular Expressions and Finite Automata - Formal Languages and Automata Theory - Regular Expressions and Finite Automata - Samarjit Chakraborty Computer Engineering and Networks Laboratory Swiss Federal Institute of Technology (ETH) Zürich March

More information

The Set Data Model CHAPTER 7. 7.1 What This Chapter Is About

The Set Data Model CHAPTER 7. 7.1 What This Chapter Is About CHAPTER 7 The Set Data Model The set is the most fundamental data model of mathematics. Every concept in mathematics, from trees to real numbers, is expressible as a special kind of set. In this book,

More information

Automata and Formal Languages

Automata and Formal Languages Automata and Formal Languages Winter 2009-2010 Yacov Hel-Or 1 What this course is all about This course is about mathematical models of computation We ll study different machine models (finite automata,

More information

Software Engineering

Software Engineering Software Engineering Lecture 04: The B Specification Method Peter Thiemann University of Freiburg, Germany SS 2013 Peter Thiemann (Univ. Freiburg) Software Engineering SWT 1 / 50 The B specification method

More information

CHAPTER 2. Logic. 1. Logic Definitions. Notation: Variables are used to represent propositions. The most common variables used are p, q, and r.

CHAPTER 2. Logic. 1. Logic Definitions. Notation: Variables are used to represent propositions. The most common variables used are p, q, and r. CHAPTER 2 Logic 1. Logic Definitions 1.1. Propositions. Definition 1.1.1. A proposition is a declarative sentence that is either true (denoted either T or 1) or false (denoted either F or 0). Notation:

More information

Catalan Numbers. Thomas A. Dowling, Department of Mathematics, Ohio State Uni- versity.

Catalan Numbers. Thomas A. Dowling, Department of Mathematics, Ohio State Uni- versity. 7 Catalan Numbers Thomas A. Dowling, Department of Mathematics, Ohio State Uni- Author: versity. Prerequisites: The prerequisites for this chapter are recursive definitions, basic counting principles,

More information

You know from calculus that functions play a fundamental role in mathematics.

You know from calculus that functions play a fundamental role in mathematics. CHPTER 12 Functions You know from calculus that functions play a fundamental role in mathematics. You likely view a function as a kind of formula that describes a relationship between two (or more) quantities.

More information

INCIDENCE-BETWEENNESS GEOMETRY

INCIDENCE-BETWEENNESS GEOMETRY INCIDENCE-BETWEENNESS GEOMETRY MATH 410, CSUSM. SPRING 2008. PROFESSOR AITKEN This document covers the geometry that can be developed with just the axioms related to incidence and betweenness. The full

More information

Indiana State Core Curriculum Standards updated 2009 Algebra I

Indiana State Core Curriculum Standards updated 2009 Algebra I Indiana State Core Curriculum Standards updated 2009 Algebra I Strand Description Boardworks High School Algebra presentations Operations With Real Numbers Linear Equations and A1.1 Students simplify and

More information

The Goldberg Rao Algorithm for the Maximum Flow Problem

The Goldberg Rao Algorithm for the Maximum Flow Problem The Goldberg Rao Algorithm for the Maximum Flow Problem COS 528 class notes October 18, 2006 Scribe: Dávid Papp Main idea: use of the blocking flow paradigm to achieve essentially O(min{m 2/3, n 1/2 }

More information

THE SEARCH FOR NATURAL DEFINABILITY IN THE TURING DEGREES

THE SEARCH FOR NATURAL DEFINABILITY IN THE TURING DEGREES THE SEARCH FOR NATURAL DEFINABILITY IN THE TURING DEGREES ANDREW E.M. LEWIS 1. Introduction This will be a course on the Turing degrees. We shall assume very little background knowledge: familiarity with

More information

KNOWLEDGE FACTORING USING NORMALIZATION THEORY

KNOWLEDGE FACTORING USING NORMALIZATION THEORY KNOWLEDGE FACTORING USING NORMALIZATION THEORY J. VANTHIENEN M. SNOECK Katholieke Universiteit Leuven Department of Applied Economic Sciences Dekenstraat 2, 3000 Leuven (Belgium) tel. (+32) 16 28 58 09

More information

Verification of Imperative Programs in Theorema

Verification of Imperative Programs in Theorema Verification of Imperative Programs in Theorema Laura Ildikó Kovács, Nikolaj Popov, Tudor Jebelean 1 Research Institute for Symbolic Computation, Johannes Kepler University, A-4040 Linz, Austria Institute

More information

Regular Expressions and Automata using Haskell

Regular Expressions and Automata using Haskell Regular Expressions and Automata using Haskell Simon Thompson Computing Laboratory University of Kent at Canterbury January 2000 Contents 1 Introduction 2 2 Regular Expressions 2 3 Matching regular expressions

More information

Loop Invariants and Binary Search

Loop Invariants and Binary Search Loop Invariants and Binary Search Chapter 4.3.3 and 9.3.1-1 - Outline Ø Iterative Algorithms, Assertions and Proofs of Correctness Ø Binary Search: A Case Study - 2 - Outline Ø Iterative Algorithms, Assertions

More information

FIBRATION SEQUENCES AND PULLBACK SQUARES. Contents. 2. Connectivity and fiber sequences. 3

FIBRATION SEQUENCES AND PULLBACK SQUARES. Contents. 2. Connectivity and fiber sequences. 3 FIRTION SEQUENES ND PULLK SQURES RY MLKIEWIH bstract. We lay out some foundational facts about fibration sequences and pullback squares of topological spaces. We pay careful attention to connectivity ranges

More information

Reading 13 : Finite State Automata and Regular Expressions

Reading 13 : Finite State Automata and Regular Expressions CS/Math 24: Introduction to Discrete Mathematics Fall 25 Reading 3 : Finite State Automata and Regular Expressions Instructors: Beck Hasti, Gautam Prakriya In this reading we study a mathematical model

More information

Notes on Complexity Theory Last updated: August, 2011. Lecture 1

Notes on Complexity Theory Last updated: August, 2011. Lecture 1 Notes on Complexity Theory Last updated: August, 2011 Jonathan Katz Lecture 1 1 Turing Machines I assume that most students have encountered Turing machines before. (Students who have not may want to look

More information

3. Mathematical Induction

3. Mathematical Induction 3. MATHEMATICAL INDUCTION 83 3. Mathematical Induction 3.1. First Principle of Mathematical Induction. Let P (n) be a predicate with domain of discourse (over) the natural numbers N = {0, 1,,...}. If (1)

More information

Mathematical Reasoning in Software Engineering Education. Peter B. Henderson Butler University

Mathematical Reasoning in Software Engineering Education. Peter B. Henderson Butler University Mathematical Reasoning in Software Engineering Education Peter B. Henderson Butler University Introduction Engineering is a bridge between science and mathematics, and the technological needs of mankind.

More information

This asserts two sets are equal iff they have the same elements, that is, a set is determined by its elements.

This asserts two sets are equal iff they have the same elements, that is, a set is determined by its elements. 3. Axioms of Set theory Before presenting the axioms of set theory, we first make a few basic comments about the relevant first order logic. We will give a somewhat more detailed discussion later, but

More information

Binary Multiplication

Binary Multiplication Binary Multiplication Q: How do we multiply two numbers? eg. 12, 345 6, 789 111105 987600 8641500 + 74070000 83, 810, 205 10111 10101 10111 00000 1011100 0000000 + 101110000 111100011 Pad, multiply and

More information

Lecture Notes on Linear Search

Lecture Notes on Linear Search Lecture Notes on Linear Search 15-122: Principles of Imperative Computation Frank Pfenning Lecture 5 January 29, 2013 1 Introduction One of the fundamental and recurring problems in computer science is

More information

How To Develop Software

How To Develop Software Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) We studied the problem definition phase, with which

More information

Chapter 3. Cartesian Products and Relations. 3.1 Cartesian Products

Chapter 3. Cartesian Products and Relations. 3.1 Cartesian Products Chapter 3 Cartesian Products and Relations The material in this chapter is the first real encounter with abstraction. Relations are very general thing they are a special type of subset. After introducing

More information

FOUNDATIONS OF ALGEBRAIC GEOMETRY CLASS 22

FOUNDATIONS OF ALGEBRAIC GEOMETRY CLASS 22 FOUNDATIONS OF ALGEBRAIC GEOMETRY CLASS 22 RAVI VAKIL CONTENTS 1. Discrete valuation rings: Dimension 1 Noetherian regular local rings 1 Last day, we discussed the Zariski tangent space, and saw that it

More information

INTRODUCTORY SET THEORY

INTRODUCTORY SET THEORY M.Sc. program in mathematics INTRODUCTORY SET THEORY Katalin Károlyi Department of Applied Analysis, Eötvös Loránd University H-1088 Budapest, Múzeum krt. 6-8. CONTENTS 1. SETS Set, equal sets, subset,

More information

THE TURING DEGREES AND THEIR LACK OF LINEAR ORDER

THE TURING DEGREES AND THEIR LACK OF LINEAR ORDER THE TURING DEGREES AND THEIR LACK OF LINEAR ORDER JASPER DEANTONIO Abstract. This paper is a study of the Turing Degrees, which are levels of incomputability naturally arising from sets of natural numbers.

More information

Appendix... B. The Object Constraint

Appendix... B. The Object Constraint UML 2.0 in a Nutshell Appendix B. The Object Constraint Pub Date: June 2005 Language The Object Constraint Language 2.0 (OCL) is an addition to the UML 2.0 specification that provides you with a way to

More information

Algorithms and Data Structures

Algorithms and Data Structures Algorithms and Data Structures Part 2: Data Structures PD Dr. rer. nat. habil. Ralf-Peter Mundani Computation in Engineering (CiE) Summer Term 2016 Overview general linked lists stacks queues trees 2 2

More information

Quotient Rings and Field Extensions

Quotient Rings and Field Extensions Chapter 5 Quotient Rings and Field Extensions In this chapter we describe a method for producing field extension of a given field. If F is a field, then a field extension is a field K that contains F.

More information

Elementary Number Theory and Methods of Proof. CSE 215, Foundations of Computer Science Stony Brook University http://www.cs.stonybrook.

Elementary Number Theory and Methods of Proof. CSE 215, Foundations of Computer Science Stony Brook University http://www.cs.stonybrook. Elementary Number Theory and Methods of Proof CSE 215, Foundations of Computer Science Stony Brook University http://www.cs.stonybrook.edu/~cse215 1 Number theory Properties: 2 Properties of integers (whole

More information

This chapter is all about cardinality of sets. At first this looks like a

This chapter is all about cardinality of sets. At first this looks like a CHAPTER Cardinality of Sets This chapter is all about cardinality of sets At first this looks like a very simple concept To find the cardinality of a set, just count its elements If A = { a, b, c, d },

More information

Metric Spaces. Chapter 1

Metric Spaces. Chapter 1 Chapter 1 Metric Spaces Many of the arguments you have seen in several variable calculus are almost identical to the corresponding arguments in one variable calculus, especially arguments concerning convergence

More information

Switching Algebra and Logic Gates

Switching Algebra and Logic Gates Chapter 2 Switching Algebra and Logic Gates The word algebra in the title of this chapter should alert you that more mathematics is coming. No doubt, some of you are itching to get on with digital design

More information

CS103B Handout 17 Winter 2007 February 26, 2007 Languages and Regular Expressions

CS103B Handout 17 Winter 2007 February 26, 2007 Languages and Regular Expressions CS103B Handout 17 Winter 2007 February 26, 2007 Languages and Regular Expressions Theory of Formal Languages In the English language, we distinguish between three different identities: letter, word, sentence.

More information

Local periods and binary partial words: An algorithm

Local periods and binary partial words: An algorithm Local periods and binary partial words: An algorithm F. Blanchet-Sadri and Ajay Chriscoe Department of Mathematical Sciences University of North Carolina P.O. Box 26170 Greensboro, NC 27402 6170, USA E-mail:

More information

The Student-Project Allocation Problem

The Student-Project Allocation Problem The Student-Project Allocation Problem David J. Abraham, Robert W. Irving, and David F. Manlove Department of Computing Science, University of Glasgow, Glasgow G12 8QQ, UK Email: {dabraham,rwi,davidm}@dcs.gla.ac.uk.

More information

Notes from Week 1: Algorithms for sequential prediction

Notes from Week 1: Algorithms for sequential prediction CS 683 Learning, Games, and Electronic Markets Spring 2007 Notes from Week 1: Algorithms for sequential prediction Instructor: Robert Kleinberg 22-26 Jan 2007 1 Introduction In this course we will be looking

More information

Lecture 1. Basic Concepts of Set Theory, Functions and Relations

Lecture 1. Basic Concepts of Set Theory, Functions and Relations September 7, 2005 p. 1 Lecture 1. Basic Concepts of Set Theory, Functions and Relations 0. Preliminaries...1 1. Basic Concepts of Set Theory...1 1.1. Sets and elements...1 1.2. Specification of sets...2

More information

Thomas Jefferson High School for Science and Technology Program of Studies Foundations of Computer Science. Unit of Study / Textbook Correlation

Thomas Jefferson High School for Science and Technology Program of Studies Foundations of Computer Science. Unit of Study / Textbook Correlation Thomas Jefferson High School for Science and Technology Program of Studies Foundations of Computer Science updated 03/08/2012 Unit 1: JKarel 8 weeks http://www.fcps.edu/is/pos/documents/hs/compsci.htm

More information

CPC/CPA Hybrid Bidding in a Second Price Auction

CPC/CPA Hybrid Bidding in a Second Price Auction CPC/CPA Hybrid Bidding in a Second Price Auction Benjamin Edelman Hoan Soo Lee Working Paper 09-074 Copyright 2008 by Benjamin Edelman and Hoan Soo Lee Working papers are in draft form. This working paper

More information

8 Divisibility and prime numbers

8 Divisibility and prime numbers 8 Divisibility and prime numbers 8.1 Divisibility In this short section we extend the concept of a multiple from the natural numbers to the integers. We also summarize several other terms that express

More information

Mathematical Induction

Mathematical Induction Mathematical Induction (Handout March 8, 01) The Principle of Mathematical Induction provides a means to prove infinitely many statements all at once The principle is logical rather than strictly mathematical,

More information

Solutions to Homework 6 Mathematics 503 Foundations of Mathematics Spring 2014

Solutions to Homework 6 Mathematics 503 Foundations of Mathematics Spring 2014 Solutions to Homework 6 Mathematics 503 Foundations of Mathematics Spring 2014 3.4: 1. If m is any integer, then m(m + 1) = m 2 + m is the product of m and its successor. That it to say, m 2 + m is the

More information

The Relation between Two Present Value Formulae

The Relation between Two Present Value Formulae James Ciecka, Gary Skoog, and Gerald Martin. 009. The Relation between Two Present Value Formulae. Journal of Legal Economics 15(): pp. 61-74. The Relation between Two Present Value Formulae James E. Ciecka,

More information

FACTORING POLYNOMIALS IN THE RING OF FORMAL POWER SERIES OVER Z

FACTORING POLYNOMIALS IN THE RING OF FORMAL POWER SERIES OVER Z FACTORING POLYNOMIALS IN THE RING OF FORMAL POWER SERIES OVER Z DANIEL BIRMAJER, JUAN B GIL, AND MICHAEL WEINER Abstract We consider polynomials with integer coefficients and discuss their factorization

More information

NOTES ON CATEGORIES AND FUNCTORS

NOTES ON CATEGORIES AND FUNCTORS NOTES ON CATEGORIES AND FUNCTORS These notes collect basic definitions and facts about categories and functors that have been mentioned in the Homological Algebra course. For further reading about category

More information

1 Sets and Set Notation.

1 Sets and Set Notation. LINEAR ALGEBRA MATH 27.6 SPRING 23 (COHEN) LECTURE NOTES Sets and Set Notation. Definition (Naive Definition of a Set). A set is any collection of objects, called the elements of that set. We will most

More information

WESTMORELAND COUNTY PUBLIC SCHOOLS 2011 2012 Integrated Instructional Pacing Guide and Checklist Computer Math

WESTMORELAND COUNTY PUBLIC SCHOOLS 2011 2012 Integrated Instructional Pacing Guide and Checklist Computer Math Textbook Correlation WESTMORELAND COUNTY PUBLIC SCHOOLS 2011 2012 Integrated Instructional Pacing Guide and Checklist Computer Math Following Directions Unit FIRST QUARTER AND SECOND QUARTER Logic Unit

More information

About the inverse football pool problem for 9 games 1

About the inverse football pool problem for 9 games 1 Seventh International Workshop on Optimal Codes and Related Topics September 6-1, 013, Albena, Bulgaria pp. 15-133 About the inverse football pool problem for 9 games 1 Emil Kolev Tsonka Baicheva Institute

More information

9.2 Summation Notation

9.2 Summation Notation 9. Summation Notation 66 9. Summation Notation In the previous section, we introduced sequences and now we shall present notation and theorems concerning the sum of terms of a sequence. We begin with a

More information

Functional Dependencies and Normalization

Functional Dependencies and Normalization Functional Dependencies and Normalization 5DV119 Introduction to Database Management Umeå University Department of Computing Science Stephen J. Hegner hegner@cs.umu.se http://www.cs.umu.se/~hegner Functional

More information

Outline. 1 Denitions. 2 Principles. 4 Implementation and Evaluation. 5 Debugging. 6 References

Outline. 1 Denitions. 2 Principles. 4 Implementation and Evaluation. 5 Debugging. 6 References Outline Computer Science 331 Introduction to Testing of Programs Mike Jacobson Department of Computer Science University of Calgary Lecture #3-4 1 Denitions 2 3 4 Implementation and Evaluation 5 Debugging

More information

The following themes form the major topics of this chapter: The terms and concepts related to trees (Section 5.2).

The following themes form the major topics of this chapter: The terms and concepts related to trees (Section 5.2). CHAPTER 5 The Tree Data Model There are many situations in which information has a hierarchical or nested structure like that found in family trees or organization charts. The abstraction that models hierarchical

More information

each college c i C has a capacity q i - the maximum number of students it will admit

each college c i C has a capacity q i - the maximum number of students it will admit n colleges in a set C, m applicants in a set A, where m is much larger than n. each college c i C has a capacity q i - the maximum number of students it will admit each college c i has a strict order i

More information

SUBGROUPS OF CYCLIC GROUPS. 1. Introduction In a group G, we denote the (cyclic) group of powers of some g G by

SUBGROUPS OF CYCLIC GROUPS. 1. Introduction In a group G, we denote the (cyclic) group of powers of some g G by SUBGROUPS OF CYCLIC GROUPS KEITH CONRAD 1. Introduction In a group G, we denote the (cyclic) group of powers of some g G by g = {g k : k Z}. If G = g, then G itself is cyclic, with g as a generator. Examples

More information

Notes on Factoring. MA 206 Kurt Bryan

Notes on Factoring. MA 206 Kurt Bryan The General Approach Notes on Factoring MA 26 Kurt Bryan Suppose I hand you n, a 2 digit integer and tell you that n is composite, with smallest prime factor around 5 digits. Finding a nontrivial factor

More information

Constructing Digital Signatures from a One Way Function

Constructing Digital Signatures from a One Way Function Op. 52 Constructing Digital Signatures from a One Way Function Leslie Lamport Computer Science Laboratory SRI International 18 October 1979 CSL - 98 333 Ravenswood Ave. Menlo Park, California 94025 (415)

More information

The Trip Scheduling Problem

The Trip Scheduling Problem The Trip Scheduling Problem Claudia Archetti Department of Quantitative Methods, University of Brescia Contrada Santa Chiara 50, 25122 Brescia, Italy Martin Savelsbergh School of Industrial and Systems

More information

MapReduce and Distributed Data Analysis. Sergei Vassilvitskii Google Research

MapReduce and Distributed Data Analysis. Sergei Vassilvitskii Google Research MapReduce and Distributed Data Analysis Google Research 1 Dealing With Massive Data 2 2 Dealing With Massive Data Polynomial Memory Sublinear RAM Sketches External Memory Property Testing 3 3 Dealing With

More information

The countdown problem

The countdown problem JFP 12 (6): 609 616, November 2002. c 2002 Cambridge University Press DOI: 10.1017/S0956796801004300 Printed in the United Kingdom 609 F U N C T I O N A L P E A R L The countdown problem GRAHAM HUTTON

More information

Writing in the Computer Science Major

Writing in the Computer Science Major Writing in the Computer Science Major Table of Contents Introduction... 2 Statement of Purpose... 2 Revision History... 2 Writing Tasks in Computer Science... 3 Documentation... 3 Planning to Program:

More information

TECHNIQUES FOR OPTIMIZING THE RELATIONSHIP BETWEEN DATA STORAGE SPACE AND DATA RETRIEVAL TIME FOR LARGE DATABASES

TECHNIQUES FOR OPTIMIZING THE RELATIONSHIP BETWEEN DATA STORAGE SPACE AND DATA RETRIEVAL TIME FOR LARGE DATABASES Techniques For Optimizing The Relationship Between Data Storage Space And Data Retrieval Time For Large Databases TECHNIQUES FOR OPTIMIZING THE RELATIONSHIP BETWEEN DATA STORAGE SPACE AND DATA RETRIEVAL

More information

Software Engineering Reference Framework

Software Engineering Reference Framework Software Engineering Reference Framework Michel Chaudron, Jan Friso Groote, Kees van Hee, Kees Hemerik, Lou Somers, Tom Verhoeff. Department of Mathematics and Computer Science Eindhoven University of

More information

6.045: Automata, Computability, and Complexity Or, Great Ideas in Theoretical Computer Science Spring, 2010. Class 4 Nancy Lynch

6.045: Automata, Computability, and Complexity Or, Great Ideas in Theoretical Computer Science Spring, 2010. Class 4 Nancy Lynch 6.045: Automata, Computability, and Complexity Or, Great Ideas in Theoretical Computer Science Spring, 2010 Class 4 Nancy Lynch Today Two more models of computation: Nondeterministic Finite Automata (NFAs)

More information

Linear Codes. Chapter 3. 3.1 Basics

Linear Codes. Chapter 3. 3.1 Basics Chapter 3 Linear Codes In order to define codes that we can encode and decode efficiently, we add more structure to the codespace. We shall be mainly interested in linear codes. A linear code of length

More information

Automated Program Behavior Analysis

Automated Program Behavior Analysis Automated Program Behavior Analysis Stacy Prowell sprowell@cs.utk.edu March 2005 SQRL / SEI Motivation: Semantics Development: Most engineering designs are subjected to extensive analysis; software is

More information

Execution of A Requirement Model in Software Development

Execution of A Requirement Model in Software Development Execution of A Requirement Model in Software Development Wuwei Shen, Mohsen Guizani and Zijiang Yang Dept of Computer Science, Western Michigan University {wwshen,mguizani,zijiang}@cs.wmich.edu Kevin Compton

More information

Stochastic Inventory Control

Stochastic Inventory Control Chapter 3 Stochastic Inventory Control 1 In this chapter, we consider in much greater details certain dynamic inventory control problems of the type already encountered in section 1.3. In addition to the

More information

Mathematical Induction. Mary Barnes Sue Gordon

Mathematical Induction. Mary Barnes Sue Gordon Mathematics Learning Centre Mathematical Induction Mary Barnes Sue Gordon c 1987 University of Sydney Contents 1 Mathematical Induction 1 1.1 Why do we need proof by induction?.... 1 1. What is proof by

More information

An example of a computable

An example of a computable An example of a computable absolutely normal number Verónica Becher Santiago Figueira Abstract The first example of an absolutely normal number was given by Sierpinski in 96, twenty years before the concept

More information

Chapter 7: Products and quotients

Chapter 7: Products and quotients Chapter 7: Products and quotients Matthew Macauley Department of Mathematical Sciences Clemson University http://www.math.clemson.edu/~macaule/ Math 42, Spring 24 M. Macauley (Clemson) Chapter 7: Products

More information

CHAPTER 7 GENERAL PROOF SYSTEMS

CHAPTER 7 GENERAL PROOF SYSTEMS CHAPTER 7 GENERAL PROOF SYSTEMS 1 Introduction Proof systems are built to prove statements. They can be thought as an inference machine with special statements, called provable statements, or sometimes

More information

Math 223 Abstract Algebra Lecture Notes

Math 223 Abstract Algebra Lecture Notes Math 223 Abstract Algebra Lecture Notes Steven Tschantz Spring 2001 (Apr. 23 version) Preamble These notes are intended to supplement the lectures and make up for the lack of a textbook for the course

More information

Quotes from Object-Oriented Software Construction

Quotes from Object-Oriented Software Construction Quotes from Object-Oriented Software Construction Bertrand Meyer Prentice-Hall, 1988 Preface, p. xiv We study the object-oriented approach as a set of principles, methods and tools which can be instrumental

More information

Detecting Pattern-Match Failures in Haskell. Neil Mitchell and Colin Runciman York University www.cs.york.ac.uk/~ndm/catch

Detecting Pattern-Match Failures in Haskell. Neil Mitchell and Colin Runciman York University www.cs.york.ac.uk/~ndm/catch Detecting Pattern-Match Failures in Haskell Neil Mitchell and Colin Runciman York University www.cs.york.ac.uk/~ndm/catch Does this code crash? risers [] = [] risers [x] = [[x]] risers (x:y:etc) = if x

More information

Relational Databases

Relational Databases Relational Databases Jan Chomicki University at Buffalo Jan Chomicki () Relational databases 1 / 18 Relational data model Domain domain: predefined set of atomic values: integers, strings,... every attribute

More information

How To Find Out What A Key Is In A Database Engine

How To Find Out What A Key Is In A Database Engine Database design theory, Part I Functional dependencies Introduction As we saw in the last segment, designing a good database is a non trivial matter. The E/R model gives a useful rapid prototyping tool,

More information

Mathematical Induction

Mathematical Induction Mathematical Induction In logic, we often want to prove that every member of an infinite set has some feature. E.g., we would like to show: N 1 : is a number 1 : has the feature Φ ( x)(n 1 x! 1 x) How

More information

CONTRIBUTIONS TO ZERO SUM PROBLEMS

CONTRIBUTIONS TO ZERO SUM PROBLEMS CONTRIBUTIONS TO ZERO SUM PROBLEMS S. D. ADHIKARI, Y. G. CHEN, J. B. FRIEDLANDER, S. V. KONYAGIN AND F. PAPPALARDI Abstract. A prototype of zero sum theorems, the well known theorem of Erdős, Ginzburg

More information

A Framework for the Semantics of Behavioral Contracts

A Framework for the Semantics of Behavioral Contracts A Framework for the Semantics of Behavioral Contracts Ashley McNeile Metamaxim Ltd, 48 Brunswick Gardens, London W8 4AN, UK ashley.mcneile@metamaxim.com Abstract. Contracts have proved a powerful concept

More information

DIFFERENTIABILITY OF COMPLEX FUNCTIONS. Contents

DIFFERENTIABILITY OF COMPLEX FUNCTIONS. Contents DIFFERENTIABILITY OF COMPLEX FUNCTIONS Contents 1. Limit definition of a derivative 1 2. Holomorphic functions, the Cauchy-Riemann equations 3 3. Differentiability of real functions 5 4. A sufficient condition

More information

CHAPTER 3. Methods of Proofs. 1. Logical Arguments and Formal Proofs

CHAPTER 3. Methods of Proofs. 1. Logical Arguments and Formal Proofs CHAPTER 3 Methods of Proofs 1. Logical Arguments and Formal Proofs 1.1. Basic Terminology. An axiom is a statement that is given to be true. A rule of inference is a logical rule that is used to deduce

More information

Module 10. Coding and Testing. Version 2 CSE IIT, Kharagpur

Module 10. Coding and Testing. Version 2 CSE IIT, Kharagpur Module 10 Coding and Testing Lesson 23 Code Review Specific Instructional Objectives At the end of this lesson the student would be able to: Identify the necessity of coding standards. Differentiate between

More information

Lecture Notes on Polynomials

Lecture Notes on Polynomials Lecture Notes on Polynomials Arne Jensen Department of Mathematical Sciences Aalborg University c 008 Introduction These lecture notes give a very short introduction to polynomials with real and complex

More information

C A R I B B E A N E X A M I N A T I O N S REPORT ON CANDIDATES S WORK IN THE CARIBBEAN SECONDARY EDUCATION CERTIFICATE EXAMINATION MAY/JUNE 2012

C A R I B B E A N E X A M I N A T I O N S REPORT ON CANDIDATES S WORK IN THE CARIBBEAN SECONDARY EDUCATION CERTIFICATE EXAMINATION MAY/JUNE 2012 C A R I B B E A N E X A M I N A T I O N S COUNCIL REPORT ON CANDIDATES S WORK IN THE CARIBBEAN SECONDARY EDUCATION CERTIFICATE EXAMINATION MAY/JUNE 2012 INFORMATION TECHNOLOGY GENERAL PROFICIENCY EXAMINATION

More information

A simple algorithm with no simple verication

A simple algorithm with no simple verication A simple algorithm with no simple verication Laszlo Csirmaz Central European University Abstract The correctness of a simple sorting algorithm is resented, which algorithm is \evidently wrong" at the rst

More information