[
https://issues.apache.org/jira/browse/MATH-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12569688#action_12569688
]
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 moment).
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?
Yes.
But I don't know exactly which formalisms must be used to donate it under APL
into the commons project?
And I also think that the current package is only a starting-point for
discussion the design of a math parser.
axel
> Operator precedence driven parser
> ----------------------------------
>
> Key: MATH-192
> URL: https://issues.apache.org/jira/browse/MATH-192
> Project: Commons Math
> Issue Type: New Feature
> Environment: Tested with commons-math-1.2-RC1-src
> Reporter: Axel Kramer
> Priority: Minor
> Attachments: parser.zip
>
>
> Attached are sources for an operator precedence driven parser as described
> here:
> http://en.wikipedia.org/wiki/Operator-precedence_parser
> 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/AllParserTests.java
> JUnit test classes for testing the evaluation in double or Complex
> calculation mode:
> /org.matheclipse.parser.test/src/org/matheclipse/parser/test/eval/AllEvalTests.java
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
