Hi.
> [...]
> >>>
> >>>>
> >>>> Another argument for not hiding the mapping is that another poor
> >> man's
> >>>> approach is to use a penalty (when the optimizer's "guess" falls
> >> out of
> >>>> bounds) and I wonder whether some algorithm could behave better
> >> with one or
> >>>> the other approach.
> >>>
> >>> As far as I understand, direct methods that do not rely on
> >> derivatives
> >>> support well penalty functions. Gradients based methods do not.
> >>
> >> We could thus implement two adapters, one that will do a mapping of the
> >> variables and another that will use the penalty approach.
>
> Done in subversion repository as of r1200516.
This is not what I had in mind. Not having thought much about it, I thought
that we would have to implement an adapter around the optimizer (i.e. that
would transform a "...Optimizer" into a "...SimpleBoundsOptimizer").
What you've coded would have been part of the internal workings of those
adapters.
Now, as I said, this is not very clear in my mind at this moment... Maybe
that all that is needed is what you already provided.
One minor point: I'd put these adapters in a new package "optimization.util"
(instead of in "optimization.direct").
Second, maybe less minor, point (and somewhat related to the above
suggestion) is that your adapters are "MultivariateRealFunction"s. What if
one wants to try this approach with an optimizer that would need the
derivatives ("DifferentiableMultivariateRealFunction")?
Admittedly, there are no such optimizers currently but the "Abstract..."
base class is already available; so, either we think that for some reason,
there won't be such optimizers (and we should probably removed the unused
stuff) or we should foresee this option and the adapters should be
genericized somehow (like the "BaseAbstractScalarOptimizer<...>" in package
"optimiszation.direct).
Does this make sense?
> [...]
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
