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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
