Skip to main content Accessibility help

We use cookies to distinguish you from other users and to provide you with a better experience on our websites. Close this message to accept cookies or find out how to manage your cookie settings.

Close cookie message
×
  1. Home
  2. Browse subjects
  3. Computer Science
  4. Programming Languages and Applied Logic
  5. Content listing

Refine search

Refine search

Access:
Content type:
Publication date:
Apply   From and To filters
Subject: Show more
Journals Show more
Publishers: Show more
Societies Show more
Series: Show more
Collections: Show more

Actions for selected content:

Select all | Deselect all
  • View selected items
  • Export citations
  • Download PDF (zip)
  • Save to Kindle
  • Save to Dropbox
  • Save to Google Drive

Save Search

You can save your searches here and later view and run them again in "My saved searches".

Please provide a title, maximum of 40 characters.
Cancel
×

5570 results in Programming Languages and Applied Logic

Page 69 of 279

  • 9 - Structures and Unions

  • from PART-I - Structured Programming
  • Kunal Pimparkhede
  • Book:
    Computer Programming with C++
    Published online:
    28 May 2018
    Print publication:
    18 October 2016, pp 445-496

  • Summary

    Overview

    Structure is a template used to create a user-defined data type. This means that, as we create the variables of built-in data types, such as int, float, and double, we can now, also create the variables of user-defined data types, provided that the template for this data type are defined by creating a structure in the program. Structure is a way to combine the logically related data elements into a single unit. Each of the data elements defined inside the structure, are called the members of a structure. The members defined inside the structure can be of a same or different data types. Hence, a structure can be defined as a template which is created for storing heterogeneous values in physically adjacent memory locations.

    What is a “user-defined” data type?

    C/C++ has a built-in set of primitive data types like int, float, char, double etc, which we can be directly used in the program. We can create variables of built-in types and perform operations with the values stored in these variables. Along with using built-in data types, we can also create customized data types in a program. “User-defined data type” is a “customized” data type that the programmer can create as per the requirements to store data in computer memory.

    Structures are used to create user-defined data types.

    What is the need to create user-defined data types in the program?

    Let us assume that you need to store data about the vehicles assembled in an automobile industry. The relevant information that you wish to maintain for each vehicle is “colour”, “no of seats”, “type of fuel” and “mileage” of the vehicle. As and when a new car is assembled you will need to create 4 different variables to store its information in computer memory. Instead, it would be easy if the programmer has an ability to create a variable of type Car using the statement,

    Car c1;

    where cl stores all the required information about the car in a real world. The variable cl can internally store the 4 attributes “colour”, “no of seats”, “type of fuel” and “mileage” of the vehicle.

  • Preface

  • Kunal Pimparkhede
  • Book:
    Computer Programming with C++
    Published online:
    28 May 2018
    Print publication:
    18 October 2016, pp xi-xii

  • Summary

    A computer program is a set of instructions which is followed by a machine to generate the required output. The language in which a computer program is written is called a computer programming language. Several computer programming languages are in use in the IT industry today, for developing diverse software applications.

    The study of C and C++ is considered an important step towards mastering computer programming fundamentals. Hence, C and C++ are included in the syllabus of any computer science course.

    This textbook provides in-depth explanations of C and C++ programming languages along with the fundamentals of the object oriented programming paradigm.

    About the Book

    This book will be of use to anyone who is a beginner and aspires to learn the fundamentals of computer programming using C and C++. It has been primarily written for students of academic courses which include the study of C, C++ and object oriented programming paradigm. Simple and lucid language has been used to facilitate easy comprehension of complex topics.

    Salient Features

    • Example-driven approach illustrates application of theoretical concepts

    • Theme of a conversation interspersed in the text, elucidate essential themes of the subject

    • Each program includes necessary comments to explain the logic used to implement a particular functionality

    • Several line diagrams and flow charts facilitate easy comprehension of theoretical concepts

    • Student-friendly pedagogical features include:

  • ✓ Error Finding Exercise

  • ✓ Solved Problems

  • ✓ Objective Questions

  • ✓ Review Questions

    • Chapter Organization

    This book comprises 17 chapters. Chapter 1 gives an overview of computer organization and architecture. It also explains the C/C++ development environment. Chapters 2 to 5 discuss the basic features of C/C++ including data types, variables and different control statements which are supported by the language. Chapter 6 describes the creation of multivalued data types (also referred to as collection types) using arrays in C/C++. Chapter 7 explains modular programming using functions. Chapter 8 elucidates the fundamentals of memory management using pointers in C/C++. Chapter 9 discusses the creation of composite data types using structures and unions in C/C++. Chapter 10 explains the principles of memory management and Dynamic memory allocations in C++ style. Chapters 11 to 17 provide in-depth coverage of object oriented features supported by C++.

  • 16 - Templates in C++

  • from PART-II - Object Oriented Programming
  • Kunal Pimparkhede
  • Book:
    Computer Programming with C++
    Published online:
    28 May 2018
    Print publication:
    18 October 2016, pp 928-968

  • Summary

    Overview

    Templates in C++ are used to facilitate generic programming by giving the programmer an ability to create generic classes/functions in the program. A component of the program is said to be generic if its functionality remains the same irrespective of data type of the values it operates on. A generic function is a function that can work with arguments of any data type, whereas a generic class is a class that can work with members of any data type. In this chapter, we will learn creation of generic functions using function templates and creation of generic classes using class templates.

    NOTES

    The objective of templates is to create generic components in the program, which can work with different data types. This saves programmers effort to define the same component multiple times and replicating same logic for different type of data values.

    Function Templates

    Function templates in C++ enable the programmer to create generic functions. These functions are adaptable to multiple data types and can execute in the same way immaterial of the data type of the values passed to it.

    The functions we have written so far in the previous chapters are strictly bonded to specific types. For example, consider the function add() as shown below:

    int add(int a,int b)

    ﹛

    int c = a+b;

    return c;

    ﹜

    The function takes two arguments of type integer and returns the resultant integer, which gives addition of two numbers. This function works well if integer values are passed to it, however the function will not produce correct results if any other type of values are passed to it.

    For instance, if we call the function add() by passing float values

    float k = add(10.2,11.5);

    the value returned in variable k will not be correct rather truncated. As per the default behaviour of C++, value in variable k will be 21.00 and not 21.7. This means that the function has performed truncation of the resultant value resulting in loss of data. And hence, the function cannot work for float type values.

    At times, it is required to implement the same logic for multiple type of values. In such cases, you can use function templates in C++.

  • 13 - Operator Overloading

  • from PART-II - Object Oriented Programming
  • Kunal Pimparkhede
  • Book:
    Computer Programming with C++
    Published online:
    28 May 2018
    Print publication:
    18 October 2016, pp 699-769

  • Summary

    Overview

    All the operators in C++ are designed to operate with the basic data types only. For example, an arithmetic operator + can be used to perform addition of integers, floats, doubles etc. but cannot be used to perform addition of user-defined objects. Let's say if we create a class Point to represent points in Cartesian coordinate system, we are not able to perform addition of two Point objects using operator + like we do it for primitive types. Recall from Chapter 11 section 11.10 that addition of Point objects P1 and P2 is performed using a function add() defined inside the class. We performed the addition of two points P1 and P2 by making a call to add() as follows:

    P3=P1.add(P2);

    The function is invoked by P1 passing P2 is passed as an argument, the result of addition is stored in object P3, which gives the x and y coordinate values of the resultant point. The addition of Point objects is performed using a member function add(), merely because the arithmetic operator + cannot be used to perform addition of user-defined objects. The basic principle of operator overloading is to extend the capability of C++ operators in order to use them with user-defined types in the same way and with the same syntax as with basic types. When we say that classes are used to create user-defined data types, it is a fair expectation that the operation with user-defined objects should be performed in the same way as they are performed with primitive types.

    If we overload operator + in class Point, we will be able to perform addition of Point objects as follows:

    P3=P1+P2;

    Making use of operator + to add Point objects makes the statement very easy to read and understand when compared to the former statement. Operator overloading is essentially used by the programmers to create programs with a friendly syntax. Clearly it is not a necessity, but it provides great luxury to the programmers to read and maintain the program.

  • 4 - Decision Making Control Statements

  • from PART-I - Structured Programming
  • Kunal Pimparkhede
  • Book:
    Computer Programming with C++
    Published online:
    28 May 2018
    Print publication:
    18 October 2016, pp 110-145

  • Summary

    Overview

    We understand from Chapters 1 and 2 that instructions in a program are executed in a sequence in which we write them in the main() function. Such an execution is called a sequential execution. In many cases it is required to change the sequence of executing instructions based on some condition. The statements that can be used to alter the sequence of executing instructions at run time of the program are called branching or decision making control statements.

    C/C++ supports a following branching/decision making control statements:

  • 1. if – else statement

  • 2. else-if ladder

  • 3. switch statement

  • 4. Ternary operator (?:)

  • 5. goto statement

    • In this chapter we discuss the syntax and working of each of the above decision making control statements supported by C/C++.

    if else Statement

    The if-else statement is used to change the sequence of execution by evaluating a specified condition at run time of the program. The condition to be evaluated must be specified in round parenthesis when defining the if block as shown in Figure 4.1. The if-else statement defines two blocks, the first block is called if block and the second block is called else block. The control of execution is transferred inside the if block if the condition specified in the parentheses is evaluated as true, whereas the control of execution is transferred inside the else block if the condition specified is evaluated as false.

    A condition is generally written using relational operators and hence an evaluation of a condition can result into two possible outcomes as ‘true’ or ‘false’. Therefore, it will be correct to say that, in any of the given scenario the control of execution will always be transferred to at least one of the two blocks (if block or the else block). Also, the control of execution will be transferred to exactly one of the two blocks (if block in case the condition is evaluated as true or it can be a else block in case the condition is evaluated as ‘false’).

  • 3 - Operators and Type Casting

  • from PART-I - Structured Programming
  • Kunal Pimparkhede
  • Book:
    Computer Programming with C++
    Published online:
    28 May 2018
    Print publication:
    18 October 2016, pp 71-109

  • Summary

    Overview

    C/C++ has a dedicated set of special characters which can be used to perform operations on the data items. Each of these special characters represent as a specific operation to be performed to the compiler. For example, a symbol + is used to perform addition, and the symbol * is used to perform multiplication and so on. There are two properties associated with each of the operators so as to define the approach used for its evaluation:

  • 1. Priority of the operator

  • 2. Associativity of the operator

    • A Priority of the operator is a precedence associated with the operator. Every Operator is assigned a specific priority using which an operator must be resolved, so as to generate the result of the expression. Assigning priority to an operator helps in avoiding the ambiguity that may arise in the order of evaluation when a given expression consists of multiple operators. So as to understand the exact meaning of operator precedence, let us consider the expression below:

    int p=10,q=5,r=2,s;

    s=p+q*r;

    After substituting the values of variables p, q, and r the expression that calculates the value of variable s can be rewritten as shown below:

    s=10+5*2;

    In the absence of operator precedence, the compiler will have two different options to generate the result of the above expression.

    Option 1: Perform addition before multiplication (wrong option)

    First perform the addition of two numbers 10 and 5, and then perform multiplication of the result with value 2. Hence, we will get the result of the expression as 30 as shown in Figure 3.1. Note that, this is a case where,we have evaluated the result of ‘addition’ before evaluating the result of ‘multiplication’. The order of evaluation is as shown in Figure 3.1.

    Option 2: Perform multiplication before addition (correct option)

    As a second option to generate the result of the expression, we could first perform multiplication of two numbers 5 and 2 and then perform addition of the result with value 10. Hence, we will get the result of the expression as 20 as shown in Figure 3.2. Note that, this is a case where, we have evaluated the result of ‘multiplication’ before evaluating the result of ‘addition’. The order of evaluation is as shown in Figure 3.2.

  • Software Development Life Cycle

  • Kunal Pimparkhede
  • Book:
    Computer Programming with C++
    Published online:
    28 May 2018
    Print publication:
    18 October 2016, pp 999-1001

  • Summary

    Any software system to be developed (using any of the programming languages) must go through a series of steps before the system is deployed and released on to the production environment. The software development life cycle (SDLC) defines the stages involved in the software development process, so as to develop a particular application. One of the models that are followed in the development of a software application is called as a ‘waterfall’ model, which is shown in Figure A3.1.

    The figure shows a series of steps that we must follow in the software development process. The meaning of each of the phases is as explained below:

    Analysis: This is a phase in software development where the software engineer understands the exact requirements of the software to be developed. The requirements of the application to be developed are captured from the end users of the application and a ‘Business requirements document’ is prepared, which describes the answers to the following questions:

  • 1. What are the inputs to the system to be developed?

  • 2. What is the processing to be performed by the system to be developed?

  • 3. What are the outputs of the system to be developed?

    • ‘Analysis’ is the detailed study of the requirements that are received from the business users for a particular software system to be developed under a given set of constraints.

    Design: Software ‘design’ is a process to create ‘model’ of the system to be developed thereby finalizing the complete approach of development. The models created during the ‘design’ phase should define the following attributes:

  • 1. The detailed software architecture of the system to be developed.

  • 2. The detailed procedure/algorithm of each functionality which is required to implement the solution.

  • 3. The specifications of the data models to be implemented for the system to be developed.

  • 4. Other software system and integrity constraints.

    • The ‘feasibility study’ is also done in the design process so as to determine if the requirements are possible to be implemented under a given set of constraints. If any of the requirements is found to be unfeasible, the development process may be reiterated from the analysis phase where the requirements for the system are redefined.

  • 2 - Preliminaries and Background I

  • from PART I - MODELS
  • Stéphane Demri, Centre National de la Recherche Scientifique (CNRS), Paris, Valentin Goranko, Stockholms Universitet, Martin Lange, Universität Kassel, Germany
  • Book:
    Temporal Logics in Computer Science
    Published online:
    13 October 2016
    Print publication:
    13 October 2016, pp 17-34

  • Summary

    This chapter presents preliminaries on set-theoretical notions, binary relations, linear orderings, fixpoint theory and computational complexity classes. Mainly, we provide notations for standard notions rather than giving a thorough introduction to these notions. More definitions are provided in the book, and we invite the reader to consult textbooks on these subjects for further information. For instance, in Moschovakis (2006) any reader can find material about set-theoretical notions, ordinals or fixpoints far beyond what is sketched in this chapter. Still, we implicitly assume that the reader has basic set-theoretic background. As stated already in Chapter 1, we do not intend to teach this material here but rather to recall the most basic notions, terminology and notation. The current chapter is included for the convenience of the reader as a quick reference.

    Structure of the chapter. The chapter is divided into two sections. The first section contains standard material on sets and relations. Section 2.1.1 presents standard set-theoretical notions that are used throughout the book. Binary relations are ubiquitous structures in this volume, and Section 2.1.2 is dedicated to standard definitions about them. In Section 2.1.3, we provide basic definitions about partial and linear orders.

    The second section contains material that is more specialised and needed for the development of a theory of and algorithms for temporal logics. Section 2.2.1 presents the basics of fixpoint theory; Chapter 8, which deals with the modal μ-calculus with fixpoint operators, uses some of the results stated herein. In Section 2.2.2, we recall standard complexity classes defined via deterministic and nondeterministic time- and space-bounded Turing machines. Other classes, in particular involving alternating Turing machines, are discussed in Chapter 11. Section 2.2.3 provides an introduction to 2-player zero-sum games of perfect information that are useful, for instance, in defining the game-theoretic approach to temporal logics.

    Sets and Relations

    Operations on Sets

    Throughout this book we use the standard notations for set-theoretical notions:membership (∈), inclusion (⊆), strict (or proper) inclusion (⊂), union of sets (∪), intersection of sets (∩), difference of sets (\) and product of sets (×). The empty set is denoted by ∅.

  • 12 - Frameworks for Decision Procedures

  • from PART IV - METHODS
  • Stéphane Demri, Centre National de la Recherche Scientifique (CNRS), Paris, Valentin Goranko, Stockholms Universitet, Martin Lange, Universität Kassel, Germany
  • Book:
    Temporal Logics in Computer Science
    Published online:
    13 October 2016
    Print publication:
    13 October 2016, pp 467-475

  • Summary

    This fourth and last part of the book provides algorithmic methods for the main decision problems that come with temporal logics: satisfiability, validity and model checking. Model checking is typically easier, particularly for branching-time logics, and therefore admits simpler solutions that have been presented in the chapters of Part II already. Since temporal logics are usually closed under complementation, satisfiability and validity are very closely related and methods dealing with one of them can easily be used to solve the other, so we will not consider them separately. Indeed, in order to check a formula φ for validity, one can check ¬φ for satisfiability and invert the result since φ is valid iff ¬φ is unsatisfiable. Satisfiability is reducible to validity likewise. Furthermore, a satisfiability-checking procedure would typically yield not only the answer but also, in the positive case, a model witnessing the satisfiability of the input formula. Such an interpreted transition system would refute validity of ¬φ, i.e. be a countermodel for its validity. Hence, the focus of this part is on satisfiability checking.

    The methods presented here are closely linked to Chapter 11, which provided lower bounds on the computational complexity of these decision problems, i.e. it explained how difficult these problems are from a computational perspective. The following chapters provide themissing halves to an exact analysis of temporal logics’ computational complexities: by estimating the time and space consumption that these methods need in order to check for satisfiability, satisfaction, etc., we obtain upper bounds on these decision problems. Thus, while Chapter 11 showed how hard at least these problems are, the following chapters show how hard they are at most, by presenting concrete algorithmic solutions for these decision problems.

    The methods presented in the following three chapters are in fact methodologies in the sense that each chapter introduces a particular framework for obtaining methods for certain temporal logics. Each of these frameworks – tableaux, automata and games – has its own characteristics, strengths and weaknesses and may or may not be particularly suited for particular temporal logics. Axiomatic systems, presented in the respective chapters of Part II, provide an alternativemethodology that historically appeared first, but they can only be used to establish validity (resp. nonsatisfiability) when it is the case, and provide no answer otherwise, so they are not really decision methods.

  • 5 - Basic Modal Logics

  • from PART II - LOGICS
  • Stéphane Demri, Centre National de la Recherche Scientifique (CNRS), Paris, Valentin Goranko, Stockholms Universitet, Martin Lange, Universität Kassel, Germany
  • Book:
    Temporal Logics in Computer Science
    Published online:
    13 October 2016
    Print publication:
    13 October 2016, pp 100-149

  • Summary

    This chapter is a brief introduction to the basic multimodal logic BML, interpreted as the simplest natural temporal logic for reasoning about transition systems. Indeed, transition systems are nothing but Kripke frames and interpreted transition systems are simply Kripke models, so a standard Kripke semantics is provided for a multimodal language with modal operators □a and ◊a, associated with each transition relation Ra. These bear natural meaning in interpreted transition systems, stating what must be true in all /respectively, what may be true at some/ Ra-successors of the current state. In order to emphasise these readings of the modal operators, we will use a notation that is unusual for modal logic, but is more suitable in the context of temporal logics: AXa (read as for all paths starting from the current state, at the next state) and EXa (for some path starting from the current state, at the next state). Thus, BML is the minimal natural logical language to specify local properties of transition systems.

    Since the chapter is written from the primary perspective of transition systems, rather than from modal logic perspective, we have put an emphasis on certain topics such as expressiveness, bisimulation, model checking, the finite model property and deciding satisfiability, while other fundamental topics in modal logic – such as deductive systems and proof theory, model theory, correspondence theory, algebraic semantics and duality theory – are almost left untouched here. Of all deductive systems developed for modal logics we only mention the axiomatic system for BML here and present a version of the tableaubased method for it in Chapter 13; for the rest we only provide basic references in the bibliographic notes.

    This chapter can also be viewed as a stepping stone towards the more expressive and interesting temporal logics that are presented further.

    Structure of this chapter. Section 5.1 presents the syntax and semantics for BML. The relational translation from BML into first-order logic (FO) is also presented emphasising the fact that BML can be viewed as a fragment of classical first-order predicate logic. Section 5.2 presents some techniques for renaming and transformation of BML formulae to equisatisfiable ones in certain normal form of modal depth two.

  • 8 - The Modal Mu-Calculus

  • from PART II - LOGICS
  • Stéphane Demri, Centre National de la Recherche Scientifique (CNRS), Paris, Valentin Goranko, Stockholms Universitet, Martin Lange, Universität Kassel, Germany
  • Book:
    Temporal Logics in Computer Science
    Published online:
    13 October 2016
    Print publication:
    13 October 2016, pp 271-328

  • Summary

    We have noted that the basic modal logic BML suffers from the deficiency of not being able to make assertions about connectivity, i.e. every BML formula can only ‘look’ up to a certain depth into a transition system. This is of course not enough for many purposes, and this is why richer formalisms like reachability logic TLR and the computation tree logic CTL have been introduced. As we demonstrated in Chapter 7, these logics possess temporal operatorswhich directly translate such assertions into the syntax of a logic. As we showed in Section 7.1.5, all temporal operators in CTL added on top of BML have simple and elegant characterisations in terms of least or greatest fixpoint solutions to certain equations.

    The modal μ-calculus Lμ uses this idea as a general principle in order to add expressive power to the basic modal logic BML. It only features two additional syntactic constructs: a least and a greatest fixpoint operator. Thus, it differs from the other logics studied here in the way that the fixpoint character of a formula is being made explicit in it. This has pros and cons: it allows any least or greatest fixpoint solution of an equation expressed with basic modal logic to be defined; on the other hand this results in a far less intuitive syntax of the logic when compared to the other temporal logics.

    These two aspects determine the role that the modal μ-calculus plays in the world of temporal logics. The generic use of fixpoint quantifiers gives it a relatively high expressive power. Many other temporal logics can be embedded into themodal μ-calculus. The explicit use of fixpoint quantifiers come with a generic instruction for doing model checking using fixpoint iteration. Such algorithms can then be specialised to the embedded temporal logics. Thus, the modal μ-calculus is often called the backbone of temporal logics.

    Structure of the chapter. In Section 8.1 we start by introducing the concept of fixpoint quantification which leads to the formal logic called the modal μ-calculus. Early on we show that it can embed CTL simply because this translation is helpful in understanding the use of fixpoint quantifiers for the specification of temporal behaviour.

  • 9 - Alternating-Time Temporal Logics

  • from PART II - LOGICS
  • Stéphane Demri, Centre National de la Recherche Scientifique (CNRS), Paris, Valentin Goranko, Stockholms Universitet, Martin Lange, Universität Kassel, Germany
  • Book:
    Temporal Logics in Computer Science
    Published online:
    13 October 2016
    Print publication:
    13 October 2016, pp 329-358

  • Summary

    The transitions in the transition systems that we have studied so far are primitive and abstract objects. The nature of the possible transitions between states and the mechanisms that generate and determine them have not been essential in the context of the linear and branching time temporal logics we have studied in the previous chapters.

    Here we introduce and study a more involved type of transition system, called concurrent game structures, for modelling scenarios that typically arise in open or multiagent systems. An open system is a system (computer, device, agent) interacting with an environment. The properties and behaviour of such open systems can be modelled by 2-player games. More generally, a multiagent system may involve several interacting (possibly, cooperating or competing) agents, each pursuing their own goals or acting randomly (like nature or the environment). Concurrent game structures are special types of multiagent transition systems, where the transitions are determined by tuples of simultaneous actions performed by a fixed set of agents. Various logical formalisms extending linear and branching-time temporal logics can be used for the specification, verification and reasoning about dynamic properties of open and multiagent systems.

    In this chapter we present and study concurrent game structures as models for the family of so-called alternating-time temporal logics. They are themost popular and influential logics for strategic reasoning in multiagent systems and are multiagent versions of branchingtime temporal logics which correspond to closed or single-agent systems in a sense that we will discuss in the chapter.

    Structure of the chapter. We introduce concurrent multiagent transition systems and models in Section 9.1 and then the logics ATL* and ATL in Section 9.2.We then discuss model checking and satisfiability testing for these logics in Section 9.3. As usual, the chapter ends with exercises and bibliographic notes.

    Concurrent Multiagent Transition Systems

    Concurrent Game Structures and Models

    We begin with a motivating example. Figure 9.1 depicts two transition systems. The one on top involves two robots, Robot1 and Robot2, and a carriage. There are three different positions of the carriage, denoted by states s0, s1 and s2. Each robot has two possible actions at any of the states: push and wait. Robot1 can only push the carriage in clockwise direction, whereas Robot2 can only push it in anticlockwise direction.

  • 14 - The Automata-Based Approach

  • from PART IV - METHODS
  • Stéphane Demri, Centre National de la Recherche Scientifique (CNRS), Paris, Valentin Goranko, Stockholms Universitet, Martin Lange, Universität Kassel, Germany
  • Book:
    Temporal Logics in Computer Science
    Published online:
    13 October 2016
    Print publication:
    13 October 2016, pp 543-624

  • Summary

    In this chapter we present the automata-based approach for a variety of temporal logics and classes of automata and compare the advantages and the drawbacks of the different constructions. We do not always aim at optimal complexity upper bounds but also take other criteria into account. This is not a chapter on automata theory but rather a chapter on automata for temporal logics. We focus our attention on reductions of decision problems for temporal logics into decision problems on automata instead of in-depth treatment of automata. References are provided, as usual, as bibliographical notes.

    As already discussed in Section 1.1.3, the automata-based approach consists of reducing logical problems to automata-based decision problems in order to take advantage of known results and decision procedures from automata theory. The notion of models for logical formulae is substituted by the notion of words or trees accepted by automata (or any other type of structures accepted by automata). The correspondence between formulae and automata, which underlines the difference between a declarative statement (a formula) and an operational device (an automaton), allows to reduce many logical problems, viz.:

    1. • satisfiability of a formula φ (i.e. existence of a model for φ) reduces to checking nonemptiness of an automaton Aφ (i.e. existence of a word/tree accepted by Aφ) by using a map between models and, respectively, words or trees;

    2. • validity of a formula φ (i.e. truth of φ is all models) reduces to checking universality of an automaton Aφ (i.e. checking whether Aφ accepts all words/trees);

    3. • entailment of one formula φ by another formula ψ reduces to checking whether all what is accepted by the automaton Aφ is also accepted by the automaton Aψ (the inclusion problem).

    The idea in a nutshell: the automata considered here are not Turing-complete and have restricted computational power and decidable decision problems, so logical decision problems can be reduced to respective automata-based decision problems for which algorithms exist. This is all the magic around this approach to solve logical decision problems: design a reduction and then rely on automata-based decision procedures.Alternatively, this approach can be viewed as a means to solving logical decision problems by using a class of devices with limited computational power, i.e. automata. This is why it helps to better understand their computational power.

Page 69 of 279