commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject Re: [Math] Commons Math (r)evolution
Date Thu, 09 Jun 2016 22:36:44 GMT

On Thu, 9 Jun 2016 18:02:49 +0300, Artem Barger wrote:
> On Thu, Jun 9, 2016 at 1:54 AM, Gilles <>
> wrote:
>> ​I guess someone need to prioritize them​ according to they 
>> importance for
>>> release.
>> Importance is relative... :-}
> ​Indeed it's very objective function,  however someone has to decide
> where to focus.​

Please list the alternatives, and I will let you know what are my
But anyone can decide what he will do or not...

>> IMO, it is important to not release unsupported code.
>> So the priority would be higher for issues that would be included
>> in the release of the new Commons components.
>> Hence the need to figure out what these components will be.
> ​Not clear whenever you really mean by not releasing unsupported code 
> is
> to exclude already existing parts which doesn't anyone who will be 
> capable
> to maintain the functionality and solve possible bugs?​

I did not understand this sentence, sorry. :-}

>>>> Which ones?
>>>> ​I will look into JIRA and provide the issue numbers, and of 
>>>> course I
>>> can cover and assist with ML part and particular clustering.​
>> Thanks.
> ​You are welcome :)
> So I looked through some of the open issues and I have a couple of
> questions them​:
> 1. Which affected version do I really need to consider as an 
> important to
> be released in the next version?

It depends what is the contents of the release.
Certainly (IMO), issues in classes that are not going to be released 
time soon, are low priority.

> 2. I've looked into affected versions: 3.5, 3.6, 3.6.1, 3.7 and 4.0.
> Overall found
> something like ~25 open bugs/issues. What about issues opened for 
> lower
> releases?

Theses are probably the hardest to fix (often it relates to the
refactoring of whole packages like e.g. MATH-756).

As I've argued in this thread, my preference is to focus on extracting
independent functionalities and turn them into new components.

The point is not to about making negative choices (a.k.a. "dropping 
but making positive choices as to what you'd include in a given 

> For example while I'm looking into MATH-1329
> <>, it sounds not 
> really
> hard to have it fixed,
> but looking on it not sure whenever it was accepted and approved as
> something that need
> to be done.
> Next MATH-1315 <> 
> seems like
> reported has provided the patch and the only thing
> missing is unit test, will addition of unit tests help to make that 
> one
> resolved?
> MATH-1284 <> here is 
> not
> clear what is the final decision, according to comments look
> like it can be resolved.
> Here MATH-1262 <> 
> according
> to the comments editing current javadoc to explain the limitation
> should also rest this case, am I missing something?
> I think I can help to handle MATH-1281
> <>, right after I will
> finish the refactoring and
> optimizations for kmeans clustering.

[Please start a new thread for each of the specific issues above.
This list holds many conversations at the same time, and if multiple
subject are handled within a single thread, it quickly becomes
impossible to follow.  Thanks!]

> ​Listed issues/tickets where I can help to provide support or fix, 
> most
> likely missed something
> but can start with these.​

It's up to you really which concrete issues you want to fix.

>> with additional functionality, since I think I can provide my code 
>> for
>>> several classification
>>> algorithms​.
>> That sounds nice.
>> Which algorithms?
> ​Naive Bayes, kNN, Decision Trees, Random Forest. I guess adding 
> these into
> the project will require
> serious redesign of ML package​.

Again, up to you to propose something new. :-)
IMHO, it is extremely important to have a clean design, and clear goals
(e.g. support for parallel computing).


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message