# NASA Technical Memorandum (Revised) An Elementary Tutorial on Formal. Specication and Verication. Using PVS 2. Ricky W.

Save this PDF as:

Size: px
Start display at page:

Download "NASA Technical Memorandum 108991 (Revised) An Elementary Tutorial on Formal. Specication and Verication. Using PVS 2. Ricky W."

## Transcription

1 NASA Technical Memorandum (Revised) An Elementary Tutorial on Formal Specication and Verication Using PVS 2 Ricky W. Butler September 1993 (revised June 1995) NASA National Aeronautics and Space Administration Langley Research Center Hampton, VA 23681

2 Abstract This paper presents a tutorial on the development of a formal specication and its verication using the Prototype Verication System (PVS). The tutorial presents the formal specication and verication techniques by way of a specic example an airline reservation system. The airline reservation system is modeled as a simple state machine with two basic operations. These operations are shown to preserve a state invariant using the theorem proving capabilities of PVS. The technique of validating a specication via \putative theorem proving" is also discussed and illustrated in detail. This paper is intended for the novice and assumes only some of the basic concepts of logic. A complete description of user inputs and the PVS output is provided, and thus it can be eectively used while one is sitting at a computer terminal. PVS is free and can be retrieved via anonymous FTP. For information about how to obtain and install PVS, see World Wide Web at KEY WORDS: formal methods, formal specication, verication & validation, theorem provers, PVS, mechanical verication

3 Contents 1 Introduction Some Preliminary Concepts : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Statement of The Example Problem : : : : : : : : : : : : : : : : : : : : : : : : : : : 1 2 Formal Specication of the Reservation System Creating Basic TYPE Denitions : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Creating a PVS Specication File : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Denition of the Reservation System Database : : : : : : : : : : : : : : : : : : : : : Aircraft Seat Layout : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Specifying Operations on the Database : : : : : : : : : : : : : : : : : : : : : : : : : : Seat Assignment Operations : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Specifying Invariants On the State Of the Database : : : : : : : : : : : : : : : : : : PVS Typechecking and Typecheck Conditions (TCCs) : : : : : : : : : : : : : : : : : 9 3 Formal Verications Proof that Cancel assn Maintains the Invariant : : : : : : : : : : : : : : : : : : : : Proof that Make assn Maintains the Invariant : : : : : : : : : : : : : : : : : : : : : : Proof of MAe : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Proof of MAu : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Proof of Theorem : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Proof that the Initial State Satises the Invariant : : : : : : : : : : : : : : : : : : : : Proof of one per seat Invariant : : : : : : : : : : : : : : : : : : : : : : : : : : : : : System Properties and Putative Theorems : : : : : : : : : : : : : : : : : : : : : : : : 47 4 Summary 58 i

5 Make a new seat assignment Cancel an existing seat assignment This example problem was derived from an Ehdm specication presented by Ben Di Vito at the Second NASA Formal Methods Workshop [6]. 2 Formal Specication of the Reservation System This section provides a step-by-step elaboration of the process one goes through in developing a formal specication of the example system. Much of the typing required to carry out this exercise can be reduced by retrieving the specications from air16.larc.nasa.gov using anonymous FTP. The specications are located in the directory pub/fm/larc/pvs-tutorial in a le named revised-specs.dmp. 2.1 Creating Basic TYPE Denitions We begin our formal specication by creating some names for the objects that our formal speci- cation will be describing. We obviously will be talking about seats in an airplane and will need a way to identify a particular seat. We decide to represent an airplane's seating structure as a two-dimensional array of \rows" and \positions". In PVS one writes row: TYPE position: TYPE to dene the two domains of values. Of course this specication says nothing about what kind of value \row" or \position" could be. We decide to number our rows and positions with positive natural numbers. This is illustrated in gure 1. Of course we really don't need an innite set of row position l, l, l, l, l,, l, l, l, l, l l, l, l,, l,, l, l l, l, l, l,, l l,,, l,, l,, l l, l, l l l l, l, l l,,, l, l, l, l l, l l, l, l,, l, l, l l,, l, l, l,, l Figure 1: Model of Seating Arrangement In An Airplane numbers since we know the largest airplane in our eet, and thus we assume the existence of two 2

6 constants that delineate the maximum number of rows in any airplane and the maximum number of positions for any row: nrows: posnat % Max number of rows nposits: posnat % Max number of positions per row We now modify our specication of \row" and \position": row: TYPE = {n: posnat 1 <= n AND n <= nrows} position: TYPE = {n: posnat 1 <= n AND n <= nposits} This denes row and position as subranges of the positive naturals (called posnat in PVS). The notation is very simple. The text before the denes the parent type and the text after the gives a predicate that denes the particular subset of the parent type that you are interested in. Thus, row is any positive natural number between 1 and nrows inclusive. 2.2 Creating a PVS Specication File We now put these together in a le. We start up PVS and type M-x nf. PVS asks for a name for the new le. We answer \basic defs.pvs". PVS creates the following le: basic_defs % [ parameters ] : THEORY BEGIN % ASSUMING % assuming declarations % ENDASSUMING END basic_defs We remove all of the text after the % characters, and then add our type denitions 1 : basic_defs: THEORY BEGIN nrows: posnat % Max number of rows nposits: posnat % Max number of positions per row row: TYPE = {n: posnat 1 <= n AND n <= nrows} position: TYPE = {n: posnat 1 <= n AND n <= nposits} END basic_defs We now issue the PVS typecheck command, M-x tc. PVS responds \basic defs typechecked in 3 seconds. No TCCS generated". We now need to dene some other types that dene the ight number, aircraft type, a position preference (e.g. aisle or window) and an identier for passengers: 1 The only remaining keywords are THEORY, which delineates the start of a new module, and the BEGIN END keywords, which surround the body of the specication. 3

7 flight: TYPE plane: TYPE preference: TYPE passenger: TYPE % Flight identifier % Aircraft type % Position preference % Passenger identifier We add this text to our le and typecheck again. 2.3 Denition of the Reservation System Database We are ready to dene the database that will maintain all of the reservations. For each ight, the system must maintain a set of seat assignments. We decide to represent each seat assignment as a record that contains a passenger and his assigned seat. This can be formally represented in PVS using the record constructor: seat_assignment: TYPE = [# seat: [row, position], pass: passenger #] The seat eld of the record is of type [row, position], an ordered pair (or 2-tuple) of row and position. The entire set of seat assignments for a ight can be represented using PVS's set constructor, set. flight_assignments: TYPE = set[seat_assignment] This denes a set type that contains only elements of type seat assignment and assigns it the name flight assignments. Sets are dened in the PVS prelude, which can be displayed using the M-x vpf command. The sets module provides denitions for the basic set operations. Some of these operations are described in table 1. operation traditional notation or meaning member 2 union [ intersection \ difference n add add element to a set singleton constructs set with 1 element subset? emptyset ; Table 1: A partial list of PVS set operations The complete ight-reservation database can now be modeled as a mapping from ight identier into that ight's current set of seat assignments: flt_db: TYPE = function[flight -> flight_assignments] This denes a type that represents the domain of all possible databases. A particular database can be represented by declaring a variable of this type: db: VAR flt_db 4

8 Initially, each ight has no assignments: initial_state(flt: flight): flight_assignments = emptyset[seat_assignment] We add this to our specication and typecheck it. 2.4 Aircraft Seat Layout Since there is a maximum number of rows and seats per row, we must indicate whether a (row, position) pair exists for a given aircraft type. This can be accomplished through use of several functions that are uniquely dened for dierent plane types: seat_exists: function[plane, [row, position] -> bool] meets_pref: function[plane, [row, position], preference -> bool] Since we do not want to restrict our specication to any particular plane type, we do not supply a denition (i.e., a function body) for these functions. They are left \uninterpreted." The intended meaning of these functions are as follows. The function seat exists is true only when the indicated seat (i.e. [row,position] )is physically present on the indicated airplane. The function meets pref species whether the particular seat is consistent with the particular preference indicated. The type of airplane assigned to a particular ight is given by the aircraft function: aircraft: function[flight -> plane] The description of the basic attributes of the system is now complete. The specication is: basic_defs: THEORY BEGIN nrows: posnat % Max number of rows nposits: posnat % Max number of positions per row row: TYPE = {n: posnat 1 <= n AND n <= nrows} position: TYPE = {n: posnat 1 <= n AND n <= nposits} flight: TYPE plane: TYPE preference: TYPE passenger: TYPE % Flight identifier % Aircraft type % Position preference % Passenger identifier seat_assignment: TYPE = [# seat: [row, position], pass: passenger #] flight_assignments: TYPE = set[seat_assignment] flt_db: TYPE = function[flight -> flight_assignments] initial_state(flt: flight): flight_assignments = emptyset[seat_assignment] % ==================================================================== 5

9 % Definitions that define attributes of a particular airplane % ==================================================================== seat_exists: function[plane, [row, position] -> bool] meets_pref: function[plane, [row, position], preference -> bool] aircraft: function[flight -> plane] END basic_defs 2.5 Specifying Operations on the Database Our method of formally specifying operations is based on the use of state transition functions. The function denes the value of system state after invocation of the operation in terms of the system state before the operation is invoked. To produce a modular specication, we will place the operations in a new theory (i.e. a new module). This is accomplished in PVS by using the M-x nt command. We issue this command and name the new theory ops. All of the denitions of the basic defs theory are made available to this theory using the IMPORTING command: ops: THEORY BEGIN IMPORTING basic_defs END ops 2.6 Seat Assignment Operations The rst operation that we need is Cancel assn(flt,pas,db), which cancels the seat assignment for a passenger, pas, on ight flt in database db: a: VAR seat_assignment Cancel_assn(flt: flight, pas: passenger, db: flt_db): flt_db = db WITH [(flt) := {a member(a,db(flt)) AND pass(a) /= pas}] The declaration of the function begins with its formal parameter list. Each argument is listed with its type. The return type of the function is given after the parameter list. This specication uses the PVS WITH construct. The WITH expression is used to dene a new function that diers from another function for a few indicated values. For example, f WITH [(1) := y] is identical to f, except possibly for f(1) 2.Thus, all seat assignment sets for ights other than flt are unchanged. For ight flt, however, all assignments on behalf of passenger pas are removed (there should be at most one). As discussed earlier (i.e. see table 1), the function member is dened in the sets module of the PVS prelude. The second operation is Make assn(flt,pas,pref,db), which makes a seat assignment, if possible, for passenger pas on ight flt in database db. There are two conditions that should prevent us from carrying out this operation on the reservation database 1. when there is no seat available that meets the passenger's specied preference 2. when the passenger already has a seat on the plane 2 The resulting function is not dierent if f(1) = y. Formally f WITH [(1) := y](x) = IF x = 1 THEN y ELSE f(x) 6

11 db: VAR flt_db flt: VAR flight pref: VAR preference Next_seat_ax: AXIOM NOT pref_filled(db, flt, pref) IMPLIES seat_exists(aircraft(flt),next_seat(db,flt,pref)) This axiom states that if a seat is available that matches the specied preference, then the function Next seat returns a [row, position] that actually exists on the airplane scheduled for ight flt. This axiom makes use of several variables. These will be used in subsequent PVS declarations. Now that wehave dened the operations, we are faced with the question, \Howdowe know that the operations were specied correctly?" One approach to this problem is to construct \putative" theorems. These are properties about the operations that should be true if we have dened them properly. For example, pas: VAR passenger Make_Cancel: THEOREM NOT pass_on_flight(pas,flt,db) => Cancel_assn(flt,pas,Make_assn(flt,pas,pref,db)) = db This states that if a particular passenger is not already assigned to a ight, then the result of assigning that passenger to a ight and then canceling his reservation will return the database to its original state 4. The process of attempting to prove such theorems can lead to the discovery of errors in the specication. The proof of this theorem will be given in a later section. Some other examples are: Cancel_putative: THEOREM NOT (EXISTS (a: seat_assignment): member(a,cancel_assn(flt,pas,db)(flt)) AND pass(a) = pas) Make_putative: THEOREM NOT pref_filled(db, flt, pref) => (EXISTS (x: seat_assignment): member(x, Make_assn(flt, pas, pref, db)(flt)) AND pass(x) = pas) 2.7 Specifying Invariants On the State Of the Database The system state is subject to three types of anomalies: 1. Assigning nonexistent seats to passengers 2. Assigning multiple seats to a single passenger 3. Assigning more than one passenger to a single seat Prevention of anomaly (1) can be formalized as follows: existence(db: flt_db): bool = (FORALL a,flt: member(a, db(flt)) IMPLIES seat_exists(aircraft(flt), seat(a))) Prevention of anomaly (2) can be formalized as follows: 4 Wehave used the alternate PVS syntax for logical implies: =>. 8

12 uniqueness(db: flt_db): bool = (FORALL a,b,flt: member(a, db(flt)) AND member(b, db(flt)) AND pass(a) = pass(b) IMPLIES a = b) Prevention of anomaly (3) can be formalized as follows: one_per_seat(db: flt_db): bool = (FORALL a,b,flt: member(a, db(flt)) AND member(b, db(flt)) AND seat(a) = seat(b) IMPLIES a = b) The overall state invariant is the conjunction of the three. However, in order to simplify the discussion we will work with the rst two and leave the last invariant as an exercise 5. The conjunction of the rst two can be captured in a single function as follows: db_invariant(db: flt_db): bool = existence(db) AND uniqueness(db) 2.8 PVS Typechecking and Typecheck Conditions (TCCs) We combine the denitions for the operations and the invariants in a new theory called ops: ops: THEORY BEGIN IMPORTING basic_defs a: VAR seat_assignment Cancel_assn(flt: flight, pas: passenger, db: flt_db): flt_db = db WITH [(flt) := {a member(a,db(flt)) AND pass(a) /= pas}] seat: VAR [row,position] pref_filled(db: flt_db, flt: flight, pref: preference): bool = (FORALL seat: meets_pref(aircraft(flt), seat, pref) IMPLIES (EXISTS a: member(a, db(flt)) AND seat(a) = seat)) pass_on_flight(pas: passenger, flt: flight, db: flt_db): bool = (EXISTS a: pass(a) = pas AND member(a,db(flt))) Next_seat: function[flt_db, flight, preference -> [row,position]] Make_assn(flt:flight, pas:passenger, pref:preference, db:flt_db): flt_db = IF pref_filled(db, flt, pref) OR pass_on_flight(pas,flt,db) THEN db ELSE (LET a = (# seat := Next_seat(db,flt,pref), pass := pas #) IN db WITH [(flt) := add(a, db(flt))]) 5 It is the easiest of the three invariants. 9

13 % ======================================================================= % Variable Declarations % ======================================================================= flt: VAR flight pas: VAR passenger db: VAR flt_db b: VAR seat_assignment pref: VAR preference Next_seat_ax: AXIOM NOT pref_filled(db, flt, pref) IMPLIES seat_exists(aircraft(flt),next_seat(db,flt,pref)) % ======================================================================= % Putative Theorems % ======================================================================= Make_Cancel: THEOREM NOT pass_on_flight(pas,flt,db) => Cancel_assn(flt,pas,Make_assn(flt,pas,pref,db)) = db % ======================================================================= % Invariants % ======================================================================= existence(db: flt_db): bool = (FORALL a,flt: member(a, db(flt)) IMPLIES seat_exists(aircraft(flt), seat(a))) uniqueness(db: flt_db): bool = (FORALL a,b,flt: member(a, db(flt)) AND member(b, db(flt)) AND pass(a) = pass(b) IMPLIES a = b) one_per_seat(db: flt_db): bool = (FORALL a,b,flt: member(a, db(flt)) AND member(b, db(flt)) AND seat(a) = seat(b) IMPLIES a = b) db_invariant(db: flt_db): bool = existence(db) AND uniqueness(db) % ======================================================================= % THEOREMS % ======================================================================= 10

14 Cancel_db_inv: THEOREM db_invariant(db) IMPLIES db_invariant(cancel_assn(flt,pas,db)) MAe: THEOREM existence(db) IMPLIES existence(make_assn(flt,pas,pref,db)) MAu: THEOREM uniqueness(db) IMPLIES uniqueness(make_assn(flt,pas,pref,db)) Make_db_inv: THEOREM db_invariant(db) => db_invariant(make_assn(flt,pas,pref,db)) initial_state_inv: THEOREM db_invariant(initial_state) When we issue the M-x tc command we notice that the system responds ops typechecked: 1 TCCs, 0 Proved, 0 subsumed, 1 unproved. Unlike many high-level programming languages, PVS often requires theorem proving in order to guarantee that the specication is type correct. This is the price one has to pay for the very powerful type structure of the language. M-x show-tccs opens up a window that displays the typecheck obligations: % Existence TCC generated (line 24) for % Next_seat: FUNCTION[flt_db, flight, preference -> [row, position]] % % unfinished Next_seat_TCC1: OBLIGATION (EXISTS (x: [[flt_db, flight, preference] -> [row, position]]): TRUE); We position the cursor on the rst obligation and type M-x pr. The PVS system responds by opening up a proof buer containing the following output: Next_seat_TCC1 : {1} (EXISTS (x: [[flt_db, flight, preference] -> [row, position]]): TRUE) Rule? The system wants us to prove that there exists a function from the triple [flt_db, flight, preference] to the ordered pair [row, position]. The constant function that returns the ordered pair (1,1) should suce, but we have not yet dened such a function. Nevertheless, we can introduce an unnamed function using the LAMBDA notation available in PVS: (LAMBDA (x: [flt_db, flight, preference]): (1,1)) The LAMBDA keyword merely indicates that a function without a name is being dened. The expressions immediately after a LAMBDA dene the parameters of the function. In this case, there is one parameter x of type [flt_db, flight, preference]. The body of the function follows the \:". In this case the body is (1,1) which is the contant ordered pair that indicates that row =1 11

15 and position =1. Now to tell the prover to use this function in formula {1}, we use the INST command as follows: Rule? (INST 1 "(LAMBDA (x: [flt_db, flight, preference]): (1,1))") Instantiating the top quantifier in 1 with the terms: (LAMBDA (x: [flt_db, flight, preference]): (1,1)), this yields 2 subgoals: Next_seat_TCC1.1 (TCC): {1} 1 <= nposits The prover tells us that wenowhavetwo subgoals to prove. The rst one named Next_seat_TCC1.1 is displayed for us, Since this is a trivial result that follows directly from the declaration of nposits, we issue an ASSERT command: Rule? (assert) Simplifying, rewriting, and recording with decision procedures, This completes the proof of Next_seat_TCC1.1. Next_seat_TCC1.2 (TCC): {1} 1 <= nrows The prover tells us that Next_seat_TCC1.1 is complete and displays the other subgoal. We issue ASSERT again, and we receive: Rule? (assert) Simplifying, rewriting, and recording with decision procedures, This completes the proof of Next_seat_TCC1.2. Q.E.D. Run time = 1.77 secs. Real time = secs. The prover produces Q.E.D. which informs us that we are done. 3 Formal Verications In this section we will walk-through the mechanical verication of the invariant properties discussed previously. This will be done using the basic commands of PVS and not the more powerful strategies. Although skilled PVS users would not approach the proofs in the manner presented 12

16 here, working through these proofs can be an excellent learning experience for the novice. Once the basic commands have been mastered, the reader should continue with the following more advanced tutorial that is based upon the same example used in this paper: J. M. Rushby and D. W. J. Stringer-Calvert "A Less Elementary Tutorial for the PVS Specication and Verication System", SRI International Technical Report CSL-95-10, June The more advanced tutorial presents proofs of all of the theorems and lemmas using no more than two or three PVS commands. To establish that the state invariant is preserved by every operation, we must prove theorems of the form: I(S1) I(op spec(s1)) where S1 is the state before the operation and I represents the state invariant. Note that op spec(s1) is the state of the system after the operation. For our example, the required theorems can be expressed as follows: Cancel_assn_inv: THEOREM db_invariant(db) => db_invariant(cancel_assn(flt,pas,db)) Make_assn_inv: THEOREM db_invariant(db) => db_invariant(make_assn(flt,pas,pref,db)) 3.1 Proof that Cancel assn Maintains the Invariant Although it is almost always advisable to search for a proof before engaging the theorem prover, the prover can be useful in the discovery of the proof. We shall use this approach on this example, since the theorem is shallow and not hard to understand. This section is meant to guide the PVS novice through his rst non-trivial use of the theorem prover. The goal is to gain some familiarity with the capabilities of the system so that further reading in the user manuals is more productive. The proofs given in this tutorial are by no means the best way of proving these theorems. They were performed with the goal of walking the user through a large number of the PVS commands 6. The user begins a proof session by positioning the cursor on a proof and typing M-x pr. The system responds with: Cancel_assn_inv : {1} (FORALL (db: flt_db, flt: flight, pas: passenger): db_invariant(db) IMPLIES db_invariant(cancel_assn(flt, pas, db))) The user then issues commands that manipulate the formula using truth-preserving operations. The goal, of course, is to simplify the formula to the point where the prover can identify the 6 All of these theorems can be proved using only a few of the more powerful PVS strategies. See J. M. Rushby and D. W. J. Stringer-Calvert "A Less Elementary Tutorial for the PVS Specication and Verication System", SRI International Technical Report CSL-95-10, June

17 formula as a tautology and thus a theorem. The user input in this paper can be identied by the rule? prompt. All of the inputs in this tutorial are only one line. Although PVS allows commands to be entered in either lower or upper case, we will use upper-case letters exclusively to enhance readability. However, the PVS language is case-sensitive and thus identiers within quotes must be the same as they appear in the specication. The abbreviations for the commands (e.g. TAB E) are case-sensitive. The rst thing that one usually does when proving a formula containing quantiers (i.e. FORALLS or EXISTS) is to remove them. This is necessary because many of the PVS commands are only eective when the quantiers have been removed. There are two basic strategies for removing quantiers: skolemization and instantiation. Some situations require skolemization and others require instantiation. In this case we need to skolemize formula [1] 7. In PVS this is accomplished using the SKOSIMP* command (TAB *): Rule? (SKOSIMP*) Repeatedly Skolemizing and flattening, Cancel_assn_inv : {-1} db_invariant(db!1) {1} db_invariant(cancel_assn(flt!1, pas!1, db!1)) Tosave the user from excessive amounts of typing, the PVS system provides abbreviated commands. Thus, the user could have typed TAB * which is the abbreviation for SKOSIMP*. We will follow the command name with the abbreviation in parentheses as an aid throughout this paper. Notice that the system has replaced the variable db with a new constant db!1. Similarly, the variables pas and flt have been replaced by pas!1 and flt!1, respectively 8. Clearly, no progress can be made until the meaning of db_invariant is exposed to the prover. This is done through use of the EXPAND command (TAB e), i.e. (EXPAND "db_invariant") 9. The system responds as follows: Rule? (EXPAND "db_invariant" ) Expanding the definition of db_invariant, Cancel_assn_inv : {-1} existence(db!1) AND uniqueness(db!1) {1} existence(cancel_assn(flt!1, pas!1, db!1)) AND uniqueness(cancel_assn(flt!1, pas!1, db!1)) 7 The basic idea of skolemization is that a formula like 8x : P (x) which asserts the validity of a predicate P for an arbitrary value of x, is equivalent to P (a) where a is a previously unused constant. 8 This may not have been your rst choice for names, but it has the advantage that the name of the original quantied variable is easily retrieved from the skolem name. 9 The TAB e command is special in that the user moves the cursor to point to an instance of the identier that is to be expanded in the current sequent. This is done prior to typing TAB e. This saves the user from having to type in the identier. 14

18 The conjunction in formula {-1} can be broken into two separate formulas with the FLATTEN command (or TAB f): Rule? (flatten) Applying disjunctive simplification to flatten sequent, Cancel_assn_inv : {-1} existence(db!1) {-2} uniqueness(db!1) [1] existence(cancel_assn(flt!1, pas!1, db!1)) AND uniqueness(cancel_assn(flt!1, pas!1, db!1)) This is a probably a good place to discuss in more detail the nature of a \sequent". The system has broken the formula into three separate formulas labeled {-1}, {-2} and [1] separated by a horizontal line. The basic idea is that all of the formulas labeled with positive numbers logically follow from the formulas labeled with negative numbers. More precisely, the conjunction of the antecedent (i.e. negative) formulas logically implies the disjunction of the consequent (i.e. positive) formulas. The curly braces indicate recently changed formulas whereas the square brackets indicate unchanged formulas. In this instance we have: f,1g^f,2g,! [1] We now notice that formula {1} is the conjunction (i.e. AND) of two formulas. In order for the formula to be true, each of these must separately be true. To reduce the amount of text that we have to think about at one time, it is helpful to break the proof into two separate steps. The PVS system lets us do this with the SPLIT command (TAB s): Rule? (SPLIT 1) Splitting conjunctions, this yields 2 subgoals: Cancel_assn_inv.1 : {-1} existence(db!1) {-2} uniqueness(db!1) {1} existence(cancel_assn(flt!1, pas!1, db!1)) The \1" in the command indicates that it should only be applied to formula 1. The system responds with Splitting conjunctions, this yields 2 subgoals: and presents us with the rst subgoal. We then proceed to expand with denitions of existence and Cancel assn: Rule? (EXPAND "existence") Expanding the definition of existence Cancel_db_inv : 15

19 {-1} (FORALL (a: [# pass: passenger, seat: [row, position] #]), (flt: flight): member(a, db!1(flt)) IMPLIES seat_exists(aircraft(flt), seat(a))) [-2] uniqueness(db!1) {1} (FORALL (a: [# pass: passenger, seat: [row, position] #]), (flt: flight): member(a, Cancel_assn(flt!1, pas!1, db!1)(flt)) IMPLIES seat_exists(aircraft(flt), seat(a))) Rule? (EXPAND "Cancel_assn") Expanding the definition of Cancel_assn, Cancel_assn_inv.1 : [-1] (FORALL (a: [# pass: passenger, seat: [row, position] #]), (flt: flight): member(a, db!1(flt)) IMPLIES seat_exists(aircraft(flt), seat(a))) [-2] uniqueness(db!1) {1} (FORALL (a: [# pass: passenger, seat: [row, position] #]), (flt: flight): member(a, db!1 WITH [(flt!1) := {a: [# pass: passenger, seat: [row, position] #] member(a, db!1(flt!1)) AND pass(a) /= pas!1}](flt)) IMPLIES seat_exists(aircraft(flt), seat(a))) We note that the function member appears in several places in the formula. Although this function is dened in the PVS prelude 10,itmust still be expanded in order for PVS to know what it means: Rule? (EXPAND "member") Expanding the definition of member, Cancel_assn_inv.1 : {-1} (FORALL (a: [# pass: passenger, seat: [row, position] #]), (flt: flight): db!1(flt)(a) IMPLIES seat_exists(aircraft(flt), seat(a))) [-2] uniqueness(db!1) {1} (FORALL (a: [# pass: passenger, seat: [row, position] #]), (flt: flight): db!1 WITH [(flt!1) := {a: [# pass: passenger, 10 This can be inspected by typing M-x vpf or M-x vpt "sets" 16

20 seat: [row, position] #] db!1(flt!1)(a) AND pass(a) /= pas!1}](flt)(a) IMPLIES seat_exists(aircraft(flt), seat(a))) Notice that member(a,db(flt)) has been changed to Db(flt)(a). This looks funny at rst, but it is correct. In PVS, sets are represented as functions that map from the domain type of the set into boolean 11. This boolean-valued function is true only for members of the set, i.e. S(x) is true if and only if x 2 S. Since the formula {1} once again has a FORALL quantier below the line, we issue a SKOSIMP* command (TAB *) to eliminate it: Rule? (SKOSIMP*) Repeatedly Skolemizing and flattening, Cancel_assn_inv.1 : {-1} db!1 WITH [(flt!1) := {a: [# pass: passenger, seat: [row, position] #] db!1(flt!1)(a) AND pass(a) /= pas!1}](flt!2)(a!1) [-2] (FORALL (a: [# pass: passenger, seat: [row, position] #]), (flt: flight): db!1(flt)(a) IMPLIES seat_exists(aircraft(flt), seat(a))) [-3] uniqueness(db!1) {1} seat_exists(aircraft(flt!2), seat(a!1)) The WITH statement in formula {-1} can be reduced to an equivalent IF-THEN-ELSE using a LIFT-IF command (TAB l): Rule? (LIFT-IF -1) Lifting IF-conditions to the top level, Cancel_assn_inv.1 : {-1} IF flt!1 = flt!2 THEN ({a: [# pass: passenger, seat: [row, position] #] db!1(flt!1)(a) AND pass(a) /= pas!1})(a!1) ELSE db!1(flt!2)(a!1) 11 This approach is feasible in a higher-order logic and can be shown to be sound. 17

Report T97:04 ISRN : SICS-T{97/04-SE ISSN : 1100-3154 Using Formal Methods A practical comparison between Z/EVES and PVS by Daniel Fredholm FDT 971204 Swedish Institute of Computer Science Box 1263, S-164

### 2. Methods of Proof Types of Proofs. Suppose we wish to prove an implication p q. Here are some strategies we have available to try.

2. METHODS OF PROOF 69 2. Methods of Proof 2.1. Types of Proofs. Suppose we wish to prove an implication p q. Here are some strategies we have available to try. Trivial Proof: If we know q is true then

### PVS System Guide Version 2.4 November 2001

PVS System Guide Version 2.4 November 2001 S. Owre N. Shankar J. M. Rushby D. W. J. Stringer-Calvert {Owre,Shankar,Rushby,Dave_SC}@csl.sri.com http://pvs.csl.sri.com/ SRI International Computer Science

### Inference Rules and Proof Methods

Inference Rules and Proof Methods Winter 2010 Introduction Rules of Inference and Formal Proofs Proofs in mathematics are valid arguments that establish the truth of mathematical statements. An argument

Verication by Finitary Abstraction Weizmann Institute of Sciences and Universite Joseph Fourier, Grenoble Fourth International Spin Workshop (SPIN'98) Paris 2.11.98 Joint work with: Y. Kesten Ben Gurion

### Specication and Renement with

Chapter 6 On the Verication of VDM Specication and Renement with PVS Sten Agerholm, Juan Bicarregui and Savi Maharaj Summary This chapter describes using the PVS system as a tool to support VDM- SL. It

### Chapter 1: Key Concepts of Programming and Software Engineering

Chapter 1: Key Concepts of Programming and Software Engineering Software Engineering Coding without a solution design increases debugging time - known fact! A team of programmers for a large software development

### Introducing Formal Methods. Software Engineering and Formal Methods

Introducing Formal Methods Formal Methods for Software Specification and Analysis: An Overview 1 Software Engineering and Formal Methods Every Software engineering methodology is based on a recommended

### Higher-Order Logic. Specification and Verification with Higher-Order Logic

Higher-Order Logic Specification and Verification with Higher-Order Logic Arnd Poetzsch-Heffter Software Technology Group Fachbereich Informatik Technische Universität Kaiserslautern Sommersemester 2010

### [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

### Logic, Sets, and Proofs

Logic, Sets, and Proofs David A. Cox and Catherine C. McGeoch Amherst College 1 Logic Logical Statements. A logical statement is a mathematical statement that is either true or false. Here we denote logical

### 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

### Chapter 1. Logic and Proof

Chapter 1. Logic and Proof 1.1 Remark: A little over 100 years ago, it was found that some mathematical proofs contained paradoxes, and these paradoxes could be used to prove statements that were known

### Mathematics for Economics (Part I) Note 5: Convex Sets and Concave Functions

Natalia Lazzati Mathematics for Economics (Part I) Note 5: Convex Sets and Concave Functions Note 5 is based on Madden (1986, Ch. 1, 2, 4 and 7) and Simon and Blume (1994, Ch. 13 and 21). Concave functions

### Peter V. Homeier and David F. Martin. homeier@cs.ucla.edu and dmartin@cs.ucla.edu

A Mechanically Veried Verication Condition Generator Peter V. Homeier and David F. Martin Computer Science Department, University of California, Los Angeles 90024 USA homeier@cs.ucla.edu and dmartin@cs.ucla.edu

### 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

### 2.1.1 Examples of Sets and their Elements

Chapter 2 Set Theory 2.1 Sets The most basic object in Mathematics is called a set. As rudimentary as it is, the exact, formal definition of a set is highly complex. For our purposes, we will simply define

### 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

### 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

### Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II)

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

### (Refer Slide Time: 1:41)

Discrete Mathematical Structures Dr. Kamala Krithivasan Department of Computer Science and Engineering Indian Institute of Technology, Madras Lecture # 10 Sets Today we shall learn about sets. You must

### Trust but Verify: Authorization for Web Services. The University of Vermont

Trust but Verify: Authorization for Web Services Christian Skalka X. Sean Wang The University of Vermont Trust but Verify (TbV) Reliable, practical authorization for web service invocation. Securing complex

### WUCT121. Discrete Mathematics. Logic

WUCT121 Discrete Mathematics Logic 1. Logic 2. Predicate Logic 3. Proofs 4. Set Theory 5. Relations and Functions WUCT121 Logic 1 Section 1. Logic 1.1. Introduction. In developing a mathematical theory,

### MAT2400 Analysis I. A brief introduction to proofs, sets, and functions

MAT2400 Analysis I A brief introduction to proofs, sets, and functions In Analysis I there is a lot of manipulations with sets and functions. It is probably also the first course where you have to take

### Invertible elements in associates and semigroups. 1

Quasigroups and Related Systems 5 (1998), 53 68 Invertible elements in associates and semigroups. 1 Fedir Sokhatsky Abstract Some invertibility criteria of an element in associates, in particular in n-ary

### Formal Engineering for Industrial Software Development

Shaoying Liu Formal Engineering for Industrial Software Development Using the SOFL Method With 90 Figures and 30 Tables Springer Contents Introduction 1 1.1 Software Life Cycle... 2 1.2 The Problem 4 1.3

### Verifying Specifications with Proof Scores in CafeOBJ

Verifying Specifications with Proof Scores in CafeOBJ FUTATSUGI, Kokichi 二 木 厚 吉 Chair of Language Design Graduate School of Information Science Japan Advanced Institute of Science and Technology (JAIST)

### Moving from CS 61A Scheme to CS 61B Java

Moving from CS 61A Scheme to CS 61B Java Introduction Java is an object-oriented language. This document describes some of the differences between object-oriented programming in Scheme (which we hope you

### Problem Set 1: Program Verification

Problem Set 1: Program Verification CS 173 Honors Section Assigned: September 7, 2011 Due on: September 14, 2011 One of the applications of logic in computer science is its use in proving programs to be

### The Foundations: Logic and Proofs. Chapter 1, Part III: Proofs

The Foundations: Logic and Proofs Chapter 1, Part III: Proofs Rules of Inference Section 1.6 Section Summary Valid Arguments Inference Rules for Propositional Logic Using Rules of Inference to Build Arguments

### def: An axiom is a statement that is assumed to be true, or in the case of a mathematical system, is used to specify the system.

Section 1.5 Methods of Proof 1.5.1 1.5 METHODS OF PROOF Some forms of argument ( valid ) never lead from correct statements to an incorrect. Some other forms of argument ( fallacies ) can lead from true

### Systems of Linear Equations in Two Variables

Chapter 6 Systems of Linear Equations in Two Variables Up to this point, when solving equations, we have always solved one equation for an answer. However, in the previous chapter, we saw that the equation

### MAT-71506 Program Verication: Exercises

MAT-71506 Program Verication: Exercises Antero Kangas Tampere University of Technology Department of Mathematics September 11, 2014 Accomplishment Exercises are obligatory and probably the grades will

### 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

### 1.2 Solving a System of Linear Equations

1.. SOLVING A SYSTEM OF LINEAR EQUATIONS 1. Solving a System of Linear Equations 1..1 Simple Systems - Basic De nitions As noticed above, the general form of a linear system of m equations in n variables

### 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

### 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

### Summation Algebra. x i

2 Summation Algebra In the next 3 chapters, we deal with the very basic results in summation algebra, descriptive statistics, and matrix algebra that are prerequisites for the study of SEM theory. You

### ML for the Working Programmer

ML for the Working Programmer 2nd edition Lawrence C. Paulson University of Cambridge CAMBRIDGE UNIVERSITY PRESS CONTENTS Preface to the Second Edition Preface xiii xv 1 Standard ML 1 Functional Programming

### Topic 1: Matrices and Systems of Linear Equations.

Topic 1: Matrices and Systems of Linear Equations Let us start with a review of some linear algebra concepts we have already learned, such as matrices, determinants, etc Also, we shall review the method

### Math 3000 Running Glossary

Math 3000 Running Glossary Last Updated on: July 15, 2014 The definition of items marked with a must be known precisely. Chapter 1: 1. A set: A collection of objects called elements. 2. The empty set (

### (LMCS, p. 317) V.1. First Order Logic. This is the most powerful, most expressive logic that we will examine.

(LMCS, p. 317) V.1 First Order Logic This is the most powerful, most expressive logic that we will examine. Our version of first-order logic will use the following symbols: variables connectives (,,,,

### Fundamentals of Mathematics Lecture 6: Propositional Logic

Fundamentals of Mathematics Lecture 6: Propositional Logic Guan-Shieng Huang National Chi Nan University, Taiwan Spring, 2008 1 / 39 Connectives Propositional Connectives I 1 Negation: (not A) A A T F

### So far we have considered only numeric processing, i.e. processing of numeric data represented

Chapter 4 Processing Character Data So far we have considered only numeric processing, i.e. processing of numeric data represented as integer and oating point types. Humans also use computers to manipulate

### 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

### 2. Propositional Equivalences

2. PROPOSITIONAL EQUIVALENCES 33 2. Propositional Equivalences 2.1. Tautology/Contradiction/Contingency. Definition 2.1.1. A tautology is a proposition that is always true. Example 2.1.1. p p Definition

### 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

### Managing large sound databases using Mpeg7

Max Jacob 1 1 Institut de Recherche et Coordination Acoustique/Musique (IRCAM), place Igor Stravinsky 1, 75003, Paris, France Correspondence should be addressed to Max Jacob (max.jacob@ircam.fr) ABSTRACT

### Chapter II. Controlling Cars on a Bridge

Chapter II. Controlling Cars on a Bridge 1 Introduction The intent of this chapter is to introduce a complete example of a small system development. During this development, you will be made aware of the

### ECE 341 Coding Standard

Page1 ECE 341 Coding Standard Professor Richard Wall University of Idaho Moscow, ID 83843-1023 rwall@uidaho.edu August 27, 2013 1. Motivation for Coding Standards The purpose of implementing a coding standard

### CS510 Software Engineering

CS510 Software Engineering Propositional Logic Asst. Prof. Mathias Payer Department of Computer Science Purdue University TA: Scott A. Carr Slides inspired by Xiangyu Zhang http://nebelwelt.net/teaching/15-cs510-se

### Introduction to Proofs

Chapter 1 Introduction to Proofs 1.1 Preview of Proof This section previews many of the key ideas of proof and cites [in brackets] the sections where they are discussed thoroughly. All of these ideas are

### 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

### Math 181 Spring 2007 HW 1 Corrected

Math 181 Spring 2007 HW 1 Corrected February 1, 2007 Sec. 1.1 # 2 The graphs of f and g are given (see the graph in the book). (a) State the values of f( 4) and g(3). Find 4 on the x-axis (horizontal axis)

### 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

### Predicate Logic Review

Predicate Logic Review UC Berkeley, Philosophy 142, Spring 2016 John MacFarlane 1 Grammar A term is an individual constant or a variable. An individual constant is a lowercase letter from the beginning

### Section 1. Statements and Truth Tables. Definition 1.1: A mathematical statement is a declarative sentence that is true or false, but not both.

M3210 Supplemental Notes: Basic Logic Concepts In this course we will examine statements about mathematical concepts and relationships between these concepts (definitions, theorems). We will also consider

### Deterministic Discrete Modeling

Deterministic Discrete Modeling Formal Semantics of Firewalls in Isabelle/HOL Cornelius Diekmann, M.Sc. Dr. Heiko Niedermayer Prof. Dr.-Ing. Georg Carle Lehrstuhl für Netzarchitekturen und Netzdienste

### 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)

### LOGICAL INFERENCE & PROOFs. Debdeep Mukhopadhyay Dept of CSE, IIT Madras

LOGICAL INFERENCE & PROOFs Debdeep Mukhopadhyay Dept of CSE, IIT Madras Defn A theorem is a mathematical assertion which can be shown to be true. A proof is an argument which establishes the truth of a

### 4.6 Null Space, Column Space, Row Space

NULL SPACE, COLUMN SPACE, ROW SPACE Null Space, Column Space, Row Space In applications of linear algebra, subspaces of R n typically arise in one of two situations: ) as the set of solutions of a linear

### Mechanical Verification of a Garbage Collector

Mechanical Verification of a Garbage Collector by Klaus Havelund FMPPTA 99 Talk by Sibylle Aregger Motivation handwritten proofs are error prone show approach to verify algorithm mechanically 2 Contents

### Chapter 15 Functional Programming Languages

Chapter 15 Functional Programming Languages Introduction - The design of the imperative languages is based directly on the von Neumann architecture Efficiency (at least at first) is the primary concern,

### COMPUTER SCIENCE TRIPOS

CST.98.5.1 COMPUTER SCIENCE TRIPOS Part IB Wednesday 3 June 1998 1.30 to 4.30 Paper 5 Answer five questions. No more than two questions from any one section are to be answered. Submit the answers in five

### Language. Johann Eder. Universitat Klagenfurt. Institut fur Informatik. Universiatsstr. 65. A-9020 Klagenfurt / AUSTRIA

PLOP: A Polymorphic Logic Database Programming Language Johann Eder Universitat Klagenfurt Institut fur Informatik Universiatsstr. 65 A-9020 Klagenfurt / AUSTRIA February 12, 1993 Extended Abstract The

### Chapter 2: Problem Solving Using C++

Chapter 2: Problem Solving Using C++ 1 Objectives In this chapter, you will learn about: Modular programs Programming style Data types Arithmetic operations Variables and declaration statements Common

### VISUAL GUIDE to. RX Scripting. for Roulette Xtreme - System Designer 2.0

VISUAL GUIDE to RX Scripting for Roulette Xtreme - System Designer 2.0 UX Software - 2009 TABLE OF CONTENTS INTRODUCTION... ii What is this book about?... iii How to use this book... iii Time to start...

### 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

### MATH 55: HOMEWORK #2 SOLUTIONS

MATH 55: HOMEWORK # SOLUTIONS ERIC PETERSON * 1. SECTION 1.5: NESTED QUANTIFIERS 1.1. Problem 1.5.8. Determine the truth value of each of these statements if the domain of each variable consists of all

### SPSS: Getting Started. For Windows

For Windows Updated: August 2012 Table of Contents Section 1: Overview... 3 1.1 Introduction to SPSS Tutorials... 3 1.2 Introduction to SPSS... 3 1.3 Overview of SPSS for Windows... 3 Section 2: Entering

### 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

### Logic, Algebra and Truth Degrees 2008. Siena. A characterization of rst order rational Pavelka's logic

Logic, Algebra and Truth Degrees 2008 September 8-11, 2008 Siena A characterization of rst order rational Pavelka's logic Xavier Caicedo Universidad de los Andes, Bogota Under appropriate formulations,

### Mining the Software Change Repository of a Legacy Telephony System

Mining the Software Change Repository of a Legacy Telephony System Jelber Sayyad Shirabad, Timothy C. Lethbridge, Stan Matwin School of Information Technology and Engineering University of Ottawa, Ottawa,

### Likewise, we have contradictions: formulas that can only be false, e.g. (p p).

CHAPTER 4. STATEMENT LOGIC 59 The rightmost column of this truth table contains instances of T and instances of F. Notice that there are no degrees of contingency. If both values are possible, the formula

### Chapter I Logic and Proofs

MATH 1130 1 Discrete Structures Chapter I Logic and Proofs Propositions A proposition is a statement that is either true (T) or false (F), but or both. s Propositions: 1. I am a man.. I am taller than

### 31 is a prime number is a mathematical statement (which happens to be true).

Chapter 1 Mathematical Logic In its most basic form, Mathematics is the practice of assigning truth to welldefined statements. In this course, we will develop the skills to use known true statements to

### A Concrete Introduction. to the Abstract Concepts. of Integers and Algebra using Algebra Tiles

A Concrete Introduction to the Abstract Concepts of Integers and Algebra using Algebra Tiles Table of Contents Introduction... 1 page Integers 1: Introduction to Integers... 3 2: Working with Algebra Tiles...

### The Generalized Railroad Crossing: A Case Study in Formal. Abstract

The Generalized Railroad Crossing: A Case Study in Formal Verication of Real-Time Systems Constance Heitmeyer Nancy Lynch y Abstract A new solution to the Generalized Railroad Crossing problem, based on

### 1 Structured Query Language: Again. 2 Joining Tables

1 Structured Query Language: Again So far we ve only seen the basic features of SQL. More often than not, you can get away with just using the basic SELECT, INSERT, UPDATE, or DELETE statements. Sometimes

### Name: Class: Date: 9. The compiler ignores all comments they are there strictly for the convenience of anyone reading the program.

Name: Class: Date: Exam #1 - Prep True/False Indicate whether the statement is true or false. 1. Programming is the process of writing a computer program in a language that the computer can respond to

APPENDIX B Advanced Relational Database Design In this appendix we cover advanced topics in relational database design. We first present the theory of multivalued dependencies, including a set of sound

### Parametric Domain-theoretic models of Linear Abadi & Plotkin Logic

Parametric Domain-theoretic models of Linear Abadi & Plotkin Logic Lars Birkedal Rasmus Ejlers Møgelberg Rasmus Lerchedahl Petersen IT University Technical Report Series TR-00-7 ISSN 600 600 February 00

### 1 Using a SQL Filter in Outlook 2002/2003 Views. 2 Defining the Problem The Task at Hand

1 Using a SQL Filter in Outlook 2002/2003 Views Those of you who have used Outlook for a while may have discovered the power of Outlook Views and use these on every folder to group, sort and filter your

### The design recipe. Programs as communication. Some goals for software design. Readings: HtDP, sections 1-5

The design recipe Readings: HtDP, sections 1-5 (ordering of topics is different in lectures, different examples will be used) Survival and Style Guides CS 135 Winter 2016 02: The design recipe 1 Programs

### Prime Numbers. Chapter Primes and Composites

Chapter 2 Prime Numbers The term factoring or factorization refers to the process of expressing an integer as the product of two or more integers in a nontrivial way, e.g., 42 = 6 7. Prime numbers are

### Requirements document for an automated teller machine. network

Requirements document for an automated teller machine network August 5, 1996 Contents 1 Introduction 2 1.1 Purpose : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 2 1.2 Scope

### Pythagorean Theorem. Overview. Grade 8 Mathematics, Quarter 3, Unit 3.1. Number of instructional days: 15 (1 day = minutes) Essential questions

Grade 8 Mathematics, Quarter 3, Unit 3.1 Pythagorean Theorem Overview Number of instructional days: 15 (1 day = 45 60 minutes) Content to be learned Prove the Pythagorean Theorem. Given three side lengths,

Mathematics 0N1 Solutions 1 1. Write the following sets in list form. 1(i) The set of letters in the word banana. {a, b, n}. 1(ii) {x : x 2 + 3x 10 = 0}. 3(iv) C A. True 3(v) B = {e, e, f, c}. True 3(vi)

### Proof: A logical argument establishing the truth of the theorem given the truth of the axioms and any previously proven theorems.

Math 232 - Discrete Math 2.1 Direct Proofs and Counterexamples Notes Axiom: Proposition that is assumed to be true. Proof: A logical argument establishing the truth of the theorem given the truth of the

### Semantic Errors in SQL Queries: A Quite Complete List

Semantic Errors in SQL Queries: A Quite Complete List Christian Goldberg, Stefan Brass Martin-Luther-Universität Halle-Wittenberg {goldberg,brass}@informatik.uni-halle.de Abstract We investigate classes

### SJÄLVSTÄNDIGA ARBETEN I MATEMATIK

SJÄLVSTÄNDIGA ARBETEN I MATEMATIK MATEMATISKA INSTITUTIONEN, STOCKHOLMS UNIVERSITET Automated Theorem Proving av Tom Everitt 2010 - No 8 MATEMATISKA INSTITUTIONEN, STOCKHOLMS UNIVERSITET, 106 91 STOCKHOLM

### FURTHER VECTORS (MEI)

Mathematics Revision Guides Further Vectors (MEI) (column notation) Page of MK HOME TUITION Mathematics Revision Guides Level: AS / A Level - MEI OCR MEI: C FURTHER VECTORS (MEI) Version : Date: -9-7 Mathematics

CBV Semantics (Draft) Navit Fedida, John Havlicek, Nissan Levi, and Hillel Miller Motorola, Inc. 7700 W. Parmer Lane Austin, TX 78729 13 January 2002 Abstract A precise denition is given of the semantics

### 1. R In this and the next section we are going to study the properties of sequences of real numbers.

+a 1. R In this and the next section we are going to study the properties of sequences of real numbers. Definition 1.1. (Sequence) A sequence is a function with domain N. Example 1.2. A sequence of real

### RIT Installation Instructions

RIT User Guide Build 1.00 RIT Installation Instructions Table of Contents Introduction... 2 Introduction to Excel VBA (Developer)... 3 API Commands for RIT... 11 RIT API Initialization... 12 Algorithmic

### CSE 308. Coding Conventions. Reference

CSE 308 Coding Conventions Reference Java Coding Conventions googlestyleguide.googlecode.com/svn/trunk/javaguide.html Java Naming Conventions www.ibm.com/developerworks/library/ws-tipnamingconv.html 2

### ON FUNCTIONAL SYMBOL-FREE LOGIC PROGRAMS

PROCEEDINGS OF THE YEREVAN STATE UNIVERSITY Physical and Mathematical Sciences 2012 1 p. 43 48 ON FUNCTIONAL SYMBOL-FREE LOGIC PROGRAMS I nf or m at i cs L. A. HAYKAZYAN * Chair of Programming and Information

### The Predicate Calculus in AI

Last time, we: The Predicate Calculus in AI Motivated the use of Logic as a representational language for AI (Can derive new facts syntactically - simply by pushing symbols around) Described propositional