commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: [Math] Toward releasing 3.0 ?
Date Fri, 27 Jan 2012 17:36:16 GMT
Le 27/01/2012 12:48, Gilles Sadowski a écrit :
> Hi.

Hi Gilles,

>>>>> It thus becomes urgent to tackle the remaining blocking issues.
>>>>> Can we please make a list of those, and of all practical matters that
>>>>> prevent the preparation of the release?
>>>> MATH-621 (see also MATH-728)
>>>>  * Unit test coverage: at least 6 branches of the code are not explored.
>>>>  * Code complexity:
>>>>    - Variable "state" that is similar to having goto's
>>>>    - drop from one "case" to the next (no "break")
>>>>    - explicit matrix computations
>>>>  * Code fragility: success or failure of some unit tests depends on the
>>>>   order of floating point operations (addition).
>>>>  * Support: no resource in the CM team to bring the code to a state where
>>>>   a Java developer can maintain it.
>>>>  I'm wary to release the code in that state.
>>> The last point is indeed quite worrying. If we are planning for a
>>> release taking place briefly, I'm of no use, because digging into this
>>> would take me forever (even if it must be done in the end by one of
>>> us, I suppose).
>> As strange as it might seem, I would like to see this code part of 3.0
>> with a big "experimental" flag on it. People can use it at their own
>> risk, but they can also help improve it.
> How do we set this flag practically?  A warning in the release notes?

Yes, something alogn this line.

> If so, we should maybe also stress that we seek volunteers to clean up the
> code and add a thorough unit test suite.


> Somewhat related to this, is the issue of the "BatteryNISTTest" class. It is
> supposedly a unit test (created by Greg Sterijevski) but many test methods
> are actually commented out because they fail; and nobody has investigated
> why. [E.g. do the failures indicate bugs, or is it normal due to a possibly
> inherent complexity of the problem?]
> IMHO, this class is too cluttered (a lot of copy/paste etc.) and should be
> rewritten with a clear separation of the problems handled and the optimizers
> used to try and solve them.
> As is, the class should not be part of the release.

OK, then we should remove it for the release and move it to next release.

>>>> MATH-698
>>>>  IIUC, "CMAESOptimizer" deals only with either no bounds or finite bounds.
>>>>  (e.g. look at method "encode", lines 904-914).
>>>>  I don't have the knowledge about the algorithm in order to know how to
>>>>  modify that code so that it will behave correctly when only one of the
>>>>  bounds is infinite (a valid case allowed by the base class for optimizers
>>>>  with simple bounds: "BaseAbstractMultivariateSimpleBoundsOptimizer").
>>>>  I would not want to release an API where simple bounds are dealt differently
>>>>  in "CMAESOptimizer" than in the supposedly common interface.
> What do you think about this point?

You ae right, consistency is important. Users should be able to switch
from one algorithm to another one for such common behaviour.


> Regards,
> Gilles
>>>> [...]
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message