Le 07/11/2011 14:42, Luc Maisonobe a écrit : > 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.
Done in revision 1198741. I have created and resolved Jira issue 702 to track the problem. Luc > >> >> >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org