• Note on pow(): java.math.BigDecimal has no pow() method; for the comparison we precalculated the corresponding 'unscaled' java.lang.BigInteger values; the bonus gained for java.math by eliminating exponent arithmetic is very small. But remember that java.math.BigInteger's pow() method is really of no use for java.math.BigDecimal, unless you do the exponent arithmetic yourselve; the road to follow is:
    java.math.BigDecimal bd;
    java.math.BigInteger bi;
    int scale = bd.scale();
    java.math.BigDecimal bdUnscaled = (scale > 0 ? bd.movePointRight(iScale) : bd);
    bi = bdUnscaledValue.toBigInteger();
    bi = bi.pow(power);
    //do your scale arithmetic here
    bd = new java.math.BigDecimal(bi, newScale);
    
  • Note on pow(): There is a potentially large performance loss for com.ibm.math and be.arci.math in that the sequence of operations to perform a pow() is fixed by IBM's specifications, excluding several optimizations; the benefit is that the result of pow() is consistent across implementations and even languages.
  • Note on pow(): Though pow() is a binary operator in com.ibm.math.BigDecimal, with a BigDecimal argument, it has more the character of a unary operator in java.lang.BigInteger, with an int parameter (be.arci.math.BigDecimal has both operand types). For our performance comparison we treated it as a unary operator with a fixed parameter, either (int)10 for java.math and be.arci.math, or the static field com.ibm.math.BigDecimal.TEN because com.ibm.math.BigDecimal only has the pow(BigDecimal) signature