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 [EMAIL PROTECTED] 2004-06-08 18:22 ------- More mailing list commentary: ----------------------------------------------------- Date: Thu, 3 Jun 2004 22:16:03 +0100 From: Stephen Colebourne "C. Scott Ananian" <[EMAIL PROTECTED]> 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 willy-nilly 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 package-private (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 specifically-desired behavior (nor is it a well-specified 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 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 -------------------------------------------------------------- Date: Sat, 5 Jun 2004 13:35:23 -0700 (PDT) From: Al Chou 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 ----------------------------------------------------------- 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 un-deprecated 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 > number-theoretic 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, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
