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 module? Where is the document with the precise requirements and instructions?
On Mon, 17 Jul 2023 at 18:39, Gilles Sadowski <gillese...@gmail.com> wrote: > Le lun. 17 juil. 2023 à 15:19, Dimitrios Efthymiou > <efthymiou.dimitri...@gmail.com> 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 how), most were from the "stat" package).] > > > 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 something to replace by > > utilising the commons math libraries. I haven't done a > > search yet. I wanted to see if the community would be OK > > with new tickets (if any) for new functionality to be implemented > > in the math libraries, GIVEN that there will automatically be > > use-cases i.e. apache already uses those algorithms. > > When I suggest new math functionality, I am always asked > > what the use-cases are and I don't have any, because I just > > want to implement unimplemented math algorithms. So, I thought > > that this way (if I find any) there will be use-cases > > Yes, but if those projects don't want to depend on the new > functionality, your time would be better used elsewhere. > As you could read today[1], it's difficult to even share code > inside the "Commons" project. For another project to > delegate some functionality is much more to ask. What > usually happens is the other way around; some functionality > already exists somewhere, and is taken advantage of right > away. > For better or (and?) worse, most use-cases came from > people who were using CM and needed something more, > which they contributed back. > Since it's "there" already, better improve it than find more > things to add (if you don't have use-cases for them). > Did I mention "clustering" and "genetic algorithm"? > > Regards, > Gilles > > [1] https://issues.apache.org/jira/browse/IMAGING-358 > > > > > On Mon, 17 Jul 2023 at 11:43, Gilles Sadowski <gillese...@gmail.com> > wrote: > > > > > Le lun. 17 juil. 2023 à 02:34, Dimitrios Efthymiou > > > <efthymiou.dimitri...@gmail.com> 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 could already do that just within "Commons"... (see other post). > > > > > > > or if math > > > > doesn't have those math algorithms, we can move them to math. Flink > and > > > > HBase for example depend on math > > > > > > For which functionality? > > > > > > Regards, > > > Gilles > > > > > > >> [...] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
