Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Date: Sat, 29 May 2004 12:21:25 -0400 (EDT)
From: "C. Scott Ananian" <cscott@cscott.net>
Sender: cananian@cag.csail.mit.edu
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [lang] [math] org.apache.commons.lang.math.Fraction class
In-Reply-To: <000801c44566$97561b80$cc432cd9@oemcomputer>
Message-ID: <Pine.GSO.4.58.0405291213410.3492@catfish.csail.mit.edu>
References: <Pine.GSO.4.58.0405281302100.3242@catfish.csail.mit.edu>
 <000801c44566$97561b80$cc432cd9@oemcomputer>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org