On Sat, 29 May 2004, Stephen Colebourne wrote: > However, we do have to be careful about introducing incompatabilities into > the class. This Fraction class should follow the 80/20 rule, and maintain > simplicity when possible. If necessary, a better implementation in the > commons-math project could then be created. If the incompatability only > affects fractions with large numerators/denominators then that might be OK > introducing an incompatability.
The existing add(), subtract(), and multiplyBy() and divide() code (as far as I can tell) all returned reduced fractions, so existing arithmetic code should largely be unaffected. The primary visible difference is that before Fraction.getFraction(2,4).equals(Fraction.getFraction(1,2))==false and now it would be true. I view the previous behavior as "surprising" and a bug, honestly. The previous implementation was very dangerous in so far as it could silently corrupt your fraction due to overflow in its temporary values, even if the result "should have" fit into an int. Now these corner cases have been fixed. This is what projects like commons promise: robust implementations of common code where all of the nasty gotchas have been thought-through and fixed. I hope that my patch accomplishes this for Fraction. > Hopefully the math project crew can review the current implementation and > patch as well. It's now bugzilla bug #29294: http://issues.apache.org/bugzilla/show_bug.cgi?id=29294 The best way to understand the patch is actually to start at the new junit tests, which identify some of the ways that the old code failed. --scott MI6 Semtex Rule Psix Noriega FBI Columbia Panama $400 million in gold bullion NSA Sabana Seca Washington Soviet Moscow PLO India Dictionary supercomputer ( http://cscott.net/ ) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
