Le 26/01/2012 15:52, Sébastien Brisard a écrit :
> Hello,
>> Hi.
>>
>>>
>>> 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.
Luc
>
>>
>> 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.
>>
>>
>> MATH-726
>> This is really a small issue. But the discussion has stalled because of a
>> long-term wish concerning a design convergence with the "nabla" project.
>> I'd rather introduce the code now, in a form that is similar to the design
>> of other packages ("solvers", "optimization", "integration").
>> I see no problem in changing that later, in the same way that there are
>> suggestions to change other things (e.g. matrix interface, factories, ...).
>>
> I agree. It's only after playing around with this new feature that we
> will be able to find its (potential) flaws. However, I do realize that
> not everyone may agree on this...
>>
>> MATH-707
>> A few more changes to be done.
>>
>>
>> Regards,
>> Gilles
>>
> Sébastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
