commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <p...@steitz.com>
Subject Re: [lang] [math] org.apache.commons.lang.math.Fraction class
Date Sat, 05 Jun 2004 18:37:47 GMT
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.

Phil


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message