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.
Yes.
>
> 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.
Luc
>
>
> Regards,
> Gilles
>
>>>> [...]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
|