Re: [Numbers] Scope?
On Thu, 02 Feb 2017 09:03:06 +0100, Jörg Schaible wrote: Gilles wrote: Hi. On Wed, 01 Feb 2017 19:28 +0100, Jörg Schaible wrote: Hi Raymond, Raymond DeCampo wrote: On Mon, Jan 30, 2017 at 8:58 AM, Gilles wrote: A very important issue here: what JDK version do we target? I'd go for Java8, in the hope to revive interest in Commons from an audience that might be put off by the "no fun" of older and soon unsupported JVM. I am inclined to go with Java 8. Oracle has stopped public updates for Java 7, so perhaps "soon unsupported" is an understatement. Android still does not even provide Java 8 support. There are always more players in the camp than expected. It would be great to have those players in our camp! I'm not against targetting old Java (cf. "Commons RNG"), so let's not start the wrong fight. The issue is: What do we gain (really) and what do we loose (really) going one way or the other? One aspect is that if we have separate components, they can target different versions (each time answering the above question). People in "Commons" pushing for a supposedly minimal mass for a component are at odds with offering more choices to contributors. We can't be expected to work with a hand tied behind the back for the sake of the "unknown" programmer. Removing the fun entails less opportunities to gather interest for the project, so that eventually there won't be any code at all, neither Java 8, nor Java 7. Don't get me wrong. I am not against Java 8 here, but the arguments "it is not maintained by Oracle" or "nobody is using it anymore" are simply not valid. I maintain other open source stuff and I get regularily complaints from developers if they cannot port their Java apps to Android where classes targeting Java 8 are not usable. How can we get that information from users, so that we can decide how to proceed, component per component? If we decide, we have a big benefit e.g. by using lambdas or streams, fine. We just have to be clear about the consequences. Is Numbers exotic enough that nearly no one expects it to run on Android? Allow me to reverse the question: Do we want to make it exotic enough in order to make it relevant in the future? Surely, we can keep the "Complex" class Java 5 compatible, but in a context becoming more "functional", shouldn't we go ahead and think about how to make it more fit to it?[1] By playing it safe, "Commons" is becoming less and less relevant, both in contents and in attractiveness. Regards, Gilles [1] "Complex" in CM 3.6.1 is still available for Android apps. Cheers, Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Numbers] Scope?
On Thu, 2 Feb 2017 13:15:00 +, sebb wrote: On 2 February 2017 at 12:35, Emmanuel Bourg wrote: Le 1/02/2017 à 20:11, Gilles a écrit : One aspect is that if we have separate components, they can target different versions (each time answering the above question). People in "Commons" pushing for a supposedly minimal mass for a component are at odds with offering more choices to contributors. We can't be expected to work with a hand tied behind the back for the sake of the "unknown" programmer. Removing the fun entails less opportunities to gather interest for the project, so that eventually there won't be any code at all, neither Java 8, nor Java 7. Keep in mind that developers are users before becoming contributors. If we target a narrower set of users we also limit our ability to recruit new contributors. So we have to find a balance between not too old technologies to avoid scaring potential contributors, and not too recent to keep a decent user base that will provide new contributors. As far as I'm concerned the 'scary' limit is anything < Java 5. I wouldn't mind contributing to a Java 5, 6 or 7 project is it's fulfilling an important need for me. +1 The reasoning is fine. But concretely, we've seen more people leaving this project because of a perceived "backwardness" than the opposite. [At a presentation of Commons Math (FOSDEM 2013), a question was asked about the Java version; the answer (that the we'd stick to Java 5) elicited a perplexed look (and zero contributor).] From your argument above, we could conclude that any project that is not attracting new contributors is useless. Is that so? If not, there must be something else, something other than the contents, that should make people willing to volunteer here rather than take the code and do their stuff somewhere else... Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Numbers] Scope?
On 2 February 2017 at 12:35, Emmanuel Bourg wrote: > Le 1/02/2017 à 20:11, Gilles a écrit : > >> One aspect is that if we have separate components, they can target >> different versions (each time answering the above question). >> People in "Commons" pushing for a supposedly minimal mass for a >> component are at odds with offering more choices to contributors. >> >> We can't be expected to work with a hand tied behind the back for >> the sake of the "unknown" programmer. >> Removing the fun entails less opportunities to gather interest for >> the project, so that eventually there won't be any code at all, >> neither Java 8, nor Java 7. > > Keep in mind that developers are users before becoming contributors. If > we target a narrower set of users we also limit our ability to recruit > new contributors. So we have to find a balance between not too old > technologies to avoid scaring potential contributors, and not too recent > to keep a decent user base that will provide new contributors. > > As far as I'm concerned the 'scary' limit is anything < Java 5. I > wouldn't mind contributing to a Java 5, 6 or 7 project is it's > fulfilling an important need for me. +1 > Emmanuel Bourg > > > - > 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: [Numbers] Scope?
Le 1/02/2017 à 20:11, Gilles a écrit : > One aspect is that if we have separate components, they can target > different versions (each time answering the above question). > People in "Commons" pushing for a supposedly minimal mass for a > component are at odds with offering more choices to contributors. > > We can't be expected to work with a hand tied behind the back for > the sake of the "unknown" programmer. > Removing the fun entails less opportunities to gather interest for > the project, so that eventually there won't be any code at all, > neither Java 8, nor Java 7. Keep in mind that developers are users before becoming contributors. If we target a narrower set of users we also limit our ability to recruit new contributors. So we have to find a balance between not too old technologies to avoid scaring potential contributors, and not too recent to keep a decent user base that will provide new contributors. As far as I'm concerned the 'scary' limit is anything < Java 5. I wouldn't mind contributing to a Java 5, 6 or 7 project is it's fulfilling an important need for me. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Numbers] Scope?
Gilles wrote: > Hi. > > On Wed, 01 Feb 2017 19:28 +0100, Jörg Schaible wrote: >> Hi Raymond, >> >> Raymond DeCampo wrote: >> >>> On Mon, Jan 30, 2017 at 8:58 AM, Gilles >>> >>> wrote: >>> A very important issue here: what JDK version do we target? I'd go for Java8, in the hope to revive interest in Commons from an audience that might be put off by the "no fun" of older and soon unsupported JVM. >>> >>> >>> I am inclined to go with Java 8. Oracle has stopped public updates >>> for >>> Java 7, so perhaps "soon unsupported" is an understatement. >> >> Android still does not even provide Java 8 support. There are always >> more >> players in the camp than expected. > > It would be great to have those players in our camp! > > I'm not against targetting old Java (cf. "Commons RNG"), so let's > not start the wrong fight. > The issue is: What do we gain (really) and what do we loose (really) > going one way or the other? > > One aspect is that if we have separate components, they can target > different versions (each time answering the above question). > People in "Commons" pushing for a supposedly minimal mass for a > component are at odds with offering more choices to contributors. > > We can't be expected to work with a hand tied behind the back for > the sake of the "unknown" programmer. > Removing the fun entails less opportunities to gather interest for > the project, so that eventually there won't be any code at all, > neither Java 8, nor Java 7. Don't get me wrong. I am not against Java 8 here, but the arguments "it is not maintained by Oracle" or "nobody is using it anymore" are simply not valid. I maintain other open source stuff and I get regularily complaints from developers if they cannot port their Java apps to Android where classes targeting Java 8 are not usable. If we decide, we have a big benefit e.g. by using lambdas or streams, fine. We just have to be clear about the consequences. Is Numbers exotic enough that nearly no one expects it to run on Android? Cheers, Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Numbers] Scope?
Hi. On Wed, 01 Feb 2017 19:28 +0100, Jörg Schaible wrote: Hi Raymond, Raymond DeCampo wrote: On Mon, Jan 30, 2017 at 8:58 AM, Gilles wrote: A very important issue here: what JDK version do we target? I'd go for Java8, in the hope to revive interest in Commons from an audience that might be put off by the "no fun" of older and soon unsupported JVM. I am inclined to go with Java 8. Oracle has stopped public updates for Java 7, so perhaps "soon unsupported" is an understatement. Android still does not even provide Java 8 support. There are always more players in the camp than expected. It would be great to have those players in our camp! I'm not against targetting old Java (cf. "Commons RNG"), so let's not start the wrong fight. The issue is: What do we gain (really) and what do we loose (really) going one way or the other? One aspect is that if we have separate components, they can target different versions (each time answering the above question). People in "Commons" pushing for a supposedly minimal mass for a component are at odds with offering more choices to contributors. We can't be expected to work with a hand tied behind the back for the sake of the "unknown" programmer. Removing the fun entails less opportunities to gather interest for the project, so that eventually there won't be any code at all, neither Java 8, nor Java 7. Regards, Gilles There are methods in java.lang.Math introduced in Java 8 (with the naming pattern *Exact) which could simplify/eliminate some of the methods in ArithmeticUtils. Cheers, Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Numbers] Scope?
Hi Raymond, Raymond DeCampo wrote: > On Mon, Jan 30, 2017 at 8:58 AM, Gilles > wrote: > >> >> A very important issue here: what JDK version do we target? >> >> I'd go for Java8, in the hope to revive interest in Commons from an >> audience that might be put off by the "no fun" of older and soon >> unsupported JVM. > > > I am inclined to go with Java 8. Oracle has stopped public updates for > Java 7, so perhaps "soon unsupported" is an understatement. Android still does not even provide Java 8 support. There are always more players in the camp than expected. > There are methods in java.lang.Math introduced in Java 8 (with the naming > pattern *Exact) which could simplify/eliminate some of the methods in > ArithmeticUtils. Cheers, Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Numbers] Scope?
On Tue, 31 Jan 2017 19:28:31 -0500, Raymond DeCampo wrote: On Mon, Jan 30, 2017 at 8:58 AM, Gilles wrote: A very important issue here: what JDK version do we target? I'd go for Java8, in the hope to revive interest in Commons from an audience that might be put off by the "no fun" of older and soon unsupported JVM. I am inclined to go with Java 8. Oracle has stopped public updates for Java 7, so perhaps "soon unsupported" is an understatement. I'm trying to put it in a mild way, given the history of discussions on such issues. The "End of Service Life" of Java 5 was 2009, yet "Commons Math" was still targetting it 7 years later (including the last 2 major versions)! There are methods in java.lang.Math introduced in Java 8 (with the naming pattern *Exact) which could simplify/eliminate some of the methods in ArithmeticUtils. Then we should move the functions that have an "xxxExact" counterparts to "FastMath" (as per the Javadoc of that class, claiming that is a drop-in replacement of "java.lang.Math"). Would you be willing to file a JIRA issue for that task, and take it on? Then a sub-task might be to check whether, as of Java 8, "FastMath" is still faster or more accurate for some functions. Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Numbers] Scope?
On Mon, Jan 30, 2017 at 8:58 AM, Gilles wrote: > > A very important issue here: what JDK version do we target? > > I'd go for Java8, in the hope to revive interest in Commons from an > audience that might be put off by the "no fun" of older and soon > unsupported JVM. I am inclined to go with Java 8. Oracle has stopped public updates for Java 7, so perhaps "soon unsupported" is an understatement. There are methods in java.lang.Math introduced in Java 8 (with the naming pattern *Exact) which could simplify/eliminate some of the methods in ArithmeticUtils. >
Re: [Numbers] Scope?
On Mon, 30 Jan 2017 12:40:06 +0100, Eric Barnhill wrote: I agree the solvers don't seem to be in the scope. Let's agree to defer the decision. :-) The MathArrays are a great idea but could use some rethinking. Fine thne. Could you please start a new thread with some of the things to rethink about? First of all there are leftover references to classes like Field that have disappeared with the larger math framework and these should go. Agreed (no use-case have popped up IIRC). Also, there are a lot of basic array-wise operations that might benefit from inclusion. To pick an example at random, element-by-element cosine. In fact I already have a whole library of these (very simple) methods for up to 3 dimensions which I would be happy to contribute. My understanding is that such operations can be accomplished elegantly with lambdas now. But speaking only for myself, I tend to stick to "old school" Java syntax and I know I find these methods very useful. A very important issue here: what JDK version do we target? I'd go for Java8, in the hope to revive interest in Commons from an audience that might be put off by the "no fun" of older and soon unsupported JVM. If there was general agreement on inclusion of MathArrays, I am happy to work on it. Great. But let's discuss first the above. Gilles Eric On Mon, Jan 30, 2017 at 8:49 AM, Emmanuel Bourg wrote: Hi, Shouldn't [numbers] focus only on number structures (fractions, complex) and the basic operations on them? I'm not sure the solvers fit in the scope. Emmanuel Bourg Le 30/01/2017 à 02:17, Gilles a écrit : > Hi. > > Anyone has a statement about it? > > Functionalities that are candidates to be moved from "Math" > to "Numbers": > * FastMath > * CombinatoricsUtils [1] > * ContinuedFraction [1] > * special functions [1] > * solvers > * MathArrays [2] > * MathUtils [1] > * ... > > Thanks, > Gilles > > [1] With redesigned API (e.g. to allow usage as Java8 functional > interface). > [2] Partly (e.g. "linearCombination"). > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Numbers] Scope?
On Mon, 30 Jan 2017 12:30:20 +0100, Emmanuel Bourg wrote: Le 30/01/2017 à 12:08, Gilles a écrit : Ideally, it should be another light-weight component (because solvers are used in so many areas). This thread is about if (and how) we can try and stretch the scope a little, so as to group several basic utilities in a single component. I'd prefer creating [math] sub modules than independent components. Either you or I have misunderstood the consensus that CM cannot provide (what I'd call) "partial" releases (I had proposed that currently unsupported code[1] will not be released anymore). The consequence is that the date of the next release of CM was likely to be: never. The consequence of which is that valuable _and_ supported code must be moved to other components (that would also become a good opportunity to get rid of obsolete stuff, and redesign without backwards compatibility burdens) in order to be useful to a larger audience. Otherwise what will be left in [math] once you are done slicing it? Good question. Development can be viewed from the [Math] component POV (removing stuff) or from each of the new components' view (what's in scope?). The former POV leads to project death.[2] The latter is being worked on, and in the end, the goal is that CM will loose nothing[3]: it will depend on other components where the "removed" functionality has been transferred. A big component like Commons Math is a nightmare to manage; as we've seen, it simply did not work (reasons, according to me, have been already amply exposed on this ML). Small components are more agile. The proposed roadmap increases the chances to attract enough contributors so that eventually the huge task of supporting the whole of CM can be considered again. In the meantime, more focused components can attract contributors who will not have to wait years to see their work released officially. This IMO is actually more community-building stuff than clinging onto an old component, full of good code[4] but an empty shell, community-wise. Gilles Emmanuel Bourg [1] Unsupported = nobody knows the code enough to timely follow up on reports about it. [2] Visible symptom is: nobody works on reports piling up in JIRA. [3] Of course, there will backwards incompatible changes, but that fact was agreed on several years ago, when the then current development branch was aimed at releasing the next major version. [4] But also containing outdated things to be revamped or thrown away. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Numbers] Scope?
On Mon, Jan 30, 2017 at 12:51 PM, sebb wrote: > > > Also, there are a lot of basic array-wise operations that might benefit > > from inclusion. To pick an example at random, element-by-element cosine. > In > > fact I already have a whole library of these (very simple) methods for up > > to 3 dimensions which I would be happy to contribute. > > If every mathematical operation has its own function that quickly gets > very unwieldy to test and maintain. > With C++ complex numbers (a library I have looked at quite a bit) there are three categories of operators: complex operations, transcendental overloads and operator overloads. Keeping with that model for arrays does not add up to so many functions. The new class would be around half those, and half the functions already in the current class (e.g. shuffle, range, norm) some of which are already operator overloads.
Re: [Numbers] Scope?
On 30 January 2017 at 11:40, Eric Barnhill wrote: > I agree the solvers don't seem to be in the scope. > > The MathArrays are a great idea but could use some rethinking. > > First of all there are leftover references to classes like Field that have > disappeared with the larger math framework and these should go. > > Also, there are a lot of basic array-wise operations that might benefit > from inclusion. To pick an example at random, element-by-element cosine. In > fact I already have a whole library of these (very simple) methods for up > to 3 dimensions which I would be happy to contribute. If every mathematical operation has its own function that quickly gets very unwieldy to test and maintain. > My understanding is that such operations can be accomplished elegantly with > lambdas now. But speaking only for myself, I tend to stick to "old school" > Java syntax and I know I find these methods very useful. Or surely one can use a Visitor strategy if lambdas are too modern? > If there was general agreement on inclusion of MathArrays, I am happy to > work on it. > > Eric > > > On Mon, Jan 30, 2017 at 8:49 AM, Emmanuel Bourg wrote: > >> Hi, >> >> Shouldn't [numbers] focus only on number structures (fractions, complex) >> and the basic operations on them? I'm not sure the solvers fit in the >> scope. >> >> Emmanuel Bourg >> >> Le 30/01/2017 à 02:17, Gilles a écrit : >> > Hi. >> > >> > Anyone has a statement about it? >> > >> > Functionalities that are candidates to be moved from "Math" >> > to "Numbers": >> > * FastMath >> > * CombinatoricsUtils [1] >> > * ContinuedFraction [1] >> > * special functions [1] >> > * solvers >> > * MathArrays [2] >> > * MathUtils [1] >> > * ... >> > >> > Thanks, >> > Gilles >> > >> > [1] With redesigned API (e.g. to allow usage as Java8 functional >> > interface). >> > [2] Partly (e.g. "linearCombination"). >> > >> > >> > - >> > 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: [Numbers] Scope?
I agree the solvers don't seem to be in the scope. The MathArrays are a great idea but could use some rethinking. First of all there are leftover references to classes like Field that have disappeared with the larger math framework and these should go. Also, there are a lot of basic array-wise operations that might benefit from inclusion. To pick an example at random, element-by-element cosine. In fact I already have a whole library of these (very simple) methods for up to 3 dimensions which I would be happy to contribute. My understanding is that such operations can be accomplished elegantly with lambdas now. But speaking only for myself, I tend to stick to "old school" Java syntax and I know I find these methods very useful. If there was general agreement on inclusion of MathArrays, I am happy to work on it. Eric On Mon, Jan 30, 2017 at 8:49 AM, Emmanuel Bourg wrote: > Hi, > > Shouldn't [numbers] focus only on number structures (fractions, complex) > and the basic operations on them? I'm not sure the solvers fit in the > scope. > > Emmanuel Bourg > > Le 30/01/2017 à 02:17, Gilles a écrit : > > Hi. > > > > Anyone has a statement about it? > > > > Functionalities that are candidates to be moved from "Math" > > to "Numbers": > > * FastMath > > * CombinatoricsUtils [1] > > * ContinuedFraction [1] > > * special functions [1] > > * solvers > > * MathArrays [2] > > * MathUtils [1] > > * ... > > > > Thanks, > > Gilles > > > > [1] With redesigned API (e.g. to allow usage as Java8 functional > > interface). > > [2] Partly (e.g. "linearCombination"). > > > > > > - > > 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: [Numbers] Scope?
Le 30/01/2017 à 12:08, Gilles a écrit : > Ideally, it should be another light-weight component (because solvers > are used in so many areas). > > This thread is about if (and how) we can try and stretch the scope a > little, so as to group several basic utilities in a single component. I'd prefer creating [math] sub modules than independent components. Otherwise what will be left in [math] once you are done slicing it? Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Numbers] Scope?
On Mon, 30 Jan 2017 08:49:49 +0100, Emmanuel Bourg wrote: Hi, Shouldn't [numbers] focus only on number structures (fractions, complex) and the basic operations on them? Strictly speaking, yes; but I'm trying to fit more in it than just the obvious, so as to not require many new components (although I'd prefer that way). I'm not sure the solvers fit in the scope. I'm also not sure. Ideally, it should be another light-weight component (because solvers are used in so many areas). This thread is about if (and how) we can try and stretch the scope a little, so as to group several basic utilities in a single component. Gilles Emmanuel Bourg Le 30/01/2017 à 02:17, Gilles a écrit : Hi. Anyone has a statement about it? Functionalities that are candidates to be moved from "Math" to "Numbers": * FastMath * CombinatoricsUtils [1] * ContinuedFraction [1] * special functions [1] * solvers * MathArrays [2] * MathUtils [1] * ... Thanks, Gilles [1] With redesigned API (e.g. to allow usage as Java8 functional interface). [2] Partly (e.g. "linearCombination"). - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Numbers] Scope?
Hi. On Mon, 30 Jan 2017 08:10:27 +0100, Benedikt Ritter wrote: Hello Gilles, Am 30.01.2017 um 02:17 schrieb Gilles : Hi. Anyone has a statement about it? Functionalities that are candidates to be moved from "Math" to "Numbers": * FastMath I just thought, maybe FastMath would fit into Commons Lang. WDYT? Could be, but I'd consider it only if Lang would become "multimodule". An interesting feature would be to be able to replace, at runtime, in some portion of code, all calls to "Math" with calls to "FastMath" (or any other class that implement the set of functions provided by the JDK's "Math" class). Is this feasible? [...] (Sorry for OT posting :-)) That's quite on-topic. We should advance on a global roadmap for handling the future of "Commons Math". "FastMath" functions are at least as accurate as "Math". But the "Fast" claim is not verified in some cases (hence a name change might be in order). The functions of "FastMath" are building blocks for other "low-level" functionality; hence it should be made available either "standalone", or in a light-weight component (hence the "Numbers" proposal), or in a module of its own. * CombinatoricsUtils [1] * ContinuedFraction [1] * special functions [1] * solvers * MathArrays [2] * MathUtils [1] * ... Thanks, Gilles [1] With redesigned API (e.g. to allow usage as Java8 functional interface). [2] Partly (e.g. "linearCombination"). - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Numbers] Scope?
Hi, Shouldn't [numbers] focus only on number structures (fractions, complex) and the basic operations on them? I'm not sure the solvers fit in the scope. Emmanuel Bourg Le 30/01/2017 à 02:17, Gilles a écrit : > Hi. > > Anyone has a statement about it? > > Functionalities that are candidates to be moved from "Math" > to "Numbers": > * FastMath > * CombinatoricsUtils [1] > * ContinuedFraction [1] > * special functions [1] > * solvers > * MathArrays [2] > * MathUtils [1] > * ... > > Thanks, > Gilles > > [1] With redesigned API (e.g. to allow usage as Java8 functional > interface). > [2] Partly (e.g. "linearCombination"). > > > - > 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: [Numbers] Scope?
Hello Gilles, > Am 30.01.2017 um 02:17 schrieb Gilles : > > Hi. > > Anyone has a statement about it? > > Functionalities that are candidates to be moved from "Math" > to "Numbers": > * FastMath I just thought, maybe FastMath would fit into Commons Lang. WDYT? Benedikt (Sorry for OT posting :-)) > * CombinatoricsUtils [1] > * ContinuedFraction [1] > * special functions [1] > * solvers > * MathArrays [2] > * MathUtils [1] > * ... > > Thanks, > Gilles > > [1] With redesigned API (e.g. to allow usage as Java8 functional >interface). > [2] Partly (e.g. "linearCombination"). > > > - > 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
[Numbers] Scope?
Hi. Anyone has a statement about it? Functionalities that are candidates to be moved from "Math" to "Numbers": * FastMath * CombinatoricsUtils [1] * ContinuedFraction [1] * special functions [1] * solvers * MathArrays [2] * MathUtils [1] * ... Thanks, Gilles [1] With redesigned API (e.g. to allow usage as Java8 functional interface). [2] Partly (e.g. "linearCombination"). - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
