Hello Devs, Thanks Gilles and Eric for guidance.
I have cloned the Commons repos and forked the Common's Stat repo. Is it possible to make pull requests to that repo to be reviewed? Or should I follow a specific method? By referring the API docs I got some idea of the separation of modules. In the current Commons's stat repo there are some classes under the package distribution. I think those can be refactored using java 8 in build statistics functionalities. Please correct me if I wrong. As Eric said separation of function and streaming implementations is good idea as designing. (In my point of view, it means method overloading -> Again correct me if I didn't understand your fact correctly) And I will share my draft proposal here for your review soon. Best Regards. On 13 March 2018 at 20:50, Gilles <gil...@harfang.homelinux.org> wrote: > 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 > >
