Decimal arithmetic
Copyright (c) IBM Corporation, 2000. All rights reserved. ©
11 Jan 2000
[previous | contents | next]

Notes

This section documents open questions and other items relevant to, but not part of, this proposal.

Open questions

As of this draft there are no open questions.

Changes suggested for java.math.BigDecimal

This proposal suggests enhancing the current java.math.BigDecimal as defined in this document. This section lists additional changes suggested for such an enhancement.

LostDigits exception

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.

Internationalization

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.

com.ibm.math.BigDecimal conversions

The constructor and toBigDecimal method, provided for converting between com.ibm.math.BigDecimal and java.math.BigDecimal, should be removed.

Deprecated methods

It is suggested that the byteValue, intValue, longValue, and shortValue methods be added where necessary and all be deprecated.

Differences from the Java 1.2 BigDecimal class

The BigDecimal class proposed in this document is an upwards compatible enhancement of the original BigDecimal class. The following differences are noted:
  1. The string constructors accept a superset of the number representations allowed before. Notably, exponential notation (e.g., "1.5E+12") is now permitted.
  2. The max and min methods now define which object is returned when the numbers compare equal, as per ANSI X3.274-1996. (The current object is returned.)
  3. In some cases it appears that the BigDecimal documentation does not fully define the operation of methods (for example, if null is passed to methods that take objects as parameters). This definition may therefore differ from the actual BigDecimal operations in these cases (but no program should be relying on them).

Future extensions

The design of the two classes in this proposal allows for future extension. In particular, new properties can be added to the MathContext class with ease. The following list documents some possible future enhancements.

Scaled arithmetic

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.

NaN and Infinity

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

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.

Fuzzy comparisons

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.


[previous | contents | next]