commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Barnhill <ericbarnh...@gmail.com>
Subject Re: [Math] Commons Math (r)evolution
Date Mon, 06 Jun 2016 08:31:28 GMT
I am not a mathematician so I would not be able to play a particularly
catholic role in commons-math. But, I am always delighted when my research
needs allow me to spin off contributions into the code base.

I work with complex valued 3 to 6-dimensional image volumes. So I am happy
to maintain code involving complex numbers first of all, as well as
investigate their integration their integration with Octave and ImgLib.

I am also interested in code for array-based math operations which is
overwhelmingly how I compute. I would be happy to maintain that code and it
does seem that now and again, suggests for how to refactor it come through
JIRA. I have my own home brewed libraries for syntactically convenient
array wise operations that may also be of interest once everyone is happy
with the current state of the code base.

Eric



On Mon, Jun 6, 2016 at 2:49 AM, Gilles <gilles@harfang.homelinux.org> wrote:

> Hello.
>
> Commons Math as it was in the last official release (v3.6.1) and
> consequently as it is in the current development branch has
> become unmaintainable.
>
> This conclusion is unavoidable when looking at the following:
>  1. codebase statistics (as of today):
>     * src/main/java       90834 lines of Java code (882 files)
>     * src/test/java       95595 lines of Java code (552 files)
>     * src/userguide/java   3493 lines of Java code (19 files)
>  2. number of posts on the "dev" ML (related to [Math]) in the
>     last 2 months:
>     * Gilles            74
>     * Artem Barger      20
>     * sebb              15
>     * Rob Tompkins       9
>     * Eric Barnhill      7
>     * 19 other people   46
>  3. development/maintenance activity in the last 4 months:
>     * commits by Gilles  133
>     * commits by others   12
>
> According to JIRA, among 180 issues currently targeted for the
> next major release (v4.0), 139 have been resolved (75 of which
> were not in v3.6.1).
>
> So, on the one hand, a lot of work has been done already, but
> on the other, a lot remains.
> Some issues have been pending for several years, in particular
> those that required a major refactoring (e.g. in the packages
> "o.a.c.m.linear" and "o.a.c.m.optim").
>
> The remaining work is unlikely to be completed soon since the
> fork of Commons Math has drastically reduced the development
> capacity.
>
> Moreover, as whole areas of the codebase have become in effect
> unsupported, it would be deceiving to release a version 4.0 of
> Commons Math that would include all of it.
>
> Of course, anyone who wishes to maintain some of these codes
> (answer user questions, fix bugs, create enhancements, etc.)
> is most welcome to step forward.
>
> But I'm not optimistic that the necessary level of support can
> be achieved in the near future for all the codebase.
> Waiting for that to happen would entail that code that could
> be in a releasable state soon will be on hold for an indefinite
> time.
>
> The purpose of this post is to initiate a discussion about
> splitting Commons Math, along the following lines:
> 1. Identify independent functionality that can be maintained
>    even by a small (even a 1-person) team within Commons and
>    make it a new component.
> 2. Identify functionality that cannot be maintained anymore
>    inside Commons and try to reach out to users of this
>    functionality, asking whether they would be willing to
>    give a helping hand.
>    If there is sufficient interest, and a new development
>    team can form, that code would then be transferred to the
>    Apache "incubator".
>
> There are numerous advantages to having separate components
> rather than a monolithic library:
>  * Limited and well-defined scope
>  * Immediate visibility of purpose
>  * Lower barrier to entry
>  * Independent development policy
>  * Homogeneous codebase
>  * Independent release schedule
>  * Foster a new community around the component
>
> According to the most recent development activity, the likely
> candidates for becoming a new component are:
>  * Pseudo-random numbers generators (package "o.a.c.m.rng")
>  * Complex numbers (package "o.a.c.m.complex")
>  * Clustering algorithms (package "o.a.c.m.ml.clustering")
>
> Other potential candidates:
>  * "FastMath" (which should be renamed to something like
>    "AccurateMath", cf. reports about slowness of some of
>    the functions)
>  * Special functions (package "o.a.c.m.special")
>  * Selected "utilities" (package "o.a.c.m.util")
>
>
> Best regards,
> Gilles
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message