commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <Luc.Maison...@free.fr>
Subject Re: [Math] Toward releasing 3.0 ?
Date Thu, 26 Jan 2012 19:32:39 GMT
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-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


Mime
View raw message