Re: Move math algorithms from all projects to math libraries

Hello. Le mar. 18 juil. 2023 à 15:25, Dimitrios Efthymiou a écrit : > > Hi Gilles. Question about the clustering package What should happen? > Create a new module commons-math-clustering and then > literally move the code from legacy to commons-math-clustering? > Are there tickets or should I cre

Re: Move math algorithms from all projects to math libraries

Hi Gilles. Question about the clustering package What should happen? Create a new module commons-math-clustering and then literally move the code from legacy to commons-math-clustering? Are there tickets or should I create one that explains that we are moving the legacy clustering package to a new

Re: Move math algorithms from all projects to math libraries

On Tue, 18 Jul 2023 at 09:43, Gilles Sadowski wrote: > > Hello. > > Le mar. 18 juil. 2023 à 02:48, Dimitrios Efthymiou > a écrit : > > > > Thanks Gilles. I checked NUMBERS-193 and i have an implementation of DD and > > i will put it in *.ext package (TBD) along with some tests. Do i have to > > l

Re: Move math algorithms from all projects to math libraries

Hello. Le mar. 18 juil. 2023 à 02:48, Dimitrios Efthymiou a écrit : > > Thanks Gilles. I checked NUMBERS-193 and i have an implementation of DD and > i will put it in *.ext package (TBD) along with some tests. Do i have to > look at Dfd.java or something, because these dfd classes in math legacy

Re: Move math algorithms from all projects to math libraries

Absolutely. Thanks On Tue, 18 Jul 2023, 07:39 Alex Herbert, wrote: > On Tue, 18 Jul 2023 at 01:48, Dimitrios Efthymiou > wrote: > > > > Thanks Gilles. I checked NUMBERS-193 and i have an implementation of DD > and > > i will put it in *.ext package (TBD) along with some tests. Do i have to > >

Re: Move math algorithms from all projects to math libraries

On Tue, 18 Jul 2023 at 01:48, Dimitrios Efthymiou wrote: > > Thanks Gilles. I checked NUMBERS-193 and i have an implementation of DD and > i will put it in *.ext package (TBD) along with some tests. Do i have to > look at Dfd.java or something, because these dfd classes in math legacy > core have

Re: Move math algorithms from all projects to math libraries

Thanks Gilles. I checked NUMBERS-193 and i have an implementation of DD and i will put it in *.ext package (TBD) along with some tests. Do i have to look at Dfd.java or something, because these dfd classes in math legacy core have lots of hard-coded decimals in there. Do these need to be copied to

Re: Move math algorithms from all projects to math libraries

Le mar. 18 juil. 2023 à 00:38, Dimitrios Efthymiou a écrit : > > good to know. I also see > https://cwiki.apache.org/confluence/display/COMMONS/MathWishList > Is this page still valid. At the top: ---CUT--- Created by ASF Infrabot, last modified on Nov 01, 2013 ---CUT--- What do you think? This i

Re: Move math algorithms from all projects to math libraries

good to know. I also see https://cwiki.apache.org/confluence/display/COMMONS/MathWishList Is this page still valid. I mean, could I work on one of these, like Add further functionality for BigDecimal and BigInteger

Re: Move math algorithms from all projects to math libraries

OK. That is what I need to know. Thank you Gilles On Mon, 17 Jul 2023 at 23:22, Gilles Sadowski wrote: > Le lun. 17 juil. 2023 à 20:49, Dimitrios Efthymiou > a écrit : > > > > All i am saying is that if HBase has a class, say MathUtils and a method > > add(double... numbers) and its body has th

Re: Move math algorithms from all projects to math libraries

Le lun. 17 juil. 2023 à 20:49, Dimitrios Efthymiou a écrit : > > All i am saying is that if HBase has a class, say MathUtils and a method > add(double... numbers) and its body has the math algorithm to do addition, > we can just replace the method body with a call to the appropriate math > class t

Re: Move math algorithms from all projects to math libraries

All i am saying is that if HBase has a class, say MathUtils and a method add(double... numbers) and its body has the math algorithm to do addition, we can just replace the method body with a call to the appropriate math class that does addition. That's all i am saying. HBase, for example already de

Re: Move math algorithms from all projects to math libraries

Le lun. 17 juil. 2023 à 15:19, Dimitrios Efthymiou a écrit : > > I don't have specific functionality in mind. You mentioned ASF projects which, IIUC, you said depend on "Commons Math". So I asked: On which "Commons Math" utilities do they depend? [Last time I checked (I don't remember where or

Re: Move math algorithms from all projects to math libraries

I don't have specific functionality in mind. I just had an idea to do a search for dependencies on java.lang.Math or BigInteger or BigDecimal and if I find any, I would see if these dependencies exist because the project has its own custom math algorithms. If yes then, there you go. We have somethi

Re: Move math algorithms from all projects to math libraries

Le lun. 17 juil. 2023 à 02:34, Dimitrios Efthymiou a écrit : > > I didn't say to introduce a dependency on math. I said that libraries that > already depend on math, may have math algorithms implemented that we could > replace with a call to the appropriate commons math methods Sounds nice. If we

Re: Move math algorithms from all projects to math libraries

Hi. Le lun. 17 juil. 2023 à 02:08, Gary Gregory a écrit : > > At one point, I had proposed to deprecate Commons Lang' math package in > favor of something else in Commons Math or elsewhere. Commons Lang would > NOT depend on Commons Math/Other, we would just deprecate with a forwarding > link. >

Re: Move math algorithms from all projects to math libraries

I didn't say to introduce a dependency on math. I said that libraries that already depend on math, may have math algorithms implemented that we could replace with a call to the appropriate commons math methods or if math doesn't have those math algorithms, we can move them to math. Flink and HBase

Re: Move math algorithms from all projects to math libraries

At one point, I had proposed to deprecate Commons Lang' math package in favor of something else in Commons Math or elsewhere. Commons Lang would NOT depend on Commons Math/Other, we would just deprecate with a forwarding link. This idea was rejected IIRC because I do not think there was agreement