Le 07/11/2011 14:24, Gilles Sadowski a écrit : > Hi Luc. > >> I am trying to use CMA-ES optimizer with simple boundaries. >> It seems the inputSigma parameter should be normalized as it is checked >> against the [0; 1] range in the checkParameters private method and as >> its value defaults to 0.3 if not not set in the initializeCMA private >> method. >> >> I would have expected this value to be in the same units as the user >> parameters and to be normalized as part of an internal processing step >> instead of relying to the user doing this. I think the method need >> normalized values internally, as per the encode/decode methods in the >> inner class FitnessFunction suggest. >> >> What do you think about it ? Should we keep normalized inputSigma (end >> hence improve documentation so people know they have to normalize the >> value) or should we accept values in the same units as the other >> parameters and use "encode" to do the normalisation ? >> >> As far as I am concerned, I would prefer the second solution, i.e. keep >> normalization an internal implementation detail. > > I like implementation details.
OK, I'll do that. > > > Best regards, > Gilles > > P.S. Please don't forget that the "CMAESOptimizer" is not yet upgraded to > use the new "optimize" API (for simple bounds); I intended to change > that by next week. Ah, thanks. This explain some strange behaviour I get. I will let you adapt this, for now I will simply set the boundaries both in the constructor and in the call to optimize. I guess the constructot will be changed later so the boundaries are set only in optimize, is this right ? > > P.P.S. If, by any chance, you could use your current work in order to expand > the code coverage of the unit tests for "BOBYQAOptimizer", that would > be most useful! [And this optimizer's API is ready for use.] I'll try to do it. However the models I optimize are quite large and depend on an external library (Orekit, of course), so this will need much rework, so I'm afraid I will do it only if I encounter problems that need some debugging. Luc > > --------------------------------------------------------------------- > 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
