Project 2 - Finite Automata Interpreter

Introduction

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

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

• Your Ruby program - fa.rb
• Public test
  • public_1.in
  • public_2.in
  • public_3.in
  • public_4.in
  • public_5.in
  • public_6.in
  • public_7.in
  • public_8.in
• Expected outputs for public tests
  • public_1.out
  • public_2.out
  • public_3.out
  • public_4.out
  • public_5.out
  • public_6.out
  • public_7.out
  • public_8.out

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

Example

a
b
.
PRINT
SIZE
c
|
*
DONE

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)
% }

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

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

NFA	Figure
ab
a|b
a*

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

Part 4: Minimizing DFA

Submission

• 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 p2.zip, 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