Le 27/01/2012 12:48, Gilles Sadowski a écrit : > Hi. Hi Gilles,
> >>>>> >>>>> 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? Yes, something alogn this line. > If so, we should maybe also stress that we seek volunteers to clean up the > code and add a thorough unit test suite. Yes. > > 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. OK, then we should remove it for the release and move it to next 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? You ae right, consistency is important. Users should be able to switch from one algorithm to another one for such common behaviour. Luc > > > Regards, > Gilles > >>>> [...] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
