[ https://issues.apache.org/jira/browse/MATH-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13463628#comment-13463628 ]
Gilles commented on MATH-867: ----------------------------- bq. That they are mixed in the code/interface I would indeed consider as a bug. Is this "bug" in the original code? bq. Generally, the boundary handling can be done without any variable transformation [...] But isn't this variable transformation part of the original code? At least, that's how it looked like from my perspective since [~docdwo] contributed the port while in contact with you. Do you mean that the "encode" and "decode" steps can be simply dropped from the code without any ill side-effects? Another issue (MATH-868) also seems related to the default transformation. > 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