commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sébastien Brisard <sebastien.bris...@m4x.org>
Subject Re: [Math] Toward releasing 3.0 ?
Date Thu, 26 Jan 2012 14:52:46 GMT
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message