\documentclass[twoside,titlepage]{report}

\usepackage{fullpage}
\usepackage{graphicx}
\usepackage{verbatim}
\usepackage{wrapfig}

\title{Mx: A programming language for scientific computation}

\author{
\begin{tabular}{cccc}
Tiantian Zhou \thanks{Tiantian Zhou is a second-year Ph.D student 
of the Department of Computer Science.}
& Hanhua Feng \thanks{Hanhua Feng is a first-year Ph.D student of
the Department of Computer Science.}
& Yong Man Ra 
& Chang Woo Lee \thanks{Yong Man Ra and Chang Woo Lee are senior undergraduate
students of the Fu Foundation School of Engineering and Applied
Science.}
\\
\multicolumn{4}{c}{\{tz2002, hf2048, yr86, cl588\}@columbia.edu}
\end{tabular}
}

\begin{document}
\maketitle
\pagenumbering{Roman}
\tableofcontents

\chapter{Introduction}
\pagenumbering{arabic}
\setcounter{page}{1}

In this project, we have designed and implemented a programming language, Mx,
designated to scientific computations.

\section{Background}

For the past fifty years, the demands for high-performance scientific
computations have been pushing various computer technologies.  Among
them, programming languages that are more efficient, more convenient,
and more natural to scientific computations have also been developed.
Unfortunately, their progress is more or less lagged behind other
computer technologies.

Fortran is one of the first-generation programming languages, which has
created many irreplaceable scientific packages.  Although there were
many other generations of Fortran standards, the backward compatibility
constantly hindered its development.  Fortran can hardly keep up
with the development of modern programming language and software
engineering techniques, modern computer hardware architecture, or even
the needs for mathematical efficiency and conveniences.  Meanwhile,
the progress of computer science in recent years is essentially
dominated by the industry of information technologies, where the
market of scientific computations is too small to be seen.
Universities no longer implement Fortran so that the population of Fortran
programmer becomes less and less.

Scientific investigators have to attempt other possible alternatives.
When they choose a programming language for their projects, they would
take these issues into account: (1) suitable and efficient for
scientific computation, (2) easy to learn (better be the language they
have learned in class), and (3) popularity, so that their programs
would not easily get out-dated, particularly for lack of maintainers.
Unfortunately, these requisites can be hardly satisfied
simultaneously.  Some people choose to use those popular languages
that are not designated for scientific computations, and have to do
lots of unnecessary and tedious work in order to implement relatively
simple mathematical formulas, while other people use non-standardized
languages, which are included in some popular commercial software
packages.  The languages in Matlab\cite{matlab} and IDL\cite{idl} are historically
satisfactory, but the down-side is that the programs written by these
languages would be affected by the economical status of their vendors,
which is in turn doomed probably by the market size of these software
packages.

Under this circumstance we present our programming language, Mx, as a
small trial in design and implementation of programming languages for
scientific computations.

\section{Related works}

Matlab by Mathworks is probably the most popular commercial language
(or rather to say, software) of this kind nowadays. Another choice is
IDL, which is developed by Research Systems Inc., a Kodak
company. There are some other related softwares such as
Maple\cite{maple}, Mathcad\cite{mathcad}, and
Mathematica\cite{mathematica}.  Some of them can do (or focus on)
symbolic computations.

Invented by Kenneth E. Iverson, who received the Turing Award of 1980
for this reason, APL is a language trying to imitate standard
mathematical notations, using hundreds of different ``primitives''
which are hard to be typed by an ordinary keyboard.

Many open-sourced numerical tools are also available.  GNU
Octave\cite{octave} is a general numerical interactive language,
originally developed for solving chemical reactor design problems.
Scilab\cite{scilab} is another free numerical tool similar to Matlab.

There are a lot of libraries written in C++, trying to make use of
object-oriented and operator overloading techniques to implement
direct matrix/vector operations by arithmetic operators \cite{oon}.
Some of them go even further: by using Blitz++\cite{blitz} the C++
compiler reportedly generates much better binary code than a Fortran
compiler can.  Another project is POOMA\cite{pooma}, which is
focused on parallel computing.  

For Java programmers working with matrix operations and mathematics,
there are two packages publicly available on the Internet.  The first
is java.vecmath\cite{vecmath}, a supportive part of Java 2D graphics
package.  The second is Jama\cite{jama}, developed by NIST with the
help of Mathworks.  The development of Jama has been ceased for years.
Both of them have limited functions.  As we can see in the later
chapters, along with this project, we developed another Java Matrix
Class (Jamaica), which provides a lot of functions that is not present
in those previously mentioned Java matrix packages.

Java does not support operator overloading, so it is not possible to
do matrix/vector operations by directly using arithmetic operators
with these matrix classes.  However, investigators are trying to add
operator overloading into Java as well as some other features, in
order to make the language more suitable to high-performance
scientific computing.  Titanium\cite{titanium} is such a project led
by computer scientists in UC Berkeley.

Besides those basic matrix/vector operations, there are many advanced
frequently-used matrix algorithm in linear algebra and matrix theory.
Unfortunately there are little choices of implementations: even Matlab
and IDL cannot build their own.  Matlab currently uses
LAPACK\cite{lapack} and IDL uses algorithms in Numerical Recipe
(NR)\cite{nr}.  Both LAPACK (and its relatives) and NR were originally
written in Fortran.  LAPACK can be translated to C by f2c\cite{f2c},
and Numerical Recipe in C was probably translated from Fortran by hand.
Algorithms in NR is said to be weak in efficiency and precision
\cite{nrprob} in part because those algorithms were originally implemented
with single-precision float numbers.

\section{Goal}

The main goal of our language is to implement and achieve a simple and
ease-of-use programming language for numerical computations.  The
programmer of our language can do matrix operations directly by
arithmetic operators such as '$+$', '$-$' and '$*$', as well as other
frequently-used symbols.  Moreover, this language also provided 
many internal functions for data manipulations, especially plotting
and painting functions.

\subsection{Portability}

Our language will run on various platforms.  For portability we will
use ANTLR\cite{antlr} as the syntax recognizer, which is running on a
Java virtual machine(VM).  The current version of our language will be
interpreted and executed, by a pure java interpreter.  With the help
of the portability of Java programming language, Mx can be virtually
run on any machine (including PDA's, hopefully).

\subsection{Efficiency}

Efficiency is always one of the most important evaluations of a
programming language for scientific computing.  There are two aspects
of efficiency: the execution efficiency, and the programming
efficiency.  Because Java itself is not so efficient as we might
expect in scientific computation, and also because our programming
language is currently interpretive, the execution efficiency is not
very applausable.  To reduce interpretive inefficiency, the user of
our programming language can use matrix operations instead of
entry-wise operations.

However, Mx greatly improves the programming efficiency.  For many
scientific computational needs, especially those in which many matrix
and vector operations are involved, the program written by Mx is very
short, as we can see in examples given in the next chapter.

\subsection{Ease-of-use}

The language will be simple and quick-to-start.  Only basic and
necessary language features would be included in the language
specification.  Meanwhile, most of the needs in numerical computations
would be fulfilled.

\section{Main language features}

In this section we describe some of main features in our language.

\subsection{Data types}

Besides some basic data types \textsl{integer}, \textsl{float} and
\textsl{string}, we support four additional data types: \textsl{matrix},
\textsl{function}, \textsl{range}, and matrix mask.  Matrix mask, or 
simply {\em matmask}, is used for selectively setting matrix contents.

\subsection{Basic matrix operations}

Basic matrix and vector operations are supported, e.g., addition,
subtraction, multiplication, transpose and inversion.  In addition,
mathematic functions such as \textsl{sin} and \textsl{cos} can be
applied to every entry of a matrix.  Other imaging processing
functions, such as image flipping and mirroring, are also provided.

\subsection{Matrix slicing and masking}

In Mx, matrix can be not only operated as a whole or entry-wise,
it can be operated through its vectors, sub-matrices or selected
elements as well.  In the latter case, other non-selected entries of
the original matrix are never touched.  The operation of getting a
vector or sub-matrix of a matrix for in-place operations is called
{\em matrix slicing}, and modifying only the selected matrix entries
is called {\em matrix masking}.

Neither java.vecmath nor Jama supports matrix slicing and masking.
Upon the writing of this report, we found another Java matrix package,
Jampack\cite{jampack}, is also publicly available.  Its underlying
data structure sounds supportive to matrix slicing.  This package,
however, was implemented differently and is in its early stage: ``The
code has only been lightly tested and certainly has bugs'', as the
author mentioned in his homepage.

Failed to find a good and suitable Java matrix package for Mx, we
developed our own underlying matrix class, Jamaica.  As a standalone
package, separated from the Mx interpreter programs, and moderately
tested, Jamaica will be soon publicly available.

\subsection{Program flow control}

The statements for program flow control were implemented, including
\textsl{if-then-else, while, break, continue}, and \textsl{for}.  
In addition, programs in our Mx language can define and invoke 
subroutines, include other files, do recursive calls, and even pass 
functions as parameters.

\subsection{Internal functions}

The minimum but necessary set of internal functions such as 
\textsl{print, input, load, save, plot, paint}, and mathematical 
functions are included.

\chapter{Tutorial}

\input{tutorial.tex}

\chapter{Language Reference Manual}

\input{lrm.tex}

\chapter{Project Plan}

\section{Team Responsibilities}

For the past two months, our team has held regular meetings for an
hour to discuss and update our goals.  Besides the meetings, however,
we have set a goal for each member of the group to achieve some type
of accomplishment by setting goals.  Here are the fundamental tasks
for each member:

\begin{flushleft}
\begin{small}
\begin{tabular}{|l|l|}
\hline
TianTian Zhou & Team leader; parser and front-end \\
\hline
Hanhua Feng & Architecture and back-end \\
\hline
Yong Man Ra & Testing and documentation \\
\hline
Chang Woo Lee & Testing and documentation \\
\hline
\end{tabular}
\end{small}
\end{flushleft}

\section{Programming style (coding conventions)}

\subsection{Antlr coding style}

If an Antlr rule is short and contains only one choice without any
action, then it will be written in one line.  The colon ``:'' always
starts at the ninth column unless the string in front of ``:'' is too
long.  In the one line mode, ``;'' is at the end of this line.

If an Antlr rule has multiple choice or actions, the ``;'' is
placed in a separated line at the ninth column.  ``$|$'' is also at
ninth column.  Short actions are in the same line of its rule and at
the right half of the screen.  Long action lines start at the
thirteenth column of the next line.  Code in actions follows the Java
coding style.

Lexem (token) names are in upper cases and syntactic items
(non-terminals) are in lower cases, which may contain the underscore
``\_''.

\subsection{Java coding style}

As the programmers using multiple programming languages, we use a
coding style that is a little different to the standard Java coding
style.

Indentation and spacing:
\begin{itemize}
\item Indentation of each level is 4 spaces.
\item The left brace ``\{'' occupies a full line and is at the same 
column as the first character of the previous text.
\item The right brace ``\}'' occupies a full line and at the same
column of its corresponding ``\{''.
\item One space between arguments and their parentheses ``('' ``)'',
but no space between function name and ``(''.
\item Add spaces between operators and operands for outer expressions.
\item Use spaces, do not use tabs.
\item The then-part and else-part of an ``if'' statement must
not be at the same line of ``if'' or ``else''.  Similar for ``for''
statement.
\end{itemize}

Names:
\begin{itemize}
\item Class names start with ``Mx'' followed by English words whose
first character is capital.
\item Variables are in lower cases, and words are separated by 
underscore ``\_''.
\item Do not use long names for local variables.  More concise, the better.
\item Method names are English words whose first characters are capital
except for the first word.
\end{itemize}

Follow Java javadoc standard for comments.

\section{Project Timeline}

Here are the deadlines for each specific task that was due.

\begin{flushleft}
\begin{small}
\begin{tabular}{|l|l|}
\hline
Feb 18 & Language white paper \\
\hline
First week of March & Language grammar \\
\hline
March 27 & Language reference manual \\
\hline
Second week of April & Supporting libraries \\
\hline
Third week of April & Front-end \\
\hline
Last week of April & Back-end \\
\hline
First week of May & Error recovery \\
\hline
May 13th & Entire project \\
\hline
\end{tabular}
\end{small}
\end{flushleft}

\section{Software project environment}

Most of the programs are written in Java.  The lexer and parser are written
in Antlr, and will be translated to java code.  We also wrote a class
in Java with macros, which will be explained later.

\subsection{Operating systems}

Since this project is developed in pure Java, it can be used
anywhere that a Java VM is running.  However, we have used other tools,
such as TCL and GNU m4.  TCL is available on many platforms including
Unix systems, Windows systems, and MAC.  GNU m4 is a Unix application.
However, GNU m4 is not necessary to be installed everywhere, unless
the template java code must be regenerated.

Our team members use Windows and Linux simultaneously.  Also thanks to
the Cygwin project, we can easily run TCL, SSH and GNU m4 on a Windows
box.

\subsection{Java 1.4}

Java is a ``simple, object-oriented, network-savvy, interpreted,
robust, secure, architecture neutral, portable, high-performance,
multithreaded, dynamic language''.  

Unfortunately, Java is not designed for scientific computing.  Writing
our Mx interpreter in Java does not prove that Java is feasible for
scientific computing.  It just proves that scientific computing {\em
can} be done in Java.  If someone hates programming languages other
than Java, please try our Java matrix class, Jamaica.

\subsection{Antlr}

The language parser is written in Antlr, ``a language tool that provides
a framework for constructing recognizers, compilers, and translators
from grammatical descriptions containing C++ or Java actions.''

\subsection{CVS}

CVS is a well-known concurrent version system for developers.  We
kept our CVS repository on a Linux machine, and use SSH to check
in/out our programs with secured network connections.

\subsection{TCL}

TCL is a shell-like scripting language, and is more efficient and
elegant than shell programs.  The testing executor program is written
in TCL.  Please refer to the testing chapter for more details.

\subsection{GNU m4}

Inspecting our code, one can find many pieces of similar code.  In our
opinion, this may happen in many interpretive programming language
applications, as long as there are many types.  Java does not support
macros, template and even function parameters (One can use derived
classes and late-binding to implement these, but it is not a good
solutions, because if so, instead of many similar code segments, he
will get many similar classes, saving in many similar program files!).
Getting tired of typing similar code, we resort to using an external
macro-replacing tool, GNU m4, which has a moderate user population.
It is used only for internal functions, because there are too many
similar functions: $\sin$, $\cos$, ...

%We shall discuss this in the section of the chapter of related issues
%in detail.

\section{Project log}

Here are the dates of significant project milestones.  Most of them
come from the CVS logs.

\begin{tabular}{|l|l|}
\hline
Feb 10 & CVS repository initialized \\
Feb 10 & The first version of white paper \\
Feb 15 & Finalized the white paper \\
Feb 25 & The first version of syntax \\
March 6 & Tiantian made significant modifications on syntax \\
March 21 & The language reference manual is added to CVS \\
March 25 & Front-end started \\
April 1 & The first version of grammar \\
April 1 & The back-end started \\
April 9 & The first version of Jamaica \\
April 17 & The first version of the back-end \\
April 25 & Early testing stage \\
May 2 & Painter and plotter ready \\
May 2 & Test executor program ready \\
May 6 & Started final report \\
May 7 & The third testing stage: examples \\
May 9 & Most tests are done \\
May 10 & The first version of final report \\
\hline
\end{tabular}

\chapter{Architecture Design}

The Mx interpreter consists of these components: a lexer that reads the
user input or program files to tokens, a parser that analyzes the
syntactic structure of the program and converts it to an abstract
syntax tree, a tree walker that travels the abstract syntax tree and
calls corresponding functions, an executor that looks up symbol
tables and diverts operations to type systems, a supporting matrix
library, and a simple error and exception processing mechanism.
Figure \ref{fig:arch} shows its block diagram.

\begin{figure}[h]
\begin{center}
\includegraphics[width=5in]{figs/arch.eps}
\caption{the system diagram of the Mx interpreter\label{fig:arch}}
\end{center}
\end{figure}

The lexer, parser and tree walker are implemented by Antlr\cite{antlr}.
The lexer and parser are implemented in Antlr file \textsl{grammar.g},
and the tree walker is implemented in Antlr file \textsl{walker.g}.
Source file \textsl{walker.g} contains short actions calling the
methods in the class MxInterpreter.

The main() method is in the class MxMain.  It first checks whether
the input is coming from the console or a file, then initializes the
lexer, the parser and the tree walker in differentiated ways.  The
class MxMain also handles exceptions and errors occurs in other classes,
and prints corresponding messages.

The back end consists of a complicated type systems.  All data are
encapsulated in classes, which are derived from a single class
\textsl{MxDataType}.  This class does the common jobs of all types,
and produce error messages, if a method is not specialized (overrided)
by the derived class.  The specialized function of simple types such
as \textsl{bool, int, double}, and \textsl{string} are in classes
\textsl{MxBool},
\textsl{MxInt}, \textsl{MxDouble} and \textsl{MxString}, respectively.
These classes are simply wrapper classes of Java elemental types.
Other data types, such as \textsl{range, matmask, function}, and 
\textsl{matrix} are in classes \textsl{MxRange}, \textsl{MxBitArray}, 
\textsl{MxFunction}, and \textsl{MxMatrix}.  These
classes are wrapper classes of our Java matrix classes
\textsl{jamaica.Range}, \textsl{jamaica.BitArray} and
\textsl{jamaica.Matrix}.  By using late-binding methods we implemented
differentiated functions for various types.  There is also an
\textsl{MxException} class, for delivering error messages.  The class
\textsl{MxInterpreter} also manipulates multi-level symbol tables,
implemented by \textsl{MxSymbolTable}.  Figure \ref{fig:types} illustrates
the type system in the Mx interpreter.

\begin{figure}[h]
\begin{center}
\includegraphics[width=5in]{figs/types.eps}
\caption{the type system of the Mx interpreter\label{fig:types}}
\end{center}
\end{figure}

In the supporting library, Jamaica, besides the classes mentioned
earlier, there are Plotter and Painter classes.  These two classes
will only use basic functions such as windows management and drawing
functions in the java.swing package.   We have heavily documented
the supporting library, with the javadoc standard, so one can 
easily know how to use the matrix classes.  On the other hand, the
interpretive classes are just slightly in-line documented, like
many non-library open-source programs we have seen.

We have also designed a translative system, as an alternative, which
may accept the Mx program files and translate to Java program files.
This expected system includes a run time environment for operations of 
\textsl{range, matmask} and \textsl{matrix} types 
(Operations of other data types can be
directly executed without using other libraries).  For this reason, we
have separated the supporting library from the interpreter and type
systems.  Given limited time (the Mx programming language is
quite large by now), we cannot implement two different systems, but
we have some discussions on this translative system in the chapter of
related issues.

\chapter{Testing Plan}

\section{Goal}

Since our compiler is to conduct mathematic operation, testing is
essential and must cover every possible input (especially special
values), otherwise the results we get would be dramatically different.

Testing is evolved throughout the compiler development, not only at the
final stage, but also from the very beginning when the grammar was
implemented. Our approach, probably like many others, is to test each
piece of our compiler and sew them together to conduct the final
test.

\section{The first stage: unit testing}

Initially, we noticed that there are certain Java packages supporting
matrix operations. However, as we are using them, it turned that these
packages did not support some of the functionalities that we
need. Thus, we ended up writing our own matrix operation library. To
ensure that all operations do what we expect, we use Matlab as our
guidance for programming and unit testing.  This library has its own
unit testing program.  This testing program saved us a lot of time in
the later testing stages, albeit neither exhaustive nor complete.  For
the other part of this project, we also did a little testing by hand,
in order to avoid fundamental errors in the system architecture.

\section{The second Stage: regression test}

Since many things can go wrong, and bugs could be hidden anywhere,
regression test is important in the project. What we want to guarantee
is what changes we make right now do not break the code we have had
before. Thus, only testing the changes we made currently is not
enough. On the other hand, to run through all the previous tests again
and again is time consuming and cumbersome. As a result, we decide to
build a script to automate this procedure. The script, written in tcl,
takes a database, which contains one or many small *.mx programs and
their expected returning values, and evaluates whether these *.mx
programs are doing what they are expected to do.

This script greatly simplified our regression test job.  At any time
after the code modification, the batched test will immediately tell
us whether we have broken some previously good code.  Also, hundreds
of small testing files are avoided.  (With hundreds of small files,
maintenance of the project files will be much more cumbersome: it
would be very hard to track revisions of these files in the CVS
repository.)  To be clear, we write up different databases for
different testing targets, such as boolean test, loop test, function
call test, and range test. This approach eventually makes our testing
systematic and assorted.

\subsection{The testing database: a small awk-like script}

The testing database file contains one or more entries of the following:
\begin{verbatim}
<expected-result> { <a-small-Mx-program> }
\end{verbatim}

Both \texttt{expected-result} and \texttt{Mx-program} can span multiple
lines. The \texttt{expected-result} part contains one or more items
separated by spaces or newlines.  Each of the items can have the
following format:
\begin{tabular}{ll}
\verb`!`          & switch between stdout and stderr (stdout by default) \\
\verb`...`        & ignore everything that follows \\
\verb`/<regexp>/` & match by regular expression \\
\verb`[<num>,<num>]`  & match a number in a range \\
\verb`<other>` &   exactly match. number comparison for numbers 
\end{tabular}

We can add comments in the testing database.  Character \texttt{;}
starts a line of comments, string \texttt{;;} starts a line of
comments that will be printed when a new test is going to be made, and
string \texttt{;;;} starts a line of comments that will be immediately
printed when the executor program is scanning the database.

\subsection{The testing database executor: a TCL program}

We developed a TCL program to parse this testing database.  This
program scans the database, subtracts pieces of code surrounded by \{
and \}, executes our Mx interpreter written in Java, and then compares
the results printed by the Mx interpreter with the expected results
given in the database, item by item.

\subsection{A sample of the testing database}

\verbatiminput{test/samples.tdb}

\section{The third stage: advanced testing examples}

Since some inter-connected errors might not be found by those small
code segments, larger testing programs with scientific computing needs
are extremely necessary.  All programs in the chapter of tutorial,
especially those complete examples, were acting as testing codes.
These examples not only helped us find some bugs, but also greatly
boosted our confidence of our Mx programming language.  Please refer
to the chapter of tutorial for these testing examples.

\chapter{Lesson Learned}

During the period of design and implementation of our Mx programming
language, we have learned some lessons.  These lessons are important
for projects in the future.

\begin{itemize}
\item Before designing a system, one should investigate the feasibility of
supporting tools.  At the beginning, we think those previously
existing matrix classes must be useful in our project.  Later, when we
begin to design the details of our programming language, we found
those matrix classes have so many deficiencies that it will not be
a better choice to add patches to it than to write a completely new one.
The detailed discussion will be in the next chapter.

\item The main frame of a project is its most important part.  When
we begin to consider how to design a system, a small change of mind
might create a very different system in the future.  Although there
are many ways in which we can achieve our destination, but which one is 
the shortest is not clear, even until you have finished a
project.  So getting advise from who has experience would make your
life much easier.  

\item If you find a much easier way to implement a family of functions, 
then use it immediately and do not fear of making some of your code
useless, because it will save you a lot of time in the future.  

As an example, at the beginning, in those functions that need a
double-compatible type as an argument, we check the data type
individually and call the error processor in each function; but later
we found, an easier way to implement this, is to call a method
doubleValue() which converts a data type to double, or raise an
exception if the argument is not double-compatible.  The exception is
a runtime exception that can spread through the stack, so those
functions will be much more concise.  We implemented doubleValue()
during the development and initially did not modify the already coded
functions, but later we found code using doubleValue() has less bugs,
so we finally changed all functions that had coded before
doubleValue() was implemented.
\end{itemize}

\chapter{Related issues}

\input{adv.tex}

\begin{onecolumn}
\begin{scriptsize}
\begin{thebibliography}{00}
\bibitem{matlab}
Matlab, http://www.mathworks.com/

\bibitem{idl}
IDL, http://www.rsinc.com/idl/index.asp

\bibitem{maple}
Maple, http://www.maplesoft.com/

\bibitem{mathcad}
Mathcad, http://www.mathsoft.com/products/mathcad/

\bibitem{mathematica}
Mathematica, http://www.wolfram.com/products/mathematica/

\bibitem{octave}
GNU Octave, http://www.octave.org/

\bibitem{scilab}
Scilab, http://www.scilab.org/

\bibitem{oon}
Object-Oriented Numerics Page, http://www.oonumerics.org/oon/

\bibitem{blitz}
Blitz++, http://www.oonumerics.org/blitz/

\bibitem{pooma}
POOMA, http://www.codesourcery.com/pooma/pooma

\bibitem{vecmath}
Java.vecmath, http://java.sun.com/products/java-media/3D/collateral/j3d\_api/j3d\_api\_3.html

\bibitem{jama}
Jama, http://math.nist.gov/javanumerics/jama/

\bibitem{titanium}
Titanium, http://www.cs.berkeley.edu/Research/Projects/titanium/

\bibitem{lapack}
http://www.netlib.org/lapack/

\bibitem{nr} 
William Press, Saul Teukolsky, William Vetterling and Brain Flannery,
Numerical Recipes in Fortran 77, 2nd Edition, Cambridge University
Press, 1992, http://www.nr.com

\bibitem{f2c}
f2c, http://www.netlib.org/f2c/

\bibitem{nrprob}
Various\ authors, 
http://www.starlink.rl.ac.uk/star/docs/sc13.htx/N-a2b3c1.html , 
http://www.lysator.liu.se/c/num-recipes-in-c.html , and
http://www.nr.com/bug-rebutt.html

\bibitem{antlr}
Antlr, http://www.antlr.org/

\bibitem{jampack}
Jampack, ftp://thales.cs.umd.edu/pub/Jampack/Jampack/AboutJampack.html
\end{thebibliography}
\end{scriptsize}
\end{onecolumn}

\appendix

\chapter{Language Syntax}

\input{syntax.tex}

\chapter{Code listing}

These are source files, testing script and databases, and examples, as of
May 13. (Generated files are not included.)

\begin{verbatim}
./src
-rw-r--r--    1 hanhua   phd          6770 May 12 17:42 grammar.g
-rw-r--r--    1 hanhua   phd          6155 May 12 17:42 walker.g
-rw-r--r--    1 hanhua   phd          4628 May 12 19:44 MxMain.java
-rw-r--r--    1 hanhua   phd         11544 May 12 17:42 MxInterpreter.java
-rw-r--r--    1 hanhua   phd          1116 May 12 19:44 MxBitArray.java
-rw-r--r--    1 hanhua   phd          1555 May 12 19:44 MxBool.java
-rw-r--r--    1 hanhua   phd          3806 May 12 19:44 MxDataType.java
-rw-r--r--    1 hanhua   phd          3771 May 12 19:44 MxDouble.java
-rw-r--r--    1 hanhua   phd           347 May 12 19:44 MxException.java
-rw-r--r--    1 hanhua   phd          1963 May 12 19:44 MxFunction.java
-rw-r--r--    1 hanhua   phd          3979 May 12 19:44 MxInt.java
-rw-r--r--    1 hanhua   phd         10306 May 12 19:44 MxMatrix.java
-rw-r--r--    1 hanhua   phd          1852 May 12 19:44 MxRange.java
-rw-r--r--    1 hanhua   phd           999 May 12 19:44 MxString.java
-rw-r--r--    1 hanhua   phd          2914 May 12 19:44 MxSymbolTable.java
-rw-r--r--    1 hanhua   phd           597 May 12 19:44 MxVariable.java
-rw-r--r--    1 hanhua   phd         15394 May 12 17:16 MxInternalFunction.m4
-rw-r--r--    1 hanhua   phd          1429 May 11 12:14 Makefile

./src/jamaica
-rw-r--r--    1 hanhua   phd         42670 May 12 17:13 Matrix.java
-rw-r--r--    1 hanhua   phd          5645 May 12 20:13 BitArray.java
-rw-r--r--    1 hanhua   phd          4569 May 12 20:13 Range.java
-rw-r--r--    1 hanhua   phd         11397 May 12 17:13 Painter.java
-rw-r--r--    1 hanhua   phd         14551 May 12 17:13 Plotter.java
-rw-r--r--    1 hanhua   phd         10061 May 12 17:13 MatrixTest.java

./test
-rwxr-xr-x    1 hanhua   phd          6847 May  9 10:50 mxtest.tcl
-rw-r--r--    1 hanhua   phd          1515 May  7 10:24 bool.tdb
-rw-r--r--    1 hanhua   phd          1133 May  7 10:39 double.tdb
-rw-r--r--    1 hanhua   phd          1181 May  9 18:41 infunc.tdb
-rw-r--r--    1 hanhua   phd           943 May  7 10:36 int.tdb
-rw-r--r--    1 hanhua   phd           863 May  9 13:55 samples.tdb
-rw-r--r--    1 hanhua   phd           175 May 13 12:44 tzfor.tdb
-rw-r--r--    1 hanhua   phd           407 May 13 12:41 tzfunc.tdb
-rw-r--r--    1 hanhua   phd           209 May 13 12:49 tzloop.tdb
-rw-r--r--    1 hanhua   phd          2086 May 13 12:37 tzmisc.tdb
-rw-r--r--    1 hanhua   phd           684 May 13 12:41 tzmx.tdb
-rw-r--r--    1 hanhua   phd           633 May 13 12:40 tzrange.tdb
-rw-r--r--    1 hanhua   phd           170 May 13 12:40 tzstring.tdb
-rw-r--r--    1 hanhua   phd           264 May  9 13:59 fmri.mx
-rw-r--r--    1 hanhua   phd          1394 May 11 23:12 lenna.mx
-rw-r--r--    1 hanhua   phd           609 May 11 23:12 lorenz.mx
-rw-r--r--    1 hanhua   phd           548 May  9 13:58 mandelbrot.mx
-rw-r--r--    1 hanhua   phd           209 May 11 23:12 potato.mx
-rw-r--r--    1 hanhua   phd           291 May  9 13:57 sierpinski.mx
-rwxr-xr-x    1 hanhua   phd           114 May 13 13:44 runall.sh
\end{verbatim}

File listing begins at the next page. $*$.mx files are not included
because they are already in the chapter of tutorial.

\newcommand{\loadsrc}[1]{
\subsection{#1}
\verbatiminput{#1}
}

\clearpage
\section{Parser}
\loadsrc{src/grammar.g}
\loadsrc{src/walker.g}

\clearpage
\section{Interpreter}
\loadsrc{src/MxMain.java}
\loadsrc{src/MxInterpreter.java}
\loadsrc{src/MxBitArray.java}
\loadsrc{src/MxBool.java}
\loadsrc{src/MxDataType.java}
\loadsrc{src/MxDouble.java}
\loadsrc{src/MxException.java}
\loadsrc{src/MxFunction.java}
\loadsrc{src/MxInt.java}
\loadsrc{src/MxMatrix.java}
\loadsrc{src/MxRange.java}
\loadsrc{src/MxString.java}
\loadsrc{src/MxSymbolTable.java}
\loadsrc{src/MxVariable.java}
\loadsrc{src/MxInternalFunction.m4}
\loadsrc{src/Makefile}

\clearpage
\section{Jamaica}

\loadsrc{src/jamaica/Matrix.java}
\loadsrc{src/jamaica/BitArray.java}
\loadsrc{src/jamaica/Range.java}
\loadsrc{src/jamaica/Painter.java}
\loadsrc{src/jamaica/Plotter.java}
\loadsrc{src/jamaica/MatrixTest.java}

\clearpage
\section{Testing script and database}

\loadsrc{test/mxtest.tcl}
\loadsrc{test/bool.tdb}
\loadsrc{test/ctrlflow.tdb}
\loadsrc{test/double.tdb}
\loadsrc{test/infunc.tdb}
\loadsrc{test/int.tdb}
\loadsrc{test/samples.tdb}
\loadsrc{test/tzfor.tdb}
\loadsrc{test/tzfunc.tdb}
\loadsrc{test/tzloop.tdb}
\loadsrc{test/tzmisc.tdb}
\loadsrc{test/tzmx.tdb}
\loadsrc{test/tzrange.tdb}
\loadsrc{test/tzstring.tdb}
\loadsrc{test/tutorial.tdb}
\loadsrc{test/runall.sh}

\end{document}
