commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 29294] - [lang][PATCH] lang.math.Fraction class deficiencies
Date Mon, 14 Jun 2004 17:19:50 GMT
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  2004-06-14 17:19 -------
Mailing list commentary:
------------------------------------
Date: Tue, 8 Jun 2004 22:08:48 -0400 (EDT)
From: Henri Yandell

> Phil Steitz wrote:
> > One thing that we might want to consider, given the magnitude of the
> > changes, is deprecating this in [lang] and moving it to [math].  That
> > way, among other things, the (better) continued fraction
> > implementation in [math] could be used in getFraction(double).  The
> > improved gcd and checked integer arithmetic methods in the patch might
> > also make good additions to o.a.c.math.MathUtils.

+1 to this too. Deprecate in 2.1, remove in 3.0.

I think Fraction will be better served by being in Math where it can
combine with other code, than in Lang. I don't think there are many
examples where Fraction will be of use but not other Math things, only an
educational piece of code where majority of the maths in Math is too
complex.

Hen
-------------------------------------------------
Date: Wed, 9 Jun 2004 21:38:38 +0100
From: Stephen Colebourne

From: "Henri Yandell" <bayard@generationjava.com>
> I think Fraction will be better served by being in Math where it can
> combine with other code, than in Lang. I don't think there are many
> examples where Fraction will be of use but not other Math things, only an
> educational piece of code where majority of the maths in Math is too
> complex.

I agree that [math] is the best home for solving these problems fully,
however I can't help feel that Fraction is a class that should be in the JDK
and fits in [lang] scope. So, [lang] gets a (fixed) Fraction class, while
[math] gets Ratio/BigFraction/Fraction/... whatever is appropriate.

Stephen
-------------------------------------
Date: Wed, 09 Jun 2004 16:59:46 -0400
From: Mark R. Diggory

Stephen Colebourne wrote:
>I agree that [math] is the best home for solving these problems fully,
>however I can't help feel that Fraction is a class that should be in the JDK
>and fits in [lang] scope. So, [lang] gets a (fixed) Fraction class, while
>[math] gets Ratio/BigFraction/Fraction/... whatever is appropriate.

This makes sense only if there is always a 1 to 1 mapping between
o.a.c.lang and java.lang, meaning, somehow the contents we have in our
lang represent things we would like to see in java.lang someday (whether
truly plausable or not). I'm not convinced this is possible, there are
too much content in java.lang that overlaps with other commons subprojects.

As well, I consider "java.lang" is really a poorly named and poorly
defined package in the first place, a kind of "catchall" for initial
object hierarchy of Java (similarly, java.util is a poorly named
"catchall" for the initial datastructures and collections) . I think
there should have been a java.math package that housed Math, Number ...
plus java.util.Random .... This would have been the home for something
like Fraction in my little fantasy world.

Either way, I think Math would be glad to support Fraction in the Math
subproject if concensus proves it wanted.

And don't mis[i]nterpret my opinion, +1 on patching it even if it stays
where it is.

-Mark

---------------------------------------------------------------------
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