commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Axel Kramer (JIRA)" <>
Subject [jira] Commented: (MATH-192) Operator precedence driven parser
Date Sun, 17 Feb 2008 11:30:34 GMT


Axel Kramer commented on MATH-192:

> how extensible is this parser ?
> Could it be "warm extensible", that is, extensible after compilation, by programme-calls?
> E.g. could I redefine after class-loading, that \ is the (binary) set difference or the
(unary) macro-call ?
With the ASTNodeFactory#getIdentifier2OperatorMap() and ASTNodeFactory#addOperator() methods,
you can achieve this dynamic operator "over-loading".
The operator characters set must also be defined properly in the IParserFactory#DEFAULT_OPERATOR_CHARACTERS
string (Unfortunately the backslash \ is not included in the operators character set at the

For the evaluation of this new operator you have to add new functions for example in the DoubleEvaluator#FUNCTION_DOUBLE_MAP
or ComplexEvaluator#FUNCTION_MAP maps.

This isn't very comfortable to use at the moment. But I think in the first step we have to
define a syntax for a math expression parser which should be the foundation for usage inside
commons math?

> paul
> PS: do I understand correctly that your submission is expected as a donation that'd be
under APL?
But I don't know exactly which formalisms must be used to donate it under APL into the commons
And I also think that the current package is only a starting-point for discussion the design
of a math parser.


> Operator precedence driven parser 
> ----------------------------------
>                 Key: MATH-192
>                 URL:
>             Project: Commons Math
>          Issue Type: New Feature
>         Environment: Tested with commons-math-1.2-RC1-src
>            Reporter: Axel Kramer
>            Priority: Minor
>         Attachments:
> Attached are sources for an operator precedence driven parser as described here:
> At the moment the used syntax for the math expressions is very similar to the Mathematica
input syntax
> and must probably be reworked for the common maths needs.
> Mainly the parser is driven by the arrays HEADER_STRINGS, OPERATOR_STRINGS and OPERATORS
in the:
>   org.matheclipse.parser.operator.ASTNodeFactory
> class.
> There's a utility class
>   org.matheclipse.parser.util.GenerateOperatorArrays
> which generates the above arrays for operator sets defined in a textfile like for example
>   /org.matheclipse.parser/eval/src/operators.txt
> JUnit test classes for testing the pure parser without any evaluations:
> /org.matheclipse.parser.test/src/org/matheclipse/parser/test/
> JUnit test classes for testing the evaluation in double or Complex calculation mode:
> /org.matheclipse.parser.test/src/org/matheclipse/parser/test/eval/

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message