You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2004/06/03 01:37:17 UTC
Re: [lang] [math] org.apache.commons.lang.math.Fraction class
I had a 5 second look yesterday, and realised how big the change is. My
immediate concern is that the Fraction class has lost its final status,
making it less immutable.
I was wondering whether it would be possible to have just one class (rather
than an additional BadFraction subclass) that held an additional field only
used when using non-reduced fractions. Effectively merging the two classes
into one?
Also, I wasn't sure what 'relatively prime' actually meant. Its probably too
mathematical for the target audience in [lang].
Finally, I believe that [lang] is the right place for these (including
BigFraction). They represent missing parts of the JDK, so [lang] is
appropriate.
Stephen
----- Original Message -----
From: "C. Scott Ananian" <cs...@cscott.net>
> > > What about getNumerator()/getDenominator() - won't these change if 2/4
is
> > > held differently? I believe that we need to preserve the 2/4 concept
> > > distinct from 1/2, at least in the [lang] version.
>
> All these concerns have been addressed in the latest version of my patch.
> I'd appreciate review and comments. Thanks!
> http://issues.apache.org/bugzilla/show_bug.cgi?id=29294
> --scott
>
> overthrow Echelon justice plastique ASW Yeltsin Sigint assassination
> early warning Soviet Bush Cocaine terrorist Legion of Doom ammunition
> ( http://cscott.net/ )
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [lang] [math] org.apache.commons.lang.math.Fraction class
Posted by "C. Scott Ananian" <cs...@cscott.net>.
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 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 decades of scheme
experience have shown to be useful.
--scott
Cheney payment Morwenstow milita Sugar Grove security explosives Hager
ASW operation Bejing corporate globalization United Nations Ortega
( http://cscott.net/ )
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [lang] [math] org.apache.commons.lang.math.Fraction class
Posted by Al Chou <ho...@yahoo.com>.
--- Phil Steitz <ph...@steitz.com> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [lang] [math] org.apache.commons.lang.math.Fraction class
Posted by Phil Steitz <ph...@steitz.com>.
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
Re: [lang] [math] org.apache.commons.lang.math.Fraction class
Posted by "C. Scott Ananian" <cs...@cscott.net>.
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
Clinton Seattle Chechnya East Timor genetic plutonium NRA cryptographic
colonel Panama cracking Sabana Seca WTO global action network corporate globalization
( http://cscott.net/ )
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [lang] [math] org.apache.commons.lang.math.Fraction class
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "C. Scott Ananian" <cs...@cscott.net>
> On Thu, 3 Jun 2004, Stephen Colebourne wrote:
> > I had a 5 second look yesterday, and realised how big the change is. My
> > immediate concern is that the Fraction class has lost its final status,
> > making it less immutable.
>
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [lang] [math] org.apache.commons.lang.math.Fraction class
Posted by "C. Scott Ananian" <cs...@cscott.net>.
On Thu, 3 Jun 2004, Stephen Colebourne wrote:
> I had a 5 second look yesterday, and realised how big the change is. My
> immediate concern is that the Fraction class has lost its final status,
> making it less immutable.
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.
The constructor for Fraction is package-private (or should be!) so no one
outside the lang package can create a subclass in any case.
> Also, I wasn't sure what 'relatively prime' actually meant. Its probably too
> mathematical for the target audience in [lang].
http://www.google.com/search?q=%22relatively%20prime%22&btnI=yes
It just means that the gcd(x,y)=1, or (equivalently) that the fraction is
"simplified". I'll be glad to add that to the javadoc.
> Finally, I believe that [lang] is the right place for these (including
> BigFraction). They represent missing parts of the JDK, so [lang] is
> appropriate.
ok.
--scott
Waco, Texas nuclear AP kibo Treasury EZLN MI5 Minister UKUSA corporate globalization
Bush President atomic Rijndael assassinate Qaddafi affinity group
( http://cscott.net/ )
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org