Thanks Gilles for the ideas.
Now I have an idea what to do. I go through the codes in
And I could identify the coupling hierarchy at the top level. So I would
like to get a start from Confidence Interval
. It seems a minor dependencies in the class it self.
How can I begin contributing? Could you please share the repo Links
corresponding to CM Statistics.
Where can we find the old code before port into new Commons components? As
you mentioned it will be a good approach to redesign process. To get a good
comparison, links of CM's Random Package code repo and current CM RNG
On 11 March 2018 at 17:07, Gilles <gil...@harfang.homelinux.org> wrote:
> On Sun, 11 Mar 2018 08:30:02 +0530, Gimhana Nadeeshan wrote:
>> Hi devs,
>> I am an 3rd year Computer Science and Engineering undergraduate of
>> University of Moratuwa and I am interested in mathematics so much. So I
>> would like to work on porting codes from Commons Math to Commons
>> component as my GSOC 2018 project.
> So How to get a head start on this problem?
> The big picture is that the "Commons Math" code must be
> split into either new components (as "sub-projects" are
> called within the "Apache Commons" project), or maven module
> within "Commons Math" (CM).
> Which of the alternatives depends on whether a "scope" (or
> "subject matter") can be clearly identified, and whether a
> fairly broad usefulness can be assumed.
> Practically, you can see how the premise turned out for
> functionalities there were/are already in the porting
> * CM's "random" package -> component "Commons RNG"
> * CM's "complex", "fraction", "util", "primes", "special"
> packages -> modules in component "Commons Numbers"
> * CM's "distribution" package -> "distribution" module
> in "Commons Statistics"
> At least one other CM package would make an obvious new
> component: "geometry".
> What should I port first
> The goal is modularization (for easier usage, maintenance,
> and development).
> The modules must not have circular dependencies. Hence
> the first step is to identify dependencies and define
> the "boundaries" of purported modules.
> The easiest is of course to define modules that have
> zero dependencies.
> Then, modules that depend on those.
> And so on, up the hierarchy.
> In practice, each ported functionality usually becomes
> a dependency of CM (whose unit test suites should still
> pass when they use the ported code).
> Dependency on other "Commons" components is allowed;
> runtime dependency on external libraries other than
> the JDK is not.
>> how to redesign it?
> I'm afraid there is no single answer.
> Personally, I don't have a clear idea of what should
> be the grand vision. Do you have suggestions?
> It would certainly be helpful to have a summary of the
> design principles used in other (OO) libraries.
> Guidelines could also perhaps be deduced from reported
> bugs, some of which are mentioned in the page of the
> GSoC report.
> I hope that other people reading this will chime in and
> help draw a concrete plan.
> Best regards,
> Best Regards,
>  https://commons.apache.org/rng
>  https://commons.apache.org/numbers
>  https://commons.apache.org/proper/commons-statistics/
>  https://issues.apache.org/jira/browse/STATISTICS-5
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
Batch Representative (15' batch)
Department of Computer Science & Engineering
University of Moratuwa
*Website : https://ngimhana94.wixsite.com/gimhanadesilva/