--- Phil Steitz <[EMAIL PROTECTED]> 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.
Al
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
