commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [Statistics]Port codes from Commons Math
Date Mon, 12 Mar 2018 23:47:47 GMT
On Mon, 12 Mar 2018 08:43:29 +0530, Gimhana Nadeeshan wrote:
> Hi devs,
>
> Thanks Gilles for the ideas.
>
> Now I have an idea what to do. I go through the codes in
> 
> https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=tree;f=src/main/java/org/apache/commons/math4/stat
>
> And I could identify the coupling hierarchy at the top level. So I 
> would
> like to get a start from Confidence Interval
> 
> <https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=blob;f=src/main/java/org/apache/commons/math4/stat/interval/ConfidenceInterval.java;h=e41ebf1753e749dd72e647b54f91f5bb6d60b828;hb=HEAD>
> . 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?

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.]

> 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. ;-)

Don't hesitate to post here with your suggestions.

> To get a good
> comparison, links of CM's Random Package code repo and current CM RNG
> component.

I think that you can already get a pretty good idea of the evolution
by comparing the generated "apidocs":
   
http://commons.apache.org/proper/commons-math/javadocs/api-3.6.1/org/apache/commons/math3/random/package-summary.html
vs
   
http://commons.apache.org/proper/commons-rng/commons-rng-client-api/javadocs/api-1.0/index.html
   
http://commons.apache.org/proper/commons-rng/commons-rng-core/javadocs/api-1.0/index.html
   
http://commons.apache.org/proper/commons-rng/commons-rng-sampling/javadocs/api-1.0/index.html

Regards,
Gilles

> Regards,
> Gimhana
>
>
> On 11 March 2018 at 17:07, Gilles <gilles@harfang.homelinux.org> 
> wrote:
>
>> Hello.
>>
>> 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
>>> Statistics
>>> component as my GSOC 2018 project.
>>>
>>
>> Welcome!
>>
>> 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
>> process:
>>  * CM's "random" package -> component "Commons RNG"[1]
>>  * CM's "complex", "fraction", "util", "primes", "special"
>>    packages -> modules in component "Commons Numbers"[2]
>>  * CM's "distribution" package -> "distribution" module
>>    in "Commons Statistics"[3]
>>
>> 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.
>>
>> and
>>> 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.[4]
>>
>> I hope that other people reading this will chime in and
>> help draw a concrete plan.
>>
>> Best regards,
>> Gilles
>>
>> Best Regards,
>>> Gimhana.
>>>
>>
>> [1] https://commons.apache.org/rng
>> [2] https://commons.apache.org/numbers
>> [3] https://commons.apache.org/proper/commons-statistics/
>> [4] https://issues.apache.org/jira/browse/STATISTICS-5
>>


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


Mime
View raw message