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
