 Phil Steitz <phil@steitz.com> 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
> numbertheoretic 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 numbertheoretic users would gravitate toward commons.math
rather than commons.lang.math, and that such users (and no one else) might
conceivably find nonreduced 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 alwaysreducing 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.
Al
__________________________________
Do you Yahoo!?
Friends. Fun. Try the allnew Yahoo! Messenger.
http://messenger.yahoo.com/

To unsubscribe, email: commonsdevunsubscribe@jakarta.apache.org
For additional commands, email: commonsdevhelp@jakarta.apache.org
