Ideas for version 3.0

[uklimaschewski]

Hi all,

I am starting to plan developing the next major release of EvalEx, namely version 3.0.
For this, I would like to gather some ideas for new features and improvements that could go into that version.

Here are some notes from my mind, to start the collection:

1. Raise Java compatibility level, open decision: What minimum version to use? (Set source and target compiler level to 1.8 #259)
2. Refactor and redesign the Function/LazyFunction structure, which is a mess but was needed to stay backward compatible.
3. Switch to Junit 5.
4. Add possibility to register/define custom operators and functions on a general level, not only directly to the expression.
5. Better string support.
6. Raise default precision.
7. Refactor built-in functions, that still use doubles, to use BigDecimals. (Various built-in functions are not exact. #207)
8. Support for arrays. (indexing support #140)
9. Support for an evaluation history. (Step by step: how was the expression evaluated)

[RobertZenz]

Got a smallish one: Instead of the eval(boolean) overload, there should be one accepting an EnumSet of features.

public enum Feature {
    STRIP_TRAILING_ZEROS;
}

public BigDecimal eval(Feature... features) { ... }
public BigDecimal eval(EnumSet<Feature> features) { ... }

Would make it clearer what the overload is for and it would be easily extendable.

[qwert2003]

4. Add possibility to register/define custom operators and functions on a general level, not only directly to the expression.

Not sure what "on a general level" means. I currently do add custom operators and functions the following way:

/** Extends the Expression class to add custom operators and functions. */
public class CustomExpression extends Expression {

see
https://sourceforge.net/p/drawj2d/code/HEAD/tree/trunk/src/com/udojava/evalex/CustomExpression.java

[RobertZenz]

On second thought, using an enum is not extendable. So it's either an int, or an interface.

public interface Feature {}

public final class StripTrailingZerosFeature extends Feature {}

Obviously, that comes with drawbacks of its own. One way or the other, the Expression has to implement the functionality. Unfortunately, not having the Expression implement the functionality would require a level of extensibility which will be hard to achieve, depending on what the Features should be able to do.

Given that stripping the trailing zeros is currently the only "feature", maybe it would be better if we would strip them by default, and drop that overload and feature-ability altogether. One could argue that the number of zeros is an implementation detail and the result should be "shrunk" to the correct amount anyway.

[uklimaschewski]

@qwert2003 At the moment, a custom function or operator can only be added to an expression instance.
I'd like to have the possibility to add them to EvalEx as a whole, so that you don't have to add them on each expression again and again.

[MDZhB]

This is a good idea. The expression class does too much right now, I think; it would make sense to factor some of the functionality out, starting with a runner class (call it EvalexEngine or something) that consumes expressions and executes them. The application would configure the runner rather than individual expressions, allowing for reusable configurations.

[MDZhB]

I'd like to clean up the tokenization code, possibly altering the EvalEx grammar in the process to make it more Java-like. My memory's a little hazy, but one example that comes to mind is how EvalEx identifies number literals -- changing the grammar would make this code simpler, and its results would be more predictable to a Java programmer.

[RobertZenz]

Last year, I was playing around with the thought of implementing my own parser (with a few extra features that I'd need to extend jMathPaper further). However, I never got it "done", not sure why, to be honest, it just dropped off my list (as did a lot of things, now that I think about it). What I did was quite over-engineered and I split the parsing into multiple steps:

1. Tokenization (String to Infix List<Token>)
2. Infix Parsing (Infix List<Token> to RPN List<Token>)
3. RPN Parsing (RPN List<Token> to EvaluableExpression)
4. Evaluation (EvaluableExpression.evaluate())

I went to great lengths to have all that customizable, so it's a lot of classes. But if you or @uklimaschewski is interested in having a look at it, I could clean it up and upload it to a private repository and grant you access to it. Maybe one or idea or the other could be useful.

[uklimaschewski]

@RobertZenz I am currently implementing it in a similar way. I think a lot of the complexity of the current implementation is based on the somehow unclear separation of the steps tokenization, rpn conversion and evaluation.
Separating the responsibilities makes the code a lot easier to read and maintain. Also the unit testing can be applied much better.

[uklimaschewski]

I would also like to support structures, in addition to arrays. Something like new Expression("myStructure.amount + myStructure.anArray[2].value") where you can add a Java POJO or JSON structure as a parameter for evaluation.