[jira] [Commented] (MATH-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[ https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13467764#comment-13467764 ] Nikolaus Hansen commented on MATH-867: -- {quote} And I have no idea how to improve the documentation... {quote} Here are my suggestions: Replace (several times) {code} * @param inputSigma Initial search volume; sigma of offspring objective variables. {code} with {code} * @param inputSigma Initial standard deviations to sample new points from startPoint {code} and {code} /** * Individual sigma values - initial search volume. inputSigma determines * the initial coordinate wise standard deviations for the search. Setting * SIGMA one third of the initial search region is appropriate. */ {code} with {code} /** * Values in inputSigma define the initial coordinate-wise * standard deviations for sampling new search points about * startPoint. * Setting inputSigma roughly to the predicted distance of * startPoint to the actually desired optimum is appropriate. * Small values for inputSigma induce the search to be more local * and very small values are more likely to find a local optimum * close to startPoint. * Extremely small values will however lead to early termination. */ {code} > CMAESOptimizer with bounds fits finely near lower bound and coarsely near > upper bound. > --- > > Key: MATH-867 > URL: https://issues.apache.org/jira/browse/MATH-867 > Project: Commons Math > Issue Type: Bug >Reporter: Frank Hess > Fix For: 3.1 > > Attachments: MATH867_patch, Math867Test.java > > > When fitting with bounds, the CMAESOptimizer fits finely near the lower bound > and coarsely near the upper bound. This is because it internally maps the > fitted parameter range into the interval [0,1]. The unit of least precision > (ulp) between floating point numbers is much smaller near zero than near one. > Thus, fits have much better resolution near the lower bound (which is mapped > to zero) than the upper bound (which is mapped to one). I will attach a > example program to demonstrate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[ https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13466331#comment-13466331 ] Nikolaus Hansen commented on MATH-867: -- {quote} And the two tests still fail. {quote} did you correct the bug in the repair method that I proposed above? > CMAESOptimizer with bounds fits finely near lower bound and coarsely near > upper bound. > --- > > Key: MATH-867 > URL: https://issues.apache.org/jira/browse/MATH-867 > Project: Commons Math > Issue Type: Bug >Reporter: Frank Hess > Attachments: MATH867_patch, Math867Test.java > > > When fitting with bounds, the CMAESOptimizer fits finely near the lower bound > and coarsely near the upper bound. This is because it internally maps the > fitted parameter range into the interval [0,1]. The unit of least precision > (ulp) between floating point numbers is much smaller near zero than near one. > Thus, fits have much better resolution near the lower bound (which is mapped > to zero) than the upper bound (which is mapped to one). I will attach a > example program to demonstrate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[ https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13466328#comment-13466328 ] Nikolaus Hansen commented on MATH-867: -- {quote} I may be missing something (and I can just make wild guesses since I have no clue about the CMAES algorithm) but I would be expecting that the code behaves the same way without boundaries as with boundaries that become arbitrarily large (i.e. when the [loBound, hiBound] interval becomes [-inf, +inf]). The line that uses "inputSigma" does not behave that way since the "range" becomes arbitrarily large as the bounds grow although when there is no boundaries it is set 1.0. {quote} as both, x and sigma are transformed in the same way it does not matter mathematically. If you choose boundaries as large as (close to) maxdouble, it will matter numerically. {quote} This is also shown by some unit tests which I've just set up, by copying existing ones which minimized a function without constraint and specifying a very large allowed interval (e.g. [-1e20, 1e20]): those tests fail. {quote} did you correct the mistake in the repair method I proposed above? {quote} Intuitively, when the solution is far from the bounds (and the initial point also), whether there are bounds or not should not matter. But with the current implementation that's clearly not the case. {quote} I agree. I am confident we will be able to sort this out. > CMAESOptimizer with bounds fits finely near lower bound and coarsely near > upper bound. > --- > > Key: MATH-867 > URL: https://issues.apache.org/jira/browse/MATH-867 > Project: Commons Math > Issue Type: Bug >Reporter: Frank Hess > Attachments: MATH867_patch, Math867Test.java > > > When fitting with bounds, the CMAESOptimizer fits finely near the lower bound > and coarsely near the upper bound. This is because it internally maps the > fitted parameter range into the interval [0,1]. The unit of least precision > (ulp) between floating point numbers is much smaller near zero than near one. > Thus, fits have much better resolution near the lower bound (which is mapped > to zero) than the upper bound (which is mapped to one). I will attach a > example program to demonstrate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[ https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13466319#comment-13466319 ] Nikolaus Hansen commented on MATH-867: -- {quote} I would like to, but as I said, the identity transformation makes one of the tests fail. It must be because something else in the code assumes that the parameters have been restricted into the [0, 1] interval, which is not true anymore. {quote} The reason is IMHO line 589, which does need to be changed according to the change in encode/decode. {quote} I wonder whether the various matrices (around lines 380) are computed based on this assumption... {quote} I would not worry much, I am pretty sure they are not. > CMAESOptimizer with bounds fits finely near lower bound and coarsely near > upper bound. > --- > > Key: MATH-867 > URL: https://issues.apache.org/jira/browse/MATH-867 > Project: Commons Math > Issue Type: Bug >Reporter: Frank Hess > Attachments: MATH867_patch, Math867Test.java > > > When fitting with bounds, the CMAESOptimizer fits finely near the lower bound > and coarsely near the upper bound. This is because it internally maps the > fitted parameter range into the interval [0,1]. The unit of least precision > (ulp) between floating point numbers is much smaller near zero than near one. > Thus, fits have much better resolution near the lower bound (which is mapped > to zero) than the upper bound (which is mapped to one). I will attach a > example program to demonstrate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[ https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13466317#comment-13466317 ] Nikolaus Hansen commented on MATH-867: -- I have corrected the repair: the last assignment {code} } else { repaired[i] = x[i]; {code} was missing (sorry). Now there is some chance that it might pass... {quote} I certainly agree. But since there was something wrong before in the code, one could also imagine that it was because of the problem that it passed before... {quote} that seems somehow irrelevant: it is an absolute statement about the algorithm, that an implementation of it must pass this test. It's not related to the question when and why it has already been past or not. otherwise, the code was, AFAICS, not wrong before unless with boundary values as large as 1e16 in absolute value. > CMAESOptimizer with bounds fits finely near lower bound and coarsely near > upper bound. > --- > > Key: MATH-867 > URL: https://issues.apache.org/jira/browse/MATH-867 > Project: Commons Math > Issue Type: Bug >Reporter: Frank Hess > Attachments: MATH867_patch, Math867Test.java > > > When fitting with bounds, the CMAESOptimizer fits finely near the lower bound > and coarsely near the upper bound. This is because it internally maps the > fitted parameter range into the interval [0,1]. The unit of least precision > (ulp) between floating point numbers is much smaller near zero than near one. > Thus, fits have much better resolution near the lower bound (which is mapped > to zero) than the upper bound (which is mapped to one). I will attach a > example program to demonstrate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[ https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13466309#comment-13466309 ] Nikolaus Hansen commented on MATH-867: -- {quote} Hence, unless someone wants to try it out, we'll of course trust you and leave the internal boundary handling in place. {quote} I spent several hundreds of hours (really!) to investigate (and try to understand) this with the greatest care I was able to. That of course doesn't mean there could be still surprises out there... > CMAESOptimizer with bounds fits finely near lower bound and coarsely near > upper bound. > --- > > Key: MATH-867 > URL: https://issues.apache.org/jira/browse/MATH-867 > Project: Commons Math > Issue Type: Bug >Reporter: Frank Hess > Attachments: MATH867_patch, Math867Test.java > > > When fitting with bounds, the CMAESOptimizer fits finely near the lower bound > and coarsely near the upper bound. This is because it internally maps the > fitted parameter range into the interval [0,1]. The unit of least precision > (ulp) between floating point numbers is much smaller near zero than near one. > Thus, fits have much better resolution near the lower bound (which is mapped > to zero) than the upper bound (which is mapped to one). I will attach a > example program to demonstrate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (MATH-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[ https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13466297#comment-13466297 ] Nikolaus Hansen edited comment on MATH-867 at 9/30/12 7:52 AM: --- {quote} Revision 1391840 contains modified "encode" and "decode" functions. Both unit tests now pass (for "testConstrainedRosen" I had to move the initial guess closer to the solution). {quote} if the test does not pass with initial point at 0.1, something is wrong (and it doesn't look like a good idea to change the test to make the code pass). I found at least one problem: {code} private double[] repair(final double[] x) { double[] repaired = new double[x.length]; for (int i = 0; i < x.length; i++) { if (x[i] < 0) { repaired[i] = 0; } else if (x[i] > 1.0) { repaired[i] = 1.0; } else { repaired[i] = x[i]; } } return repaired; } {code} must read {code} private double[] repair(final double[] x) { double[] repaired = new double[x.length]; if (boundaries == null) { for (int i = 0; i < x.length; i++) { repaired[i] = x[i]; } } else { final double[] bLoEnc = encode(boundaries[0]); final double[] bHiEnc = encode(boundaries[1]); for (int i = 0; i < x.length; i++) { if (x[i] < bLoEnc[i]) { repaired[i] = bLoEnc[i]; } else if (x[i] > bHiEnc[i]) { repaired[i] = bHiEnc[i]; } else { repaired[i] = x[i]; } } } return repaired; } {code} I am not sure whether or not this is the reason why the test fails. was (Author: jolievie): {quote} Revision 1391840 contains modified "encode" and "decode" functions. Both unit tests now pass (for "testConstrainedRosen" I had to move the initial guess closer to the solution). {quote} if the test does not pass with initial point at 0.1, something is wrong (and it doesn't look like a good idea to change the test to make the code pass). I found at least one problem: {code} private double[] repair(final double[] x) { double[] repaired = new double[x.length]; for (int i = 0; i < x.length; i++) { if (x[i] < 0) { repaired[i] = 0; } else if (x[i] > 1.0) { repaired[i] = 1.0; } else { repaired[i] = x[i]; } } return repaired; } {code} must read {code} private double[] repair(final double[] x) { double[] repaired = new double[x.length]; if (boundaries == null) { for (int i = 0; i < x.length; i++) { repaired[i] = x[i]; } } else { final double[] bLoEnc = encode(boundaries[0]); final double[] bHiEnc = encode(boundaries[1]); for (int i = 0; i < x.length; i++) { if (x[i] < bLoEnc[i]) { repaired[i] = bLoEnc[i]; } else if (x[i] > bHiEnc[i]) { repaired[i] = bHiEnc[i]; } } } return repaired; } {code} I am not sure whether or not this is the reason why the test fails. > CMAESOptimizer with bounds fits finely near lower bound and coarsely near > upper bound. > --- > > Key: MATH-867 > URL: https://issues.apache.org/jira/browse/MATH-867 > Project: Commons Math > Issue Type: Bug >Reporter: Frank Hess > Attachments: MATH867_patch, Math867Test.java > > > When fitting with bounds, the CMAESOptimizer fits finely near the lower bound > and coarsely near the upper bound. This is because it internally maps the > fitted parameter range into the interval [0,1]. The unit of least precision > (ulp) between floating point numbers is much smaller near zero than near one. > Thus, fits have much better resolution near the lower bound (which is mapped > to zero) than the upper bound (which is mapped to one). I will attach a > example program to demonstrate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[ https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13466308#comment-13466308 ] Nikolaus Hansen commented on MATH-867: -- {quote} Revision 1391840 contains modified "encode" and "decode" functions. Both unit tests now pass (for "testConstrainedRosen" I had to move the initial guess closer to the solution). No change was required for "inputSigma"; I still do not understand why it works as is (cf. lines 588, 589). {quote} to me it makes perfectly sense: luckily enough line 589 performs the same transformation on inputSigma as the encode function on getStartPoint() (maybe this should be mentioned in a comment?). As the transformation is linear, the situations before and after the transformations are mathematically equivalent (the bug came from loosing digits due to a subtraction, which is now omitted). As said before it would simplify the code if both transformations were omitted (but we could leave this to another issue). {quote} And I have no idea how to improve the documentation... {quote} I'll think about it. > CMAESOptimizer with bounds fits finely near lower bound and coarsely near > upper bound. > --- > > Key: MATH-867 > URL: https://issues.apache.org/jira/browse/MATH-867 > Project: Commons Math > Issue Type: Bug >Reporter: Frank Hess > Attachments: MATH867_patch, Math867Test.java > > > When fitting with bounds, the CMAESOptimizer fits finely near the lower bound > and coarsely near the upper bound. This is because it internally maps the > fitted parameter range into the interval [0,1]. The unit of least precision > (ulp) between floating point numbers is much smaller near zero than near one. > Thus, fits have much better resolution near the lower bound (which is mapped > to zero) than the upper bound (which is mapped to one). I will attach a > example program to demonstrate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[ https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13466297#comment-13466297 ] Nikolaus Hansen commented on MATH-867: -- {quote} Revision 1391840 contains modified "encode" and "decode" functions. Both unit tests now pass (for "testConstrainedRosen" I had to move the initial guess closer to the solution). {quote} if the test does not pass with initial point at 0.1, something is wrong (and it doesn't look like a good idea to change the test to make the code pass). I found at least one problem: {code} private double[] repair(final double[] x) { double[] repaired = new double[x.length]; for (int i = 0; i < x.length; i++) { if (x[i] < 0) { repaired[i] = 0; } else if (x[i] > 1.0) { repaired[i] = 1.0; } else { repaired[i] = x[i]; } } return repaired; } {code} must read {code} private double[] repair(final double[] x) { double[] repaired = new double[x.length]; if (boundaries == null) { for (int i = 0; i < x.length; i++) { repaired[i] = x[i]; } } else { final double[] bLoEnc = encode(boundaries[0]); final double[] bHiEnc = encode(boundaries[1]); for (int i = 0; i < x.length; i++) { if (x[i] < bLoEnc[i]) { repaired[i] = bLoEnc[i]; } else if (x[i] > bHiEnc[i]) { repaired[i] = bHiEnc[i]; } } } return repaired; } {code} I am not sure whether or not this is the reason why the test fails. > CMAESOptimizer with bounds fits finely near lower bound and coarsely near > upper bound. > --- > > Key: MATH-867 > URL: https://issues.apache.org/jira/browse/MATH-867 > Project: Commons Math > Issue Type: Bug >Reporter: Frank Hess > Attachments: MATH867_patch, Math867Test.java > > > When fitting with bounds, the CMAESOptimizer fits finely near the lower bound > and coarsely near the upper bound. This is because it internally maps the > fitted parameter range into the interval [0,1]. The unit of least precision > (ulp) between floating point numbers is much smaller near zero than near one. > Thus, fits have much better resolution near the lower bound (which is mapped > to zero) than the upper bound (which is mapped to one). I will attach a > example program to demonstrate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[ https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13466253#comment-13466253 ] Nikolaus Hansen commented on MATH-867: -- just another motivation: inputSigma is related to the uncertainty on getStartPoint(), as we cannot intrinsically know whether this is in the order of 1 or 1e-4 or 1e4 or 10e23. > CMAESOptimizer with bounds fits finely near lower bound and coarsely near > upper bound. > --- > > Key: MATH-867 > URL: https://issues.apache.org/jira/browse/MATH-867 > Project: Commons Math > Issue Type: Bug >Reporter: Frank Hess > Attachments: MATH867_patch, Math867Test.java > > > When fitting with bounds, the CMAESOptimizer fits finely near the lower bound > and coarsely near the upper bound. This is because it internally maps the > fitted parameter range into the interval [0,1]. The unit of least precision > (ulp) between floating point numbers is much smaller near zero than near one. > Thus, fits have much better resolution near the lower bound (which is mapped > to zero) than the upper bound (which is mapped to one). I will attach a > example program to demonstrate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (MATH-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[ https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13466246#comment-13466246 ] Nikolaus Hansen edited comment on MATH-867 at 9/30/12 2:32 AM: --- {quote} However v2 makes the remaining modifications simpler. The problem is that we don't know what are "the remaining modifications": {quote} I thought I knew... {quote}we never got beyond to the point were both "testFitAccuracyDependsOnBoundary" and "testConstrainedRosen" pass. {quote} the former, because inputSigma was not adapted appropriately, the latter because the test against boundaries was not adapted appropriately. {quote} There are two different things: 1. Does the existence of constraints modify the search procedure is some way (i.e. CMAES must "know" that it deals with boundaries)? {quote} yes. Otherwise it will sample and evaluation points outside the boundaries. {quote} 2. Alternately, is it possible to pass a modified objective function (in which the allowed range of the original objective function has been mapped to the [-inf, +inf] interval) and have CMAES behave the same (i.e. find the same solution)? {quote} probably not the same, but possibly reasonably well, unless the boundary is mapped to (or close to) inf, which is likely to lead to unexpected results, if the optimum is on (or close to) the boundary. checking MultivariateFunctionPenaltyAdapter (which does not map the parameters, rather computes a penalty), the answer is likely to be no, if the optimal solution happens to be on (or very close to) the bound. The methods developed for CMA-ES should work much better in this case. {quote} regarding the documentation of inputSigma: I don't see in what sense the doc says that it depends on the bounds. Then what is "initial search volume"? {quote} the volume/region where points are likely to be sampled in the beginning of the search. Points beyond, say, startpoint + 10*sigma are not likely to be sampled in the beginning. {quote} I interpret the doc as roughly saying "0.3 times the range". Perhaps this is wrong, in which case it should be made clearer... {quote} I agree, it is not clear (I guess it was taken from another doc and slightly changed context). {quote} We noticed that very small or very large values for "sigma" did not work; so maybe we should say "inputSigma must be of order 1" . {quote} no, it entirely depends on how far we expect the optimal solution to be from the start solution. Putting it differently: one could rescale parameters by a factor 1000 (say in one case it is km, in the other m), then one would need to rescale inputSigma accordingly (which would not be in the order of one). Codes I write typically don't accept a default value for inputSigma, basically for this reason. I agree however that a value of 1 might often turn out OK. was (Author: jolievie): {quote} However v2 makes the remaining modifications simpler. The problem is that we don't know what are "the remaining modifications": {quote} I thought I knew... {quote}we never got beyond to the point were both "testFitAccuracyDependsOnBoundary" and "testConstrainedRosen" pass. {quote} the former, because inputSigma was not adapted appropriately, the latter because the test against boundaries was not adapted appropriately. {quote} There are two different things: 1. Does the existence of constraints modify the search procedure is some way (i.e. CMAES must "know" that it deals with boundaries)? {quote} yes. Otherwise it will sample and evaluation points outside the boundaries. {quote} 2. Alternately, is it possible to pass a modified objective function (in which the allowed range of the original objective function has been mapped to the [-inf, +inf] interval) and have CMAES behave the same (i.e. find the same solution)? {quote} probably not the same, but possibly reasonably well, unless the boundary is mapped to (or close to) inf, which is likely to lead to unexpected results, if the optimum is on (or close to) the boundary. checking MultivariateFunctionPenaltyAdapter (which does not map the parameters, rather computes a penalty), the answer is likely to be no, if the optimal solution happens to be on (or very close to) the bound. {quote} regarding the documentation of inputSigma: I don't see in what sense the doc says that it depends on the bounds. Then what is "initial search volume"? {quote} the volume/region where points are likely to be sampled in the beginning of the search. Points beyond, say, startpoint + 10*sigma are not likely to be sampled in the beginning. {quote} I interpret the doc as roughly saying "0.3 times the range". Perhaps this is wrong, in which case it should be made clearer... {quote} I agree, it is not clear (I guess it was taken from another doc and slightly changed context). {quote} We noticed that ver
[jira] [Commented] (MATH-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[ https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13466246#comment-13466246 ] Nikolaus Hansen commented on MATH-867: -- {quote} However v2 makes the remaining modifications simpler. The problem is that we don't know what are "the remaining modifications": {quote} I thought I knew... {quote}we never got beyond to the point were both "testFitAccuracyDependsOnBoundary" and "testConstrainedRosen" pass. {quote} the former, because inputSigma was not adapted appropriately, the latter because the test against boundaries was not adapted appropriately. {quote} There are two different things: 1. Does the existence of constraints modify the search procedure is some way (i.e. CMAES must "know" that it deals with boundaries)? {quote} yes. Otherwise it will sample and evaluation points outside the boundaries. {quote} 2. Alternately, is it possible to pass a modified objective function (in which the allowed range of the original objective function has been mapped to the [-inf, +inf] interval) and have CMAES behave the same (i.e. find the same solution)? {quote} probably not the same, but possibly reasonably well, unless the boundary is mapped to (or close to) inf, which is likely to lead to unexpected results, if the optimum is on (or close to) the boundary. checking MultivariateFunctionPenaltyAdapter (which does not map the parameters, rather computes a penalty), the answer is likely to be no, if the optimal solution happens to be on (or very close to) the bound. {quote} regarding the documentation of inputSigma: I don't see in what sense the doc says that it depends on the bounds. Then what is "initial search volume"? {quote} the volume/region where points are likely to be sampled in the beginning of the search. Points beyond, say, startpoint + 10*sigma are not likely to be sampled in the beginning. {quote} I interpret the doc as roughly saying "0.3 times the range". Perhaps this is wrong, in which case it should be made clearer... {quote} I agree, it is not clear (I guess it was taken from another doc and slightly changed context). {quote} We noticed that very small or very large values for "sigma" did not work; so maybe we should say "inputSigma must be of order 1" . {quote} no, it entirely depends on how far we expect the optimal solution to be from the start solution. Putting it differently: one could rescale parameters by a factor 1000 (say in one case it is km, in the other m), then one would need to rescale inputSigma accordingly (which would not be in the order of one). Codes I write typically don't accept a default value for inputSigma, basically for this reason. I agree however that a value of 1 might often turn out OK. > CMAESOptimizer with bounds fits finely near lower bound and coarsely near > upper bound. > --- > > Key: MATH-867 > URL: https://issues.apache.org/jira/browse/MATH-867 > Project: Commons Math > Issue Type: Bug >Reporter: Frank Hess > Attachments: MATH867_patch, Math867Test.java > > > When fitting with bounds, the CMAESOptimizer fits finely near the lower bound > and coarsely near the upper bound. This is because it internally maps the > fitted parameter range into the interval [0,1]. The unit of least precision > (ulp) between floating point numbers is much smaller near zero than near one. > Thus, fits have much better resolution near the lower bound (which is mapped > to zero) than the upper bound (which is mapped to one). I will attach a > example program to demonstrate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[ https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13466240#comment-13466240 ] Nikolaus Hansen commented on MATH-867: -- regarding the documentation of inputSigma: I don't see in what sense the doc says that it depends on the bounds. The doc says how it should be set (but this is a bit blurry, to the extend of how "initial search volume" and "initial search region" are interpreted) > CMAESOptimizer with bounds fits finely near lower bound and coarsely near > upper bound. > --- > > Key: MATH-867 > URL: https://issues.apache.org/jira/browse/MATH-867 > Project: Commons Math > Issue Type: Bug >Reporter: Frank Hess > Attachments: MATH867_patch, Math867Test.java > > > When fitting with bounds, the CMAESOptimizer fits finely near the lower bound > and coarsely near the upper bound. This is because it internally maps the > fitted parameter range into the interval [0,1]. The unit of least precision > (ulp) between floating point numbers is much smaller near zero than near one. > Thus, fits have much better resolution near the lower bound (which is mapped > to zero) than the upper bound (which is mapped to one). I will attach a > example program to demonstrate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[ https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13466239#comment-13466239 ] Nikolaus Hansen commented on MATH-867: -- {quote} Since in some previous comments, you indicated that boundaries do not necessarily need to be taken into account inside the CMAES algorithm, a possibility is to review the entire code, and remove all code related to boundaries. {quote} I believe that this must be a misunderstanding. We do not need the transformation into [0,1] (or any other transformation for that matter) to take into account boundaries. But we need to possibly take into account the boundaries within CMAES, if the returned solution is supposed to be in the bounds. > CMAESOptimizer with bounds fits finely near lower bound and coarsely near > upper bound. > --- > > Key: MATH-867 > URL: https://issues.apache.org/jira/browse/MATH-867 > Project: Commons Math > Issue Type: Bug >Reporter: Frank Hess > Attachments: MATH867_patch, Math867Test.java > > > When fitting with bounds, the CMAESOptimizer fits finely near the lower bound > and coarsely near the upper bound. This is because it internally maps the > fitted parameter range into the interval [0,1]. The unit of least precision > (ulp) between floating point numbers is much smaller near zero than near one. > Thus, fits have much better resolution near the lower bound (which is mapped > to zero) than the upper bound (which is mapped to one). I will attach a > example program to demonstrate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[ https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13466238#comment-13466238 ] Nikolaus Hansen commented on MATH-867: -- This issue's bug is not solved by v1 alone. The way how to check the boundaries in isFeasible and the method repair must be adapted to the encode/decode function, otherwise a more severe bug has been introduced (even if it would pass all tests). I agree that v1, along with corrected boundary checks, can solve the issue. However v2 makes the remaining modifications simpler. Besides, the testConstrainedRosen must not fail, definitely not! > CMAESOptimizer with bounds fits finely near lower bound and coarsely near > upper bound. > --- > > Key: MATH-867 > URL: https://issues.apache.org/jira/browse/MATH-867 > Project: Commons Math > Issue Type: Bug >Reporter: Frank Hess > Attachments: MATH867_patch, Math867Test.java > > > When fitting with bounds, the CMAESOptimizer fits finely near the lower bound > and coarsely near the upper bound. This is because it internally maps the > fitted parameter range into the interval [0,1]. The unit of least precision > (ulp) between floating point numbers is much smaller near zero than near one. > Thus, fits have much better resolution near the lower bound (which is mapped > to zero) than the upper bound (which is mapped to one). I will attach a > example program to demonstrate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[ https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13466199#comment-13466199 ] Nikolaus Hansen commented on MATH-867: -- I second to make encode/decode the identity to address the bug. I don't even see a different way to address it. Then, inputSigma/sigmaArray/insigma should become independent of the boundary values (which seems consistent with the doc, as long as encode/decode remains the identity). my previous snippet must read {code} guess[i] - sigmaArray[i]/2. > fitfun.encode(boundaries[0])[i] {code} because we have {code} final double[] guess = fitfun.encode(getStartPoint()); {code} i.e. guess is an encoded initial guess. > CMAESOptimizer with bounds fits finely near lower bound and coarsely near > upper bound. > --- > > Key: MATH-867 > URL: https://issues.apache.org/jira/browse/MATH-867 > Project: Commons Math > Issue Type: Bug >Reporter: Frank Hess > Attachments: MATH867_patch, Math867Test.java > > > When fitting with bounds, the CMAESOptimizer fits finely near the lower bound > and coarsely near the upper bound. This is because it internally maps the > fitted parameter range into the interval [0,1]. The unit of least precision > (ulp) between floating point numbers is much smaller near zero than near one. > Thus, fits have much better resolution near the lower bound (which is mapped > to zero) than the upper bound (which is mapped to one). I will attach a > example program to demonstrate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[ https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13465719#comment-13465719 ] Nikolaus Hansen commented on MATH-867: -- {quote} I believe the reason is that defaulting sigma to 0.3 times the range causes the fitter to jump from the initial value (which is order of 1 away from the target) to some huge value on the order of 1e16 on the first step. {quote} Right. I suggest to make sigmaArray independent of the boundary values. Otherwise setting boundaries like [1e-15,1e15] still will most likely lead to an unexpected behavior: the user just does not want to exceed this value, while the algorithm interprets the interval as being reasonable values to be checked out. Still it makes perfectly sense to check consistency between the initial guess, sigmaArray and boundaries, in that, say, {code} fitfun.encode(guess)[i] - sigmaArray[i]/2. > fitfun.encode(boundaries[0])[i] {code} in case of a lower bound. {quote} It doesn't reach the target exactly due to one of the many stop conditions hard-coded into the generationLoop which decide that the fit is "good enough" and quit. {quote} more specifically, stopTolX is defined relative to the initial value of sigmaArray. This specific problem should therefore go away if stopTolX is defined as an absolute value like 1e-11. I think absolute and relative definition of stopTolX are both justified. Generally, the patch becomes buggy, when encode and decode are changed/reused. In this case, where solutions are compared with boundaries, like {code} if(x[i] < boundaries[0][i]) {code} the comparison must be done with encoded boundaries: {code} encLboundaries = fitfun.encode(boundaries[0]); if (x[i] < encLboundaries[i]) {code} > CMAESOptimizer with bounds fits finely near lower bound and coarsely near > upper bound. > --- > > Key: MATH-867 > URL: https://issues.apache.org/jira/browse/MATH-867 > Project: Commons Math > Issue Type: Bug >Reporter: Frank Hess > Attachments: MATH867_patch, Math867Test.java > > > When fitting with bounds, the CMAESOptimizer fits finely near the lower bound > and coarsely near the upper bound. This is because it internally maps the > fitted parameter range into the interval [0,1]. The unit of least precision > (ulp) between floating point numbers is much smaller near zero than near one. > Thus, fits have much better resolution near the lower bound (which is mapped > to zero) than the upper bound (which is mapped to one). I will attach a > example program to demonstrate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[ https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13465693#comment-13465693 ] Nikolaus Hansen commented on MATH-867: -- {quote} But when set to "false", the result is: sol=[0.997107074864516, 0.9942080214735094, 0.9884131718553784, 0.9768835748661846, 0.954143705394098, 0.910067297297918, 0.8275510138614142, 0.6833931486612853, 0.4636505565068948, 0.20554769008446425, 0.0, 0.009899135523990096, 0.0] Is this expected? {quote} No! The code must pass this test with high probability. > CMAESOptimizer with bounds fits finely near lower bound and coarsely near > upper bound. > --- > > Key: MATH-867 > URL: https://issues.apache.org/jira/browse/MATH-867 > Project: Commons Math > Issue Type: Bug >Reporter: Frank Hess > Attachments: MATH867_patch, Math867Test.java > > > When fitting with bounds, the CMAESOptimizer fits finely near the lower bound > and coarsely near the upper bound. This is because it internally maps the > fitted parameter range into the interval [0,1]. The unit of least precision > (ulp) between floating point numbers is much smaller near zero than near one. > Thus, fits have much better resolution near the lower bound (which is mapped > to zero) than the upper bound (which is mapped to one). I will attach a > example program to demonstrate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[ https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13463747#comment-13463747 ] Nikolaus Hansen commented on MATH-867: -- Why are variables transformations generally desirable? Because, for example, if a parameter x_i should only have positive values, the transformation x_i -> x_i^2 makes the objective function compatible to any unbounded optimizer. Or, for example, rescaling of variables (e.g. unit m in km etc) can change an ill-conditioned problem to a well-conditioned one. > CMAESOptimizer with bounds fits finely near lower bound and coarsely near > upper bound. > --- > > Key: MATH-867 > URL: https://issues.apache.org/jira/browse/MATH-867 > Project: Commons Math > Issue Type: Bug >Reporter: Frank Hess > Attachments: Math867Test.java > > > When fitting with bounds, the CMAESOptimizer fits finely near the lower bound > and coarsely near the upper bound. This is because it internally maps the > fitted parameter range into the interval [0,1]. The unit of least precision > (ulp) between floating point numbers is much smaller near zero than near one. > Thus, fits have much better resolution near the lower bound (which is mapped > to zero) than the upper bound (which is mapped to one). I will attach a > example program to demonstrate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[ https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13463721#comment-13463721 ] Nikolaus Hansen commented on MATH-867: -- the "bug" is not in the original code. In some CMA-ES codes, variable transformations are provided as an option (not in the one which was translated). This is however just meant as a convenience feature, as it could be equivalently implemented as part of the objective function (and should IMHO preferably viewed as such). This should IMHO be a general feature implemented in the optimization library, as the benefits of variable transformations are not tightly linked to any specific optimization method. It should be easily possible to drop the transformation in CMAESOptimizer, in which case 0 and 1 must be replaced by the lower and upper boundary values in some parts of the code. > CMAESOptimizer with bounds fits finely near lower bound and coarsely near > upper bound. > --- > > Key: MATH-867 > URL: https://issues.apache.org/jira/browse/MATH-867 > Project: Commons Math > Issue Type: Bug >Reporter: Frank Hess > Attachments: Math867Test.java > > > When fitting with bounds, the CMAESOptimizer fits finely near the lower bound > and coarsely near the upper bound. This is because it internally maps the > fitted parameter range into the interval [0,1]. The unit of least precision > (ulp) between floating point numbers is much smaller near zero than near one. > Thus, fits have much better resolution near the lower bound (which is mapped > to zero) than the upper bound (which is mapped to one). I will attach a > example program to demonstrate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (MATH-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[ https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461891#comment-13461891 ] Nikolaus Hansen edited comment on MATH-867 at 9/25/12 3:53 AM: --- It seems important to point out that a parameter transformation or scaling and variable boundaries are two different things. That they are mixed in the code/interface I would indeed consider as a bug. Generally, the boundary handling can be done without any variable transformation and therefore does not need to effect precision. If we want positive variable values only, the code should IMHO support only applying a lower bound in some way. Maybe it is still important to mention: a relevant initial parameter to CMA-ES is an initial step-size (a standard deviation) possibly in each coordinate. You might think of this step-size as similar to the width of the initial simplex in Nelder&Mead. Choosing this step-size is equivalent to choosing a different "diff"-factor in the encoding as suggested above. was (Author: jolievie): It seems important to point out that a parameter transformation or scaling and variable boundaries are two different things. That they are mixed in the code/interface I would indeed consider as a bug. Generally, the boundary handling can be done without any variable transformation and therefore does not need to effect precision. If we want positive variable values only, the code should support only applying a lower bound in some way. My suggestion would be indeed to have as interface boundaries and a unit-scale for each parameter (by default one). Only the latter would control the "encoding", in the way suggested above as "diff". Maybe it is still important to mention: a relevant initial parameter to CMA-ES is an initial step-size (a standard deviation) related to the unit-scale, which seem to be hidden from the user as it is now. You might think of this step-size as similar to the width of the initial simplex in Nelder&Mead. > CMAESOptimizer with bounds fits finely near lower bound and coarsely near > upper bound. > --- > > Key: MATH-867 > URL: https://issues.apache.org/jira/browse/MATH-867 > Project: Commons Math > Issue Type: Bug >Reporter: Frank Hess > Attachments: Math867Test.java > > > When fitting with bounds, the CMAESOptimizer fits finely near the lower bound > and coarsely near the upper bound. This is because it internally maps the > fitted parameter range into the interval [0,1]. The unit of least precision > (ulp) between floating point numbers is much smaller near zero than near one. > Thus, fits have much better resolution near the lower bound (which is mapped > to zero) than the upper bound (which is mapped to one). I will attach a > example program to demonstrate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[ https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461891#comment-13461891 ] Nikolaus Hansen commented on MATH-867: -- It seems important to point out that a parameter transformation or scaling and variable boundaries are two different things. That they are mixed in the code/interface I would indeed consider as a bug. Generally, the boundary handling can be done without any variable transformation and therefore does not need to effect precision. If we want positive variable values only, the code should support only applying a lower bound in some way. My suggestion would be indeed to have as interface boundaries and a unit-scale for each parameter (by default one). Only the latter would control the "encoding", in the way suggested above as "diff". Maybe it is still important to mention: a relevant initial parameter to CMA-ES is an initial step-size (a standard deviation) related to the unit-scale, which seem to be hidden from the user as it is now. You might think of this step-size as similar to the width of the initial simplex in Nelder&Mead. > CMAESOptimizer with bounds fits finely near lower bound and coarsely near > upper bound. > --- > > Key: MATH-867 > URL: https://issues.apache.org/jira/browse/MATH-867 > Project: Commons Math > Issue Type: Bug >Reporter: Frank Hess > Attachments: Math867Test.java > > > When fitting with bounds, the CMAESOptimizer fits finely near the lower bound > and coarsely near the upper bound. This is because it internally maps the > fitted parameter range into the interval [0,1]. The unit of least precision > (ulp) between floating point numbers is much smaller near zero than near one. > Thus, fits have much better resolution near the lower bound (which is mapped > to zero) than the upper bound (which is mapped to one). I will attach a > example program to demonstrate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-867) CMAESOptimizer with bounds fits finely near lower bound and coarsely near upper bound.
[ https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461853#comment-13461853 ] Nikolaus Hansen commented on MATH-867: -- I don't see anything wrong with the new version (the original version better facilitates the display of the evolution of variables in a single picture). It seems also clear where the original version fails: taking the difference in the above computation leads to a loss of significant digits if x[i] and boundaries[0][i] largely differ, that is, if the solution is far away from the lower bound. However the use of boundaries for a range like [0, 5e16] seems not reasonable to me and it was not meant to be used like that. More specifically, I don't see a good reason to set an upper bound of 5e16, in particular when the initial point is 1. I would expect a reasonable initial point to lie roughly in the middle of the search interval. If the variable is supposed to be as large as 5e16, it is likely advisable to apply a non-linear transformation, e.g. to optimization its logarithm. More general, when searching in an interval of size 1e16 using double precision, one can, in principle, hardly expect to get a solution with a precision better than, say, 10 in which case one has identified the optimum with 15 digits of precision. > CMAESOptimizer with bounds fits finely near lower bound and coarsely near > upper bound. > --- > > Key: MATH-867 > URL: https://issues.apache.org/jira/browse/MATH-867 > Project: Commons Math > Issue Type: Bug >Reporter: Frank Hess > Attachments: Math867Test.java > > > When fitting with bounds, the CMAESOptimizer fits finely near the lower bound > and coarsely near the upper bound. This is because it internally maps the > fitted parameter range into the interval [0,1]. The unit of least precision > (ulp) between floating point numbers is much smaller near zero than near one. > Thus, fits have much better resolution near the lower bound (which is mapped > to zero) than the upper bound (which is mapped to one). I will attach a > example program to demonstrate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MATH-442) CMA evolution strategy is missing in optimization
[ https://issues.apache.org/jira/browse/MATH-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12933083#action_12933083 ] Nikolaus Hansen commented on MATH-442: -- I think the CMA-ES fits fine into to direct category (but I am familiar with the meaning of the word direct search, I don't assume everyone is). Nelder-Mead and CMA-ES are similar in that they do not need derivatives and they do not even need function values: they are comparison based and only use a ranking between a number of candidate solutions. Moreover, Nelder-Mead and CMA-ES share all their invariance properties (not many other optimization algorithms do). Being rank-based implies invariance under monotonous transformations of the objective function value, but there are others (e.g. invariance under coordinate system changes). I believe these are important properties, also from the application viewpoint. The main conceptional different to Nelder-Mead: CMA-ES is stochastic (randomized, if you like). The main practical difference: CMA-ES works also in large dimension and there is a control parameter for tuning the locality of search. You could have an elaborate discussion whether CMA-ES estimates a gradient. My take on it: methods that move opposite to the gradient will regularly fail anyway. I also find it strange that algorithms in the general category are in fact less general. Where can I subscribe to the list? > CMA evolution strategy is missing in optimization > - > > Key: MATH-442 > URL: https://issues.apache.org/jira/browse/MATH-442 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 3.0 >Reporter: Dr. Dietmar Wolz > Original Estimate: 48h > Remaining Estimate: 48h > > Recently I implemented the optimization algorithm CMA-ES based on > org.apache.commons.math.linear and used it for the GTOC5 global trajectory > optimization contest http://gtoc5.math.msu.su/. It implements the > MultivariateRealOptimizer interface and would nicely fit into the > org.apache.commons.math.optimization package. The original author of CMA-ES > (Nikolaus Hansen) volunteered to support me (proof-reading + testing) in the > creation of a CMA-ES contribution for commons.math. > The CMA evolution strategy http://www.lri.fr/~hansen/cmaesintro.html is a > very powerful algorithm for difficult non-linear non-convex optimization > problems in continuous domain. See http://www.lri.fr/~hansen/cec2005.html for > a comparison chart. If there is interest I will create a patch including the > proposed Implementation for evaluation. It seems we would need an additional > sub-package - org.apache.commons.math.optimization.evolutionary. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.