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"? > > > 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?] > > > >>>> > >>>> 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) MATH-444 (trivial) Unscheduled but probably to be fixed before 3.0: MATH-744 Best, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
