BROOM: A Matrix
Language
Chris Tobin
Michael Weiss
Gabe Glaser
Brian Pellegrini
Broom Overview and Summary
 A high-level language for manipulating
matrices
 Many useful built in matrix operations.
 Ability to define and build more
complicated functions for specialized
analysis of information
Motivation
 Matrices are universal mathematical
constructs
 Learning curve is not as steep
 Specialized use, without extraneous things
to understand other than
what you need it for.
 No need for expensive software
Goals
 Intuitive syntax
 High level
 Very portable
 Flexible
 Useful and informative error checking
Broom Syntax
 Intuitive
 for ( ) … endfor
 Freeform
 whitespace inserted at will
 Smooth built-in matrix operation syntax
 A = inv(B); // finds the inverse of B
 Features:
 Control flow constructs: for, while, if
 Nested logical operators and expressions
 A wide range of built-in functions
Built-in Functions
 Many useful built-in function calls:







det
colswap, rowswap
inv
gauss
appendUD, appendLR
setCol, setRow
Too numerous to list…22 total
Semantics
 Broom features:
 Function definitions
 Allow for modularity, power, and reusable code.
 Variable definitions
 Two intuitive mathematical types
 Number
 Matrix
 Scoping rules:
 local – for functions
 global – accessible by all
 All functions call-by-value for simplicity
Compiler Components and
Composition
 There are 5 main components of BCC, the
Broom translator
 Lexer
 Parser
 Static Semantics Checker
 W/Symbol Tables
 BroomMatrix.java
 Contains Matrix manipulation code and functions
 Code Generator
ANTLR
 The Lexer and Parser were implemented using
ANTLR.
 ANTLR’s AST class was used to create the Abstract
Syntax Tree and Nodes.
 The Static Semantics Checker was
implemented as a TreeWalker of the ANTLR
AST and maintained Symbol Tables for the
various scopes.
 Symbol Tables were written as a simple Java class
 Code Generator was also implemented as a
TreeWalker of ANTLR AST.
 Accumulates a “program string” as it walks the AST
and prints string to file upon finishing traversal
Block Diagram of Compiler
Example of Generated Code
MyProgram.broom:
MyProgram
global Matrix myMatrix;
myMatrix = [1,2;
3,4;];
//function definitions here...
start()
Number value;
value = det( myMatrix *
[1,3;
7,8;]);
//print the value you got
value.print();
//print the global Matrix
myMatrix.print();
endstart
MyProgram.java
public class MyProgram
{
BroomMatrix myMatrix;
public MyProgram()
{
float[][] _temp0 = {{(float) 1,
(float) 2}, {(float) 3, (float) 4}};
myMatrix = new BroomMatrix( _temp0);
}
public void start()
{
float value;
float[][] _temp1 = {{(float) 1,
(float) 3}, {(float) 7, (float) 8}};
value =
BroomMatrix.det(BroomMatrix.multiply(m
yMatrix, new BroomMatrix( _temp1)));
BroomMatrix.printVariable(value);
BroomMatrix.printVariable(myMatrix);
}
public static void main(String[] args)
{
MyProgram myProgram = new MyProgram();
myProgram.start();
}
}
Output of The Simple Program
$ javac MyProgram.java
$ java MyProgram
26.0
1.0 2.0
3.0 4.0
Error Checking
 Two main types of errors
 Semantic Errors
 Invalid use of logical ops
 Invalid type assignments
 Use of reserved words as variable names, etc.
 Run-Time Errors
 Reference to non-existent index
 Use of improperly formatted matrix.
*Note: If “de ja vu” is experienced something in your
matrix may have been changed.
Example Test Program
wrongNumColls
// Test for number of columns errors
// Author Brian Pellegrini
// This is supposed to make sure that error checking for
//assignment of matrix values works...it is supposed to fail
// MUA HAHAHHAHAHHAH
global Matrix A,B;
A= [1, 0, 1; 0, 1;];
B= [0, 1; 1, 0 , 2;];
start()
print ("If this printed checker didn't work");
endstart
Example Test Results
BroomProgram did not compile; the following errors were detected:
* Error in *global declaration* : invalid matrix specification.
Expected a row with 3 elements, but got 2
Error in *global declaration* : invalid matrix specification.
Expected a row with 2 elements, but got 3
 BROOM compiler found all the errors!
 During testing one has to be careful that errors being tested are
the only ones present in the program
 Inadvertent bugs can cause lots of lost time spend debugging
“ghost bugs”
Lessons Learned
 Leave no stone unturned
 Need to test every possible error user might
encounter
 Need to test both errors in user’s code, and errors in
generated JAVA code
 Exhaustive testing pays off in the end
 Have someone else try it!
 Have a friend write a program, they might find errors
that the testing team simply overlooked.