Le jeu. 20 juil. 2023 à 23:46, Dimitrios Efthymiou
a écrit :
>
> I am not home now, but these are the ones i remember from looking at the
> GitHub repo:
> AbstractStorelessUnivariateStatistic.java
> AbstractUnivariateStatistic.java
> WeightedEvaluation.java
> Sum.java
> FirstMoment.java
>
I am not home now, but these are the ones i remember from looking at the
GitHub repo:
AbstractStorelessUnivariateStatistic.java
AbstractUnivariateStatistic.java
WeightedEvaluation.java
Sum.java
FirstMoment.java
Mean.java
SecondMoment.java
StandardDeviation.java
Variance.java
VectorialMean.java
On
I am not home now, but these are the ones i remember from looking at the
GitHub repo:
AbstractStorelessUnivariateStatistic.java
AbstractUnivariateStatistic.java
WeightedEvaluation.java
Sum.java
FirstMoment.java
Mean.java
SecondMoment.java
StandardDeviation.java
Variance.java
VectorialMean.java
Le jeu. 20 juil. 2023 à 23:28, Dimitrios Efthymiou
a écrit :
>
> Unfortunately, i just tried a simple move, but there are deoendencies on 3
> distance classes
But... those classes are only used by the "clustering" package; they
are not external dependencies; they would go into the new module
as
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, wrote:
> Le jeu. 20 juil. 2023 à 21:19,
Le jeu. 20 juil. 2023 à 21:19, Dimitrios Efthymiou
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
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?
On Thu,
Hello.
Le mer. 19 juil. 2023 à 12:59, Dimitrios Efthymiou
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
Le mer. 19 juil. 2023 à 17:48, Elliotte Rusty Harold
a écrit :
>
> On Wed, Jul 19, 2023 at 11:38 AM Gilles Sadowski wrote:
>
> > I think that the page one would look for is this one:
> >https://commons.apache.org/proper/commons-math/dependency-info.html
>
> It's fine to put it there, but
On Wed, Jul 19, 2023 at 11:38 AM Gilles Sadowski wrote:
> I think that the page one would look for is this one:
>https://commons.apache.org/proper/commons-math/dependency-info.html
It's fine to put it there, but even if it's correct it's still too
hard to find. The only way to get to that
Le mer. 19 juil. 2023 à 16:03, Elliotte Rusty Harold
a écrit :
>
> On Wed, Jul 19, 2023 at 9:53 AM Gilles Sadowski wrote:
>
> > > org.apache.commons.math4 and org.apache.commons.math3
> > >
> > > Although it's not easy to find,
> >
> > What do you mean?
> > Is it something we can fix here?
> >
>
On Wed, Jul 19, 2023 at 9:53 AM Gilles Sadowski wrote:
> > org.apache.commons.math4 and org.apache.commons.math3
> >
> > Although it's not easy to find,
>
> What do you mean?
> Is it something we can fix here?
>
Probably. I did a google search and hunted around on the web pages at
Le mer. 19 juil. 2023 à 14:58, Elliotte Rusty Harold
a écrit :
>
> Commons Math 4 and Commons Math 3 have different java packages:
>
> org.apache.commons.math4 and org.apache.commons.math3
>
> Although it's not easy to find,
What do you mean?
Is it something we can fix here?
> it does look like
Commons Math 4 and Commons Math 3 have different java packages:
org.apache.commons.math4 and org.apache.commons.math3
Although it's not easy to find, it does look like the Maven
coordinates have changed as well.
so it's effectively a completely new release of a new project that
can coexist
Hi.
Le mer. 19 juil. 2023 à 13:43, Elliotte Rusty Harold
a écrit :
>
> Ok, don't do that unless it's new code in new packages. Otherwise
> you're creating a dependency hell for existing clients. It is
> extremely developer hostile. Pretty much all of https://jlbp.dev/
> applies but especially
>
Hello.
Le mer. 19 juil. 2023 à 12:59, Dimitrios Efthymiou
a écrit :
>
> 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.
It
I see. I didn't suggest I would start creating modules here and there.
I just wanted to know if there is a plan to, eventually, put all
those legacy packages into their own projects like analysis,
linear algebra, special functions, optimisation, etc.
That's all. I am not gonna do it. But since on
Ok, don't do that unless it's new code in new packages. Otherwise
you're creating a dependency hell for existing clients. It is
extremely developer hostile. Pretty much all of https://jlbp.dev/
applies but especially
JLBP-5: Do not include a class in more than one classpath entry
JLBP-6: Rename
no. I mean creating maven modules inside commons-math, like
the existing ones:
commons-math-neuralnet
commons-math-transform
On Wed, 19 Jul 2023 at 12:29, Elliotte Rusty Harold
wrote:
> Could you be precise about what you mean by "modularisation"? It's a
> very overloaded term. Do you mean Java
Could you be precise about what you mean by "modularisation"? It's a
very overloaded term. Do you mean Java 9 modules as defined by the
JPMS?
On Wed, Jul 19, 2023 at 12:33 AM Dimitrios Efthymiou
wrote:
>
> Hello everyone. Is there, or gonna be, a dedicated ticket for the
> modularisation of all
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
Hello.
Le mer. 19 juil. 2023 à 11:21, Dimitrios Efthymiou
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:
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
Hello.
Le mer. 19 juil. 2023 à 02:33, Dimitrios Efthymiou
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
Hello everyone. Is there, or gonna be, a dedicated ticket for the
modularisation of all 14 packages commons-math-legacy has? I think that
some of them are easy to modularise like optimisation, special and filter
25 matches
Mail list logo
