commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <gil...@harfang.homelinux.org>
Subject Re: [Math] Toward releasing 3.0 ?
Date Fri, 27 Jan 2012 11:48:53 GMT
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.

How do we set this flag practically?  A warning in the release notes?
If so, we should maybe also stress that we seek volunteers to clean up the
code and add a thorough unit test suite.

Somewhat related to this, is the issue of the "BatteryNISTTest" class. It is
supposedly a unit test (created by Greg Sterijevski) but many test methods
are actually commented out because they fail; and nobody has investigated
why. [E.g. do the failures indicate bugs, or is it normal due to a possibly
inherent complexity of the problem?]
IMHO, this class is too cluttered (a lot of copy/paste etc.) and should be
rewritten with a clear separation of the problems handled and the optimizers
used to try and solve them.
As is, the class should not be part of the release.

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

What do you think about this point?


Regards,
Gilles

> >> [...]

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message