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
>
>

Reply via email to