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).
>
> 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
