Hello.
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>
wrote:
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
available:
https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=log
[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?
As
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
http://markmail.org/message/7t2mjaprsuvb3waj).
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.
Eric
Eric,
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,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
