Default precision and scale about evalex

[uklimaschewski]

Thanks alot, I am always happy to hear some applause ;-)

The default precision is set through the default MathContext:

private MathContext mc = MathContext.DECIMAL32;

According to Java, the DECIMAL32 defines a precision of 7 and a rounding mode of HALF_EVEN, which matches the IEEE 754R Decimal32 format.

I think it would be no problem to change the default MathContext to have a precision of 0, I agree with your idea.
But I'd like to keep the default rounding mode at HALF_EVEN, I think it is the most common used mode.

With precision and scale, I see a bit of a problem, as the Java implementation has IMHO a problem here.
The MathContext, which is used overall in calculation only knows about precision and not scale, whereas the BigDecimal implementation only knows about scale and not precision.

[LeonLiuY]

Thank you for quick response!

I've read the code.

addFunction(new Function("ROUND", 2) {
    @Override
    public BigDecimal eval(List<BigDecimal> parameters) {
        BigDecimal toRound = parameters.get(1);
        int precision = parameters.get(0).intValue();
        return toRound.setScale(precision, mc.getRoundingMode());
    }
});

It seems that ROUND(expression,precision) actually is ROUND(expression,scale).
The test case also stands by it:

@Test
public void testRounding() {
    assertEquals("3.8", new Expression("round(3.78787,1)").eval().toString());
    assertEquals("3.788", new Expression("round(3.78787,3)").eval().toString());
    assertEquals("3.734", new Expression("round(3.7345,3)").eval().toString());
    assertEquals("-3.734", new Expression("round(-3.7345,3)").eval().toString());
    assertEquals("-3.79", new Expression("round(-3.78787,2)").eval().toString());
    assertEquals("123.79", new Expression("round(123.78787,2)").eval().toString());
}

Maybe this is somewhat different understanding of "precision" and "scale".
My definition is:
Precision is the number of significant digits of the whole BigDecimal,
while scale is the number of the digits after the decimal point.

Another problem I found is:
If we use exp.setPrecision(0);, eval 1/3 will result
java.lang.ArithmeticException: Non-terminating decimal expansion; no exact representable decimal result.
It is obvious. To solve it, I can:

• Do not use 0 on precision, use a positive number. But in some situation, I do not know what is the "positive number". Estimating what exactly is the maximum value of the calculation is annoying.
• Keep 0(unlimited) precision, use a function like 1/3R2 while "R2" represents "round result to scale 2", or DIV(1, 3, 2), which is much easier to implement.

I think in financial applications. scale and rounding are important because money has a minimum unit, while precision seems not that useful. They always require an unlimited precision because they do not want to lose any money. (They control the fractional part and give freedom to the integer part)

Anyway, now I can figure out how to use EvalEx -- I'll use 0 precision and define a function DIV to avoid repeating decimal. The ROUND function is just what I need for controlling scale on other operations.

I'm not native English speaker, thank you a lot for patience.

[uklimaschewski]

Thanks alot for your input, I will meditate about it, when I find some time :-)