Hi Gilles, Le 13/02/2012 12:01, Gilles Sadowski a écrit : > Hello. > >>> >>>>>>> >>>>>>> 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. > > Does this information go in the "description" attribute of the "release" tag > in the file "changes.xml"?
Yes, it would be an appropriate place since the release notes are extracted from this file. > >> >>> 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. > > Practically, how can I do that? Just "svn del"? [If so, how is it moved in > again for the nex release?] I would rather set up a 3.0 release branch and do the svn del here. > >>> >>>>>> >>>>>> 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. > > This issue MATH-698 is still pending. > > Others that were not postponed to after 3.0 are: > MATH-712 (trivial) > MATH-707 (done or almost done, depending on the comments) I would consider it is done. > MATH-444 (trivial) Yes, and it is probably time to do it now. > > Unscheduled but probably to be fixed before 3.0: > MATH-744 Agreed. I'll resolve MATH-650 soon, making an arbitrary choice by myself (so you will know who is to blame). Luc > > > Best, > 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
