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.
Phil
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
