commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From S├ębastien Brisard <>
Subject Re: [Math] Towards release 3.1
Date Sat, 04 Aug 2012 18:23:48 GMT
Hi Gilles,

> More than 60 issues have been resolved since the release of Commons Math
> 3.0.
> I think that it is time to lay out a road map for the next release (3.1),
> with a target date of early September (at which point, 3.0 will be 6 months
> old).
I agree.

> The following issues have been worked on as much as permitted for a minor
> release (backwards-compatibility) and thus can be considered resolved w.r.t.
> the 3.1 release:
>   MATH-825
>   MATH-803
See my comments on MATH-821 below.

>   MATH-800
>   MATH-799
>   MATH-784
The issue is effectively solved, but must remain opened as a reminder until 4.0.

> The following issues are bugs that do not block the 3.1 release (either they
> are minor or they would require semantic changes that are forbidden, or will
> be surprising, in a minor release):
>   MATH-821
I'm waiting for answers on the users ML (see Maybe august was not the
best time to launch such a poll. Will try to resend it in early
september, what do you think?
>   MATH-788
>   MATH-758
> The following are the more serious issues:
>   MATH-836
>   MATH-828
>   MATH-819
>   MATH-789
>   MATH-778
Dfp Dfp.multiply(int x) does not comply with the general contract
FieldElement.multiply(int n)
This one will have to wait, because the problem is a bit deeper than I
thought initially. I still need to make a thorough report.

>   MATH-740
>   MATH-738
Incomplete beta function I(x, a, b) is inaccurate for large values of
a and/or b. I'm working on this one. Not sure I'll be able to give a
satisfactory answer, but I would like some more time to work on it.

> "Wish" or "improvement" issues that miss a patch should not be blocking the
> 3.1 release.
> Some of them are still marked with 3.1 as the target version. Please give
> your opinion about whether they could be easily implemented in the next few
> weeks, or should be postponed to release 3.2 or 4.0.
MATH-820 is fairly easy to implement, but not absolutely necessary. If
I can find some time, I will happily do that, but otherwise, it can
> Some issues have a large scope and would require a re-design of certain
> classes (e.g. MATH-765 and related), not to be implemented in a minor
> release.
> Please review all issues (especially those assigned to you, or reported by
> you, or where you took an active part in the discussion) and provide
> feedback on their "currentness".
> Thanks and best regards,
> Gilles
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message