commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Al Chou <>
Subject Re: [lang] [math] org.apache.commons.lang.math.Fraction class
Date Sat, 05 Jun 2004 20:35:23 GMT
--- Phil Steitz <> wrote:
> C. Scott Ananian wrote:
> > On Thu, 3 Jun 2004, Stephen Colebourne wrote:
> > 
> >>This presumes that everyone wants a reduced fraction. I believe that there
> >>are use cases for holding an unreduced one. The main one that strikes me is
> >>education.
> > 
> > The org.apache.commons.math.Fraction class is not targetted at education.
> > It's intended to be useful for working programmers.
> The problem is that we do not know what the "working programmers" are 
> going to use this class for.  Your view seems to be that "Fraction" should 
> really be "RationalNumber" -- so that two equivalent fractions are equal. 
>   The problem is that the class is not named or currently implemented that 
> way (in terms of representation and identity).  Representing the fractions 
> themselves instead of collapsing immediately to the equivalence classes 
> (rational numbers) is more flexible; though as you point out, more care 
> has to be taken to prevent overflows and some efficiency in the arithmetic 
> operations may be sacrificed as a result.
> If we just fix the computational bugs in the current implementation, the 
> overflow situation should be OK with the arithmetic operations implemented 
> as they are now, since they call reduce() before returning results.  We 
> may in fact want to add alternative methods that do not reduce returned 
> fractions, or that otherwise restrict / control denominators.  While I do 
> not have specific use cases in mind, it could be that some 
> number-theoretic applications for this sort of thing may exist.
> The fact that all current operations reduce returned values led me 
> initially to agree that it was pointless to maintain the disctinction 
> between equivalent fractions.  Thinking about it some more, I am -0 to 
> changing Fraction to "RationalNumber."  I think our best path is to start 
> by fixing the computational bugs and then see what sorts of applications 
> emerge.

It seems to me that number-theoretic users would gravitate toward commons.math
rather than commons.lang.math, and that such users (and no one else) might
conceivably find non-reduced representations of fractions useful (it sure would
be nice to have someone here with number theory experience to tell us; the only
use I think I'd ever have is if I cared to know the exact history of the values
in a calculation or derivation, but that would probably arise only in the
context of computerized algebra, which I have never tried to program).  That
seems to argue for moving this class directly into commons.math as is, and
leaving behind an always-reducing version of itself in commons.lang.math.

But I am definitely +1 to first fixing the defects in the current class where
it lives and deferring other decisions.


Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger. 

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message