Unfortunately, i just tried a simple move, but there are deoendencies on 3 distance classes and about 12 stats classes, because there are transitive dependencies. Not to mention the respective test classes.
On Thu, 20 Jul 2023, 22:22 Gilles Sadowski, <gillese...@gmail.com> wrote: > Le jeu. 20 juil. 2023 à 21:19, Dimitrios Efthymiou > <efthymiou.dimitri...@gmail.com> a écrit : > > > > are you saying that in order to move the ml.clustering classes > > to the new clustering module, I can take all the dependencies to classes > > and their transitive dependencies, copy them to the new clustering > module, > > but only keep in them the minimum required code for the new module to > > operate? > > To some extent, yes. But the main point is the refactoring. For example, > your wouldn't copy the code from "linear" after seeing that one can do > without it. But also note in this case that exposing a "double[][]" > instead > may not be the best choice for a long-term API. As was mentioned, it > would be worth looking at how other libraries provide similar > functionality. > The module should solve all issues mentioned in JIRA; it's not just copying > the classes and removing dependencies. > > Gilles > > > > > On Thu, 20 Jul 2023 at 15:27, Gilles Sadowski <gillese...@gmail.com> > wrote: > > > > > Hello. > > > > > > Le mer. 19 juil. 2023 à 12:59, Dimitrios Efthymiou > > > <efthymiou.dimitri...@gmail.com> a écrit : > > > > > > > > [...] > > > > 1-- [...] > > > > 2--As for the atomic refactoring and feature branch, well, > > > > unless someone moves the Variance class (you said that someone > > > > is doing it now) and the distance package and whatever other > > > > dependencies exist within the ml.clustering package, > > > > there can be no moving of the remaining clustering classes > > > > to the new clustering module, right? > > > > 3-- [...] > > > > 4--I don't know how to continue with the clustering modularisation > > > > given all those dependencies. Maybe I shouldn't have started this, > > > > because now I am stuck > > > > > > You aren't. > > > > > > The dependencies found in "o.a.c.math4.legacy.ml.clustering" are > > > (1) "MatrixUtils" and "RealMatrix" (from the "linear" package) > > > (2) "Variance" and "VectorialMean" (from the "stat" package) > > > > > > (1) creates the coupling for a single method ("getMembershipMatrix") > > > that isn't called from anywhere (not even the unit tests). Remove the > > > method and the dependency towards "linear" vanishes. > > > > > > (2) "Variance" can be replaced with a temporary implementation like > > > (untested copy/paste from "SecondMoment" and "FirstMoment"): > > > ---CUT--- > > > class Variance { > > > private int n = 0; > > > private double dev = 0; > > > private double nDev = 0; > > > private double m2 = 0; > > > private double m1 = 0; > > > > > > void increment(final double d) { > > > ++n; > > > dev = d - m1; > > > nDev = dev / n; > > > m1 += nDev; > > > m2 += ((double) n - 1) * dev * nDev; > > > } > > > > > > double get() { > > > return m2; > > > } > > > } > > > ---CUT--- > > > Then, creating a private copy of class "VectorialMean" (replacing, > > > in the copy, CM exceptions with JDK ones) would complete the > > > removal of the dependency towards the "stat" package. > > > > > > And so on. > > > > > > Regards, > > > Gilles > > > > > > > > > [...] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >