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
