I saw 1575, but I didn't see subtasks for all 14 packages. Is there a plan to modularise all 14 packages? 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, slowly. 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
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 > >