go to previous page   go to home page   go to next page


    fsa.addTrans( 0, 'a', 1 );
    fsa.addTrans( 1, 'b', 1 );
    fsa.addTrans( 1, 'c', 2 );
    fsa.addTrans( 2, 'd', 0 ); 

Advantages and Disadvantages

It is easy to implement automata with this table-driven framework. All you need to do is call methods to set up the tables. You could even have the program query the user about the transitions and final states, or read this information from a text file. (This would make a good programming exercise.) Better yet, the program could ask the user for a regular expression and then compile it into table entries. (This would be a very challenging programming exercise.)

However, in practice, for most string recognition tasks you should use the regular expression classes that come with Java. See the following chapters. (These classes themselves were almost certainly written using a table-driven approach.)

If you wish to implement a transducer, or deal with input other than character strings, the table-driven approach may be awkward to use. The type of implementation explained in sections two and three may be better.

A way to deal with these difficulties is to use features of object oriented programming. Define classes State, Transition, TransitionTable, and Input. The table object would contain transition objects (complete with transducer methods), indexed by state and input objects. But for many problems, simple automata are all you need, and simple programs can easily implement them.


(Though Question: ) Could a one-character pushback automaton be implemented in table-driven fashion?