Copyright (c) IBM Corporation, 2000. All rights reserved. ©
|11 Jan 2000|
|[previous | contents | next]|
This definition currently uses ArithmeticException to signify the 'lost digits' condition. It might be appropriate to define a new LostDigitsException (a subclass of ArithmeticException) for this event.
The BigDecimal class as proposed provides canonical string representations of BigDecimal numbers through the format and toString methods. These primitives depend on the rules for decimal arithmetic and so are included in the class.
It is assumed that locale-sensitive classes (such as the classes in the java.text package) will in due course use these primitives to provide enhanced number presentations: for example, the DecimalFormat class might provide formatting for BigDecimal numbers which allows thousands separators or a different decimal indicator. If these are added, and provide a superset of the function of the two format methods, then the latter should be removed.
The constructor and toBigDecimal method, provided for converting between com.ibm.math.BigDecimal and java.math.BigDecimal, should be removed.
It is suggested that the byteValue, intValue, longValue, and shortValue methods be added where necessary and all be deprecated.
The concept of scaled fixed point arithmetic, where the final result has a specific scale, could be extended to all operator methods simply by adding a new form setting to the MathContext class, indicating that results should be calculated to give an exact result with a scale of digits digits.
In everyday arithmetic, undefined and infinite results are considered errors, and the current design reflects this by raising an exception for these circumstances. BigDecimals could be extended to permit the representation of Not-a-Number (NaN) and +/- Infinity, with these values being allowed when enabled by a property in the MathContext object.
Transcendental methods could be added to the BigDecimal class, or provided as a separate class (similar to java.lang.Math). The most-requested of these would simply extend the existing pow method to allow non-whole powers.
The ANSI standard from which this proposal is derived includes provision for 'fuzzy comparisons' (numeric fuzz), where numeric comparisons are carried out at a lower precision than other numeric operations.
This concept could be added, controlled by a property in the MathContext class, but has been omitted from this proposal as it was rarely used (possibly because the need for such comparisons is much reduced in a decimal floating point arithmetic). There is also some evidence that fuzzy comparisons can give confusing results.