CMSC 330, Spring 2012

Organization of Programming Languages

Project 2 - Finite Automata Interpreter

Due 11:59pm Thu, Mar 1st, 2012 (extended to Sat, Mar 3rd)


You will need to implement code to build up NFAs, convert them to DFAs, minimize DFAs, and test whether a string is accepted by a DFA. You will do this by extending a provided FiniteAutomaton class that operates as part of a simple interpreter.

Getting Started

Download the following archive file and extract its contents.

Along with files used to make direct submissions to the submit server (submit.jar, .submit, submit.rb), you will find the following project files:

To test your FiniteAutomaton implementation, you can execute it on input files from the command line by typing commands like ruby fa.rb < When you compare your output to the output in files like public_1.out, be aware that for full credit you only need to match lines that do not begin with %; these lines are effectively comments to the grading script. Nevertheless, this output should help you debug your implementation, to make sure you are constructing automata that have the right number of states, transitions, etc. even if the state names differ.

The fa.rb file you downloaded already implements a simple interpreter for commands to build/transform finite automata, print out various properties about them (such as the number of states they have, or the strings they accept), and use them to accept/reject particular strings. The interpreter operates using a stack, where each object on the stack is a finite automaton. Commands pop zero, one, or two finite automata from the stack and push zero or one finite automata on stack as a result, along with potentially printing output. Each command is separated by a whitespace: there is nothing special about line breaks. The interpreter (implemented in top-level function interpreter) works by creating new FiniteAutomaton objects and invoking methods on them.

The interpreter will accept the following commands:

  • symbol where symbol is a lowercase letter or the uppercase E. In the former case this command creates finite automaton that accepts just that letter, and in the latter case it creates an automaton that accepts the empty string. The new automaton is pushed onto the stack.
  • . pops off top 2 finite automata on the stack and creates a new NFA representing their concatenation, pushing this new NFA on to the stack
  • | pops off top 2 finite automaton on stack, creates a new NFA representing their union, pushing this new NFA on to the stack
  • * pops off top finite automaton on stack, creates a new NFA representing its closure, pushing this new NFA on to the stack
  • SIZE prints # of states in the finite automaton at the top of the stack (without popping it off)
  • PRINT prints the finite automaton at the top of the stack (without popping it off). All output from this command is preceded by %
  • DFA converts finite automaton (DFA or NFA) at the top of the stack to a DFA
  • MINIMIZE minimizes the finite automaton (must be a DFA) at the top of the stack
  • "str" decides whether finite automaton (must be a DFA) at the top of the stack accepts or rejects string str
  • GENSTR# prints all strings accepted by finite automaton (must be a DFA) at the top of the stack of length # or less
  • DONE interpreter exits


Here is an example session with the interpreter:
The first line creates an FA that accepts exactly the string a, and pushes it on the stack. The second line creates an FA that accepts exactly the string b, and pushes it on the stack. The third line pops these two automata off of the stack, and constructs a new automaton that accepts the concatenation of strings accepted by the two, i.e., ab. This new automaton is pushed back on the stack, and is now the only automaton on the stack.

The next command prints out this automaton (leaving it on the stack), producing output like the following:

% Start 0
% Final { 3 }
% States { 0 1 2 3 }
% Alphabet { a b }
% Transitions {
%  (0 a 1)
%  (1  2)
%  (2 b 3)
% }
Note that different implementations might produce different output in this case, most notably because they could choose different names for states.

The next command prints the number of states in the topmost automaton (leaving it on-stack), in this case 4. The next command constructs an automaton that accepts the string c and pushes it on-stack. The subsequent command pops off this automaton and combines with the the ab automaton also on-stack to produce the automaton implementing ab|c, pushing it on-stack. The next command creates a new automaton from this one, implementing (ab|c)*. The final command terminates the session.

As mentioned, linebreaks are immaterial. Exactly the same results would be produced by the input

a b . PRINT SIZE c | * DONE

Part 1: Extend the FiniteAutomaton class to support NFAs

The FiniteAutomaton class in fa.rb is based on the DFA class used as an example during discussion section. The original DFA class is able to represent DFAs and run them to determine whether input strings are accepted by the DFA. You need to decide how to change/extend this FiniteAutomaton class to represent both NFAs and DFAs. In particular, your modified class should support additional features allowed by NFAs, such as epsilon-transitions and multiple transitions with the same label. You may choose to represent epsilon-transitions as transitions labeled with the empty string "" (as we do in our reference implementation used to produce the sample public outputs) or some other label.

If an automaton is deterministic (i.e., it represents a DFA), it should be able to run on input strings input strings; i.e., the accept? method should return true if your FiniteAutomaton object is actually a DFA and it accepts the string; the accept? method returns false otherwise (that is, if the automaton is actually an NFA, or if it does not accept the string).

Part 2: Building NFAs out of other NFAs

The symbol! method for creating a new NFA for an individual symbol is provided. You need to add the ability to construct more complex NFAs from these single-symbol NFAs. Three of the commands of the interpreter require the ability to create new NFA from existing NFA, using one of the following actions: concatenate, union, and closure. You need to implement the same functionality for NFAs represented by the FiniteAutomaton class in the methods concat! union! closure!. You must construct the new NFA using the algorithm discussed in lecture. In particular, given two NFA a and b as follows:
You should be able to use the algorithm described in class to create a single NFA representing:




Note that though there are other algorithms for generating correct NFA for these operations, using them will yield a different NFA that will not pass the submit server tests. Your methods may (destructively) modify the current NFAs a and b. You can assume there is only one start state for each NFA.

Part 3: Reducing NFA to DFA

Once you have a NFA, invoking the toDFA method should create a new finite automaton representing a DFA created by the subset reduction method presented in class. I.e., the method should return a new FiniteAutomaton object that will accept only the strings accepted by the current FiniteAutomaton object, but which does not have epsilon-transitions or multiple transitions from a state with the same label.

Part 4: Minimizing DFA

Once you have a DFA, invoking the minimize method should create and return a new finite automaton representing a minimal DFA accepting the same language. You can either create a new DFA or (destructively) modify the existing FiniteAutomaton object on which mimimize is called; in either case you need to return the minimized DFA. You may assume that the minimize method will not be invoked on a NFA, but only the DFAs created by the toDFA method. As a result you do not need to handle dead states (since if you implemented the previous parts of the project correctly, these DFAs will not have dead states).


You can submit your project in two ways:
  • Submit your fa.rb file directly to the submit server by clicking on the submit link in the column "web submission".

    Next, use the submit dialog to submit your fa.rb file directly.

    Select your file using the "Browse" button, then press the "Submit project!" button. You do not need to put it in a Jar or Zip file. Some students have mentioned problems with using Internet Explorer, because submissions being extracted in directories (e.g., "C:\My Documents\330\fa.rb") where the submit server could not find them. The problems went away when switching to the Mozilla Firefox browser.

  • Submit directly by executing a Java program on a computer with Java and network access. Use the submit.jar file from the archive, To submit, go to the directory containing your project, then either execute submit.rb or type the following command directly:

    java -jar submit.jar

    You will be asked to enter your class account and password, then all files in the directory (and its subdirectories) will be put in a jar file and submitted to the submit server. If your submission is successful you will see the message:

    Successful submission # received for project 2

Hints and Tips

  • Be sure you have read and understand the project grading policies in the course syllabus. Do this well in advance of the project due date.

    Academic Integrity

    The Campus Senate has adopted a policy asking students to include the following statement on each assignment in every course: "I pledge on my honor that I have not given or received any unauthorized assistance on this assignment." Consequently your program is requested to contain this pledge in a comment near the top.

    Please carefully read the academic honesty section of the course syllabus. Any evidence of impermissible cooperation on projects, use of disallowed materials or resources, or unauthorized use of computer accounts, will be submitted to the Student Honor Council, which could result in an XF for the course, or suspension or expulsion from the University. Be sure you understand what you are and what you are not permitted to do in regards to academic integrity when it comes to project assignments. These policies apply to all students, and the Student Honor Council does not consider lack of knowledge of the policies to be a defense for violating them. Full information is found in the course syllabus---please review it at this time.

  • Web Accessibility