unfortunately, the problem already arises with a linear coordinate-wise
mapping: which coordinate gives the unit where sigma is defined on?
from a practical viewpoint it is important to consider coordinate-wise
non-linear mappings. Multidimensional mappings (e.g. with "covariance") I
have never been able to apply successfully.
Cheers,
Niko
On Mon, 07 Nov 2011 21:00:51 +0100, Luc Maisonobe (Commented) (JIRA)
<j...@apache.org> wrote:
[
https://issues.apache.org/jira/browse/MATH-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13145744#comment-13145744
]
Luc Maisonobe commented on MATH-702:
------------------------------------
You are right.
for now, encoding/decoding is both liner only and hidden in a private
inner class (FitnessFunction), so users only see simple bounds and
inside these bounds the transform is linear.
For sure if we come up with a different mapping, we will need to come up
with a way to define also the mapping of covariance. One way would be to
rely on the Jacobian, but it would be strange to propose mapping
function and requiring them to be smooth while the goal function by
itself could be highly non-smooth.
So for now, the simple linear mapping seems sufficient to me, and would
need improvement only if we change some internals of the class.
CMA-ES optimizer input sigma should not be normalized by user
-------------------------------------------------------------
Key: MATH-702
URL: https://issues.apache.org/jira/browse/MATH-702
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Reporter: Luc Maisonobe
Priority: Minor
Fix For: 3.0
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.
The optimizer should accept values in the same units as the other
parameters and use "encode" (or a similar function) to do the
normalization. This way, normalization is considered an internal
implementation detail.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
Science is a way of trying not to fool yourself.
The first principle is that you must not fool yourself, and you
are the easiest person to fool. So you have to be very careful
about that. After you've not fooled yourself, it's easy not to
fool other[ scientist]s. You just have to be honest in a
conventional way after that.
-- Richard P. Feynman
Nikolaus Hansen
INRIA, Research Centre Saclay – Ile-de-France
Machine Learning and Optimization group (TAO)
University Paris-Sud (Orsay)
LRI (UMR 8623), building 490
91405 ORSAY Cedex, France
Phone: +33-1-691-56495, Fax: +33-1-691-54240
URL: http://www.lri.fr/~hansen
