thanks Gilles. 1--I think I broke the build, because I did not include (correctly) the dependency on clustering inside the root pom.xml. My local build succeeds. I hope that the GitHub build succeeds, as well. 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--I see that the commons-statistics project, for example, has empty modules. I think the geometry project (I don't remember which one) has some classes that are still in commons-math, because the migration is not complete. So, I thought that I coud do the same i.e. move the clusteirng classes that do not depend on anything 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
On Wed, 19 Jul 2023 at 11:36, Gilles Sadowski <gillese...@gmail.com> wrote: > Hello. > > Le mer. 19 juil. 2023 à 11:21, Dimitrios Efthymiou > <efthymiou.dimitri...@gmail.com> a écrit : > > > > I saw 1575, but I didn't see subtasks for all 14 packages. > > Is there a plan to modularise all 14 packages? > > Obviously, it would be good to achieve that, as pointed out > in the release notes of version 4.0-beta1: > https://commons.apache.org/proper/commons-math/changes-report.html > > But there is no "plan", like an ordered list of instructions to > follow from start to end. > The general task is "refactoring". > > > As for the dependencies on core, linear, analysis, well, > > from what I know, the way to modularise a codebase that > > was not designed to be modular, is to start moving classes > > that do not depend on legacy ones, 1-by-1, > > And break the build like it is currently the case with the > "clustering" refactoring? > > > slowly. > > As noted on JIRA[1], the move of an existing functionality into > its own (maven) module should be "atomic" on the "master" > branch. When the refactoring (started on a developer's local > machine) is sufficiently advanced, we can create a feature > branch so that several developers can more easily collaborate. > > > For classes that depend on legacy ones, then we can create > > new analysis and linear modules, create interfaces in them > > that have the methods our new modularised classes need, > > have the legacy classes in analysis and linear implement > > those interfaces, have the legacy module depend on the new > > analysis and linear modules (since they have the new interfaces), > > have the new optimisation module depend on the new > > analysis and linear modules and gradually you can move implementation > > code from the legacy to the new modules. The dependencies > > will be from legacy to the new modules and not the other way > > around. So the process I would try is: > > 1--create module commons-math-optimisation > > 2--create module commons-math-analysis > > 3--create module commons-math-linear-algebra > > 4--see on which analysis classes does optimisation depends? > > 5--see no which specific methods does optimisation depends? > > 6--create interfaces in commons-math-analysis for those classes and their > > methods that optimisation needs > > 7--have the analysis classes implement their respective interfaces from > > commons-math-analysis (maintaining the API) > > 8--have commons-math-legacy depend on commons-math-analysis and > > commons-math-linear-algebra > > 9--use these interfaces from within commons-math-optimisation > > 10-gradual move of methods and classes from commons-math-legacy to > > commons-math-optimisation, commons-math-analysis, > > commons-math-linear-algebra > > Sure! :-} > The devil is in the details... > > One crucial task is to have a way to (optionally) call external > implementations of linear algebra algorithms and data-structures. > I've no idea whether it's possible to adapt all the functionality to a > new design based only on interfaces (and not loose performance). > Unless we can really switch between alternative implementations > this is a lot of work with literally no gain. > Another possibility (also mentioned in [1]) is to isolate the needed > utilities in a "private" toolbox. [However, I'd be *very* reluctant if it > entails copying several hundred or thousand lines.] > > Regards, > Gilles > > [1] > https://issues.apache.org/jira/browse/MATH-1579?focusedCommentId=17744504&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17744504 > > > > > On Wed, 19 Jul 2023 at 09:49, Gilles Sadowski <gillese...@gmail.com> > wrote: > > > > > Hello. > > > > > > Le mer. 19 juil. 2023 à 02:33, Dimitrios Efthymiou > > > <efthymiou.dimitri...@gmail.com> a écrit : > > > > > > > > Hello everyone. Is there, or gonna be, a dedicated ticket for the > > > > modularisation of all 14 packages commons-math-legacy has? > > > > > > https://issues.apache.org/jira/browse/MATH-1575 > > > > > > > I think that > > > > some of them are easy to modularise like optimisation, > > > > > > When I list the dependencies towards other packages in "legacy", > > > I see > > > o.a.c.math4.legacy.core > > > o.a.c.math4.legacy.linear > > > o.a.c.math4.legacy.analysis > > > > > > How do you suggest to handle it? > > > > > > > special > > > > > > Here, there is only one class, but it should be analysed to > > > suggest a better API (and maybe improve performance). > > > There is also the question of whether to provide this and other > > > special functions with extended precision[1] (and maybe move > > > them to [Numbers]; like the gamma family of functions). > > > > > > > and filter > > > > > > When I list the dependencies towards other packages in "legacy", > > > I see > > > o.a.c.math4.legacy.linear > > > > > > Regards, > > > Gilles > > > > > > > > > [1] See section 7.4 in D. Bailey's documentation: > > > https://www.davidhbailey.com/dhbpapers/mpfun2020.pdf > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
