**Fully decimal**- This class behaves exactly as your own math on paper; there are no imprecisions as caused by converting non-integer numbers to binary representation and back.
**Precision and rounding**- ArciMath BigDecimal objects maintains the precision they were constructed with, when doing math on them. So
`0.99 x 10 = 9.90, not 9.9`, making it a usefull class for financial math as well. But all math and formatting methods can take a new precision as well as a rounding mode. **Formatting**- Since version 2.02, ArciMath BigDecimal contains BigDecimalFormat, probably the most powerfull and most flexible number parsing and formatting class. Formatting allows detailed control over number output, with padding and alignment. Parsing on the other hand is lenient enough to accept the defined output format as well as most common user input styles.
**Fixed***and*floating point- Yes, you read it right. Where
`java.math.BigDecimal`is fixed-point only, ArciMath BigDecimal operates both as a fixed-point class (with the compatibility mode method signatures) and as a full decimal floating point class. And you can use it for very long integer numbers just as well. **Speed**- ArciMath BigDecimal maintains a higher speed level than both
`java.math.BigDecimal`and`com.ibm.math.BigDecimal`at upto 100s of digits. Some methods are really orders of magnitude faster. **Overflow protection**- If your environment has the memory for it, you can do math with 999.999.999 digits and exponents from -999.999.999 to +999.999.999. But still all ArciMath BigDecimal operations will detect overflow beyond these boundaries, to protect you from obtaining wrong results. Similarly BigDecimalFormat will detect and signal overflow beyond a formatting pattern's maximum width.
**100% pure Java**- java.math.BigDecimal delegates all math operations to a C-library. That library clearly cannot profit from Java's enhanced memory management; during our extensive comparative tests we had several crashes in
`java.math.BigDecimal`due to virtual memory management (we must admit, under Windows98 only!). But none when using either`com.ibm.math.BigDecimal`or our own`be.arci.math.BigDecimal`. IBM follows a 99% Java approach, by delegating some methods to java.math.BigInteger, and hence to native libraries. ArciMath BigDecimal is coded for 100% in Java. **Integrity**- Because numbers can be highly sensitive to even a single changed bit, ArciMath BigDecimal offers protection of your data on persistence or transmission through Java's serialization mechanism. On serialization, ArciMath BigDecimal stores a double CRC checking code into the serialized object. On de-serialization, this CRC coding is checked, and other validity checks are performed.
**Backward compatible**- ArciMath BigDecimal is a drop-in replacement for com.ibm.math.BigDecimal. This includes almost complete backward compatibility with
`java.math.BigDecimal`, both in method signature and in results. Three known differences however between ArciMath BigDecimal and com.ibm.math.BigDecimal on the one hand, and java.math.BigDecimal on the other hand are- ArciMath BigDecimal accepts an exponent in constructors from String, and the toString() method renders them back again.
- The ArciMath max and min methods define which object is returned when the numbers compare equal; ArciMath BigDecimal returns the current object in that case, whereas the behaviour of java.math is not specified.
- In some other cases too the java.math documentation does not fully define the operation of methods (for example, if null is passed to methods that take objects as parameters). ArciMath BigDecimal may therefore differ from the actual BigDecimal operations in such cases (but no program should be relying on them).