Details
-
Improvement
-
Status: Closed
-
Minor
-
Resolution: Fixed
-
2.0
-
None
-
None
-
Operating System: Linux
Platform: PC
-
29294
Description
The attached patch addresses several deficiencies in the Fraction class:
a) 'reduction' should never be necessary. The fraction is stored as a pair of
relatively prime integers (i.e. always in simplified form). The reduce() and
getReducedFraction() methods have been deprecated and are now a no-op, and
identical to getFraction(), respectively. The static field TWO_QUARTERS is also
deprecated; it is now identical to the field ONE_HALF.
b) this also fixes the API oddity where currently a.compareTo(b)==0 does not
imply that a.equals(b). Once fractions are simplified, equals() corresponds
correctly to numerical equality.
c) the hashCode() method currently has a race condition if used in
multithreaded code: two threads accessing a hashcode which has not yet been
hashed may obtain different values returned from hashCode().
d) the gcd algorithm used in fraction has been changed to use a more efficient
'binary' algorithm which does not require division.
e) all code has been reviewed so that values at the edges of the range of
integers (ie Integer.MIN_VALUE and Integer.MAX_VALUE) are handled correctly.
Note that Integer.MIN_VALUE cannot be negated, so this entails typically
maintaining values as negative numbers when magnitudes are required. [See for
example the patch to Fraction.toProperString()]
f) the current pow() algorithm suffers from numerical inaccuracies due to
casting between double and int. It has been replaced by a double-and-multiply
method which guarantees accuracy. The new pow algorithm supports negative
powers as well (up to an including Integer.MIN_VALUE)
g) A 'resolveObject' method has been added to maintain backwards-compatibility
with existing serialized Fractions. These are now simplified on deserialization.
h) The addition and multiplication algorithms used have been updated to conform
to those described in Knuth's "The Art of Computer Programming" section 4.5.
This also means they will operate with larger fractions before overflowing.
i) All overflow conditions ought to throw an ArithmeticException. This was not
the case in the existing code (some overflows silently corrupted the result).
j) The JUnit tests for this class have been extended to test and verify all of
the above. Clover now indicates very few uncovered lines of code, most of which
are legitimately unreachable. Checkstyle emits no warnings. The javadoc for
all methods has been extended and corrected.