On Tue, 13 Mar 2018 09:25:19 +0100, Eric Barnhill wrote:
On Tue, Mar 13, 2018 at 12:47 AM, Gilles <gil...@harfang.homelinux.org>

Where can we find the old code before port into new Commons components?

The code bases are managed by the "git" software; the whole history is

[I'd advise to "clone" the repositories on your local computer, and
use the command line tools.]

I believe you will want to clone the commons-math repositories, but then develop your own "fork" of the commons-statistics repository. Gilles can
correct me if that is wrong.

Actually, I know only my workflow:
 $ git clone ...
 $ git branch ...
 $ git commit ...
 $ git push


I didn't find it very easy to cooperate with developers who
fork on GitHub and submit PRs.
I've now found the "git" command that creates a branch from
a PR, but it would be so much more comfortable to just switch
directory and do "git pull".

In the context of GSoC, would it be possible to grant some
privilege to non-committers so that they can update a selected
"git" repository?
If not, what is the next easiest way to share a "common space"
(aka "sandbox") from which it would be easy to copy reviewed
bits over to the official source repository?

you mentioned it will be a good approach to redesign process.

You don't necessarily need to analyze how the code was before
the port/refactoring; looking at how it is now is sufficient,
unless you suspect that something is wrong now and might have
been better before. ;-)

In particular, the statistics library was designed before Java 8. Java 8
however has provided both efficient programming strategies for these
statistical methods (in the form of lambdas and streams) as well as some built-in methods providing summary statistics functions (see discussion at

Very good point, indeed.
IMO, the new component should be targeted Java 8.
Even Java 9 (enforcing modularity with JPMS): if by the time we think
of releasing the code, we still want to avoid "multi-release" JARs it
will be easy to just remove the "module-info" files (I don't think much
else Java 9 specific would used by "Commons Statistics").

In fact, given the very slow pace at which new components are being
brought to releasable state, I'd like to ask whether it would be OK
to make "incremental" releases?  That would mean: focus on (maven)
modules that seem close to feature-complete and bug-free, fix the
remaining issues and perform a release with that module added.

It seems that the expectations were set to high (content-wise given
the amount of human resources), so that neither CM can be released
(too many non-fixed issues) nor its "Commons Numbers" spin-off that
contains many modules, some of which are blocked by lack of consensus
or dangling discussions.

It probably makes sense, as a design strategy, to separate the function implementation from the streaming implementation. For example, a 2D integer array will probably require a different streaming implementation than a 1D
double array, but they can  probably both be passed the same function
handle to collect, say, the mean or max value.

The role of commons might then be to provide a convenient interface, so that the user can simply call a static method like SummaryStats.mean() and
not have to worry about the implementation.

The other difficulty I see, is that quantile and median statistics will not be as easy to stream as statistics with a closed-form solution like mean or variance. There may however be great algorithms out there for pulling the median or the 95% quantile out of a stream -- if so they should be used.



Would you be the official "mentor" for the GSoC participants that
are interested in helping with the porting of "o.a.c.math4.stat"?

Thank you,

To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to