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.
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, ...).
MATH-707
A few more changes to be done.
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
