Add support for both custom and unknown custom types.  For now, all unknown
types are simply treated as reals for generation purposes.  Custom types can
be registered with a particular VariableParser using any previously existing
type.  All the generation code ignores the new type name and continues as
before.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@11086 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

If an unknown error is received, treat it as a failure but without sample
values.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@11085 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

If an smtlib checker doesn't generate sample values, use an empty array so
the system can handle everything properly.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@11084 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

In preparation for enumerations, a more complete handling of variable information
is required.  Thus create a VariableCollection and use it appropriately.  As
much as possible, the VariableCollection is pushed down the stack as much as
possible.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@11083 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

VariableParser now needs to store information about custom types (specifically
enumerations).  Thus make parseVariable take an instance now by making it
a method of VariableParser again.  Also change the TET to use a global
singleton (called TET) to store the TET's VariableParser (since the type
information is global to Matlab).

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@11082 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10859 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

Sometimes when starting up, a previous handle would clash with an existing
handle, causing the TET to fail to load and locking Matlab into a state
where it can no longer exit.  Fix by ensuring on load no previous handle
is ever used, and instead just regenerate all of them.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/trunk/TableTool@10858 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

Add parsing and generating support for the exponent operator.  It currently
doesn't support generation over fixed point values, since CVC3 doesn't include
an easy to use function.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10857 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

Adds support for the implication operator in PVS (=>).  Matlab's support for
it is questionable, and thus ignored for now.  The operator is supported in
all layers, including generators.

Note that due to matlab not supporting all the operators, GenericGeneratorTest
now uses PVS to parse in its mega expression.  This changed the parsed's
expression's content, and thus the expression changed a little dramatically.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10856 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

For both SMTLIB and CVC3, variable subtypes conditions are now emitted into
the necessary places.  This doesn't directly relate to the PVS support added
earlier.  For now, no proof is done that the subtype has any allowed input,
but that doesn't matter as the table would still be "valid" for no input.
Determining that the connected Simulink blocks have correct typing is not
considered currently.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10855 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

The subtype given for variables are now properly parsed into the entire system.
Currently they are not actually used when generating the checker statements.
The expressions are fully parsed expressions, ready for output however.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10854 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

Somehow the NotEquals operator fell through the cracks when implementing
all the other operators.  Add it in, along with the necessary tests so it
will round trip the system properly.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10853 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

In order to support PVS style subtype expressions, the system has to be able
to parser such expressions.  To simplify the variable list parse, it simply
extracts the PVS expressions as a single token, unprocessed.  While requiring
more parsing work for the subtype expression, it avoids the necessity of
changing the parser in the future should a new subtype language be used.

As part of this change, the variable list parser's lexer became to complicated
to be expressed in Antlr's combined grammar format.  Thus split it out.
Everything works the same as before from an API point of view.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10852 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

Since any parser will have to test itself against a variety of operator, make
life simple and have one set of tests for all operators.  Also remove as much
code duplication as possible, by having one generic method that takes an operator
(as a String) and a parse function that handles calling the parse function
and compares the result as appropriate.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10851 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

The subtypes given in tables are given in PVS syntax.  To use these in other
languages, the TET needs to parse PVS expressions.  Note that this parser
is very basic, and only handles the bare minimum needed.  It only handles
basic Math expressions, similar to Matlab.  It doesn't do /= yet, due to missing
support further down the stack.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10850 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

The code to find the operation for a given text string was hidding in the
*Operation enumerations.  Move this code into MatlabParser, as it isn't
reusable as many languages use different symbols.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10849 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

Since all expressions are in fact general pupose expression, and not tied
to Matlab in the slightest, avoid calling the classes as Matlab*.  No actual
functional change is required for this.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10848 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

Since MatlabParser has no reason to have an instance of it managed by a
user, just make it use a single static method to access its functionality.
Overall it makes code simpler (avoiding the nasty getRootExpression call).

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10847 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

Instead of having new instances of VariableParser created, and thus wrapping
a Map<String, Variable> in a very inelegant way, simply have a single method
that actually does the VariableParser work, and directly returns the Map.
Also ensure all tests + Matlab continue to work, and tighten up some extra
imports and Matlab output in affected areas.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10846 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

The package name matlab2smt is really ugly, and not really representative of
what it really does anymore.  Thus create an expression package for the pieces
representing an expression, and a parsers package for all parsers, including
both the variable and the Matlab parsers.  Also make
MatlabParserOperatorParseTest not rely on (now) private members.  Instead
use the toString methods to get a generator independent representation, and
test that it matches appropriately.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10845 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

Since the java code is turning into entire toolbox for dealing with tabular
expressions, move the code to an appropriate package.  Even if it doesn't
become a full toolbox (for java), it is deeply used by the Matlab toolbox.
Thus pull the name from there.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10844 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

Add some toString methods to aid debugging the operations setup.  It isn't
committed centrally as I'm not sure it is a good idea.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10843 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

Handle the negative and fractional outputs from SMTLIB.  This required
extending the SMTLIB output grammar to accept negative and division operations.
Currently the support is cheated some, so that only the necessary pieces are
actually parsed.  Further support for more operations will require extending
the support further.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10724 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

Since periods are usually a wildcard, make sure to quote it so that it is
properly handled as a period, and not any random value.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10723 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

To handle the case when more complicated output is received from SMTLIB,
properly parse SMTLIB output.

Due to ANTLR trying to consume the full stream, the SMTLIB response is first
put in a string.  A simple algorithm, using the brackets, is used to find the
beginning and end.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10722 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

Update antlr to the latest release.  Also adjust the Matlab Grammar to continue
working.  No functional change necessary.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10721 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

Update the assembly plugin, used to generate the jar with dependencies, to
the latest released (non-beta) version.  No functional change.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10720 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

CVC3 doesn't allow decimal points to represent rational numbers.  Thus simplify
things by putting the literal into fractional form.  Currently reduction is
not attempted, and the simplest form is used.  Ex. 4.56 becomes (456/100) (as
tested in the accompanying unit test).

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10714 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

Since queries is now a Java List, don't use matlab to combine them (it makes
an array of Lists).  Instead use the Java method addAll to do it.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10713 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

The CVC3 generator originally insured that the TCC numbering was always unqie
for a table.  Re-add this functionality.  Specifically, when building the walker,
add a parameter to its constructor to set its starting TCC number.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10712 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

Fixed point operations are now all tested.  Due to literals automatically
casting to reals, it is necessary to push the "x" variable further into the
expression.  To ensure everything works, add one more condition without x to
make sure everything stays stable.  Everything works, after adjusting search
strings.

Also, deal with both signed/unsigned fixed point types.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10711 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

When generating binary operations, the requested type sent down was the output
type, not the input type.  However, the generator expects the input type to
know how to output the operation.  Fix that.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10710 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

Add a test for CVC3 fixed point support, and get fixed point working again.
This implements support for the fixed point marker, and make use of it.

The only problem is that literals by default fall down to Reals, so not all
operations are tested.  This needs to be fixed.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10709 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

Now that Matlab parsing is pretty much all done, remove extra output.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10708 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

Real operators are now added for CVC3 generation.  Fixed point is still left
out.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10707 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

Implement other operators for SMTLIB.  Also implement a test for it.  The test
is parameterized, so CVC3 support is easy to add.  Due to the parameterization,
a newer version of JUnit is required, so bump the version in the pom.xml file.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10706 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

When dealing with expressions, and generating output for them, types have
to be exactly known.  However, when two literals are added together (like:
5+5), the type to use for that is unknown.  To fix this issue, type information
has to be forced down the pipe.  So know the addition operation now knows it
needs to produce a particular type (ex Real or Fixed Point), and then tests
what the subexpressions can produce (for literals, they can produce either,
but a variable can only be what it is).

For Real, that is fine.  However a fixed point can take an infinite number of
different possibilities, and one cannot test for every combination.  So instead
a type "marker" is introduced.  This marker instead identifies that a fixed
point type is generally wanted, but specifics are unknown.  The system will
query for an appropriate type, and requires the specific type is returned, and
not a marker.  All types are also markers for themselves, so Reals, for instance,
don't need anything special.

While the marker system sounds good in theory, it currently is fully implemented,
so fixed point is currently broken.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10705 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

Binary ops now includes:
-
/
>=
<
<=
Unary:
-
YAY!

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10704 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

Test that each operator is parsed in properly.  Currently only tests implemented
operators, with more to follow.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10703 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

The java code now loads into Matlab automatically, but it uses a differnt
jar file location now.  Things work though.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10668 57e6efec-57d4-0310-aeb1-a6c144bb1a8b