Term Paper

(THEORY OF COMPUTATION) ON

REAL WORLD APPLICATIONS OF DIFFERENT TYPES OF AUTOMATA

Submitted By: Vishaldeep Singh Section: K18E3 Roll No. : 03 Reg. No.: 10802706

Serial No.
1
Introduction

CONTENTS

General Applications of Automata Biology Cellular Automata Game for Life Pascals Triangle Brains Brain Finite Automata Applications Other Applications

TYPES OF AUTOMATA AND APPLICATIONS TURING MACHINE LINEAR BOUNDED AUTOMATA PUSH DOWN AUTOMATA FINITE AUTOMATA

Turing Machine Real time Implementation Software Implementation

Applications of Turing Machine Turing Machine Counting Turing Machine Subtraction 3-State Busy Beaver 4-State Busy Beaver Justification

Linear Bounded Automata

Applications of LBA Genetic Programming Parse Trees Emptiness Problem

Push Down Automata

Applications of PDA Online Transaction process system The UPPAAL tool Tower of Hanoi (Recursive Solution) Timed Automata Model Deterministic Top Down Parsing LL Grammar Context free Language Predictive Bottom up Parsing LR Grammar Converting a PDA

9 10

Finite Automata Applications of Finite Automata Finite State Programming Event Driven Finite State Machine(FSM) Virtual FSM DFA based text filter in Java Acceptors and Recognizers Transducers UML state diagrams Hardware Applications FSM Real Time Scenario 1 FSM Real Time Scenario 2

11

Conclusion

INTRODUCTION
Automata theory is the basis for the theory of formal languages. A proper treatment of formal language theory begins with some basic definitions:

A symbol is simply a character, an abstraction that is meaningless by itself. An alphabet is a finite set of symbols. A word is a finite string of symbols from a given alphabet. Finally, a language is a set of words formed from a given alphabet.

The set of words that form a language is usually infinite, although it may be finite or empty as well. Formal languages are treated like mathematical sets, so they can undergo standard set theory operations such as union and intersection. Additionally, operating on languages always produces a language. As sets, they are defined and classified using techniques of automata theory. Formal languages are normally defined in one of three ways, all of which can be described by automata theory:

regular expressions standard automata a formal grammar system

Regular Expressions Example :

alphabet A1 = {a, b} alphabet A2 = {1, 2} language L1 = the set of all words over A1 = {a, aab, ...} language L2 = the set of all words over A2 = {2, 11221, ...} language L3 = L1 L2 language L4 = {an | n is even} = {aa, aaaa, ...} language L5 = {anbn | n is natural} = {ab, aabb, ...}
Languages can also be defined by any kind of automaton, like a Turing Machine. In general, any automata or machine M operating on an alphabet A can produce a perfectly valid language L. The system could be

represented by a bounded Turing Machine tape, for example, with each cell representing a word. After the instructions halt, any word with value 1 (or ON) is accepted and becomes part of the generated language. From this idea, one can defne the complexity of a language, which can be classified as P or NP, exponential, or probabilistic, for example. Noam Chomsky extended the automata theory idea of complexity hierarchy to a formal language hierarchy, which led to the concept of formal grammar. A formal grammar system is a kind of automata specifically defined for linguistic purposes. The parameters of formal grammar are generally defined as:

a set of non-terminal symbols N a set of terminal symbols a set of production rules P a start symbol S

Grammar Example:
start symbol = S non-terminals = {S} terminals = {a, b} production rules: S aSb, S ba S aSb abab S aSb aaSbb aababb L = {abab, aababb, ...} As in purely mathematical automata, grammar automata can produce a wide variety of complex languages from only a few symbols and a few production rules. Chomsky's hierarchy defines four nested classes of languages, where the more precise a classes have stricter limitations on their grammatical production rules. The formality of automata theory can be applied to the analysis and manipulation of actual human language as well as the development of human-computer interaction (HCI) and artificial intelligence (AI).

GENERAL APPLICATIONS OF AUTOMATA

Biology:
To the casual observer, biology is an impossibly complex science. Traditionally, the intricacy and variation found in life science has been attributed to the notion of natural selection. Species become "intentionally" complex because it increases their chance for survival. For example, a camouflage-patterned toad will have a far lower risk of being eaten by a python than a frog coloured entirely in orange. This idea makes sense, but automata theory offers a simpler and more logical explanation, one that relies not on random, optimizing mutations but on a simple set of rules. Basic automata theory shows that simplicity can naturally generate complexity. Apparent randomness in a system results only from inherent complexities in the behaviour of automata, and seemingly endless variations in outcome are only the products of different initial states. A simple mathematical example of this notion is found in irrational numbers. The square root of nine is just 3, but the square root of ten has no definable characteristics. One could compute the decimal digits for the lifetime of the universe and never find any kind of recurring patter or orderly progression; instead, the sequence of numbers seems utterly random. Similar results are found in simple two-dimensional cellular automaton. These structures form gaskets and fractals that sometimes appear orderly and geometric, but can resemble random noise without adding any states or instructions to the set of production rules. The most classic merging of automata theory and biology is John Conway's Game of Life. "Life" is probably the most frequently written program in elementary computer science. The basic structure of Life is a two-dimensional cellular automaton that is given a start state of any number of filled cells. Each time step, or generation, switches cells on or off depending on the state of the cells that surround it. The rules are defined as follows:

All eight of the cells surrounding the current one are checked to see if they are on or not. Any cells that are on are counted, and this count is then used to determine what will happen to the current cell: 1. Death: if the count is less than 2 or greater than 3, the current cell is switched off. 2. Survival: if (a) the count is exactly 2, or (b) the count is exactly 3 and the current cell is on, the current cell is left unchanged. 3. Birth: if the current cell is off and the count is exactly 3, the current cell is switched on.

Like any manifestation of automata theory, the Game of Life can be defined using extremely simple and concise rules, but can produce incredibly complex and intricate patterns. In addition to the species-level complexity illustrated by the Game of Life, complexity within an individual organism can also be explained using automata theory. An organism might be complex in its full form, but examining constituent parts reveals consistency, symmetry, and patterns. Simple organisms, like maple leaves and star fish, even suggest mathematical structure in their full form. Using ideas of automata theory as a basis for generating the wide variety of life forms we see today, it becomes easier to think that sets of mathematical rules might be responsible for the complexity we notice every day. Inter-species observations also support the notion of automata theory instead of the specific and random optimization in natural selection. For example, there are striking similarities in patterns between very different organisms:

Mollusks and pine cones grow by the Fibonacci sequence, reproducible by math. Leopards and snakes can have nearly identical pigmentation patterns, reproducible by two-dimensional automata.

With these ideas in mind, it is difficult not to imagine that any biological attribute can be simulated with abstract machines and reduced to a more manageable level of simplicity.

Cellular Automata:
The history of cellular automata dates back to the forties with Stanislas Ulam. This mathematician was interested in the evolution of graphic constructions generated by simple rules. The base of his construction was a two-dimensional space divided into "cells", a sort of grid. Each of these cells could have two states : ON or OFF. Starting from a given pattern, the following generation was determined according to neighbourhood rules. For example, if a cell was in contact with two "ON" cells, it would switch on too ; otherwise it would switch off. Ulam, who used one of the first computers, quickly noticed that this mechanism permitted to generate complex and graceful figures and that these figures could, in some cases, selfreproduce. Extremely simple rules permitted to build very complex patterns. On that basis, the following question was asked : can these recursive mechanisms (i.e. in that case depending on their own previous state) explain the complexity of the real ? Is this complexity only apparent, the fundamental rules being themselves simple. Cellular automata left laboratories in 1970 with the now famous Game of Life of John Horton Conway.

(I) Game for Life Like Ulam's cellular spaces, the game of life is based a grid constituted of cells, for example :

Determination of neighbourhood

First generation

Second generation

Example of a 1 dimension automaton (Pascal's triangle)

It is also possible to modify the determination of neighbourhood. If we consider two dimensions automata, the most common neighbourhoods are6 : For example, Fredkin's automata, that uses a Moore neighbourhood is based on the parity of neighbourhood. It's a totalistic automaton, that is to say the state of the cells depends on the sum of the states of neighbouring cells. In this case there is reproduction only if there is an odd neighbourhood value. This automata has got the remarkable property to reproduce nine copies of any basic pattern. Fredkin's rule can easily be generalized to more than two dimensions.
(II) Pascals Triangle Pascals triangle is an array of numbers which has found uses in many areas of mathematics. 1 11

Do you see the pattern?

12 1 1331 146? 1

Example Can you nd the missing number? Example Can you nd the next row? Answer: The missing number is 4 and is found by adding the two numbers above the empty space. Answer: The next row is formed by the addition rule for nding missing spaces: 1, 5, 10, 10, 5, 1. The 1s on either end also follow this rule if there are implicit zeros. So the triangle really looks like
...01 0... ...0110... ...01210... ...013310... ...0146410... One of the most common uses of numbers from Pascals triangle is in the binomial formulas,

such as:

The coecients of (a + b)n come from row n of Pascals triangle.

(III) Brains Brain:

It is also possible to modify the number of states. You needn't restrict yourself to both states life/death. Numerous famous automata use more than two states. One of the most famous is Brian's Brains presented by Brian Silverman in 1984. This three states automaton (life, ghost, death) generates a wide diversity of complex gliders within astonishing graphic patterns.
Brian's Brain

In a general way, it is possible to build any type of automata by playing on structural and functional rules. The first ones define the spatial structure of the automata network, that is its number of dimensions, the disposition of cells (squares, hexagons, in a two dimensional automaton) and the type of neighbourhood determination. The second ones will determine the number of states and the transition rules8. The choice of these two types of rules permits to build a universe adapted to the demanded aim.

Finite Automata Applications:

Software for designing and checking the behaviour of digital circuits
Lexical analyzer of a typical compiler
Lexical analyzer of a typical compiler

finding
Sowa r e f o ver i fyi n system of al l types that have a ni te num er of r g s b states (e.g., stock market transaction, communication/network protocol)

Other Applications :
Many other branches of science also involve unbelievable levels of complexity, impossibly large degrees of variation, and apparently random processes, so it makes sense that automata theory can contribute to a better scientific understanding of these areas as well. The modern-day pioneer of cellular automata applications is Stephen Wolfram, who argues that the entire universe might eventually be describable as a machine with finite sets of states and rules and a single initial condition. He relates automata theory to a wide variety of scientific pursuits, including:

Fluid Flow Snowflake and crystal formation Chaos theory Cosmology Financial analysis
Graphical Application of Cellular Automata

Types of Automata & Applications

(1.) Turing Machine (2.) Linear Bound Automata (3.) Push Down Automata (4.) Finite Automata

TURING MACHINE
Introduction:
A Turing machine is a theoretical device that manipulates symbols on a strip of tape according to a table of rules. Despite its simplicity, a Turing machine can be adapted to simulate the logic of any computer algorithm, and is particularly useful in explaining the functions of a CPU inside a computer. The "Turing" machine was described by Alan Turing in 1936, who called it an "(automatic)-machine". The Turing machine is not intended as a practical computing technology, but rather as a thought experiment representing a computing machine. Turing machines help computer scientists understand the limits of mechanical computation.

Real Time Implementation

Read/Write Head

The read/write head is the center of the machine. The tape in the machine is a 1000 roll of white 35mm film leader. The characters are written by the machine with a black dry erase marker. Each character cell is 1.125 in width. Although the tape is not infinite in length, it is long enough for any practical use and can hold approximately 10K bits worth of binary data.

The read/write head from the front

The read/write head from the top. Here you can see the servo that controls the "Y" axis of the pen. The base of the head is 8.5 x 4".

(1)View from the back of the head showing the transport system. The stepper motor is at the lower left and includes a home sensor. (2)Here is one of the film drive cogs with its cover/hold down moved aside. There is one cover at each end on the read/write head base.

(1). Back view of the write section of the head. Here you can see the two servos, one for the Y axis, the other for pen lift. The pen is fit into and slides through telescoping brass tubes. (2). Line scan camera and illumination section. The TSL-1401 linescan camera captures 128 bits of data in a single line. Exposure time is about 1/200 sec.

(1). View of the erase section from the back. The mechanism is raised and lower with the small pin that comes through the base of the head. This pin rides on a cam attached to a servo. (2). The erase section from the top. The erase cylinder is covered with 1/4" thick felt. The whole erase section pivots when it is raised and lowered on a small shaft attached to the frame.

Schematic of the electrical components of the Turing machine.

Software Overview:

The Turing machine is controlled by a Parallax Propeller chip. Most of the programming for the machine is done in the Propeller chip's Spin language. There are two major sections of the programming. One deals with the user interactions and the other is the actual running of the Turing states. User interactions: Loading programs from SD card. Formally, these programs are called states or transition rules. Creating a default tape. Programs often work on a tape that has some number already on it and these can be edited by the user. Utility functions. This includes things like moving the tape to a new position, erasing a bulk section of the tape, and changing the way a program runs or steps through its actions. Turing Machine Loop: Reads, writes and erases the tape. Finds the state rule that matches the current state and what was read from the cell. Updates the feedback display.

Applications of Turing Machine

(1.) Turing Machine Counting

Counting is one of the first math skills we learn. It's really not that much different for a computer or a Turing machine except they normally use binary numbers, so they count in binary. In this Turing machine example, you can see the machine following a simple set of steps to count in binary.

How the Turing Machine Counts Counting is really just repeatedly adding one to a number. If we count in decimal like most humans do, we keep adding one to a number. When adding one causes a digit to change to a zero we have to carry an extra one over to the digit to the left and add it there. This has become so automatic for us that we seldom even think about it any more. The Turing machine counts in the same way, it's just adding one to the number that is currently on the tape. The big difference is that the Turing machine counts in binary. When it changes a digit to a zero it also carries and adds the one to the digit to the left. But because there are only zeros and ones in binary this carry happens a lot more often. The states required for counting with the Turning machine are some of the easiest to understand. The three rules that make up state "0" do not change the tape, they simple move to the right most cell without changing the tape. When a blank cell is found, the tape moves one cell back to the left and changes to state "1". State "1" is where the counting happens. The three rules of state "1" are really rules for adding one and carrying. We know that we are starting from the right most digit because

we are coming to this state from state "0". If we read a zero, we change it to a one and have finished adding because there is nothing to carry. So the state is changed back to "0" and the tape is moved back to the right. If though, we read a one, it is changed to a zero, and we now need to carry that one to the left. This carry is accomplished with the second rule of state "1". It does this by moving to the left one digit and staying in state "1". By staying in state "1" the machine in a sense stays in the add one mode, thus carrying the one. The machine will stay in state one until it finds a zero to add the one to or it finds a blank. The third rule of state "1" handles blank cells by treating them just like zeros, that is they are changed to a one and the adding of one is completed.
The States Used For This Example (Explanation of the Programming Syntax Used)
(0,1) -> (0,1) Right (0,0) -> (0,0) Right (0,B) -> (1,B) Left 1 //This state moves the tape to the right most digit //This state moves the tape to the right most digit //When a blank at the right is found we change to state

//This next block, state 1, is where the counting really happens (1,0) -> (0,1) Right (1,1) -> (1,0) Left (1,B) -> (0,1) Right

//If we change a 0 to a 1 we change back to state 0

//If we change a 1 to a 0 we keep looking to the left

//If we change a Blank to a 1 we change back to state 0

For the Keen Observers Keen observers will note that the sample shown in the video stops on it's own after it reaches 16 in decimal. This was done for the video and only takes one change to the program shown above. The third rule of state "1" is changed to:
(1,B) -> (0,1) Halt //If we change a Blank to a 1 we stop

This has the effect of stopping the counting when the tape adds a one to the blank cell at the left of the number. For the Really Keen Observers Really keen observers will note that the sample shown in the video continues to move to the left after a one was written to the tape. This was done so that the whole tape was visible on each pass of adding one. It doesn't change the outcome in any way. It was done by adding a state "2" and changing state "1" like this:
(1,0) -> (2,1) Left (1,1) -> (1,0) Left (1,B) -> (0,1) Halt stop (2,1) (2,0) (2,B) state -> (2,1) Left -> (2,0) Left -> (0,B) Right 0 //If we change a 0 to a 1 we change to state 2 //If we change a 1 to a 0 we keep looking //We have to stop sometime, so if we find a blank we //This state moves the tape to the left most digit //This state moves the tape to the left most digit //When the blank at the left is found we switch to

(2.) Turing Machine Subtraction

Although there are a number of Turing state machines that will accomplish subtraction, this method uses only ones, zeros, and blank cells. It's not that difficult to understand how a Turing machine does subtraction. In this example, the space between the number sets separates the two sides of the equation. The machine removes matching "1"s from each side of the equation until there are no more "1"s on the right side. A count of the "1"s on the left side of the equation gives us the answer. While there are a large number of states in this example, most of them are responsible for finding the parts of the equation and the ends of each part (states 0, 1, 3, 4, 5). Two states (states 6 and 7) remove the leftover zeros at the end. The two states "2" and "8" remove the ones that match on each side of the equation.

The States Used For This Example :

(0,0) -> (0,0) Right (0,1) -> (0,1) Right (0,B) -> (1,B) Right (1,0) -> (1,0) Right (1,1) -> (1,1) Right (1,B) -> (2,B) Left //finds right edge of second number //finds right edge of first number

(2,0) -> (2,0) Left (2,1) -> (3,0) Left (2,B) -> (5,B) Right (3,0) -> (3,0) Left (3,1) -> (3,1) Left (3,B) -> (8,B) Left (4,0) -> (4,0) Right (4,1) -> (4,1) Right (4,B) -> (5,B) Right (5,0) -> (5,0) Right (5,1) -> (5,1) Right (5,B) -> (6,B) Left (6,0) -> (6,B) Left (6,1) -> (6,1) Left (6,B) -> (7,B) Left (7,0) -> (7, ) Left (7,1) -> (7,1) Left (7,B) -> (9,B) Right (8,0) -> (8,0) Left

//if a 0 keep looking for a 1

//removed right most 1 from right number

//if we find a blank before a 1, then erase 0s //move to left number

//finds right edge of first number

//finds right edge of second number

//removed 0 from right number

//removes 0 from left number

(8,1) -> (0,0) Right again (8,B) -> (4,B) Right (9,0) -> (9,0) Halt (9,1) -> (9,1) Halt (9,B) -> (9,0) Halt

//move left looking for a 1 to change to a 0 //if a 1 is found, change to zero and loop //if blank then all done, then erase 0s //halts the program

(3.) A 3-State busy beaver

The busy beaver problem is an interesting theoretical computer science problem. The problem is to find the smallest number of states that outputs as much data as possible yet eventually halts on its own. More formally it goes something like this given an n-state Turing machine with a two symbol alphabet {0, 1}, what is the maximum number of 1s that the machine may print on an initially blank tape before halting? This problem turns out to be non-computable, that is, for a small number of states an answer can be found, but in general it cannot be solved. Theorists call such problems non-computable. The number of steps it takes to run to completion (halt) grows very rapidly as the number of states increase. This 3-state example takes 14 steps while the 4-state example takes 107 steps. Increasing from there, a 5-state example has been found that takes 47,176,870 steps, and a 6state example that takes 2.584 x102879 steps. I will not be trying any of these in the near future.
The States Used For This Example
(0,0) -> (1,1) Right (0,1) -> (0,1) Halt (0,B) -> (1,1) Right (1,0) -> (2,0) Right (1,1) -> (1,1) Right (1,B) -> (2,0) Right (2,0) -> (2,1) Left (2,1) -> (0,1) Left (2,B) -> (2,1) Left

(4.) A 4-State busy beaver

The smallest number of states that outputs as much data as possible yet eventually halts on it's own. More formally it goes something like this given an n-state Turing machine with a two symbol alphabet {0, 1}, what is the maximum number of 1s that the machine may print on an initially blank tape before halting? This problem turns out to be non-computable, that is, for a small number of states an answer can be found, but in general it cannot be solved. Theorists call such problems non-computable. The number of steps it takes to run to completion (halt) grows very rapidly as the number of states increase. A 3-state example takes 14 steps while this 4-state example takes 107 steps. Increasing from there, a 5-state example has been found that takes 47,176,870 steps, and a 6state example that takes 2.584 x102879 steps.
The States Used For This Example

(0,0) -> (1,1) Right (0,1) -> (1,1) Left (0,B) -> (1,1) Right (1,0) -> (0,1) Left (1,1) -> (2,0) Left (1,B) -> (0,1) Left (2,0) -> (2,1) Halt (2,1) -> (3,1) Left (2,B) -> (2,1) Halt (3,0) -> (3,1) Right (3,1) -> (0,0) Right (3,B) -> (3,1) Right

Justification:
How the States for the Turing Machine are Written Programming for my Turing machine is written as simple text files on any computer and saved to SD cards. The states described in these text files are then loaded into and interpreted by the Turing machine. I use a fairly standard notation for describing the states: ( State Number, Symbol Read) -> ( Next State Number, Symbol To Write) Next Cell Each state normally consists of three rules, one for each of the three symbols (0, 1, blank) that can possibly be read from a cell. So the first rule in the following state sample tells the machine: If the machine is in state "1" and there is a zero in the cell, change this to a one, change to state "0", and move one cell to the left.
(1,0) -> (0,1) Left (1,1) -> (1,0) Left (1,B) -> (0,1) Right

The second rule tells the machine: If there is a one in the cell, change this to a zero, leave the state as "1", and move one cell to the left. The third rule tells the machine: If the cell is blank, change this to a one, change to state "0", and move one cell to the right. The only other rule you will see in the sample programs is the next cell move of "Halt".
(1,B) -> (0,1) Halt

This is just as it sounds, when this rule is followed the cell is changed from blank to one and the machine stops. Summary of The Examples: While I have taken some liberty with a number of terms and concepts, I hope you can see just how simple the rules that drive a Turing machine are. Changing ones to zeros, moving one cell to the left or right, these concepts are simple, yet they can compute anything that is computable. And from these simple concepts, the most complex computers of today are born.

LINEAR BOUND AUTOMATA

In computer science, a linear bounded automaton (plural linear bounded automata, abbreviated LBA) is a restricted form of nondeterministic Turing machine. Linear bounded automata satisfy the following three conditions: 1. Its input alphabet includes two special symbols, serving as left and right endmarkers. 2. Its transitions may not print other symbols over the end-markers. 3. Its transitions may neither move to the left of the left end-marker or to the right of the right end-marker.

As in the definition of Turing machines, it possesses a tape made up of cells that can contain symbols from a finite alphabet, a head that can read from or write to one cell on the tape at a time and can be moved, and a finite number of states. It differs from a Turing machine in that while the tape is initially considered to have unbounded length, only a finite contiguous portion of the tape, whose length is a linear function of the length of the initial input, can be accessed by the read/write head. Instead of having potentially infinite tape on which to compute, computation is restricted to the portion of the tape containing the input plus the two tape squares holding the end markers. Since the size of the accessible tape is bounded by some linear function of the length of the input, the linear bounded automaton is computationally equivalent to a nondeterministic Turing machine restricted to the portion of the tape containing the input, hence the name linear bounded automaton. This limitation makes the LBA a somewhat more accurate model of computers that actually exist than a Turing machine, whose definition assumes unlimited tape.

Applications of Linear Bound Automata

(1.) Genetic Programming:
GP is a child of the genetic algorithm (GA). The seminal work on GAs is Adaptation in natural and artificial systems . In outline, Gas work as follows. 1 Initialisation Generate an initial population at random. 2 Evaluation Compute the fitness of each individual in the population, which is a measure of how well it meets the requirements. 3 Breeding Breed a new population, favouring fitter individuals as parents. 4 Termination If the population contains an individual which meets the requirements, or if some other limit is reached, then stop. Otherwise continue from Step 2. For example, suppose we wish to design a roof truss in the form of a triangle with 2 braces on each side:

Roof truss

We can reasonably expect the truss to be symmetrical, so for a given height And width there are 4 variables, shown in the figure as a, b, c and d. These are real values within a limited range. We can thus represent any individual design by a real array of length 4, and an initial population of designs could easily be generated with a random number generator (RNG). An array of 4 reals permits designs where the braces cross each other or cross the centre of the truss. If we want to exclude these or similar possibilities, then a different representation might be necessary.

(2.) Parse Trees

The input to our algorithm is a set of strings, S, in an SEC q p language where the dimensionality, p, and degree, q, are known. S must contain at least all strings in the language up to a depth d (the value of d is discussed later). The shortest string in S is the concatenation of the elements in the axiom. However, there are multiple possibilities for what the actual axiom is (depending on the dimensionality of the language). From the shortest string, a set of possible

axioms, A, is generated. For example, if p=2 and the shortest string in S is aa, then the set of possible axioms is { (, aa), (a, a), (aa, ) } .

(3.) Emptiness Problem

Example:

PUSH-DOWN AUTOMATA
We discovered that finite automata were far too weak to even tell if an input string was of the form anbn. In this section we shall extend the power of finite automata a little so that we can decide membership in sets which cannot be accepted by finite automata. Let's begin. In fact, let's provide a finite automaton with a data structure which will allow it to recognize strings of the form a

Recognition Algorithm It is clear exactly what happens when the algorithm of figure 1 is used on the input aaabbb. The machine reads the a's and builds a pile of three discs. Then it reads the b's and removes the discs from the pile one by one as each b is read. At this point it has finished the input and its pile is empty so it accepts. If it was given aabbb, it would place two discs on the pile and then remove them as it read the first two b's. Then it would leave the second while loop with one b left to read (since the pile was empty) and thus not accept. For aaabb it would end with one disk on the pile and not accept that input either. When given the input string aabbab, the machine would finish the second loop with ab yet to be read

Applications of Push Down Automata

(1.) Online Transaction Processing system
In this work an attempt is made to model the on-line transaction processing system of a banking organization with timed automata. In Figure 2 the organization of the bank is depicted. It consists of multiple branches with multiple tellers at each branch.

The transactions that are performed represent the work done when a customer makes a deposit or a withdrawal. Transactions are handled by a database system, which considers them as concurrent processes. For each transaction there is a set of records, each one of which can be in a locked or unlocked state. The way the concurrent processes are processed by the database system is pictorially presented.

(2.) The UPPAAL tool

A simulation model is a model which is formulated by using arithmetic and algebraic relations along with non-mathematical logical processes. It consists of five major components: state variables, variables, functional relations, inputs and outputs. UPPAAL is a tool for modeling, simulating and verifying real-time systems. The tool is appropriate for systems that can be modeled as a collection of non-deterministic processes with finite control

structure and real-valued clocks, communicating through channels or shared variables. UPPAAL consists of three main parts: a description language, a simulator and a model-checker. An automaton contains location and transitions connecting the locations. In UPPAAL, time is modeled using clock variables. The timing constraints are attached to transitions or to the locations in the form of labels. A label can be a guard that expresses the conditions under which the transition can be performed. A transition can contain clocks, boolean variables, integer variables or synchronous channels. A system in UPPAAL consists of a collection of automata. These automata can communicate using the shared variables or the synchronous channels. The synchronization of two channels is indicated by the use of an exclamation mark (!) and a question mark(?). The ! at the end of the channel name indicates that the channel is used for sending. The ? is used to indicate that the channel receives. The label of a location consists of three parts: the name of the location, the option invariant and the option Committed or Urgent. The invariant indicates the period that the automaton can remain in the location.

(3.) Tower Of Hanoi (Recursive Solution)

(4.) The Timed Automata Model

In this work a model with three branches and different number of tellers is considered where some customers are served while others may arrive. A five automata model has been developed to describe the dynamic processing of transactions by the bank database system. These five automata have been

given the tag names OLTP, P0, Clock, P2 and P3. The OLTP is the basic automaton, which is synchronized with the others and is shown.

(5.) Determinsitic Top-Down Parsing and LL Grammars

The basic idea is simple: given the current input symbol and the current nonterminal symbol, usually pushed onto the stack, consult a parsing table, or, in the jargon of automata theory, a finite state transition function (the current state is the current non-terminal symbol), and replace the symbol on the stack with the proper right-hand side to continue simulating the derivation. See Fig. 5.9 for an illustration of this process. If the top of the stack is a terminal symbol and matches the input, then just pop that symbol and continue with the rest of the input string. A simplified process is given in the following algorithm.

Figure 5.9: Top-Down Parser as a PDA

(6.) Context-Free Languages

(7.) Predictive Bottom-Up Parsing and LR Grammars

If one does then introduce a new rule S' S and make S' the new start symbol. Bottom up methods are a little more involved in the theory of parsing. Consider, for example, the right derivation of the expression a + b*c:
E E+T E + T*F E + T*id F + b*c E + T*c id + b*c E + F*c a + b*c. E + id*c

E + b*c Example:

T + b*c

Predictive Parse of the expression a + b*c Stack Input Action $ a + b*c$ Shift id$ + b*c$ Reduce F$ + b*c$ Reduce T$ + b*c$ Reduce E$ + b*c$ Reduce + E$ b*c$ Shift b + E$ *c$ Shift id + E$ *c$ Reduce F + E$ *c$ Reduce T + E$ *c$ Reduce *T + E$ c$ Shift c*T + E$ $ Reduce id*T + E$ $ Reduce F*T + E$ $ Reduce T + E$ $ Reduce E$ $ Accept

(8.) Converting a PDA

In order to change the acceptance mode of a PDA one has to click on the menu entry Convert. As soon as some PDA has been selected the input le is checked for errors. If everything is ne a new window, lled with the information of

the chosen PDA, appears.

Converting a PDA

At next the user has to enter a new initial stack symbol, a new start state, and a new nal state. Note that these information are needed for both conversions (see Section 2.3). So it is irrelevant whether the given PDA should be converted into a

PDA that accepts by empty stack or by nal state. After that the user has to choose whether the given PDA accepts by empty stack or by nal state, by clicking on the button Accepts by Empty Stack or Accepts by Final State. If the rst button is selected, the given PDA is converted into a PDA that accepts by nal state. Otherwise a PDA that accepts by empty stack is constructed. As soon as one of those buttons is pressed the new PDA is displayed in the bottom of the window. Finally, via the Save button it is possible to store the created PDA.

FINITE AUTOMATA
Hardware applications:

The circuit diagram for a 4-bit TTLcounter, a type of state machine

In a digital circuit, an FSM may be built using a programmable logic device, a programmable logic controller, logic gates and flip flops or relays. More specifically, a hardware implementation requires a register to store state variables, a block of combinational logic which determines the state transition, and a second block of combinational logic that determines the output of an FSM. One of the classic hardware implementations is the Richards controller. Mealy and Moore machines produce logic with asynchronous output, because there is a propagation delay between the flip-flop and output. This causes slower operating frequencies in FSM. A Mealy or Moore machine can be convertible to a FSM which output is directly from a flip-flop, which makes the FSM run at higher frequencies. This kind of FSM is sometimes called Medvedev FSM.[9] A counter is the simplest form of this kind of FSM.
Software applications

The following concepts are commonly used to build software applications with finite state machines: Automata-based programming Event driven FSM Virtual FSM (VFSM)

Applications of Finite Automata

(1.) Automata-based programming / Finite State Programming
Automata-based programming is a programming paradigm in which the program or its part is thought of as a model of a finite state machine (FSM) or any other (often more complicated) formal automaton (see automata theory). Sometimes a potentially-infinite set of possible states is introduced, and such a set can have a complicated structure, not just an enumeration. FSM-based programming is generally the same, but, formally speaking, doesn't cover all possible variants as FSM stands for finite state machine andautomatabased programming doesn't necessarily employ FSMs in the strict sense. The following properties are key indicators for automata-based programming:

 The time period of the program's execution is clearly separated down to the steps of the automaton. Each of the steps is effectively an execution of a code section (same for all the steps), which has a single entry point. Such a section can be a function or other routine, or just a cycle body. The step section might be divided down to subsection to be executed depending on different states, although this is not necessary. Any communication between the steps is only possible via the explicitly noted set of variables named the state. Between any two steps, the program (or its part created using the automata-based technique) cannot have implicit components of its state, such as local (stack) variables' values, return addresses, the current instruction pointer etc. That is, the state of the whole program, taken at any two moments of entering the step of the automaton, can only differ in the values of the variables being considered as the state of the automaton.

Example:
Traditional (imperative) program in C
The program which solves the example task in traditional (imperative) style can look something like this: #include <stdio.h> int main(void) { int c; do { c = getchar(); while(c == ' ') c = getchar(); while(c != EOF && c != ' ' && c != '\n') { putchar(c); c = getchar(); } putchar('\n'); while(c != EOF && c != '\n') c = getchar(); } while(c != EOF); return 0; }

Automata-based style program (FSP)

The same task can be solved by thinking in terms of finite state machines. Note that line parsing has three stages: skipping the leading spaces, printing the word and skipping the trailing characters. Let's call them states before, inside and after. The program may now look like this: #include <stdio.h> int main(void) { enum states { before, inside, after } state; int c; state = before; while((c = getchar()) != EOF) { switch(state) { case before: if(c == '\n') { putchar('\n'); } else if(c != ' ') { putchar(c); state = inside; } break; case inside: switch(c) { case ' ': state = after; break; case '\n': putchar('\n'); state = before; break; default: putchar(c); } break; case after: if(c == '\n') { putchar('\n'); state = before; } } } return 0; }

Although the code now looks longer, it has at least one significant advantage: there's only one reading (that is, call to the getchar() function) instruction in the

program. Besides that, there's only one loop instead of the four the previous versions had. In this program, the body of the while loop is the automaton step, and the loop itself is the cycle of the automaton's work.

The program implements (models) the work of a finite state machine shown on the picture. The N denotes the end of line character, the S denotes spaces, and the A stands for all the other characters. The automaton follows exactly one arrow on each step depending on the current state and the encountered character. Some state switches are accompanied with printing the character; such arrows are marked with asterisks.

(2.) Event driven finite state machine

In computation, a finite-state machine (FSM) is event driven if the transition from one state to another is triggered by an event or a message. This is in contrast to the parsing-theory origins of the term finite-state machine where the machine is described as consuming characters or tokens. Often these machines are implemented as threads or processes communicating with one another as part of a larger application. For example, a telecommunication protocol is most of the time implemented as an event-driven finite-state machine.

(3.) Virtual Finite State Machine

A virtual finite state machine is a finite state machine (FSM) defined in a virtual environment. The VFSM concept provides a software specification method to describe the behaviour of a control system using assigned names of input control properties and of output actions.

The VFSM method introduces an execution model and facilitates the idea of an executable specification. This technology is mainly used in complex machine control, instrumentation and telecommunication applications.

(4.) A DFA-based Text Filter in Java

The first thing to deal with is the input alphabet. The DFA above uses the alphabet 0, 1, which is the alphabet of interest for this problem. But the program will work with a typed input string, so we do not have the luxury of restricting the alphabet in this way. The program should accept 011 (a representation for the number 3) and reject 101 (a representation for the number 5), but it must also properly reject strings like 01i and fred. The alphabet for the Java implementation must be the whole set of characters that can occur in a Java stringthat is, the whole set of values making up the Java char type. The DFA we actually implement will have four states, like this:

(5.) Acceptors and recognizers

Acceptors and recognizers (also sequence detectors) produce a binary output, saying either yes or no to answer whether the input is accepted by the machine or not. All states of the FSM are said to be either accepting or not accepting. At the time when all input is processed, if the current state is an accepting state, the input is accepted; otherwise it is rejected. As a rule the input are symbols (characters);

actions are not used. The example in figure 2 shows a finite state machine which accepts the word nice. In this FSM the only accepting state is number 7.The machine can also be described as defining a language, which would contain every word accepted by the machine but none of the rejected ones; we say then that the language is accepted by the machine. By definition, the languages accepted by FSMs are the regular languages - that is, a language is regular if there is some FSM that accepts it. Start state The start state is usually shown drawn with an arrow pointing at it from anywhere Accept state An accept state (sometimes referred to as an accepting state) is a state at which the machine has successfully performed its procedure. It is usually represented by a double circle. An example of an accepting state appears on the right in this diagram of a deterministic finite automaton (DFA) which determines if the binary input 4 contains an even number of 0s. S1 (which is also the start state) indicates the state at which an even number of 0s has been input and is therefore defined as an accepting state. This machine will give a correct end state if the binary number contains an even number of zeros including a string with no zeros. Examples of strings accepted by this DFA are epsilon (the empty string), 1, 11, 11..., 00, 010, 1010,10110 and so on.

(6.) Transducers
Transducers generate output based on a given input and/or a state using actions. They are used for control applications and in the field of computational linguistics. Here two types are distinguished: Moore machine The FSM uses only entry actions, i.e. output depends only on the state. The advantage of the Moore model is a simplification of the behaviour. Consider an elevator door. The state machine recognizes two commands command open and command close which trigger state changes. The entry action (E:) in state Opening starts a motor opening the door, the entry action in state Closing starts a motor in the other direction closing the door. States Opened and Closed dont perform any actions. They signal to the outside world (e.g., to other state machines) the situation: door is open or door is closed.

Mealy machine The FSM uses only input actions, i.e., output depends on input and state. The use of a Mealy FSM leads often to a reduction of the number of states. The example in figure 4 shows a Mealy FSM implementing the same behaviour as in the Moore example (the behaviour depends on the implemented FSM execution model and will work, e.g., for virtual FSM but not for event driven FSM). There are two input actions (I:): start motor to close the door if command close arrives and start motor in the other direction to open the door if command open arrives. The opening and closing intermediate states are not shown.

(7.) UML state machines

The Unified Modeling Language has a very rich semantics and notation for describing state machines. UML state machines overcome the limitations of traditional finite state machines while retaining their main benefits. UML state machines introduce the new concepts of hierarchically nested states and orthogonal regions, while extending the notion of actions. UML state machines have the characteristics of both Mealy machines and Moore machines. They support actions that depend on both the state of the system and the triggering event, as in Mealy machines, as well as entry and exit actions, which are associated with states rather than transitions, as in Moore machines.UML state machine example (a toaster oven)

(8.) Hardware applications

1. From the network management perspective (the access provider):
It may be interested on grabbing usual information which would be interesting to improve long term relationship with the user; It may collect information about the handovers of a user and relate them with positioning information; It may correlate information about routes and timing of accesses.

2. From the content provider perspective:

It may adapt the delivery of media to specifics of devices, location, timing,

type of user, etc It can understand the criteria by which the user chooses the access providers; It can explore the contextual information to add value to the content (advertisement, linking to 3rd party products, etc); As the user has the control over the mobility aspects, the access provider can focus on providing better and more varied services[4]; It can provide brokerage services based on the common information available.

3. From the user perspective:

It can choose the provider based upon several criteria:

Best price Better response Best matching to his/her requirements Economy (use a home user-owned WLAN, during a traffic jam) It can use contextual information to adapt the user device profile of usage: Power management (CPU, memory, display, network interface) Streaming control (proximity to known blind spots such as tunnels) Optimization of content delivery to a new profile, on vertical handovers with a lower bandwidth provider.

(9.) FSM real time application scenario:

One possible way to implement finite state machines is to have a controller of some type which acts as switch box. When the thread of execution swings around to execute code of the FSM, it is pointed at the controller which evaluates or determines the current state, usually through the use of a switch (case) statement or if-then-else statements. Once the current state is determined, the code for that state is executed, actions performed and possibly state transitions for the next time the FSM is executed. The controller may be a simple switch statement evaluating an integer, but an implementation may see the controller performing some pre-processing of inputs and triggering of state transitions before-hand.

Figure 3.1: A FSM implementation where the controller acts as a switch box to determine which state to run. The red line denotes the thread of execution.

We started out with a definition of finite state machine, learning that it can be used as a control technique for a system, describing states or behaviors of that system, and defining rules or conditions that govern transitions from the systems current state to another state. Section one showed that a finite state machine is considered to be deterministic which means its actions are easily predictable. A number of extensions to finite state machines such as random selection of transitions, and fuzzy state machines shows us another common type of FSM called non-determinist where the systems actions were not as predictable, giving a better appearance of intelligence.

(10.) FSM real time application scenario (2):

A finite state machine isn't a crazy type of machine. A finite state machine is one way to write programs. A finite state machine is usually just called a FSM A FSM is made up of two things. First, it has some writing about what's happening. Then, it has some arrows that show different choices you can make. You should make a choice and follow the arrow.

FSMs are good for making games and stories. Here is one game where you have to find some treasure. First, go to Start. Then, you just follow the arrows until you get to the end.

Here is a simpler FSM that lets you explore the rooms of a house.

Let's try making a program that lets you explore the house. First, number all of the rooms.

Now we'll start programming. When programming a FSM, you need the computer to know which room you are in. You should start in room 1.

The computer should tell you something different depending on which room you are in.

The computer should also ask you where you want to go. The computer should then change the room number depending on your answer.

After your room has changed, the computer should go back to the beginning and tell you about the new room. You can use a loop for this.

That's it! You can run the program now. You will be able to move through the different rooms.

Try taking the FSM for the treasure game and programming it into the computer. Then, try making your own FSM game.

Conclusion:
Finite state machines represent a very powerful way of describing and implementing the control logic for applications. I have used them to implement communication protocols, to control the interactions in a GUI, and many many other applications. FSMs are powerful because they are a very dense representation. A lot of logic can be represented by a relatively small diagram. They are powerful because they follow very simple rules, and are easy to verify. And they are powerful because they can be used to generate code.

CONCLUSION
We started out with a definition of finite state machine, learning that it can be used as a control technique for a system, describing states or behaviors of that system, and defining rules or conditions that govern transitions from the systems current state to another state. Section one showed that a finite state machine is considered to be deterministic which means its actions are easily predictable. A number of extensions to finite state machines such as random selection of transitions, and fuzzy state machines shows us another common type of FSM called non-determinist where the systems actions were not as predictable, giving a better appearance of intelligence. Next we took a close look at a simple real world implementation and learned how a rocket projectile could be modeled using FSM. This lead us to a more advanced example where we saw the behavior of a semi-intelligent monster modeled using a combination of hierarchical finite state machines and the use of goals as a primary motivator. This showed us a real implementation of a non-deterministic finite state machine where the monsters "melee attack" state was selected using a combination of inputs and a randomly generated number. Finally we took a broader look at the Quake computer game implementation and examined the framework used to support the monsters that populate the games single player experience. We learned how a polymorphic approach was used for the execution of a monsters "current state" and that input events were also processed using polymorphism allowing any entity finite state machines actions to directly effect entities. We saw how a simple framework that supported a variety of state machines could be considered a simple multi-agent system where each individual state machine simple had to plug in relevant monster specific code into the framework. Finite state machines are a simple and effective artificial intelligence technique for controlling a system and providing the appearance of intelligence. We learned that that the perceived appearance of intelligence is more important than actual intelligence, and that finite state machines are able to provide this perception. This was proven through practical analysis of a computer game, which is a very unforgiving domain when it comes to quality of both product and game playing experience.