Re: [lang] Divesting the commons.lang.math package
Divest? I object to removing Fraction from [lang], as its a very core concept tat is missing from the JDK. And thee are many users who would just want Fraction and none of the rest of the [math] library. The [lang] maths package is fo non-mathematicians. The [math] library is for serious mathematicians. Big difference. As per the commons charter, there is nothing wrong with having duplicated code/concepts in Commons. Stephen Paul Benedict wrote: Without any further input (over a week), I say it's safe to divest. On Sun, Jan 3, 2010 at 5:58 AM, Luc Maisonobe luc.maison...@free.fr wrote: Henri Yandell a écrit : On Sat, Jan 2, 2010 at 1:57 PM, Paul Benedict pbened...@apache.org wrote: This is how I believe the commons.lang.math package can be eliminated. Based on the current 3.0-SNAPSHOT API, there are only three classes left: Fraction IEEE754rUtils NumberUtils 1) Fraction should leave; it is completely inappropriate for this library. It has nothing to do with the JDK or supporting the Java language. It belongs squarely in Commons Math. 2) IEEE754rUtils should move to the root of commons.lang 3) NumberUtils should move to the root of commons.lang We discussed Fraction being deleted earlier in 3.0, but the view was to keep it. I'm happy for it to go. [math]'s version appears to be practically the same. Half of NumberUtils is String conversion. The other half are min/max; which is what IEEE754Utils is. These could potentially move to [math]'s util.MathUtils. One advantage is that people looking for these minor methods would have an on ramp into the other components for the more powerful features. One concern I have is finding the basic functionality in another package. You go to [math] and it's all about the powerful deep things, not a random reusable bit of code off to the side. Maybe the right solution there is Commons Common, with 80% reuse/20% power; or maybe the solution is documentation in which all the basic types of methods are collated and link to the components they're in. We probably lack good documentation on the basic utility parts in [math]. Luc Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] Divesting the commons.lang.math package
On Mon, Jan 11, 2010 at 5:17 PM, Stephen Colebourne scolebou...@btopenworld.com wrote: Divest? I object to removing Fraction from [lang], as its a very core concept tat is missing from the JDK. And thee are many users who would just want Fraction and none of the rest of the [math] library. Having people to import Commons Math to just use Fraction is equal to people having to import Commons Lang to use Fraction. If that's all you want, you have to import something. Likewise, since I don't think this class is missing from the JDK, I don't think it deserves to stay in Commons Lang. It doesn't add to anything in the Java language -- it is the foundation of a math library. Paul - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
RE: [lang] Divesting the commons.lang.math package
-- it is the foundation of a math library. I have to disagree on this point. An application can use Fractions instead of a doubles, if you can deal with the API usage compared to operators. This what we (in a different century, when I worked for a Smalltalk vendor) did in Smalltalk for ALL non-integers, we used fractions and precision was never lost. Neat trick when supported at the language level. In a similar vein, I've lost count as to how many times, I've re-invented Smalltalk's Association class. Now that Java has Generics, I think I've finally settled on something reusable. So I do not see Fraction as the foundation for anything really. It stands on its own nicely IMO. Gary -Original Message- From: paulus.benedic...@gmail.com [mailto:paulus.benedic...@gmail.com] On Behalf Of Paul Benedict Sent: Monday, January 11, 2010 15:25 To: Commons Developers List Subject: Re: [lang] Divesting the commons.lang.math package On Mon, Jan 11, 2010 at 5:17 PM, Stephen Colebourne scolebou...@btopenworld.com wrote: Divest? I object to removing Fraction from [lang], as its a very core concept tat is missing from the JDK. And thee are many users who would just want Fraction and none of the rest of the [math] library. Having people to import Commons Math to just use Fraction is equal to people having to import Commons Lang to use Fraction. If that's all you want, you have to import something. Likewise, since I don't think this class is missing from the JDK, I don't think it deserves to stay in Commons Lang. It doesn't add to anything in the Java language -- it is the foundation of a math library. Paul - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] Divesting the commons.lang.math package
Without any further input (over a week), I say it's safe to divest. On Sun, Jan 3, 2010 at 5:58 AM, Luc Maisonobe luc.maison...@free.fr wrote: Henri Yandell a écrit : On Sat, Jan 2, 2010 at 1:57 PM, Paul Benedict pbened...@apache.org wrote: This is how I believe the commons.lang.math package can be eliminated. Based on the current 3.0-SNAPSHOT API, there are only three classes left: Fraction IEEE754rUtils NumberUtils 1) Fraction should leave; it is completely inappropriate for this library. It has nothing to do with the JDK or supporting the Java language. It belongs squarely in Commons Math. 2) IEEE754rUtils should move to the root of commons.lang 3) NumberUtils should move to the root of commons.lang We discussed Fraction being deleted earlier in 3.0, but the view was to keep it. I'm happy for it to go. [math]'s version appears to be practically the same. Half of NumberUtils is String conversion. The other half are min/max; which is what IEEE754Utils is. These could potentially move to [math]'s util.MathUtils. One advantage is that people looking for these minor methods would have an on ramp into the other components for the more powerful features. One concern I have is finding the basic functionality in another package. You go to [math] and it's all about the powerful deep things, not a random reusable bit of code off to the side. Maybe the right solution there is Commons Common, with 80% reuse/20% power; or maybe the solution is documentation in which all the basic types of methods are collated and link to the components they're in. We probably lack good documentation on the basic utility parts in [math]. Luc Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] Divesting the commons.lang.math package
Henri Yandell a écrit : On Sat, Jan 2, 2010 at 1:57 PM, Paul Benedict pbened...@apache.org wrote: This is how I believe the commons.lang.math package can be eliminated. Based on the current 3.0-SNAPSHOT API, there are only three classes left: Fraction IEEE754rUtils NumberUtils 1) Fraction should leave; it is completely inappropriate for this library. It has nothing to do with the JDK or supporting the Java language. It belongs squarely in Commons Math. 2) IEEE754rUtils should move to the root of commons.lang 3) NumberUtils should move to the root of commons.lang We discussed Fraction being deleted earlier in 3.0, but the view was to keep it. I'm happy for it to go. [math]'s version appears to be practically the same. Half of NumberUtils is String conversion. The other half are min/max; which is what IEEE754Utils is. These could potentially move to [math]'s util.MathUtils. One advantage is that people looking for these minor methods would have an on ramp into the other components for the more powerful features. One concern I have is finding the basic functionality in another package. You go to [math] and it's all about the powerful deep things, not a random reusable bit of code off to the side. Maybe the right solution there is Commons Common, with 80% reuse/20% power; or maybe the solution is documentation in which all the basic types of methods are collated and link to the components they're in. We probably lack good documentation on the basic utility parts in [math]. Luc Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[lang] Divesting the commons.lang.math package
This is how I believe the commons.lang.math package can be eliminated. Based on the current 3.0-SNAPSHOT API, there are only three classes left: Fraction IEEE754rUtils NumberUtils 1) Fraction should leave; it is completely inappropriate for this library. It has nothing to do with the JDK or supporting the Java language. It belongs squarely in Commons Math. 2) IEEE754rUtils should move to the root of commons.lang 3) NumberUtils should move to the root of commons.lang That's it. Pretty simple. Paul - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] Divesting the commons.lang.math package
On Sat, Jan 2, 2010 at 1:57 PM, Paul Benedict pbened...@apache.org wrote: This is how I believe the commons.lang.math package can be eliminated. Based on the current 3.0-SNAPSHOT API, there are only three classes left: Fraction IEEE754rUtils NumberUtils 1) Fraction should leave; it is completely inappropriate for this library. It has nothing to do with the JDK or supporting the Java language. It belongs squarely in Commons Math. 2) IEEE754rUtils should move to the root of commons.lang 3) NumberUtils should move to the root of commons.lang We discussed Fraction being deleted earlier in 3.0, but the view was to keep it. I'm happy for it to go. [math]'s version appears to be practically the same. Half of NumberUtils is String conversion. The other half are min/max; which is what IEEE754Utils is. These could potentially move to [math]'s util.MathUtils. One advantage is that people looking for these minor methods would have an on ramp into the other components for the more powerful features. One concern I have is finding the basic functionality in another package. You go to [math] and it's all about the powerful deep things, not a random reusable bit of code off to the side. Maybe the right solution there is Commons Common, with 80% reuse/20% power; or maybe the solution is documentation in which all the basic types of methods are collated and link to the components they're in. Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
