A Simplified Abstract Syntax for the Dataflow Algebra. A. J. Cowling

Size: px
Start display at page:

Download "A Simplified Abstract Syntax for the Dataflow Algebra. A. J. Cowling"

Transcription

1 Verification and Testing Research Group, Department of Computer Science, University of Sheffield, Regent Court, 211, Portobello Street, Sheffield, S1 4DP, United Kingdom dcs.shef.ac.uk Telephone: Fax: Abstract Previous definitions of the dataflow algebra have been identified as suffering from two practical problems, and this report discusses how both of these could be resolved. One problem is that the naming of the syntactic and semantic layers of detail of the algebra causes some confusion, and the reasons are described for renaming these as the event and computation layers respectively. The other problem is that the abstract syntax for what is now being called the event layer employed a number of sub-domains, reflecting the fact that it was concerned as much with defining the syntax of expressions in the algebra as it was with the underlying semantic domain. This report therefore presents a simplified version of the abstract syntax, which provides a more appropriate definition of the underlying semantic domain. It then shows how the fundamental axioms and theorems of the earlier version apply to the new abstract syntax, and in particular it corrects an error in the previous version of the formal semantics for the algebra, and hence shows the soundness and completeness of these axioms. The new version also gives a simpler presentation of the underlying algebra, while being fully consistent with the earlier version. Key Words and Phrases Formal specifications, data flow diagrams, dataflow algebra, semantic domains, syntax of expressions, parallel systems, distributed systems. 1. Introduction In developing the dataflow algebra (DFA from now on) as a formal model for data flow diagrams [1], a formal definition was produced for the abstract syntax of the DFA [2], and this was then used extensively by Nike in the work for his PhD thesis [3]. During the course of Nike's work, various comments were made by other reviewers to the effect that there was scope for simplifying this abstract syntax, in order to use just a single semantic domain rather than the multiple domains that had been adopted. Separately, other reviewers had also commented on the names that were being used for the three levels of detail into which the DFA structures its models of systems. Initially these had been termed the lexical, syntactic and semantic levels, based on the analogy between DFA specifications and formal grammars, but (as described in [2]) the lexical layer had soon been renamed the topological layer, since this reflected more precisely its role in the specification process, namely that of defining the topology of the system being specified. As the DFA had been developed, and the idea of there being a separate layer of the notation for each level of detail had been established, so it had become clear that each layer required rigorous definition of both its syntax and its semantics. This had led to apparent complications of the terminology, which required distinctions to be made between constructs such as the semantics of the syntactic layer and the syntax of the semantic layer. The reviewers had therefore suggested that these complications could be avoided if new names could be found for the other two layers as well, in order to reflect better their roles within the specification process. The purpose of this report is therefore to describe responses to both of these suggestions. Section 2 discusses the naming of the levels of detail within the DFA approach, and section 3 overviews the issue of defining the abstract syntax for what hitherto has been called the syntactic layer, and the effects on this issue of the distinction between single and multiple semantic domains. The rest of the report then develops the detail of an abstract syntax that is based on what for this purpose should be classed as a single semantic domain, although (as section 4 describes), this does actually involve a number of related semantic domains rather than just one.

2 2. Naming the Levels of Detail In trying to find new names for what previously have been called the syntactic and semantic layers of a DFA specification, the obvious main criterion for evaluating different possible names is that they should reflect accurately the roles of the layers within a specification. In addition, there is a secondary criterion to consider, which is the impact of any name change on the machine-readable version of the DFA, as defined in [2]. Currently this defines that each layer of a specification should be structured into one or more sections that each begin with a keyword identifying the relevant layer, namely TOPOLOGY, SYNTAX or SEMANTICS. Any change in the name of a layer should therefore be matched by a change to the corresponding keyword, although for practical reasons of backwards compatibility it would be preferable to introduce the new keyword as an alternative to rather than a replacement for the old one. Thus, the new names for the layers also have to be chosen so as not to conflict with keywords or key concepts that are already in use in the machine readable notation. For the syntactic layer, its role in a specification is to define the permitted sequences of actions, which suggests that a name such as the sequencing layer might be an appropriate choice. Unfortunately, though, the second criterion rules this out, because the concept of sequence is already in use as one of the primitive types, represented by the keyword SEQ. Hence, an alternative needs to be found, while still conveying the notion of defining the possible order in which actions can occur. Possibilities such as the ordering layer or the time layer have been considered, but neither seem particularly appropriate, since they do not indicate what things are being ordered, or are being constrained to occur at particular times. These names could, of course, be expanded to something like action ordering layer or action time layer, but the result would be clumsy, and again the concept of action is already in use as a primitive type, represented by the keyword ACT, and so these possibilities must be ruled out too. Other analysis and design methods were then reviewed, to see whether they used terms that could be borrowed for this purpose, and it was noted that in SSADM the term event is used to correspond to what would be modelled in the DFA as an action. For instance: An event is something that happens in the real world to cause a change to be made to the database. We usually, though not always, show the trigger as a data flow across the system boundary. [4 page 188]. Furthermore, events have a time ordering associated with them, which is modelled in SSADM using the technique of entity life histories: The life is expressed as the permitted sequence of events that can cause the entity to change. [5 page 43]. This is also consistent with the use of the term event in the programming of graphical user interfaces, where again the notion of a stream of events that occur in a particular sequence is fundamental. This suggests that a name such as the event ordering layer or event sequence layer would be appropriate, and in practice it would be simpler to just shorten this to event layer. This is therefore the name that has been chosen, and from now on what has previously been called the syntactic layer of the DFA will be referred to as the event layer. Consequently, in the machine readable form of the notation, the keyword EVENT will need to be introduced as an alternative to SYNTAX. Turning to the semantic layer, the role of this is essentially to define what data flows from one process to another in the course of each action, which in practice also means defining what processing has to take place to generate this data, and then what processing has to take place to handle it. This suggested that a possible name for it might be the data value layer, but this was clumsy, while shortening it to the data layer seemed liable to cause confusion with the whole activity of data modelling, which is nominally a separate activity from the process modelling that is the primary purpose of the DFA. Another possibility was to use a name such processing layer, but again this could cause confusion for much the same reason, since all three layers of the DFA are concerned with modelling aspects of the processing in a system. These possibilities did, however, lead to the idea of trying to find a name that would combine the two concepts of data and processing, since to some extent the semantic layer does define the combination of these. A term that is often used for this combination is computation, and so the name computation layer has been chosen as the alternative to semantic layer, so that from now on what has previously been called the semantic layer of the DFA will be referred to as the computation layer. In the machine readable form of the notation this will be abbreviated to COMP, and so this keyword will need to be introduced as an alternative to SEMANTICS. Having made these name changes, the DFA will therefore be described in future as having three layers of detail, namely the topological, event and computation layers. Then, each of these three layers will have both a syntax and a semantics, but references to these will not run the risk of being confused with the names of the layers themselves. 3. The Abstract Syntax of the Event Layer The rest of this report is concerned solely with what is now being called the event layer of the DFA, for which previously two different multiple-domain models had been defined. One of these models, referred to as the basic syntax, just provided the operations of sequencing (denoted by ; used as an infix symbol) and alternation (denoted by as an infix symbol). The other model, referred to as the extended syntax, also included the parallel composition operator (denoted by as an infix symbol) and constrained parallel compositions (denoted by c as an infix symbol). The multiple-domain 2

3 approach had been adopted for both of these models because they were to be used as a basis for employing structural induction, both for defining new operations and for proving properties of these operations. In the course of comparing different possible approaches to the development of the models, it had been realised that an advantage of the multipledomain approach was that it reduced the number of levels of structuring that needed to be considered in any such induction, and hence the number of cases that needed to be considered. At the time this advantage had appeared to outweigh any that the single-domain approach might possess. A simple example of this advantage is the sequence s = a1 ; a2 ; a3, where a1, a2 and a3 are all actions. (Indeed, from now on the convention will be adopted for this report that, unless otherwise specified, variables whose names begin with a are assumed to be actions, and similarly that ones whose names begin with s are assumed to be arbitrary sequences.) In principle s can be viewed as having one of two constructions, which can be denoted as a1 ; (a2 ; a3) and (a1 ; a2) ; a3 respectively. As far as reasoning about the properties of s is concerned it does not matter which of these two constructions is adopted, since the associativity of ; ensures that the two are equal. A single-domain model would, however, require that both constructions had to be considered as separate cases, each involving two levels of operator application, which potentially could need to be considered together. By contrast, the multiple-domain models ensure that the first construction must be regarded as the definitive one, so that only this form of construction need be considered when using structural inductions. Also, in principle they would then treat the term (a2 ; a3) as a separate construction, so that its analysis would not necessarily need to be considered along with the analysis of with the whole structure. While the reviewers who were suggesting the need for a single-domain model accepted this argument, their view was that a consequence of it was that the multiple-domain models were actually defining an algebra of expressions over data flows, rather than the underlying algebra of the data flows themselves. The justification for this was that in principle the operations of the algebra were supposed to be applicable to any elements in the underlying algebra, rather than just to certain elements that were selected on the basis of belonging to particular sub-domains. Hence, to define the underlying algebra properly it was argued that a single-domain model was needed. This argument has been accepted, and the purpose of the rest of this report is to describe the development of such a model, and its relationship with the previous ones. 4. Overview of the Single Domain While this model is described as a single-domain one, it actually involves three separate levels of abstraction in the modelling, and each of these is represented in terms of at least one domain. Where this is more than one domain for a particular level, though, then the others are essentially subsets of the main one, and it is the property that there is just one main domain for each level of abstractions that justifies the description single-domain. The three levels of abstraction that are identified correspond respectively to the concepts of expressions, of constructions for sequences and of equivalence classes over these constructions, and informally they can be described as follows, along with the relationships between them. The first level of abstraction is that of expressions over sequences of actions, and this is treated as a domain which will be called SeqExp. This domain follows the usual pattern for expressions, in that it is constructed from operators and operands, where the operands may be either constants or variables that are drawn from the domains representing the other two layers of abstraction. The two primitive operators in this domain are those of sequencing and alternation, and expressions which only involve these two operators can be described as primitive expressions. For some purposes it may be convenient to regard them as forming a sub-domain of SeqExp, and this will be called PSeqExp. Other operators will be introduced as required, and defined by means of their signatures and axioms, which will be written in terms of equalities, with the usual interpretation of equality as substitutability. The second level of abstraction is that of constructions of sequences, and this is treated as a domain which will be called SeqConst. This domain represents the set of objects over which the algebra of sequences is defined, and then the operations of this algebra are again those of sequencing and alternation. Their primitive role is reflected in the construction of this domain, which starts from a set of constants corresponding to the actions, that are referred to as atomic objects, and which includes the two distinguished constants for the silent action (denoted ε) and the forbidden action (denoted φ). Then, a set of non-atomic objects are built up from this by application of these two operations. Thus, atomic objects might be denoted by a1 or a2, and then non-atomic objects by a1 ; a2 or a1 a2. The construction of any object in this domain is unique, in the sense that for instance a1 a2 has a different construction from a2 a1, and similarly a1 ; ε has a different construction from either a1 or ε ; a1. The third level of abstraction is that of equivalence classes over the constructions of sequences, as defined by the axioms of the algebra. It is therefore this level that represents the actual algebra of sequences with all its important properties, and so in some respects it is the most important domain, which is why it is simply called Seq. The way in which the equivalence classes are induced by the axioms then means that, for instance, one of these classes will contain (amongst 3

4 others) the following elements of SeqConst: (a), (a ; ε), (ε ; a), (a a), ((a ; φ) a), and (a (a ; φ)), all of which evaluate to a under the axioms. In defining these rigorously, the domain SeqExp can be taken as understood, and the only notation that needs to be defined is the use of the symbol Í to represent the relationship "is defined as" between a new operation (on the left hand side) and the expression which defines it (on the right hand side). This relationship then leads to one that will be termed reduction, which holds between elements of SeqExp and (under transitive closure) those of PSeqExp. Similarly, there is a relationship between PSeqExp and SeqConst that can be taken as understood, since it is the bijective relationship known as denotation, which means that an expression such as a1 ; a2 denotes exactly one element of SeqConst, namely the one constructed as a1 ; a2. The other relationships between the domains are those between SeqConst and Seq. There is a functional relationship from SeqConst to Seq, which will be called classification because it maps objects into the equivalence classes to which they belong. This relationship is surjective, since every element of SeqConst maps into an equivalence class in Seq, but it is not bijective, because some different elements of SeqConst (ie ones with different constructions) map into the same equivalence class. Consequently, in the opposite direction there are a number of relationships from Seq to SeqConst which can be called selection, in that they are given some criteria, and then map from an equivalence class back to some set of elements of SeqConst that are in this equivalence class and that satisfy the criteria. Typically these criteria will relate to the structure of the elements of SeqConst, and in some cases they will give rise to progressively smaller subdomains of SeqConst. Indeed, in some cases these criteria may even identify a unique element of the equivalence class; where they do not, then selection will imply a (possibly arbitrary) choice between equivalent elements, so that the effect is of a functional (ie injective) relationship. There are two other points to note about these relationships. One is that, to avoid cluttering the notation, all of them are treated as coercions, meaning that their applications are to be inferred as appropriate, depending on the particular domains that form the context in which the objects are being discussed. The second point is that these relationships can, of course, be composed, and in particular the composition of reduction (where necessary), denotation and classification produces a surjective function from SeqExp to Seq, and this will be called evaluation since it corresponds exactly to what is usually understood to be the process that takes place when an expression is evaluated. 5. Actions and Sequence Constructions Given this informal description of the three levels of abstraction and the relationships between them, the starting point for the rigorous definition of these domains (or at least of SeqConst and Seq) is that, for any system, the topological layer of a DFA specification defines two sets. One is the set of processes within the system, which will be denoted by PROC. The other is the set of unidirectional channels, which will be denoted by CHAN, where each channel represents a link in the routes along which data can flow between the processes. The elements of PROC are distinct, meaning that for any two arbitrary elements p1 and p2 PROC one can always determine whether they are the same (which is an equivalence relation, denoted p1 p2) or different (denoted p1 / p2). Similarly, the elements of CHAN are distinct, and the same equivalence relation is defined over them. Also, since processes and channels are separate concepts, the two sets PROC and CHAN are disjoint. From these two sets, the topological level of a DFA specification then constructs a set of possible actions, each of the form source! channel? destination, where source PROC, channel CHAN and destination PROC. This set of possible actions will be denoted PA, and for any action a in PA the three components are denoted as a.source, a.channel and a.destination respectively. The elements of PA will also be distinct, and whether any two arbitrary actions are the same or different is defined by the following pair of axioms. (i) (ii) a1, a2 PA, a1.source a2.source a1.channel a2.channel a1.destination a2.destination a1 a2 a1, a2 PA, a1.source / a2.source a1.channel / a2.channel a1.destination / a2.destination a1 / a2 It is obvious that these definitions ensure that the relation over PA is also symmetric, transitive and reflexive, and hence is an equivalence relation. From the possible actions PA a set Act of actions is then constructed, as ACT = PA {ε, φ}. The notion of actions being distinct caries over to ACT in the obvious fashion, with the addition of the following axioms, which explicitly state the symmetry to ensure that is also an equivalence relation over ACT. 4

5 (iii) (iv) (v) a PA, a / ε ε / a a PA, a / φ φ / a ε / φ φ / ε From the algebraic point of view these actions form the constants of the domain of sequence constructions, and so elements of Act are (as indicated above) also referred to as atomic sequences. Hence, it follows that Act SeqConst, and indeed the existence of non-atomic sequences means that Act SeqConst. These non-atomic sequences are the elements of SeqConst Act (where is used to denote the set difference operation), and they are the sequences that must be constructed by applying the two basic operators of the algebra (viz sequencing and alternation) recursively, starting with applications to the elements of Act, and then to the elements constructed in this way, and so on. This therefore gives the following axioms for the construction of SeqConst. (vi) (vii) (viii) (ix) a Act, a SeqConst s1, s2 SeqConst, s1 ; s2 SeqConst s1, s2 SeqConst, s1 s2 SeqConst There are no other elements of SeqConst This last axiom can be expressed more formally as follows. (x) (xi) (xii) s SeqConst, either a Act : a s (ie s is atomic), or (s is non-atomic), but not both, and if s is non-atomic then either s1, s2 SeqConst : s s1 ; s2, or s1, s2 SeqConst : s s1 s2 The notions of actions being distinct also extends to sequence constructions, so that any two arbitrary elements s1 and s2 of SeqConst either have the same construction (denoted s1 s2) or different constructions (denoted s1 / s2). This is defined formally by the following axioms, which reflect the "either or but not both" in axioms (x), (xi) and (xii). (xiii) s, s1, s2 SeqConst : s s1 ; s2, a Act, s / a a / s (xiv) s, s1, s2 SeqConst : s s1 s2, a Act, s / a a / s (xv) s, s1, s2, s3, s4 SeqConst, s s1 ; s2 s / s3 s4. (xvi) s, s1, s2, s3, s4 SeqConst, s s1 s2 s / s3 ; s4. (xvii) s1, s2, s3, s4 SeqConst, s1 s2 s3 s4 s1 ; s2 s3 ; s4 (xviii) s1, s2, s3, s4 SeqConst, s1 s2 s3 s4 s1 s2 s3 s4 (xix) s1, s2, s3, s4 SeqConst, s1 / s2 s3 / s4 s1 ; s2 / s3 ; s4 (xx) s1, s2, s3, s4 SeqConst, s1 / s2 s3 / s4 s1 s2 / s3 s4 6. Equality of Sequences The domain Seq is constructed from SeqConst by means of the equivalence relation that is denoted by the symbol =, where the cases that represent the distinctive algebraic properties of the sequences are defined by the following set of axioms. s, s1, s2, s3 SeqConst, (i) s1 ; (s2 ; s3) = (s1 ; s2) ; s3 (sequencing is associative), (ii) s ; ε = ε ; s = s (the silent action is the left and right identities for sequencing), (iii) s1 (s2 s3) = (s1 s2) s3 (alternation is associative), (iv) s1 s2 = s2 s1 (alternation is commutative), (v) s s = s (alternation is idempotent), (vi) s φ = φ s = s (the forbidden action is the left and right identities for alternation), (vii) s1 ; (s2 s3) = (s1 ; s2) (s1 ; s3) (sequencing distributes over alternation), (viii) (s1 s2) ; s3 = (s1 ; s3) (s2 ; s3) (on both sides), and (ix) φ ; s = φ, (the forbidden action is a left zero for sequencing). To guarantee that equality will actually be an equivalence relation it is then necessary to add some axioms that provide the base cases of its behaviour, and state formally the properties of symmetry and transitivity. (x) (xi) s1, s2 SeqConst : s1 s2 s1 = s2 s1, s2 SeqConst : s1 s2 s1 / s2 5

6 (xii) (xiii) s1, s2 SeqConst : s1 = s2 s2 = s1 s1, s2, s3 SeqConst : s1 = s2 s2 = s3 s1 = s3 Then, the property that equality is therefore an equivalence relation has two consequences. One of these consequences is that, for any two elements sa and sb of SeqConst such that sa = sb, their equality must result from the transitive closure of applications of axioms (i) to (ix). That is, either these two sequences are equal by a single application of one of the axioms (i) to (x) (which includes the possibility that they have the same construction), or there must exist a chain of n (ie one or more) intermediate sequences (ie elements of SeqConst) s 1 to s n, such that sa = s 1, s i-1 = s i for all 1 < i n, and s n = sb, such that at each step in the chain the equality is a consequence of a single application of one of the axioms (i) to (ix). The other consequence of equality being an equivalence relation is that the domain Seq can be defined formally as the quotient algebra obtained from SeqConst under the equality relation. Another way of looking at this is that the functional properties of selection and classification extend axioms (i) to (ix) to Seq under the normal interpretation of equality as substitutability, since two equivalence classes must be the same if elements of one can be substituted for elements of the other. For instance, the axiom s1 s2 = s2 s1, where s1, s2 Seq, can be understood as meaning that, for any s1c, s2c SeqConst such that s1 is the classification of s1c and s2 is the classification of s2c, the classification of (s1c s2c) is substitutable for (ie the same equivalence class as) the classification of (s2c s1c). The extensions of the other axioms can be interpreted similarly. Given these interpretations, a convention that will be used is that the particular domain which applies can be inferred from the symbols which are being used to denote the underlying equivalence relationship, since and / are only used between elements of SeqConst, while = and are used between objects which may be elements of Seq or SeqConst, but are being interpreted as elements of Seq. 7. Reductions of Sequence Constructions An important property of axioms (i) to (ix) in the previous section is that some of them can also be regarded as defining what are effectively reductions of non-atomic constructions. Specifically, axiom (ii) defines that any object constructed as s ; ε or as ε ; s can always be reduced to the object s, in the sense that they will both always be in the same equivalence class as s. Also, axiom (v) defines a similar reduction for any object constructed as s s, and axiom (ix) defines that any object constructed as φ ; s can always be reduced to the object φ. This makes it possible to define a subset of SeqConst that contains just the objects that have been so reduced, and this subset will be denoted by SeqConst1. It is defined formally in terms of two operations, one called IsReduced1 which determines whether or not an object is in this subset, and the other called Reduce1 which produces for any object a member of its equivalence class that is in this subset. The operation Reduce1 has signature SeqConst SeqConst, and is defined by the following axioms. (i) a Act, Reduce1 (a) Í a. (ii) s SeqConst: s s1 ; s2, Reduce1 (s) Í if s1 ε then Reduce1 (s2) elsif s2 ε then Reduce1 (s1) elsif s1 φ then φ else Reduce1 (s1) ; Reduce1 (s2) fi. (iii) s SeqConst: s s1 s2, Reduce1 (s) Í if s1 φ then Reduce1 (s2) elsif s2 φ then Reduce1 (s1) elsif s1 s2 then Reduce1 (s1) else Reduce1 (s1) Reduce1 (s2) fi. Similarly, the operation IsReduced1 has signature SeqConst Bool, and it is defined by the following axioms. (iv) (v) (vi) a Act, IsReduced1 (a) Í true. s SeqConst: s s1 ; s2, IsReduced1 (s) Í (s1 / ε) (s1 / φ) (s2 / ε) IsReduced1 (s1) IsReduced1 (s2). s SeqConst: s s1 s2, IsReduced1 (s) Í (s1 / φ) (s2 / φ) (s1 / s2) IsReduced1 (s1) IsReduced1 (s2). Then, the important property of these two operations, namely that every object in SeqConst can be mapped by the operation Reduce1 into one that is equivalent, and for which IsReduced1 is true, can be expressed in a theorem as given below. The proof of this theorem is by structural induction, but in order to do this it is necessary to establish that the inductions do actually terminate. To make this possible some measure is needed of the structural complexity of an object 6

7 in SeqConst, such that the recursive cases in the structural induction can be shown to involve component objects that have a strictly lower value of this measure than the object of which they are components. The simplest way of achieving this is for this measure to effectively count the number of actions appearing as components in the object, and so it is termed the structural complexity count, which is represented by an operation called SCC with signature SeqConst Nat, and defined by the following axioms. (vii) a Act, SCC (a) Í 1. (viii) s SeqConst: s s1 ; s2, SCC (s) Í SCC (s1) + SCC (s2). (ix) s SeqConst: s s1 s2, SCC (s) Í SCC (s1) + SCC (s2). A consequence of this definition is that, since the value of SCC for any object must be greater than zero, the required relationship must hold between the complexity count for an object and the complexity counts for its components, which can be expressed formally as follows. (x) (xi) s SeqConst: s s1 ; s2, (SCC (s1) < SCC (s)) (SCC (s2) < SCC (s)). s SeqConst: s s1 s2, (SCC (s1) < SCC (s)) (SCC (s2) < SCC (s)). Another consequence of this definition is that the value of SCC is consistent with the associative properties, so that (for instance): SCC( s1 ; (s2 ; s3) ) = SCC( (s1 ; s2) ; s3 ), and SCC( s1 (s2 s3) ) = SCC( (s1 s2) s3 ). The basic approach for proving a property by structural induction is therefore that the base cases will be those of actions, and the recursive cases will be those of alternation and sequencing. For the recursive cases the induction hypothesis will be stated in terms of the required property holding for all sequences having an SCC which is strictly less than that of the particular form of sequence being analysed, which is guaranteed to hold from (x) and (xi) above. Thus, the analysis of the recursive cases simply needs to show, from the induction hypothesis, that this property must also hold for the form of construction being analysed. Then, the final stage of the proof is to induct upwards over the possible values of SCC (ie over all possible sequence constructions). This approach can be used to state and prove the required properties for Reduce1 and IsReduced1 as follows. Theorem 1. s SeqConst, IsReduced1 (Reduce1 (s)) Reduce1 (s) = s As described above, the proof is by structural induction, over three main cases that correspond to the possible structures of the object s. The induction hypothesis is that, for any n> 1, the theorem holds s SeqConst : SCC (s) < n and the induction step is to show that it therefore holds s SeqConst : SCC (s) = n. Base case: an action, so that n = 1. a Act, Reduce1 (a) a Reduce1 (a) = a Reduce1 (a) Act IsReduced1 (Reduce1 (a)) from axiom (i) from axiom (x) in section 4, and from axiom (iv) Recursive case: an object constructed by sequencing, so that s s1 ; s2. This gives rise to a set of sub-cases, one for each of the if then alternatives in axiom (xiii), as follows. Sub-case: s1 ε Reduce1 (s) Reduce1 (s2) IsReduced1 (Reduce1 (s)) = IsReduced1 (Reduce1 (s2)) = true from induction hypothesis, and Reduce1 (s) Reduce1 (s2) = s2 from induction hypothesis = ε ; s2 from axiom (ii) of section 4 s A point to be noted about the reasoning used here is that the domain implicitly moves from SeqConst to Seq at the point where the operator = is used, and then it implicitly moves back again to SeqConst where the operator is used. This 7

8 kind of movement between the two domains is a necessary part of most proofs, and hence will not be commented on again. Sub-case: s2 ε Reduce1 (s) Reduce1 (s1) IsReduced1 (Reduce1 (s)) = IsReduced1 (Reduce1 (s1)) = true from induction hypothesis, and Reduce1 (s) Reduce1 (s1) = s1 from induction hypothesis = s1 ; ε from axiom (ii) of section 4 s Sub-case: s1 φ Reduce1 (s) φ IsReduced1 (Reduce1 (s)) = IsReduced1 (φ) = true from axiom (iv), and Reduce1 (s) φ = s from axiom (ix) of section 4 Sub-case: (s1 / ε) (s2 / ε) (s1 / φ) Reduce1 (s) Reduce1 (s1) ; Reduce1 (s2) IsReduced1 (Reduce1 (s)) = IsReduced1 (Reduce1 (s1)) IsReduced1 (Reduce1 (s2)) from axiom (v) = true from induction hypothesis, and Reduce1 (s) Reduce1 (s1) ; Reduce1 (s2) = s1 ; s2 from induction hypothesis, twice s This therefore completes the set of sub-cases for this case. Recursive case: an object constructed by alternation, so that s s1 s2. This similarly gives rise to a set of sub-cases, one for each of the if then alternatives in axiom (xiv), as follows. Sub-case: s1 φ Reduce1 (s) Reduce1 (s2) IsReduced1 (Reduce1 (s)) = IsReduced1 (Reduce1 (s2)) = true from induction hypothesis, and Reduce1 (s) Reduce1 (s2) = s2 from induction hypothesis = φ s2 from axiom (vi) of section 4 s Sub-case: s2 φ Reduce1 (s) Reduce1 (s1) IsReduced1 (Reduce1 (s)) = IsReduced1 (Reduce1 (s1)) = true from induction hypothesis, and Reduce1 (s) Reduce1 (s1) = s1 from induction hypothesis = s1 φ from axiom (vi) of section 4 s Sub-case: s1 s2 Reduce1 (s) Reduce1 (s1) IsReduced1 (Reduce1 (s)) = IsReduced1 (Reduce1 (s1)) = true from induction hypothesis, and Reduce1 (s) Reduce1 (s1) = s1 from induction hypothesis = s1 s2 axioms (x) and (v) of section 4 s 8

9 Sub-case: (s1 / φ) (s2 / φ) (s1 / s2) Reduce1 (s) Reduce1 (s1) Reduce1 (s2) IsReduced1 (Reduce1 (s)) = IsReduced1 (Reduce1 (s1)) IsReduced1 (Reduce1 (s2)) from axiom (vi) = true from induction hypothesis, and Reduce1 (s) Reduce1 (s1) Reduce1 (s2) = s1 s2 from induction hypothesis, twice s This therefore completes the set of sub-cases for this case, and hence completes all the cases required for the proof, and so the last stage is to define the actual induction. This starts from the base case, which is a single action, with SCC equal to one. The inductive step is then that, since the properties hold for all sequences with SCC < n, by the case analysis above they must also hold for all sequences with SCC = n, and so the result is proved for successive values of n from 2 upwards. This therefore establishes the theorem as a whole. On the basis of this result, the sub-domain SeqConst1 can then be defined formally, by the following axiom: (xii) SeqConst1 Í {s SeqConst : IsReduced1 (s)}. where a corollary of the theorem is that Reduce1 can be used to map any object in SeqConst into an equivalent (ie equal) object in SeqConst1. Thus, from now on a number of the results that are being established will be expressed in terms of SeqConst1 rather than SeqConst, because their proofs will rely at some points on the properties of the constructions that are captured in the definition of IsReduced1. 8. Formal Semantics The next step in making rigorous the definition of Seq is to examine the formal semantics of sequence constructions and sequences. In principle the formal semantics that had been given for the multiple-domain model should not have needed to be altered at all, since the set of axioms used to define these semantics covered precisely the cases required for the single-domain model too. In practice, though, it had been recognised that there was a need to prove formally that these semantics were consistent with the set of axioms at the beginning of section 6: that is, to prove the soundness of the axioms with respect to the semantics. In the course of attempting to do this a counter-example had been found, which indicated that a slight modification was required to these formal semantics. To explain this, the original definition will be repeated here, then the example described, and then the modification of the semantics defined. Then, the proofs of consistency between the semantics and these axioms can be given, which is done in the next section. The fundamental construction used in the semantics is that of strings of possible actions (ie excluding either ε or φ), which form a type that can be denoted PAString. This type is equipped with the usual operation of concatenation of two strings, which is denoted by a.b for any two strings a and b, and it is also equipped with the constant λ that represents the empty string, and so is a left and right identity for concatenation. The semantics are then defined in terms of sets of these strings, which form a type denoted P PAString, and this is equipped with an operation that is denoted by A B for any two sets A, B P PAString, and which is defined by the axiom (i) A B Í {a.b where a A, b B} Thus, the empty set of strings is the zero element for this operation, and the set {λ} is the left and right identity element for it, which for convenience will be denoted Λ. The semantics of any element of SeqConst are then defined as an ordered pair of these sets, the first element containing the valid strings (meaning those representing sequences of actions that terminate correctly), and the second set the invalid strings (meaning those representing sequences of actions that terminate in the forbidden action). These ordered pairs are defined in terms of an abstract type that was not originally given a name, but here will be called SeqSem. This type has one constructor operation and two observer operations, where for any valid and invalid sets v, i P PAString the constructor operation is denoted <v, i>, and for any sem SeqSem the observer operations are denoted valid(sem) and invalid(sem) respectively. The properties of these operations are then defined by the basic axiom (ii) sem SeqSem, <valid(sem), invalid(sem)> = sem 9

10 An invariant condition which was identified for the two sets v and i was that any given string could not be in both sets, since this would correspond to a system having reached a point where it had a choice between either performing the forbidden action φ, or continuing with some other actions. In such a situation, the property that φ is the identity for the alternation operator would imply that always the option of continuing with other actions would be taken, and so the string in question should not appear in the invalid set. Hence, the invariant for the semantics was stated as the requirement that the two sets v and i must be disjoint, which was expressed by the axiom (iii) sem SeqSem, valid(sem) invalid(sem) = Then, in principle the semantics of any expression were defined in terms of a semantic function Sem, but in practice the need to cater for two different properties of the forbidden action (one as denoting invalid termination, and the other its role as identity for the alternation operator) meant that two such functions needed to be introduced. One of these, denoted SemS, applies to sequencing and defines the deadlock properties for φ, while the other, denoted SemA, applies to alternation and defines the identity properties for φ. For this purpose all three of these operations can be regarded as defining the semantics of any element of SeqConst, and so will have signature SeqConst SeqSem. The definitions of them also need to introduce two auxiliary operations, called SemAlt and SemSeq, each with signature SeqSem SeqSem SeqSem, and the axioms defining them all are as follows. (iv) SemS (φ) Í Sem (φ) = <, Λ> (v) SemA (φ) Í <, > (vi) SemS (ε) Í SemA (ε) Í Sem (ε) Í <Λ, > (vii) SemS (a) Í SemA (a) Í Sem (a) Í <{a}, > (viii) SemS (s1 ; s2) Í SemA (s1 ; s2) Í Sem (s1 ; s2) Í SemSeq ( SemS (s1), SemS (s2) ) (ix) SemS (s1 s2) Í SemA (s1 s2) Í Sem (s1 s2) Í SemAlt ( SemA (s1), SemA (s2) ) (x) SemSeq (x, y) Í <v, i (v i)> where v Í valid (x) valid (y) and i Í invalid (x) ( valid (x) invalid (y) ) (xi) SemAlt (x, y) Í <v, i (v i)> where v Í valid (x) valid (y) and i Í invalid (x) invalid (y) Here, the significance of defining the invalid sets for both SemSeq and SemAlt as i (v i) was to ensure that the invariant valid(sem) invalid(sem) = would hold, but of course this expression could in each case have been written more simply as i v, using the general result that, for any sets A and B, A (B A) = A (A B) = A B. The counter-example that had then been found to these definitions (or, more precisely, to the desired property that they should be consistent with the axioms in section 6) was as follows. Example. Consider the following three elements of SeqConst: s1 ε (a ; φ) s2 a ; b and s s1 ; s2 which therefore gives s = (a ; b) (a ; φ ; a ; b) = (a ; b) (a ; φ) = a ; (b φ) = a ; b From the above definitions, it is easy to calculate that Sem (a ; φ) = <, {a}> from axioms (vii), (iv), (viii) and (x), and hence that Sem (s1) = <Λ, {a}> from axioms (ix) and (xi); similarly that Sem (s2) = <{a.b}, > from axioms (vii), (viii) and (x). For s, however, the calculation of the semantics can be done in two ways. One way is to calculate Sem (s) = SemSeq ( SemS (s1), SemS (s2) ) from axiom (viii) = SemSeq (<Λ, {a}>, <{a.b}, >) by substitution from above = <(Λ {a.b}), ( ( {a} (Λ )) (Λ {a.b} ) )> from axiom (x) = <{a.b}, ( ( {a} ) {a.b} )> from the properties of = <{a.b}, {a}> The other way of calculating the semantics is from s = a ; b, which (as for s2) gives directly Sem (s) = <{a.b}, > 10

11 Consequently, the two ways of calculating Sem (s) give different results, with the result obtained from using axioms (viii) and (x) being the incorrect one. What this example demonstrates is that, having calculated v and i as defined in axioms (x) or (xi) respectively, which in this case gives v = {a.b} and i = {a}, it is not sufficient simply to remove from i any strings that appear in v. Rather, it is also necessary to remove from i any string that appears as an initial substring of a string in v, so that in this case the fact that the string a.b in v starts with a is sufficient to require that the string a should be removed from i. The significance of this is that the invariant for the semantics that was given above in axiom (iii) needs to be strengthened, so that it does not merely require the two sets of strings to be disjoint, but also requires that no invalid string can appear as an initial substring of a valid one. Such initial substrings of a string are usually called its prefixes, and these can be defined for this purpose in three stages, as follows. Firstly, we introduce the infix operation IsPrefixOf, with signature PAString PAString Bool, defined as (xii) x IsPrefixOf y Í { z PAString : x.z = y} A corollary of this definition is that x IsPrefixOf x must be true, since λ is an element of PAString. The second stage is then to introduce the operation Prefixes, with signature PAString P PAString, defined by the axiom (xiii) Prefixes (x) Í {y : PAString : y IsPrefixOf x } Thirdly, this operation is generalised to the signature P PAString P PAString, by defining the axiom (xiv) Prefixes (x) Í UPr efixes(y) y x Given these, the stronger form of the invariant that needs to be maintained for the semantics can be stated as: (xv) sem SeqSem, Prefixes (valid(sem)) invalid(sem) = and this stronger form replaces axiom (iii) above. The revised definitions for SemAlt and SemSeq, which ensure that this stronger invariant is maintained, can then be stated as (xvi) (xvii) SemSeq (x, y) Í <v, i Prefixes (v)> where v Í valid (x) valid (y) and i Í invalid (x) ( valid (x) invalid (y) ) SemAlt (x, y) Í <v, i Prefixes (v)> where v Í valid (x) valid (y) and i Í invalid (x) invalid (y) and these revised definitions replace axioms (x) and (xi) above. The prefixes as defined here then have three important properties, which can be stated as theorems, as follows. Theorem 2. x, y P PAString, Prefixes (x) Prefixes (x y) p Prefixes (x), q P PAString : p.q x p.q x y p Prefixes (x y) Theorem 3. x, y P PAString, Prefixes (x) Prefixes (x y) p Prefixes (x), q x : p IsPrefixOf q r y : q.r x y p IsPrefixOf q.r p Prefixes (x y) 11

12 Theorem 4. x, y P PAString, x Prefixes (y) Prefixes (x y) p x Prefixes (y), q x, r Prefixes (y) : p = q.r s y : r IsPrefixOf s q.r IsPrefixOf q.s p IsPrefixOf q.s p Prefixes (x y) In addition to the property of the operator that is expressed in theorem 4, there are also important relationships between it and the set difference and set union operators, which can be expressed as follows. Theorem 5. x, y, z P PAString, (x (y z)) (x z) = (x y) (x z) (x (y z)) (x z) = { p.q : p x q y (q z) ( r.s : r x s z r.s = p.q) } from axiom (i) = { p.q : (p x q y) (p x q y q z) ( r.s : r x s z r.s = p.q) } expanding = { p.q : (p x q y) ( r.s : r x s z r.s = p.q) } eliminating, which for any p and q can be justified by setting r = p and s = q = (x y) (x z) from axiom (i) Theorem 6. x, y, z P PAString, (x y) (x z) = x (y z) p x y, q x, r y : p = q.r q x, r y z q.r x (y z) Similarly, p x z, q x, r z : p = q.r q x, r y z q.r x (y z) Hence, p (x y) (x z) p (x (y z)) and so (x y) (x z) x (y z) p x (y z), q x, r (y z) : p = q.r (q x, r y) (q x, r z) (p x y) (p x z) p (x y) (x z) Hence, p (x (y z)) p (x y) (x z) and so x (y z) (x y) (x z) Therefore, (x y) (x z) = x (y z) Theorem 7. x, y, z P PAString, (x y) z = (x z) (y z) The proof is symmetrical with the proof of theorem 6, and does not need to be given in detail. 12

13 There are also four basic results from set theory that provide useful properties of the set difference operator. They are stated here without proof, as though they were axioms: (xviii) x, y, z P PAString, (x y) z = (x z) (y z) (xix) x, y, z P PAString, ((x y) z) y = (x z) y (xx) x, y, z P PAString, y z x y = (x z) (y z) (xxi) x, y, z P PAString, y z (x y) z = (x z) y = x z 9. Soundness of the Axioms and Formal Semantics Given the revised definition of the formal semantics contained in axioms (iv) to (ix), (xvi) and (xvii) of the previous section, then the properties expressed in theorems 2 to 7 and axioms (xviii) to (xxi) of the previous section make it possible to prove the consistency of the semantics with axioms (i) to (ix) from section 6, thereby showing that these axioms are sound with respect to the semantics. This consistency is expressed in the set of theorems in this section, with one for each of the axioms. These theorems and proofs are presented in the same order as the axioms appear in section 6. In the notes on each proof step, references to axioms are to ones in the previous section. To make the presentation of these results more readable, the convention is adopted for the theorems in this section that elements of SeqConst are shown in bold face. Theorem 8. s1, s2, s3 SeqConst, Sem( s1 ; (s2 ; s3) ) = Sem( (s1 ; s2) ; s3 ) Let Sem( s1 ), Sem( s2 ) and Sem( s3 ) be denoted by <v1, i1>, <v2, i2> and <v3, i3> respectively. Then, Sem( s2 ; s3 ) = <(v2 v3), (i2 (v2 i3) Prefixes (v2 v3))> Sem( s1 ; (s2 ; s3) ) = <(v1 v2 v3), (i1 (v1 [(i2 (v2 i3) Prefixes (v2 v3))]) Prefixes (v1 v2 v3)> = <(v1 v2 v3), (i1 Prefixes (v1 v2 v3) ) [ v1 ((i2 (v2 i3) Prefixes (v2 v3)) v1 Prefixes (v2 v3)] [Prefixes (v1 v2 v3) v1 Prefixes (v2 v3)]> ax. (xviii), (xx), th. 4 = <(v1 v2 v3), (i1 Prefixes (v1 v2 v3) ) [(v1 (i2 (v2 i3)) v1 Prefixes (v2 v3)) [Prefixes (v1 v2 v3) v1 Prefixes (v2 v3)] ]> theorem 20 = <(v1 v2 v3), (i1 Prefixes (v1 v2 v3) ) [(v1 i2) (v1 v2 i3) (Prefixes (v1 v2 v3)]> axiom (xx), th. 4 = <(v1 v2 v3), (i1 (v1 i2) (v1 v2 i3) Prefixes (v1 v2 v3))> axiom (xviii) Sem( s1 ; s2 ) = <(v1 v2), (i1 (v1 i2) Prefixes (v1 v2))> Sem( (s1 ; s2) ; s3 ) = <(v1 v2 v3), ([i1 (v1 i2) Prefixes (v1 v2)] (v1 v2 i3) Prefixes (v1 v2 v3))> = <(v1 v2 v3), ([[i1 (v1 i2) Prefixes (v1 v2)] (v1 v2 i3) Prefixes (v1 v2)] [Prefixes (v1 v2 v3) Prefixes (v1 v2)])> axiom (xx), th. 3 = <(v1 v2 v3), ([i1 (v1 i2) (v1 v2 i3) Prefixes (v1 v2)] [Prefixes (v1 v2 v3) Prefixes (v1 v2)])> axiom (xix) = <(v1 v2 v3), (i1 (v1 i2) (v1 v2 i3) Prefixes (v1 v2 v3)) > axiom (xx) = Sem( s1 ; (s2 ; s3) ) 13

14 Theorem 9. s SeqConst, Sem( s ; ε ) = Sem( ε ; s ) = Sem( s ) Let Sem( s ) = <v, i> where i Prefixes (v) =. Then, Sem( s ; ε ) = <v Λ, i (v ) Prefixes (v Λ)> = <v, i Prefixes (v)> = <v, i Prefixes (v)> = <v, i> = Sem( s ) And Sem( ε ; s ) = <Λ v, (Λ i) Prefixes (Λ v)> = <v, i Prefixes (v)> = <v, i Prefixes (v)> = <v, i> = Sem( s ) Theorem 10. s1, s2, s3 SeqConst, Sem( s1 (s2 s3) ) = Sem( (s1 s2) s3 ) Let Sem( s1 ), Sem( s2 ) and Sem( s3 ) be denoted by <v1, i1>, <v2, i2> and <v3, i3> respectively. Then, Sem( s2 s3 ) = <(v2 v3), (i2 i3) Prefixes (v2 v3)> Sem( s1 (s2 s3) ) = <(v1 v2 v3), ((i1 [(i2 i3) Prefixes (v2 v3)]) Prefixes (v1 v2 v3))> = <(v1 v2 v3), ([i1 (i2 i3) Prefixes (v2 v3)) Prefixes (v2 v3)] [Prefixes (v1 v2 v3) Prefixes (v2 v3)])> axiom (xix), (xx), th. 2 = <(v1 v2 v3), ([i1 i2 i3 Prefixes (v2 v3)] [Prefixes (v1 v2 v3) Prefixes (v2 v3)])> axiom (xix) = <(v1 v2 v3), (i1 i2 i3 Prefixes (v1 v2 v3))> axiom (xx), th. 2 Sem( s1 s2 ) = <(v1 v2), (i1 i2) Prefixes (v1 v2)> Sem( (s1 s2) s3 ) = <(v1 v2 v3), ([i1 i2 Prefixes (v1 v2)] i3) Prefixes (v1 v2 v3)> = <(v1 v2 v3), ([([i1 i2 Prefixes (v1 v2)] i3) Prefixes (v1 v2)] [Prefixes (v1 v2 v3) Prefixes (v1 v2)])> axiom (xix), (xx), th. 2 = <(v1 v2 v3), ([i1 i2 i3 Prefixes (v1 v2)] [Prefixes (v1 v2 v3) Prefixes (v1 v2)])> axiom (xix) = <(v1 v2 v3), (i1 i2 i3 Prefixes (v1 v2 v3))> axiom (xx), th. 2 = Sem( s1 (s2 s3) ) Theorem 11. s1, s2 SeqConst, Sem( s1 s2 ) = Sem( s2 s1 ) Let Sem( s1 ) and Sem( s2 ) be denoted by <v1, i1> and <v2, i2> respectively. Then, Sem( s1 s2 ) = <(v1 v2), (i1 i2) Prefixes (v1 v2)> = <(v2 v1), (i2 i1) Prefixes (v2 v1)> = Sem( s2 s1 ) Theorem 12. s SeqConst, Sem( s s ) = Sem( s ) 14

15 Let Sem( s ) = <v, i> where i Prefixes (v) =. Then, Sem( s s ) = <(v v), (i i) Prefixes (v v)> = <v, i Prefixes (v)> = <v, i> = Sem( s ) Theorem 13. s SeqConst, Sem( s φ ) = Sem( φ s ) = Sem( s ) Let Sem( s ) = <v, i> where i Prefixes (v) =. Then, Sem( s φ ) = <v, i Prefixes (v )> = <v, i Prefixes (v)> = <v, i> = Sem( s ) And Sem( φ s ) = < v, i Prefixes ( v)> = <v, i Prefixes (v)> = <v, i> = Sem( s ) Theorem 14. s1, s2, s3 SeqConst, Sem( s1 ; (s2 s3) ) = Sem( (s1 ; s2) (s1 ; s3) ) Let Sem( s1 ), Sem( s2 ) and Sem( s3 ) be denoted by <v1, i1>, <v2, i2> and <v3, i3> respectively. Then, Sem( s2 s3 ) = <(v2 v3), (i2 i3) Prefixes (v2 v3)> Sem( s1 ; (s2 s3) ) = <(v1 (v2 v3)), (i1 (v1 [(i2 i3) Prefixes (v2 v3)]) Prefixes (v1 (v2 v3)))> = <(v1 (v2 v3)), (i1 Prefixes (v1 (v2 v3)) ) [v1 (i2 i3 Prefixes (v2 v3)) Prefixes (v1 (v2 v3))] axiom (xviii) = <(v1 (v2 v3)), (i1 Prefixes (v1 (v2 v3)) ) ([v1 (i2 i3 Prefixes (v2 v3)) (v1 Prefixes (v2 v3))] [Prefixes (v1 (v2 v3)) (v1 Prefixes (v2 v3))])> axiom (xx), th. 4 = <(v1 (v2 v3)), (i1 Prefixes (v1 (v2 v3)) ) ([(v1 (i2 i3)) v1 Prefixes (v2 v3)] [Prefixes (v1 (v2 v3)) (v1 Prefixes (v2 v3))])> theorem 5 = <(v1 (v2 v3)), (i1 Prefixes (v1 (v2 v3)) ) ((v1 (i2 i3)) Prefixes (v1 (v2 v3)))> axiom (xx), th. 4 = <(v1 (v2 v3)), (i1 (v1 (i2 i3)) Prefixes (v1 (v2 v3))> axiom (xviii) Sem(s1 ; s2) = <(v1 v2), (i1 (v1 i2) Prefixes (v1 v2))> Sem( s1 ; s3 ) = <(v1 v3), (i1 (v1 i3) Prefixes (v1 v3))> Sem( (s1 ; s2) (s1 ; s3) ) = <(v1 v2) (v1 v3), ([i1 (v1 i2) Prefixes (v1 v2)] [i1 (v1 i3) Prefixes (v1 v3)] Prefixes ((v1 v2) (v1 v3)) )> = <(v1 (v2 v3)), theorem 6 ([i1 (v1 i2) Prefixes (v1 v2) Prefixes ((v1 v2) (v1 v3))] [i1 (v1 i3) Prefixes (v1 v3) Prefixes ((v1 v2) (v1 v3))]> axiom (xviii) 15

This is already grossly inconvenient in present formalisms. Why do we want to make this convenient? GENERAL GOALS

This is already grossly inconvenient in present formalisms. Why do we want to make this convenient? GENERAL GOALS 1 THE FORMALIZATION OF MATHEMATICS by Harvey M. Friedman Ohio State University Department of Mathematics friedman@math.ohio-state.edu www.math.ohio-state.edu/~friedman/ May 21, 1997 Can mathematics be

More information

3.4 Deduction and Evaluation: Tools Conditional-Equational Logic

3.4 Deduction and Evaluation: Tools Conditional-Equational Logic 3.4 Deduction and Evaluation: Tools 3.4.1 Conditional-Equational Logic The general definition of a formal specification from above was based on the existence of a precisely defined semantics for the syntax

More information

Complexity Theory. Compiled By : Hari Prasad Pokhrel Page 1 of 20. ioenotes.edu.np

Complexity Theory. Compiled By : Hari Prasad Pokhrel Page 1 of 20. ioenotes.edu.np Chapter 1: Introduction Introduction Purpose of the Theory of Computation: Develop formal mathematical models of computation that reflect real-world computers. Nowadays, the Theory of Computation can be

More information

MA651 Topology. Lecture 4. Topological spaces 2

MA651 Topology. Lecture 4. Topological spaces 2 MA651 Topology. Lecture 4. Topological spaces 2 This text is based on the following books: Linear Algebra and Analysis by Marc Zamansky Topology by James Dugundgji Fundamental concepts of topology by Peter

More information

Semantics via Syntax. f (4) = if define f (x) =2 x + 55.

Semantics via Syntax. f (4) = if define f (x) =2 x + 55. 1 Semantics via Syntax The specification of a programming language starts with its syntax. As every programmer knows, the syntax of a language comes in the shape of a variant of a BNF (Backus-Naur Form)

More information

Lecture : Topological Space

Lecture : Topological Space Example of Lecture : Dr. Department of Mathematics Lovely Professional University Punjab, India October 18, 2014 Outline Example of 1 2 3 Example of 4 5 6 Example of I Topological spaces and continuous

More information

Propositional Logic. Part I

Propositional Logic. Part I Part I Propositional Logic 1 Classical Logic and the Material Conditional 1.1 Introduction 1.1.1 The first purpose of this chapter is to review classical propositional logic, including semantic tableaux.

More information

CS4215 Programming Language Implementation. Martin Henz

CS4215 Programming Language Implementation. Martin Henz CS4215 Programming Language Implementation Martin Henz Thursday 26 January, 2012 2 Chapter 4 The Language simpl In this chapter, we are exting the language epl in order to provide a more powerful programming

More information

STABILITY AND PARADOX IN ALGORITHMIC LOGIC

STABILITY AND PARADOX IN ALGORITHMIC LOGIC STABILITY AND PARADOX IN ALGORITHMIC LOGIC WAYNE AITKEN, JEFFREY A. BARRETT Abstract. Algorithmic logic is the logic of basic statements concerning algorithms and the algorithmic rules of deduction between

More information

Contents. Chapter 1 SPECIFYING SYNTAX 1

Contents. Chapter 1 SPECIFYING SYNTAX 1 Contents Chapter 1 SPECIFYING SYNTAX 1 1.1 GRAMMARS AND BNF 2 Context-Free Grammars 4 Context-Sensitive Grammars 8 Exercises 8 1.2 THE PROGRAMMING LANGUAGE WREN 10 Ambiguity 12 Context Constraints in Wren

More information

LOGIC AND DISCRETE MATHEMATICS

LOGIC AND DISCRETE MATHEMATICS LOGIC AND DISCRETE MATHEMATICS A Computer Science Perspective WINFRIED KARL GRASSMANN Department of Computer Science University of Saskatchewan JEAN-PAUL TREMBLAY Department of Computer Science University

More information

Programming Languages Third Edition

Programming Languages Third Edition Programming Languages Third Edition Chapter 12 Formal Semantics Objectives Become familiar with a sample small language for the purpose of semantic specification Understand operational semantics Understand

More information

RAQUEL s Relational Operators

RAQUEL s Relational Operators Contents RAQUEL s Relational Operators Introduction 2 General Principles 2 Operator Parameters 3 Ordinary & High-Level Operators 3 Operator Valency 4 Default Tuples 5 The Relational Algebra Operators in

More information

SOFTWARE ENGINEERING DESIGN I

SOFTWARE ENGINEERING DESIGN I 2 SOFTWARE ENGINEERING DESIGN I 3. Schemas and Theories The aim of this course is to learn how to write formal specifications of computer systems, using classical logic. The key descriptional technique

More information

RSL Reference Manual

RSL Reference Manual RSL Reference Manual Part No.: Date: April 6, 1990 Original Authors: Klaus Havelund, Anne Haxthausen Copyright c 1990 Computer Resources International A/S This document is issued on a restricted basis

More information

CSCI.6962/4962 Software Verification Fundamental Proof Methods in Computer Science (Arkoudas and Musser) Sections p.

CSCI.6962/4962 Software Verification Fundamental Proof Methods in Computer Science (Arkoudas and Musser) Sections p. CSCI.6962/4962 Software Verification Fundamental Proof Methods in Computer Science (Arkoudas and Musser) Sections 10.1-10.3 p. 1/106 CSCI.6962/4962 Software Verification Fundamental Proof Methods in Computer

More information

COMP-421 Compiler Design. Presented by Dr Ioanna Dionysiou

COMP-421 Compiler Design. Presented by Dr Ioanna Dionysiou COMP-421 Compiler Design Presented by Dr Ioanna Dionysiou Administrative! [ALSU03] Chapter 3 - Lexical Analysis Sections 3.1-3.4, 3.6-3.7! Reading for next time [ALSU03] Chapter 3 Copyright (c) 2010 Ioanna

More information

T. Background material: Topology

T. Background material: Topology MATH41071/MATH61071 Algebraic topology Autumn Semester 2017 2018 T. Background material: Topology For convenience this is an overview of basic topological ideas which will be used in the course. This material

More information

This book is licensed under a Creative Commons Attribution 3.0 License

This book is licensed under a Creative Commons Attribution 3.0 License 6. Syntax Learning objectives: syntax and semantics syntax diagrams and EBNF describe context-free grammars terminal and nonterminal symbols productions definition of EBNF by itself parse tree grammars

More information

Computing Fundamentals 2 Introduction to CafeOBJ

Computing Fundamentals 2 Introduction to CafeOBJ Computing Fundamentals 2 Introduction to CafeOBJ Lecturer: Patrick Browne Lecture Room: K408 Lab Room: A308 Based on work by: Nakamura Masaki, João Pascoal Faria, Prof. Heinrich Hußmann. See notes on slides

More information

THREE LECTURES ON BASIC TOPOLOGY. 1. Basic notions.

THREE LECTURES ON BASIC TOPOLOGY. 1. Basic notions. THREE LECTURES ON BASIC TOPOLOGY PHILIP FOTH 1. Basic notions. Let X be a set. To make a topological space out of X, one must specify a collection T of subsets of X, which are said to be open subsets of

More information

Appendix 1. Description Logic Terminology

Appendix 1. Description Logic Terminology Appendix 1 Description Logic Terminology Franz Baader Abstract The purpose of this appendix is to introduce (in a compact manner) the syntax and semantics of the most prominent DLs occurring in this handbook.

More information

Appendix 1. Description Logic Terminology

Appendix 1. Description Logic Terminology Appendix 1 Description Logic Terminology Franz Baader Abstract The purpose of this appendix is to introduce (in a compact manner) the syntax and semantics of the most prominent DLs occurring in this handbook.

More information

AXIOMS FOR THE INTEGERS

AXIOMS FOR THE INTEGERS AXIOMS FOR THE INTEGERS BRIAN OSSERMAN We describe the set of axioms for the integers which we will use in the class. The axioms are almost the same as what is presented in Appendix A of the textbook,

More information

3.1 Constructions with sets

3.1 Constructions with sets 3 Interlude on sets Sets and functions are ubiquitous in mathematics. You might have the impression that they are most strongly connected with the pure end of the subject, but this is an illusion: think

More information

CHAPTER 1 BOOLEAN ALGEBRA CONTENTS

CHAPTER 1 BOOLEAN ALGEBRA CONTENTS pplied R&M Manual for Defence Systems Part D - Supporting Theory HPTER 1 OOLEN LGER ONTENTS Page 1 INTRODUTION 2 2 NOTTION 2 3 XIOMS ND THEOREMS 3 4 SET THEORY 5 5 PPLITION 6 Issue 1 Page 1 hapter 1 oolean

More information

9.5 Equivalence Relations

9.5 Equivalence Relations 9.5 Equivalence Relations You know from your early study of fractions that each fraction has many equivalent forms. For example, 2, 2 4, 3 6, 2, 3 6, 5 30,... are all different ways to represent the same

More information

However, this is not always true! For example, this fails if both A and B are closed and unbounded (find an example).

However, this is not always true! For example, this fails if both A and B are closed and unbounded (find an example). 98 CHAPTER 3. PROPERTIES OF CONVEX SETS: A GLIMPSE 3.2 Separation Theorems It seems intuitively rather obvious that if A and B are two nonempty disjoint convex sets in A 2, then there is a line, H, separating

More information

4.5 Pure Linear Functional Programming

4.5 Pure Linear Functional Programming 4.5 Pure Linear Functional Programming 99 4.5 Pure Linear Functional Programming The linear λ-calculus developed in the preceding sections can serve as the basis for a programming language. The step from

More information

Basic Elements of Computer Algebra in MIZAR

Basic Elements of Computer Algebra in MIZAR Basic Elements of Computer Algebra in MIZAR Adam Naumowicz Czeslaw Bylinski Institute of Computer Science University of Bialystok, Poland adamn@math.uwb.edu.pl Section of Computer Networks University of

More information

Module 3. Requirements Analysis and Specification. Version 2 CSE IIT, Kharagpur

Module 3. Requirements Analysis and Specification. Version 2 CSE IIT, Kharagpur Module 3 Requirements Analysis and Specification Lesson 6 Formal Requirements Specification Specific Instructional Objectives At the end of this lesson the student will be able to: Explain what a formal

More information

Constrained Types and their Expressiveness

Constrained Types and their Expressiveness Constrained Types and their Expressiveness JENS PALSBERG Massachusetts Institute of Technology and SCOTT SMITH Johns Hopkins University A constrained type consists of both a standard type and a constraint

More information

INTRODUCTION TO THE HOMOLOGY GROUPS OF COMPLEXES

INTRODUCTION TO THE HOMOLOGY GROUPS OF COMPLEXES INTRODUCTION TO THE HOMOLOGY GROUPS OF COMPLEXES RACHEL CARANDANG Abstract. This paper provides an overview of the homology groups of a 2- dimensional complex. It then demonstrates a proof of the Invariance

More information

Formal semantics of loosely typed languages. Joep Verkoelen Vincent Driessen

Formal semantics of loosely typed languages. Joep Verkoelen Vincent Driessen Formal semantics of loosely typed languages Joep Verkoelen Vincent Driessen June, 2004 ii Contents 1 Introduction 3 2 Syntax 5 2.1 Formalities.............................. 5 2.2 Example language LooselyWhile.................

More information

Foundations of AI. 9. Predicate Logic. Syntax and Semantics, Normal Forms, Herbrand Expansion, Resolution

Foundations of AI. 9. Predicate Logic. Syntax and Semantics, Normal Forms, Herbrand Expansion, Resolution Foundations of AI 9. Predicate Logic Syntax and Semantics, Normal Forms, Herbrand Expansion, Resolution Wolfram Burgard, Andreas Karwath, Bernhard Nebel, and Martin Riedmiller 09/1 Contents Motivation

More information

Notes on Principia Mathematica

Notes on Principia Mathematica Notes on Principia Mathematica M. Randall Holmes November 5, 2014 These are my notes toward an interpretation of the Principia Mathematica of Russell and Whitehead (hereinafter PM ). Manners forbid saying

More information

CSC 501 Semantics of Programming Languages

CSC 501 Semantics of Programming Languages CSC 501 Semantics of Programming Languages Subtitle: An Introduction to Formal Methods. Instructor: Dr. Lutz Hamel Email: hamel@cs.uri.edu Office: Tyler, Rm 251 Books There are no required books in this

More information

An Evolution of Mathematical Tools

An Evolution of Mathematical Tools An Evolution of Mathematical Tools From Conceptualization to Formalization Here's what we do when we build a formal model (or do a computation): 0. Identify a collection of objects/events in the real world.

More information

Supplementary Notes on Abstract Syntax

Supplementary Notes on Abstract Syntax Supplementary Notes on Abstract Syntax 15-312: Foundations of Programming Languages Frank Pfenning Lecture 3 September 3, 2002 Grammars, as we have discussed them so far, define a formal language as a

More information

6.001 Notes: Section 8.1

6.001 Notes: Section 8.1 6.001 Notes: Section 8.1 Slide 8.1.1 In this lecture we are going to introduce a new data type, specifically to deal with symbols. This may sound a bit odd, but if you step back, you may realize that everything

More information

Lecture 22 Tuesday, April 10

Lecture 22 Tuesday, April 10 CIS 160 - Spring 2018 (instructor Val Tannen) Lecture 22 Tuesday, April 10 GRAPH THEORY Directed Graphs Directed graphs (a.k.a. digraphs) are an important mathematical modeling tool in Computer Science,

More information

Handout 9: Imperative Programs and State

Handout 9: Imperative Programs and State 06-02552 Princ. of Progr. Languages (and Extended ) The University of Birmingham Spring Semester 2016-17 School of Computer Science c Uday Reddy2016-17 Handout 9: Imperative Programs and State Imperative

More information

Mathematically Rigorous Software Design Review of mathematical prerequisites

Mathematically Rigorous Software Design Review of mathematical prerequisites Mathematically Rigorous Software Design 2002 September 27 Part 1: Boolean algebra 1. Define the Boolean functions and, or, not, implication ( ), equivalence ( ) and equals (=) by truth tables. 2. In an

More information

COMP 181. Agenda. Midterm topics. Today: type checking. Purpose of types. Type errors. Type checking

COMP 181. Agenda. Midterm topics. Today: type checking. Purpose of types. Type errors. Type checking Agenda COMP 181 Type checking October 21, 2009 Next week OOPSLA: Object-oriented Programming Systems Languages and Applications One of the top PL conferences Monday (Oct 26 th ) In-class midterm Review

More information

About the Authors... iii Introduction... xvii. Chapter 1: System Software... 1

About the Authors... iii Introduction... xvii. Chapter 1: System Software... 1 Table of Contents About the Authors... iii Introduction... xvii Chapter 1: System Software... 1 1.1 Concept of System Software... 2 Types of Software Programs... 2 Software Programs and the Computing Machine...

More information

axiomatic semantics involving logical rules for deriving relations between preconditions and postconditions.

axiomatic semantics involving logical rules for deriving relations between preconditions and postconditions. CS 6110 S18 Lecture 18 Denotational Semantics 1 What is Denotational Semantics? So far we have looked at operational semantics involving rules for state transitions, definitional semantics involving translations

More information

Summary of Contents LIST OF FIGURES LIST OF TABLES

Summary of Contents LIST OF FIGURES LIST OF TABLES Summary of Contents LIST OF FIGURES LIST OF TABLES PREFACE xvii xix xxi PART 1 BACKGROUND Chapter 1. Introduction 3 Chapter 2. Standards-Makers 21 Chapter 3. Principles of the S2ESC Collection 45 Chapter

More information

A GRAPH FROM THE VIEWPOINT OF ALGEBRAIC TOPOLOGY

A GRAPH FROM THE VIEWPOINT OF ALGEBRAIC TOPOLOGY A GRAPH FROM THE VIEWPOINT OF ALGEBRAIC TOPOLOGY KARL L. STRATOS Abstract. The conventional method of describing a graph as a pair (V, E), where V and E repectively denote the sets of vertices and edges,

More information

3.7 Denotational Semantics

3.7 Denotational Semantics 3.7 Denotational Semantics Denotational semantics, also known as fixed-point semantics, associates to each programming language construct a well-defined and rigorously understood mathematical object. These

More information

Chapter 3. Set Theory. 3.1 What is a Set?

Chapter 3. Set Theory. 3.1 What is a Set? Chapter 3 Set Theory 3.1 What is a Set? A set is a well-defined collection of objects called elements or members of the set. Here, well-defined means accurately and unambiguously stated or described. Any

More information

A Typed Lambda Calculus for Input Sanitation

A Typed Lambda Calculus for Input Sanitation A Typed Lambda Calculus for Input Sanitation Nathan Fulton Carthage College nfulton@carthage.edu April 11, 2013 Abstract Programmers often wish to validate or sanitize user input. One common approach to

More information

1.3. Conditional expressions To express case distinctions like

1.3. Conditional expressions To express case distinctions like Introduction Much of the theory developed in the underlying course Logic II can be implemented in a proof assistant. In the present setting this is interesting, since we can then machine extract from a

More information

FOUR EDGE-INDEPENDENT SPANNING TREES 1

FOUR EDGE-INDEPENDENT SPANNING TREES 1 FOUR EDGE-INDEPENDENT SPANNING TREES 1 Alexander Hoyer and Robin Thomas School of Mathematics Georgia Institute of Technology Atlanta, Georgia 30332-0160, USA ABSTRACT We prove an ear-decomposition theorem

More information

The Geodesic Integral on Medial Graphs

The Geodesic Integral on Medial Graphs The Geodesic Integral on Medial Graphs Kolya Malkin August 013 We define the geodesic integral defined on paths in the duals of medial graphs on surfaces and use it to study lens elimination and connection

More information

Chapter 2 Overview of the Design Methodology

Chapter 2 Overview of the Design Methodology Chapter 2 Overview of the Design Methodology This chapter presents an overview of the design methodology which is developed in this thesis, by identifying global abstraction levels at which a distributed

More information

Semantics of programming languages

Semantics of programming languages Semantics of programming languages Informatics 2A: Lecture 27 John Longley School of Informatics University of Edinburgh jrl@inf.ed.ac.uk 21 November, 2011 1 / 19 1 2 3 4 2 / 19 Semantics for programming

More information

EXTREME POINTS AND AFFINE EQUIVALENCE

EXTREME POINTS AND AFFINE EQUIVALENCE EXTREME POINTS AND AFFINE EQUIVALENCE The purpose of this note is to use the notions of extreme points and affine transformations which are studied in the file affine-convex.pdf to prove that certain standard

More information

Point-Set Topology 1. TOPOLOGICAL SPACES AND CONTINUOUS FUNCTIONS

Point-Set Topology 1. TOPOLOGICAL SPACES AND CONTINUOUS FUNCTIONS Point-Set Topology 1. TOPOLOGICAL SPACES AND CONTINUOUS FUNCTIONS Definition 1.1. Let X be a set and T a subset of the power set P(X) of X. Then T is a topology on X if and only if all of the following

More information

Matching Theory. Figure 1: Is this graph bipartite?

Matching Theory. Figure 1: Is this graph bipartite? Matching Theory 1 Introduction A matching M of a graph is a subset of E such that no two edges in M share a vertex; edges which have this property are called independent edges. A matching M is said to

More information

Topic 1: What is HoTT and why?

Topic 1: What is HoTT and why? Topic 1: What is HoTT and why? May 5, 2014 Introduction Homotopy type theory (HoTT) is a newly emerging field of mathematics which is currently being developed as a foundation of mathematics which is in

More information

arxiv:submit/ [math.co] 9 May 2011

arxiv:submit/ [math.co] 9 May 2011 arxiv:submit/0243374 [math.co] 9 May 2011 Connectivity and tree structure in finite graphs J. Carmesin R. Diestel F. Hundertmark M. Stein 6 May, 2011 Abstract We prove that, for every integer k 0, every

More information

Preface... (vii) CHAPTER 1 INTRODUCTION TO COMPUTERS

Preface... (vii) CHAPTER 1 INTRODUCTION TO COMPUTERS Contents Preface... (vii) CHAPTER 1 INTRODUCTION TO COMPUTERS 1.1. INTRODUCTION TO COMPUTERS... 1 1.2. HISTORY OF C & C++... 3 1.3. DESIGN, DEVELOPMENT AND EXECUTION OF A PROGRAM... 3 1.4 TESTING OF PROGRAMS...

More information

Lecture IV - Further preliminaries from general topology:

Lecture IV - Further preliminaries from general topology: Lecture IV - Further preliminaries from general topology: We now begin with some preliminaries from general topology that is usually not covered or else is often perfunctorily treated in elementary courses

More information

Consider a description of arithmetic. It includes two equations that define the structural types of digit and operator:

Consider a description of arithmetic. It includes two equations that define the structural types of digit and operator: Syntax A programming language consists of syntax, semantics, and pragmatics. We formalize syntax first, because only syntactically correct programs have semantics. A syntax definition of a language lists

More information

CHAPTER 8. Copyright Cengage Learning. All rights reserved.

CHAPTER 8. Copyright Cengage Learning. All rights reserved. CHAPTER 8 RELATIONS Copyright Cengage Learning. All rights reserved. SECTION 8.3 Equivalence Relations Copyright Cengage Learning. All rights reserved. The Relation Induced by a Partition 3 The Relation

More information

Slides for Faculty Oxford University Press All rights reserved.

Slides for Faculty Oxford University Press All rights reserved. Oxford University Press 2013 Slides for Faculty Assistance Preliminaries Author: Vivek Kulkarni vivek_kulkarni@yahoo.com Outline Following topics are covered in the slides: Basic concepts, namely, symbols,

More information

Chapter 2 The Language PCF

Chapter 2 The Language PCF Chapter 2 The Language PCF We will illustrate the various styles of semantics of programming languages with an example: the language PCF Programming language for computable functions, also called Mini-ML.

More information

Chapter 3. Describing Syntax and Semantics

Chapter 3. Describing Syntax and Semantics Chapter 3 Describing Syntax and Semantics Chapter 3 Topics Introduction The General Problem of Describing Syntax Formal Methods of Describing Syntax Attribute Grammars Describing the Meanings of Programs:

More information

Relational Data Model

Relational Data Model Relational Data Model 1. Relational data model Information models try to put the real-world information complexity in a framework that can be easily understood. Data models must capture data structure

More information

Z Notation. June 21, 2018

Z Notation. June 21, 2018 Z Notation June 21, 2018 1 Definitions There are many different ways to introduce an object in a Z specification: declarations, abbreviations, axiomatic definitions, and free types. Keep in mind that the

More information

Chapter 3. The While programming language

Chapter 3. The While programming language Chapter 3 The While programming language 1 Contents 3 The While programming language 1 3.1 Big-step semantics........................... 2 3.2 Small-step semantics.......................... 9 3.3 Properties................................

More information

AN ALGORITHM WHICH GENERATES THE HAMILTONIAN CIRCUITS OF A CUBIC PLANAR MAP

AN ALGORITHM WHICH GENERATES THE HAMILTONIAN CIRCUITS OF A CUBIC PLANAR MAP AN ALGORITHM WHICH GENERATES THE HAMILTONIAN CIRCUITS OF A CUBIC PLANAR MAP W. L. PRICE ABSTRACT The paper describes an algorithm which generates those Hamiltonian circuits of a given cubic planar map

More information

1. M,M sequential composition: try tactic M; if it succeeds try tactic M. sequential composition (, )

1. M,M sequential composition: try tactic M; if it succeeds try tactic M. sequential composition (, ) Dipl.-Inf. Achim D. Brucker Dr. Burkhart Wolff Computer-supported Modeling and Reasoning http://www.infsec.ethz.ch/ education/permanent/csmr/ (rev. 16802) Submission date: FOL with Equality: Equational

More information

CS422 - Programming Language Design

CS422 - Programming Language Design 1 CS422 - Programming Language Design Denotational Semantics Grigore Roşu Department of Computer Science University of Illinois at Urbana-Champaign 2 Denotational semantics, alsoknownasfix-point semantics,

More information

Discharging and reducible configurations

Discharging and reducible configurations Discharging and reducible configurations Zdeněk Dvořák March 24, 2018 Suppose we want to show that graphs from some hereditary class G are k- colorable. Clearly, we can restrict our attention to graphs

More information

Fundamental Concepts. Chapter 1

Fundamental Concepts. Chapter 1 Chapter 1 Fundamental Concepts This book is about the mathematical foundations of programming, with a special attention on computing with infinite objects. How can mathematics help in programming? There

More information

Principles of Programming Languages

Principles of Programming Languages Principles of Programming Languages Lesson 14 Type Checking Collaboration and Management Dana Fisman www.cs.bgu.ac.il/~ppl172 1 Type Checking We return to the issue of type safety we discussed informally,

More information

Advanced Algorithms Class Notes for Monday, October 23, 2012 Min Ye, Mingfu Shao, and Bernard Moret

Advanced Algorithms Class Notes for Monday, October 23, 2012 Min Ye, Mingfu Shao, and Bernard Moret Advanced Algorithms Class Notes for Monday, October 23, 2012 Min Ye, Mingfu Shao, and Bernard Moret Greedy Algorithms (continued) The best known application where the greedy algorithm is optimal is surely

More information

An Annotated Language

An Annotated Language Hoare Logic An Annotated Language State and Semantics Expressions are interpreted as functions from states to the corresponding domain of interpretation Operators have the obvious interpretation Free of

More information

4. Simplicial Complexes and Simplicial Homology

4. Simplicial Complexes and Simplicial Homology MATH41071/MATH61071 Algebraic topology Autumn Semester 2017 2018 4. Simplicial Complexes and Simplicial Homology Geometric simplicial complexes 4.1 Definition. A finite subset { v 0, v 1,..., v r } R n

More information

To prove something about all Boolean expressions, we will need the following induction principle: Axiom 7.1 (Induction over Boolean expressions):

To prove something about all Boolean expressions, we will need the following induction principle: Axiom 7.1 (Induction over Boolean expressions): CS 70 Discrete Mathematics for CS Fall 2003 Wagner Lecture 7 This lecture returns to the topic of propositional logic. Whereas in Lecture 1 we studied this topic as a way of understanding proper reasoning

More information

The Encoding Complexity of Network Coding

The Encoding Complexity of Network Coding The Encoding Complexity of Network Coding Michael Langberg Alexander Sprintson Jehoshua Bruck California Institute of Technology Email: mikel,spalex,bruck @caltech.edu Abstract In the multicast network

More information

Introduction to Lexical Analysis

Introduction to Lexical Analysis Introduction to Lexical Analysis Outline Informal sketch of lexical analysis Identifies tokens in input string Issues in lexical analysis Lookahead Ambiguities Specifying lexical analyzers (lexers) Regular

More information

Mathematics Shape and Space: Polygon Angles

Mathematics Shape and Space: Polygon Angles a place of mind F A C U L T Y O F E D U C A T I O N Department of Curriculum and Pedagogy Mathematics Shape and Space: Polygon Angles Science and Mathematics Education Research Group Supported by UBC Teaching

More information

The generalized Schoenflies theorem

The generalized Schoenflies theorem The generalized Schoenflies theorem Andrew Putman Abstract The generalized Schoenflies theorem asserts that if ϕ S n 1 S n is a topological embedding and A is the closure of a component of S n ϕ(s n 1

More information

A MODEL CATEGORY STRUCTURE ON THE CATEGORY OF SIMPLICIAL CATEGORIES

A MODEL CATEGORY STRUCTURE ON THE CATEGORY OF SIMPLICIAL CATEGORIES A MODEL CATEGORY STRUCTURE ON THE CATEGORY OF SIMPLICIAL CATEGORIES JULIA E. BERGNER Abstract. In this paper we put a cofibrantly generated model category structure on the category of small simplicial

More information

Last class. CS Principles of Programming Languages. Introduction. Outline

Last class. CS Principles of Programming Languages. Introduction. Outline Last class CS6848 - Principles of Programming Languages Principles of Programming Languages V. Krishna Nandivada IIT Madras Interpreters A Environment B Cells C Closures D Recursive environments E Interpreting

More information

CSCI.6962/4962 Software Verification Fundamental Proof Methods in Computer Science (Arkoudas and Musser) Chapter p. 1/27

CSCI.6962/4962 Software Verification Fundamental Proof Methods in Computer Science (Arkoudas and Musser) Chapter p. 1/27 CSCI.6962/4962 Software Verification Fundamental Proof Methods in Computer Science (Arkoudas and Musser) Chapter 2.1-2.7 p. 1/27 CSCI.6962/4962 Software Verification Fundamental Proof Methods in Computer

More information

One of the most important areas where quantifier logic is used is formal specification of computer programs.

One of the most important areas where quantifier logic is used is formal specification of computer programs. Section 5.2 Formal specification of computer programs One of the most important areas where quantifier logic is used is formal specification of computer programs. Specification takes place on several levels

More information

1 Introduction. 3 Syntax

1 Introduction. 3 Syntax CS 6110 S18 Lecture 19 Typed λ-calculus 1 Introduction Type checking is a lightweight technique for proving simple properties of programs. Unlike theorem-proving techniques based on axiomatic semantics,

More information

ROUGH MEMBERSHIP FUNCTIONS: A TOOL FOR REASONING WITH UNCERTAINTY

ROUGH MEMBERSHIP FUNCTIONS: A TOOL FOR REASONING WITH UNCERTAINTY ALGEBRAIC METHODS IN LOGIC AND IN COMPUTER SCIENCE BANACH CENTER PUBLICATIONS, VOLUME 28 INSTITUTE OF MATHEMATICS POLISH ACADEMY OF SCIENCES WARSZAWA 1993 ROUGH MEMBERSHIP FUNCTIONS: A TOOL FOR REASONING

More information

(Refer Slide Time: 4:00)

(Refer Slide Time: 4:00) Principles of Programming Languages Dr. S. Arun Kumar Department of Computer Science & Engineering Indian Institute of Technology, Delhi Lecture - 38 Meanings Let us look at abstracts namely functional

More information

From Types to Sets in Isabelle/HOL

From Types to Sets in Isabelle/HOL From Types to Sets in Isabelle/HOL Extented Abstract Ondřej Kunčar 1 and Andrei Popescu 1,2 1 Fakultät für Informatik, Technische Universität München, Germany 2 Institute of Mathematics Simion Stoilow

More information

Basics of Graph Theory

Basics of Graph Theory Basics of Graph Theory 1 Basic notions A simple graph G = (V, E) consists of V, a nonempty set of vertices, and E, a set of unordered pairs of distinct elements of V called edges. Simple graphs have their

More information

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

Higher-Order Logic. Specification and Verification with Higher-Order Logic Higher-Order Logic Specification and Verification with Higher-Order Logic Arnd Poetzsch-Heffter (Slides by Jens Brandt) Software Technology Group Fachbereich Informatik Technische Universität Kaiserslautern

More information

Algebra of Sets. Aditya Ghosh. April 6, 2018 It is recommended that while reading it, sit with a pen and a paper.

Algebra of Sets. Aditya Ghosh. April 6, 2018 It is recommended that while reading it, sit with a pen and a paper. Algebra of Sets Aditya Ghosh April 6, 2018 It is recommended that while reading it, sit with a pen and a paper. 1 The Basics This article is only about the algebra of sets, and does not deal with the foundations

More information

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

AXIOMS OF AN IMPERATIVE LANGUAGE PARTIAL CORRECTNESS WEAK AND STRONG CONDITIONS. THE AXIOM FOR nop AXIOMS OF AN IMPERATIVE LANGUAGE We will use the same language, with the same abstract syntax that we used for operational semantics. However, we will only be concerned with the commands, since the language

More information

Notes on metric spaces and topology. Math 309: Topics in geometry. Dale Rolfsen. University of British Columbia

Notes on metric spaces and topology. Math 309: Topics in geometry. Dale Rolfsen. University of British Columbia Notes on metric spaces and topology Math 309: Topics in geometry Dale Rolfsen University of British Columbia Let X be a set; we ll generally refer to its elements as points. A distance function, or metric

More information

The Graphs of Triangulations of Polygons

The Graphs of Triangulations of Polygons The Graphs of Triangulations of Polygons Matthew O Meara Research Experience for Undergraduates Summer 006 Basic Considerations Let Γ(n) be the graph with vertices being the labeled planar triangulation

More information

CS 6110 S14 Lecture 38 Abstract Interpretation 30 April 2014

CS 6110 S14 Lecture 38 Abstract Interpretation 30 April 2014 CS 6110 S14 Lecture 38 Abstract Interpretation 30 April 2014 1 Introduction to Abstract Interpretation At this point in the course, we have looked at several aspects of programming languages: operational

More information