Put simply, I am not a mathematician (and don't have Knuth books). This code was submitted and I did what I could to make a class that appears to work. If you can improve it, that's great.
If you are willing, the best way to procede would be to patch those methods that would be 'safe' to patch. eg you mention the gcd and pow implementations as could be better. (http://jakarta.apache.org/commons/patches.html to Bugzilla please) ie. perhaps a two stage patch is possible? 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. Hopefully the math project crew can review the current implementation and patch as well. Stephen ----- Original Message ----- From: "C. Scott Ananian" <[EMAIL PROTECTED]> > The Fraction class in commons Lang 2.0 is decidedly suboptimal. > As Knuth describes in Chapter 4.5, the Fraction should be maintained > as a pair of integers which are relatively prime. No 'reduction' of > fractions is ever required. In addition, the gcd algorithm implemented > would be better implemented with a modern algorithm which uses subtraction > instead of division (see Knuth 4.5.2, 'A binary method'). Finally, > the pow() implementation is very dangerous, in that it assumed the double > returned by Math.pow() can be accurately converted to an int. A > better method would preserve precision by computing nth powers using > doubling and adding, a technique known since ancient Egypt. > > This change would introduce some minor backwards-compatibility issues: > reduce() would become deprecated and a no-op, some applications might > notice that the numerator and denominator of un-simplified fractions were > different in existing code, and the serialization code would have to > perform reduction on serialized fractions as they are read in. But larger > fractions would be able to be represented without overflow (among other > benefits) without forcing the user to repeatedly call 'reduce()'. > 'reduce'. > > Would you accept a patch to Fraction making these changes? I'm going to > make them anyway for a project I'm working on, but I'll put in the extra > effort to clean them up and prepare a patch if you would find that useful. > --scott > [feel free to forward to the relevant commons-lang list] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
