DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=29294>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=29294
[lang][PATCH] lang.math.Fraction class deficiencies
 Additional Comments From cananian@alumni.princeton.edu 20040608 18:22 
More mailing list commentary:

Date: Thu, 3 Jun 2004 22:16:03 +0100
From: Stephen Colebourne
"C. Scott Ananian" <cscott@cscott.net> write:
> The idea is to remove the deprecated methods in some future version of
> lang; at which point Fraction can be made final again (and BadFraction
> completely disappears). It would be harder to purge BadFraction if its
> code is mixed willynilly with the 'real' Fraction code.
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.
Somewhere along the line I've lost the reason why we should deprecate
unreduced fractions. They are a valid representation of a fraction (so long
as the internal calculations are done properly), so why not allow them?
BTW, the 2/4 != 1/2 is consistent with the JDK  classes like BigDecimal
IIRC will have similar 'odd' behaviour, eg 0.500 != 0.5.
> The constructor for Fraction is packageprivate (or should be!) so no one
> outside the lang package can create a subclass in any case.
I hadn't noticed that, so the final is not an issue.
Stephen

Date: Thu, 3 Jun 2004 17:50:00 0400 (EDT)
From: C. Scott Ananian
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.
If people complain about the deprecation, then the methods can be
undeprecated. I doubt that will be the case.
> Somewhere along the line I've lost the reason why we should deprecate
> unreduced fractions. They are a valid representation of a fraction (so long
> as the internal calculations are done properly), so why not allow them?
The primary reason is programmer convenience. Fractions will overflow
unless simplified regularly. Further, the user will 'expect' that
1/2==2/4. Maintaining in 'simplified form' also allows more predictable
overflow behavior. By making this the actual behavior, potential bugs are
eliminated, and the user is not surprised.
Again, it's not like the deprecation can't be removed during alpha, beta,
or after release or some vocal existing user appears.
> BTW, the 2/4 != 1/2 is consistent with the JDK  classes like BigDecimal
> IIRC will have similar 'odd' behaviour, eg 0.500 != 0.5.
In BigDecimal these numbers are arguably different: they have different
precisions and thus round differently. For example:
divide(0.5,2) != divide(0.500,2)
Fraction is not intended to be used in this manner. Fractions
are not rounded. Computing with an unsimplified fraction may result in
overflow when a simplified fraction will not, but that is not a
specificallydesired behavior (nor is it a wellspecified one).
Is there any other example of such behavior in the JDK?
scott

Date: Sat, 05 Jun 2004 11:37:47 0700
From: Phil Steitz
C. Scott Ananian wrote:
> 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.
Phil

Date: Sat, 5 Jun 2004 13:35:23 0700 (PDT)
From: Al Chou
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

Date: Tue, 8 Jun 2004 13:58:06 0400 (EDT)
From: C. Scott Ananian
On Sat, 5 Jun 2004, Phil Steitz wrote:
> 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.
Yes. Scheme has had this numeric class for a long time (1975) and it IS what
"working programmers" find useful.
> 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.
...and the current implementation allows both uses, although it deprecates
the latter (due to its being harder for programmers to use correctly).
It can be undeprecated at some later time if there is outcry.
> 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.
This is always a really bad way to design software.
> 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.
I have an application, and I made the changes that my application and decades
of scheme experience have shown to be useful.
scott

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