A Formal Model of Computation

We’ve spent some time building an intuition for finite automata through state diagrams. Now, it’s time to put this on a solid mathematical foundation. Why? Because if we want to prove things about the limits of what these machines can do, we need a precise, unambiguous definition.

Historically, it’s interesting to note that the more powerful Turing Machine was formalized before the simpler finite automaton. However, starting with automata is a fantastic way to learn the vocabulary and mechanics of formal models. We can zoom in and see exactly what it means to “compute” in a very constrained world.

Definition: Deterministic Finite Automaton (DFA)

A Deterministic Finite Automaton (DFA) is a mathematical object that we can define as a 5-tuple (a quintuple). We’ll call our automaton :

Let’s break down these five components.

  1. : The Set of States This is a finite, non-empty set of states. In our diagrams, these are the circles. The finiteness of is the most crucial, and limiting, feature of this model. Unlike a Turing machine with its infinite tape, a DFA can only store a finite amount of information, determined by which of its states it is currently in.

  2. : The Input Alphabet This is a finite set of symbols that the automaton can read. The input words are strings from .

  3. : The Start State This is one special state from where every computation begins. In diagrams, we mark it with an incoming arrow.

  4. : The Set of Accepting States This is a subset of the states. If the automaton finishes reading the input word and is in one of these states, the word is accepted. In diagrams, we mark them with a double circle. Note that can be empty, though such an automaton wouldn’t be very interesting.

  5. : The Transition Function This is the “program” of the automaton. It’s a function that takes the current state and the next input symbol and returns the next state.

    For example, means “if in state and you read a 1, transition to state .” The fact that is a function is what makes the automaton deterministic: for any given state and input symbol, there is exactly one, unambiguous next state. This implies two rules for our diagrams:

    • For every state, there must be exactly one outgoing arrow for every symbol in the alphabet .
    • You cannot have two arrows leaving the same state with the same label.

How an Automaton Computes

Now that we have the static definition, let’s formalize the dynamic process of computation.

Configurations

A configuration is a snapshot of the automaton’s state at any point during a computation. It captures everything we need to know to continue:

  1. The current state the automaton is in.
  2. The remaining part of the input word that still needs to be read.

A configuration is a pair where and .

  • Start Configuration: For an input word , the computation always begins in the configuration .
  • End Configuration: Any configuration where the remaining word is empty is an end configuration. It looks like for some state .

Steps and Computations

A step is the process of moving from one configuration to the next. We use the notation to represent a single step.

This means we transition from configuration to . This step is valid if and only if:

  1. is a single symbol from .
  2. is the rest of the input string.
  3. The transition function dictates this move: .

A computation is a sequence of steps starting from the start configuration. We use for the reflexive, transitive closure of the step relation, meaning “can reach in zero or more steps.”

The Language of an Automaton

We can now formally define the language accepted by a DFA.

The language accepted by an automaton , denoted , is the set of all input words for which the computation of on starts in the initial configuration and ends in a configuration with an accepting state.

The Extended Transition Function

It’s often cumbersome to talk about sequences of steps. We can extend the transition function to a new function, , that works on entire words instead of single symbols.

tells us which state we land in after starting at state and reading the entire word . It’s defined inductively:

  1. Base Case: Reading the empty word doesn’t change the state.
  2. Inductive Step: To read a word (a word followed by a symbol ), we first see where takes us, and then apply the original for the final symbol .

Using this, we can write a much cleaner definition for the language of an automaton:

The Class of Regular Languages

We can now define a fundamental class of languages.

The class of regular languages, denoted by the calligraphic , is the set of all languages for which a Deterministic Finite Automaton exists.

The name “regular” is no coincidence. It turns out that this class of languages is precisely the same class that can be described by regular expressions. One can prove that for any regular expression, you can build a DFA that accepts the same language, and for any DFA, you can derive an equivalent regular expression.

Proving an Automaton Correct: The Method of State Classes

How can we be certain that an automaton we’ve designed accepts the correct language? We need a formal proof technique. The most powerful method is to define the class of each state.

The class of a state , denoted , is the set of all words that drive the automaton from the start state to state .

These classes have two crucial properties that stem from the deterministic nature of the automaton:

  1. They cover all strings: Every word must end up in exactly one state, so the union of all state classes is .
  2. They are disjoint: A single word cannot end in two different states.

Together, these mean that the state classes form a partition of .

The language of the automaton is then simply the union of the classes of its accepting states:

Example: Proving the Parity Checker Correct

Let’s formally prove that our parity automaton accepts all strings of even length.

Claim: The classes of the states are:

Proof by Induction on Word Length

  • Base Case (): The only word is . It has zero 0s and zero 1s (both even). The automaton starts and ends in . So . The claim holds.

  • Inductive Step: Assume the claim holds for all words of length . Let be a word of length . We can write , where and is a single symbol. By the inductive hypothesis, we know is in the correct class based on its parity counts. We must check all 8 cases (4 states for , 2 choices for ). Let’s do one:

    • Suppose (even 0s, even 1s) and . The word has an odd number of 0s and an even number of 1s. Our claim says should be in . Does the automaton agree? From state , reading a 0 transitions to . Yes, it matches.

By checking all 8 cases, we can confirm the claim is correct.

Conclusion: The accepting states are . The language is .

  • Words in have (even 0s + even 1s) even total length.
  • Words in have (odd 0s + odd 1s) even total length. Therefore, is the language of all binary strings of even length.

Building an Automaton: A Worked Example

Let’s design a DFA for the following language:

The language consists of words with exactly three 0s AND either at least two 1s OR exactly zero 1s.

The key to tackling such a problem is to realize that the automaton must track the counts of 0s and 1s simultaneously. We can imagine a grid of states, where each state represents a pair of counts seen so far.

  • The number of 0s can be 0, 1, 2, 3, or "" (more than 3). This gives us 5 conditions to track vertically.
  • The number of 1s can be 0, 1, or "". This gives us 3 conditions to track horizontally.

This conceptual grid forms the structure of our automaton. Each state will represent having seen zeros and ones.

Let’s analyze the structure of this state diagram:

  • Rows: The rows count the number of 1s.
    • Top row: We have seen zero 1s.
    • Middle row: We have seen exactly one 1.
    • Bottom row: We have seen two or more 1s.
  • Columns: The columns count the number of 0s.
    • First column: Zero 0s.
    • Second column: One 0.
    • Third column: Two 0s.
    • Fourth column: Exactly three 0s.
    • Fifth column: More than three 0s (a “trap” column).

Transitions:

  • Reading a 0 moves us one step to the right within the same row (increasing the 0 count).
  • Reading a 1 moves us one step down within the same column (increasing the 1 count).

Special States:

  • Start State: The top-left state, , represents having seen zero 0s and zero 1s.
  • Trap States: The rightmost column represents having seen more than three 0s. Once we enter this column, we can never leave, because the condition can no longer be met.
  • Loops: The bottom row represents having seen two or more 1s. Since the condition is , reading more 1s doesn’t change the satisfaction of this condition, so we loop on 1s in this row. Similarly, we loop on 0s in the rightmost column.

Accepting States: To be accepted, a word must end in a state that satisfies both conditions.

  1. The 0s condition: . This means we must be in the fourth column.
  2. The 1s condition: OR . This means we must be in the top row OR the bottom row.

The states that satisfy both are the intersection of these requirements:

  • (top row, fourth column)
  • (bottom row, fourth column)

These are marked with double circles in the diagram.

State Minimization (A Quick Look)

One might notice that the three states in the rightmost “trap” column are functionally identical: once entered, they are non-accepting and can never be left. We could simplify the automaton by merging these three states into a single “trap” or “garbage” state ().

(Note: This is a conceptual simplification; the original diagram is also a valid and correct DFA for the language.)

Defining the State Classes

To formally prove this automaton is correct, we would define the class for each state. Let’s name the states where is the count of 0s and is the count of 1s.

  • For and :
  • For the “at least” states:
  • For the trap states: (and similarly for )

The language of the automaton is the union of the classes of the accepting states:

This precisely matches the formal definition of our target language.

Defining State Classes for the Infix Automaton

A typical exam question would be not only to design such an automaton but also to formally define the class of each state, that is, to describe precisely which words land you in which state. Let’s do this for the automaton we just built.

The key is to remember what each state represents: the longest suffix of the word seen so far that is also a prefix of our target pattern, AABA.

  • The Accepting State: This one is straightforward. The only way to land in the accepting state is to have successfully found the infix AABA. Once there, we never leave. Therefore, the class of this state is simply the language itself.

  • The “Almost There” State: This is the class of all words that have put us on the brink of success.

    We must explicitly exclude the words that are already in . For example, the word AABAAB ends in AAB, but it also contains AABA, so it would be in , not here.

  • The “Two As” State: These are words where the longest relevant suffix is AA.

    We must exclude words that have an even longer relevant suffix, like AAB.

  • The “Single A” State: These are words where the longest relevant suffix is just a single A.

  • The Start State: This class contains everything else. These are the words that do not contain the AABA infix and do not end in A, AA, or AAB.

    This includes words that end in B, like BB or ABAB, and the empty word .

This completes the formal analysis of our automaton. We have not only designed a machine to solve the problem but have also rigorously defined what each component of the machine is “thinking” at every step of the computation.

Continue here: 07 Combining Automata and Proving Non-Regularity