You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Luc Maisonobe <Lu...@free.fr> on 2011/11/07 22:38:45 UTC
[math] constrained optimization
Hi all,
Gilles has started adding an API for simple bounds constraints in
optimization, which will soo be available for both Bobyqa and CMA-ES, as
both method naturally support such constraints.
I wondered if we could take the opportunity to set up a poor man
implementation in the abstract base class for optimizers that do not
support constraints, such as Nelder-Mead and Virginia Torczon's
multi-directional algorithm. Gilles work on the proper API plus this
poor man implementation would allow solving the old issue MATH-196 I
created 3 years and an half ago ...
A basic implementation can be based on an array of mappers inserted
between the user variables and the variables the optimizer manages. For
each component of the current point x[i] considered in user space, we
would map it to an optimizer variable y[i] using:
for (int i = 0; i < n; ++i) {
y[i] = mapper[i].encode(x[i]);
}
and a similar setting for retrieving x[i] from y[i] using a decode
function. The x[i] variables would be subject to bounds (some may be
bounded and others not bouded), whereas y[i] would all be unbounded.
Mapper would be an interface with four implementations, depending on bounds.
NoBoundsMapper would be used for components x[i] which are nturally
unbounded, encode and decode would be the identity function.
LowerBoundMapper would be used for components x[i] that must be larger
than a lower bound a:
encode(x) = ln(x - a)
decode(y) = a + exp(y).
UpperBoundMapper would be used for components x[i] that must be lesser
than an upper bound b:
encode(x) = -ln(b -x)
decode(y) = b - exp(-y).
LowerUpperBoundMapper would be used for components x[i] that must be
betwee lower bound a and upper bound b:
encode(x) = ln((x - a) / (b - x))
decode(y) = (a + b exp(y)) / (1 + exp(y))
Due to numerical considerations and the fact infinity can be
represented, I'm not sure if the bounds can be reached or not, it
probably depends on how we implement the encode/decode functions.
For sure, it does not replace proper handling of bounds, but it would be
quite useful. It is what we suggested as a fallback solution to several
users who needed constrained optimization.
If you agree with this, I could implement it in the next few days, so
Gilles could set up the proper handling for CMA-ES and fine-tune the API.
What do you think about this ?
Luc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Validator] won't be continued ?
Posted by Matt Benson <gu...@gmail.com>.
On Sun, Nov 27, 2011 at 3:02 PM, Erhan Bagdemir
<er...@googlemail.com> wrote:
> Thanks for your reply.
> I think that it's a project which seems to be discontinued.
> The last reply on Jira is from August.
> Maybe they do need some contribution support from newcomers :-)
I assure you, the Bean Validation podling is not discontinued. There
just isn't that terribly much to do anymore. You'll see activity
increase when the next version of the specification comes out,
certainly. Bean Validation is likely to graduate from the incubator
any time, whenever all the interested parties get enough spare cycles.
HTH,
Matt
>
>
> Am 27.11.2011 um 19:39 schrieb Simone Tripodi:
>
>> Hi Erhan,
>> for JSR303 I suggest you adopting Apache BeanValidation[1].
>> HTH!
>> Simo
>>
>> [1] http://incubator.apache.org/bval/cwiki/index.html
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>>
>> On Sun, Nov 27, 2011 at 7:16 PM, | Erhan Bagdemir
>> <er...@googlemail.com> wrote:
>>> Is there any plan or improvement for Validator project?
>>> I see on Jira that the second version was already planed some time ago and includes JSR303 in which i'm very interested.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Validator] won't be continued ?
Posted by Erhan Bagdemir <er...@googlemail.com>.
Thanks for your reply.
I think that it's a project which seems to be discontinued.
The last reply on Jira is from August.
Maybe they do need some contribution support from newcomers :-)
Am 27.11.2011 um 19:39 schrieb Simone Tripodi:
> Hi Erhan,
> for JSR303 I suggest you adopting Apache BeanValidation[1].
> HTH!
> Simo
>
> [1] http://incubator.apache.org/bval/cwiki/index.html
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Sun, Nov 27, 2011 at 7:16 PM, | Erhan Bagdemir
> <er...@googlemail.com> wrote:
>> Is there any plan or improvement for Validator project?
>> I see on Jira that the second version was already planed some time ago and includes JSR303 in which i'm very interested.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Validator] won't be continued ?
Posted by Simone Tripodi <si...@apache.org>.
Hi Erhan,
for JSR303 I suggest you adopting Apache BeanValidation[1].
HTH!
Simo
[1] http://incubator.apache.org/bval/cwiki/index.html
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sun, Nov 27, 2011 at 7:16 PM, | Erhan Bagdemir
<er...@googlemail.com> wrote:
> Is there any plan or improvement for Validator project?
> I see on Jira that the second version was already planed some time ago and includes JSR303 in which i'm very interested.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Validator] won't be continued ?
Posted by Nick Burch <ni...@alfresco.com>.
On Sun, 27 Nov 2011, | Erhan Bagdemir wrote:
> Is there any plan or improvement for Validator project?
I was hoping to get another release out during ApacheCon, but alas I
didn't get the time. It is on my todo list, but if someone fancied helping
by working up a patch to fix the issues raised in the last release vote,
that'd speed things up :)
> I see on Jira that the second version was already planed some time ago
> and includes JSR303 in which i'm very interested.
As Matt has pointed out, if you're interested in JSR303 then you should be
using BeanValidator, as that's where the development of the functionality
at Apache has occured
Nick
[Validator] won't be continued ?
Posted by | Erhan Bagdemir <er...@googlemail.com>.
Is there any plan or improvement for Validator project?
I see on Jira that the second version was already planed some time ago and includes JSR303 in which i'm very interested.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] constrained optimization
Posted by Luc Maisonobe <Lu...@free.fr>.
Hello,
Le 14/11/2011 16:34, luc.maisonobe@free.fr a écrit :
> Hi Gilles,
>
> ----- Mail original -----
>> Hi.
>>
>>>> [...]
>>>>>
>>>>> In this case, the new API with boundaries setting should not be
>>>>> set
>>>> at
>>>>> the level of the abstract class that is share by CMA-ES, Bobyqa,
>>>>> Nelder-Mead and MultiDirectional.
>>>>
>>>> You are right but this was considered as a compromise in order to
>>>> avoid
>>>> an
>>>> additional level in the hierarchy:
>>>> BaseAbstractSimpleBoundsScalarOptimizer<FUNC extends
>>>> MultivariateRealFunction>
>>>> extends BaseAbstractScalarOptimizer<FUNC>
>>>>
>>>> Shall I add it?
>>>> If there aren't any drawbacks apart from an additional class, it
>>>> is
>>>> indeed
>>>> clearer.
>>>
>>> If you think it's clearer, then go ahead.
>>
>> In principle, it would be; but in practice, this entails adding one
>> "...SimpleBounds..." class or interface for each existing class of
>> interface that could support simple bounds.
>> [Then, if someday we add another kind of constraint, this will again
>> multiply by two the number of classes and interfaces...]
>>
>> I think this will complicate things a lot for no benefit.
>>
>> With the current version, I assumed that an algorithm may choose to
>> ignore
>> the bounds settings.
>
> This would be really difficult to understand for users. Most of them
> don't know which optimizer support bounds and which don't. I would
> expect them to rely on the fact the method is in the API or not.
>
>>
>> If we must make things really fool-proof, the algorithms that do not
>> support
>> bounds could throw "UnsupportedOperationException" from the
>> corresponding
>> "optimize" (which must then be overridden in each affected class).
>>
>> What do you think?
>
> I'm really not a big fan of adding methods just for throwing
> UnsupportedOperationException in many (if not most) cases. Also having
> the unbounded method call the bounded one which in turn can ignore the
> bounds is error prone.
>
> What about two different interfaces, one for unbounded optimization and one for simple boundaries ?
> Some optimizers would implement both, some would implement only one. Thes
> would be interfaces, not abstract classes in this case. It does make sense and
> is much simpler.
Thanks Gilles for having set up these interfaces.
I have tried to create a SimpleBoundsOptimizerAdapter that would wrap a
BaseMultivariateRealOptimizer and implement the
BaseSimpleBoundsMultivariateRealOptimizer interface, thus allowing to
use raw optimizers for solving bounded problems.
It turns out to be impossible to hide the underlying function adapters
in all cases. The problem lies with the mapping adapter, because it
really changes the values. This implies it should be used not only for
function evaluation only, but also for start point (this is easy), for
result optimum (this is easy), for convergence checker (this is really
difficult since convergence is based on deltas) and in the specific case
of simplex optimizer, to the simplex itself (this is almost impossible
since we have to know it is simplex based and since the initial simplex
is also based on deltas). In fact, the existing test cases for the
mapping function adapter already show what is needed.
So I think we can't completely hide these function adapters, and we
should simply let these adapters available for users, who can manage
them appropriately and use their mapping in both directions when needed.
The user guide was already updated and contains documentation for these
function adapters in the optimizers section. This documentation can be
extended to explain the convergence and simplex issues for the mapping
adapter.
Considering this, I am going to resolve issue MATH-196, except if
someone complains.
best regards,
Luc
>
> Luc
>
>>
>>>> [...]
>>
>>
>> Gilles
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] constrained optimization
Posted by lu...@free.fr.
Hi Gilles,
----- Mail original -----
> Hi.
>
> > > [...]
> > >>
> > >> In this case, the new API with boundaries setting should not be
> > >> set
> > >at
> > >> the level of the abstract class that is share by CMA-ES, Bobyqa,
> > >> Nelder-Mead and MultiDirectional.
> > >
> > >You are right but this was considered as a compromise in order to
> > >avoid
> > >an
> > >additional level in the hierarchy:
> > >BaseAbstractSimpleBoundsScalarOptimizer<FUNC extends
> > >MultivariateRealFunction>
> > > extends BaseAbstractScalarOptimizer<FUNC>
> > >
> > >Shall I add it?
> > >If there aren't any drawbacks apart from an additional class, it
> > >is
> > >indeed
> > >clearer.
> >
> > If you think it's clearer, then go ahead.
>
> In principle, it would be; but in practice, this entails adding one
> "...SimpleBounds..." class or interface for each existing class of
> interface that could support simple bounds.
> [Then, if someday we add another kind of constraint, this will again
> multiply by two the number of classes and interfaces...]
>
> I think this will complicate things a lot for no benefit.
>
> With the current version, I assumed that an algorithm may choose to
> ignore
> the bounds settings.
This would be really difficult to understand for users. Most of them
don't know which optimizer support bounds and which don't. I would
expect them to rely on the fact the method is in the API or not.
>
> If we must make things really fool-proof, the algorithms that do not
> support
> bounds could throw "UnsupportedOperationException" from the
> corresponding
> "optimize" (which must then be overridden in each affected class).
>
> What do you think?
I'm really not a big fan of adding methods just for throwing
UnsupportedOperationException in many (if not most) cases. Also having
the unbounded method call the bounded one which in turn can ignore the
bounds is error prone.
What about two different interfaces, one for unbounded optimization and one for simple boundaries ?
Some optimizers would implement both, some would implement only one. Thes
would be interfaces, not abstract classes in this case. It does make sense and
is much simpler.
Luc
>
> > > [...]
>
>
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] constrained optimization
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hi.
> > [...]
> >>
> >> In this case, the new API with boundaries setting should not be set
> >at
> >> the level of the abstract class that is share by CMA-ES, Bobyqa,
> >> Nelder-Mead and MultiDirectional.
> >
> >You are right but this was considered as a compromise in order to avoid
> >an
> >additional level in the hierarchy:
> >BaseAbstractSimpleBoundsScalarOptimizer<FUNC extends
> >MultivariateRealFunction>
> > extends BaseAbstractScalarOptimizer<FUNC>
> >
> >Shall I add it?
> >If there aren't any drawbacks apart from an additional class, it is
> >indeed
> >clearer.
>
> If you think it's clearer, then go ahead.
In principle, it would be; but in practice, this entails adding one
"...SimpleBounds..." class or interface for each existing class of
interface that could support simple bounds.
[Then, if someday we add another kind of constraint, this will again
multiply by two the number of classes and interfaces...]
I think this will complicate things a lot for no benefit.
With the current version, I assumed that an algorithm may choose to ignore
the bounds settings.
If we must make things really fool-proof, the algorithms that do not support
bounds could throw "UnsupportedOperationException" from the corresponding
"optimize" (which must then be overridden in each affected class).
What do you think?
> > [...]
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] constrained optimization
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 10/11/2011 23:39, Gilles Sadowski a écrit :
> 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.
It could be done just as you say: building optimizers adapters on top of
the functions adapters. Documentation should be updated, though.
An intersting side effect would be that we could also do the
encoding/decoding of start point and result point in case of mapping
adapter. For no, the user has to do it by himself which is cumbersome.
So +1 to add this.
>
> 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?
It would work only for mapping adapter. Penalty adapter cannot be
differentiated.
Luc
>
>> [...]
>
>
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] constrained optimization
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] constrained optimization
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 09/11/2011 22:44, Luc Maisonobe a écrit :
>
>
>
> Gilles Sadowski <gi...@harfang.homelinux.org> a écrit :
>
>> Hello.
>>
>>>>>>
>>>>>> Gilles has started adding an API for simple bounds constraints in
>>>>>> optimization, which will soo be available for both Bobyqa and
>> CMA-ES, as
>>>>>> both method naturally support such constraints.
>>>>>>
>>>>>> I wondered if we could take the opportunity to set up a poor man
>>>>>> implementation in the abstract base class for optimizers that do
>> not
>>>>>> support constraints, such as Nelder-Mead and Virginia Torczon's
>>>>>> multi-directional algorithm. Gilles work on the proper API plus
>> this
>>>>>> poor man implementation would allow solving the old issue
>> MATH-196 I
>>>>>> created 3 years and an half ago ...
>>>>>>
>>>>>> A basic implementation can be based on an array of mappers
>> inserted
>>>>>> between the user variables and the variables the optimizer
>> manages. For
>>>>>> each component of the current point x[i] considered in user
>> space, we
>>>>>> would map it to an optimizer variable y[i] using:
>>>>>>
>>>>>> for (int i = 0; i < n; ++i) {
>>>>>> y[i] = mapper[i].encode(x[i]);
>>>>>> }
>>>>>>
>>>>>> and a similar setting for retrieving x[i] from y[i] using a
>> decode
>>>>>> function. The x[i] variables would be subject to bounds (some may
>> be
>>>>>> bounded and others not bouded), whereas y[i] would all be
>> unbounded.
>>>>>>
>>>>>> Mapper would be an interface with four implementations, depending
>> on bounds.
>>>>>>
>>>>>> NoBoundsMapper would be used for components x[i] which are
>> nturally
>>>>>> unbounded, encode and decode would be the identity function.
>>>>>>
>>>>>> LowerBoundMapper would be used for components x[i] that must be
>> larger
>>>>>> than a lower bound a:
>>>>>> encode(x) = ln(x - a)
>>>>>> decode(y) = a + exp(y).
>>>>>>
>>>>>> UpperBoundMapper would be used for components x[i] that must be
>> lesser
>>>>>> than an upper bound b:
>>>>>> encode(x) = -ln(b -x)
>>>>>> decode(y) = b - exp(-y).
>>>>>>
>>>>>> LowerUpperBoundMapper would be used for components x[i] that must
>> be
>>>>>> betwee lower bound a and upper bound b:
>>>>>> encode(x) = ln((x - a) / (b - x))
>>>>>> decode(y) = (a + b exp(y)) / (1 + exp(y))
>>>>>
>>>>> I forgot to say all these classes would be internal ones, the user
>> would
>>>>> never see them, he will simply see Gilles API with the bounds
>> arrays,
>>>>> where some elements of the array could be set to infinity, or some
>>>>> arrays could be null which would be equivalent to set all their
>>>>> components to infinity with the proper sign.
>>>>>
>>>>> Luc
>>>>>
>>>>>>
>>>>>> Due to numerical considerations and the fact infinity can be
>>>>>> represented, I'm not sure if the bounds can be reached or not, it
>>>>>> probably depends on how we implement the encode/decode functions.
>>>>>>
>>>>>> For sure, it does not replace proper handling of bounds, but it
>> would be
>>>>>> quite useful. It is what we suggested as a fallback solution to
>> several
>>>>>> users who needed constrained optimization.
>>>>>>
>>>>>> If you agree with this, I could implement it in the next few
>> days, so
>>>>>> Gilles could set up the proper handling for CMA-ES and fine-tune
>> the API.
>>>>>>
>>>>>> What do you think about this ?
>>>>
>>>> I wonder whether this feature should be "prominent" rather than
>> "internal".
>>>> By having it an implementation detail we run the risk of giving a
>> false
>>>> impression of an algorithm's ability to correctly/efficiently deal
>> with the
>>>> constraints. It seems dangerous to hide a feature that is in fact
>> not part
>>>> of the "standard" implementation (cf. another discussion where this
>> point
>>>> was also raised).
>>>
>>> In this case, the new API with boundaries setting should not be set
>> at
>>> the level of the abstract class that is share by CMA-ES, Bobyqa,
>>> Nelder-Mead and MultiDirectional.
>>
>> You are right but this was considered as a compromise in order to avoid
>> an
>> additional level in the hierarchy:
>> BaseAbstractSimpleBoundsScalarOptimizer<FUNC extends
>> MultivariateRealFunction>
>> extends BaseAbstractScalarOptimizer<FUNC>
>>
>> Shall I add it?
>> If there aren't any drawbacks apart from an additional class, it is
>> indeed
>> clearer.
>
> If you think it's clearer, then go ahead.
>
>>
>>> I proposed this implementation, as a way to provide this even for the
>>> last two methods. Of course, we should document this. In this case,
>> it
>>> is not a modification of the algorithm, and in fact we do rely on the
>>> original ones. We simply add another method, which uses an internal
>> adapter.
>>>
>>>> An alternative would be to create an adapter class (which users
>> would have
>>>> to explicitly instantiate) that would take care of the conversion
>> from
>>>> bounded to unbounded.
>>
>> With the new class, I think that it will be necessary to figure out how
>> to use
>> the "adapter" pattern instead of hiding the "poor man's" handling of
>> bounds.
>> Do you agree?
>
> Yes. And we should make it clear in the documentation that there are classes
> that already handle bounds by themselves and classes that do not and hence
> should use the adaptor. So each approach should have an @see reference to
> the other approach, so user understand there are two approaches and can
> decide which one is more suited to the problem at hand.
>
>>
>>>> Concerning the mapping itself, it migh be useful to be able to
>> select the
>>>> "encode" and "decode" functions.[1]
>>>
>>> Fine, I missed this.
>>>
>>>>
>>>> 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. In the documentation, the
adapters refer directly to the CMAES and BOBYQA optimizers as better
ways to handle constraints. These references may be updated with the new
intermediate abstract class when it will be available.
Luc
>
> Yes.
>
> Best regards
> Luc
>
>>
>>
>> Regards,
>> Gilles
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] constrained optimization
Posted by Luc Maisonobe <Lu...@free.fr>.
Gilles Sadowski <gi...@harfang.homelinux.org> a écrit :
>Hello.
>
>> >>>
>> >>> Gilles has started adding an API for simple bounds constraints in
>> >>> optimization, which will soo be available for both Bobyqa and
>CMA-ES, as
>> >>> both method naturally support such constraints.
>> >>>
>> >>> I wondered if we could take the opportunity to set up a poor man
>> >>> implementation in the abstract base class for optimizers that do
>not
>> >>> support constraints, such as Nelder-Mead and Virginia Torczon's
>> >>> multi-directional algorithm. Gilles work on the proper API plus
>this
>> >>> poor man implementation would allow solving the old issue
>MATH-196 I
>> >>> created 3 years and an half ago ...
>> >>>
>> >>> A basic implementation can be based on an array of mappers
>inserted
>> >>> between the user variables and the variables the optimizer
>manages. For
>> >>> each component of the current point x[i] considered in user
>space, we
>> >>> would map it to an optimizer variable y[i] using:
>> >>>
>> >>> for (int i = 0; i < n; ++i) {
>> >>> y[i] = mapper[i].encode(x[i]);
>> >>> }
>> >>>
>> >>> and a similar setting for retrieving x[i] from y[i] using a
>decode
>> >>> function. The x[i] variables would be subject to bounds (some may
>be
>> >>> bounded and others not bouded), whereas y[i] would all be
>unbounded.
>> >>>
>> >>> Mapper would be an interface with four implementations, depending
>on bounds.
>> >>>
>> >>> NoBoundsMapper would be used for components x[i] which are
>nturally
>> >>> unbounded, encode and decode would be the identity function.
>> >>>
>> >>> LowerBoundMapper would be used for components x[i] that must be
>larger
>> >>> than a lower bound a:
>> >>> encode(x) = ln(x - a)
>> >>> decode(y) = a + exp(y).
>> >>>
>> >>> UpperBoundMapper would be used for components x[i] that must be
>lesser
>> >>> than an upper bound b:
>> >>> encode(x) = -ln(b -x)
>> >>> decode(y) = b - exp(-y).
>> >>>
>> >>> LowerUpperBoundMapper would be used for components x[i] that must
>be
>> >>> betwee lower bound a and upper bound b:
>> >>> encode(x) = ln((x - a) / (b - x))
>> >>> decode(y) = (a + b exp(y)) / (1 + exp(y))
>> >>
>> >> I forgot to say all these classes would be internal ones, the user
>would
>> >> never see them, he will simply see Gilles API with the bounds
>arrays,
>> >> where some elements of the array could be set to infinity, or some
>> >> arrays could be null which would be equivalent to set all their
>> >> components to infinity with the proper sign.
>> >>
>> >> Luc
>> >>
>> >>>
>> >>> Due to numerical considerations and the fact infinity can be
>> >>> represented, I'm not sure if the bounds can be reached or not, it
>> >>> probably depends on how we implement the encode/decode functions.
>> >>>
>> >>> For sure, it does not replace proper handling of bounds, but it
>would be
>> >>> quite useful. It is what we suggested as a fallback solution to
>several
>> >>> users who needed constrained optimization.
>> >>>
>> >>> If you agree with this, I could implement it in the next few
>days, so
>> >>> Gilles could set up the proper handling for CMA-ES and fine-tune
>the API.
>> >>>
>> >>> What do you think about this ?
>> >
>> > I wonder whether this feature should be "prominent" rather than
>"internal".
>> > By having it an implementation detail we run the risk of giving a
>false
>> > impression of an algorithm's ability to correctly/efficiently deal
>with the
>> > constraints. It seems dangerous to hide a feature that is in fact
>not part
>> > of the "standard" implementation (cf. another discussion where this
>point
>> > was also raised).
>>
>> In this case, the new API with boundaries setting should not be set
>at
>> the level of the abstract class that is share by CMA-ES, Bobyqa,
>> Nelder-Mead and MultiDirectional.
>
>You are right but this was considered as a compromise in order to avoid
>an
>additional level in the hierarchy:
>BaseAbstractSimpleBoundsScalarOptimizer<FUNC extends
>MultivariateRealFunction>
> extends BaseAbstractScalarOptimizer<FUNC>
>
>Shall I add it?
>If there aren't any drawbacks apart from an additional class, it is
>indeed
>clearer.
If you think it's clearer, then go ahead.
>
>> I proposed this implementation, as a way to provide this even for the
>> last two methods. Of course, we should document this. In this case,
>it
>> is not a modification of the algorithm, and in fact we do rely on the
>> original ones. We simply add another method, which uses an internal
>adapter.
>>
>> > An alternative would be to create an adapter class (which users
>would have
>> > to explicitly instantiate) that would take care of the conversion
>from
>> > bounded to unbounded.
>
>With the new class, I think that it will be necessary to figure out how
>to use
>the "adapter" pattern instead of hiding the "poor man's" handling of
>bounds.
>Do you agree?
Yes. And we should make it clear in the documentation that there are classes
that already handle bounds by themselves and classes that do not and hence
should use the adaptor. So each approach should have an @see reference to
the other approach, so user understand there are two approaches and can
decide which one is more suited to the problem at hand.
>
>> > Concerning the mapping itself, it migh be useful to be able to
>select the
>> > "encode" and "decode" functions.[1]
>>
>> Fine, I missed this.
>>
>> >
>> > 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.
Yes.
Best regards
Luc
>
>
>Regards,
>Gilles
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] constrained optimization
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hello.
> >>>
> >>> Gilles has started adding an API for simple bounds constraints in
> >>> optimization, which will soo be available for both Bobyqa and CMA-ES, as
> >>> both method naturally support such constraints.
> >>>
> >>> I wondered if we could take the opportunity to set up a poor man
> >>> implementation in the abstract base class for optimizers that do not
> >>> support constraints, such as Nelder-Mead and Virginia Torczon's
> >>> multi-directional algorithm. Gilles work on the proper API plus this
> >>> poor man implementation would allow solving the old issue MATH-196 I
> >>> created 3 years and an half ago ...
> >>>
> >>> A basic implementation can be based on an array of mappers inserted
> >>> between the user variables and the variables the optimizer manages. For
> >>> each component of the current point x[i] considered in user space, we
> >>> would map it to an optimizer variable y[i] using:
> >>>
> >>> for (int i = 0; i < n; ++i) {
> >>> y[i] = mapper[i].encode(x[i]);
> >>> }
> >>>
> >>> and a similar setting for retrieving x[i] from y[i] using a decode
> >>> function. The x[i] variables would be subject to bounds (some may be
> >>> bounded and others not bouded), whereas y[i] would all be unbounded.
> >>>
> >>> Mapper would be an interface with four implementations, depending on bounds.
> >>>
> >>> NoBoundsMapper would be used for components x[i] which are nturally
> >>> unbounded, encode and decode would be the identity function.
> >>>
> >>> LowerBoundMapper would be used for components x[i] that must be larger
> >>> than a lower bound a:
> >>> encode(x) = ln(x - a)
> >>> decode(y) = a + exp(y).
> >>>
> >>> UpperBoundMapper would be used for components x[i] that must be lesser
> >>> than an upper bound b:
> >>> encode(x) = -ln(b -x)
> >>> decode(y) = b - exp(-y).
> >>>
> >>> LowerUpperBoundMapper would be used for components x[i] that must be
> >>> betwee lower bound a and upper bound b:
> >>> encode(x) = ln((x - a) / (b - x))
> >>> decode(y) = (a + b exp(y)) / (1 + exp(y))
> >>
> >> I forgot to say all these classes would be internal ones, the user would
> >> never see them, he will simply see Gilles API with the bounds arrays,
> >> where some elements of the array could be set to infinity, or some
> >> arrays could be null which would be equivalent to set all their
> >> components to infinity with the proper sign.
> >>
> >> Luc
> >>
> >>>
> >>> Due to numerical considerations and the fact infinity can be
> >>> represented, I'm not sure if the bounds can be reached or not, it
> >>> probably depends on how we implement the encode/decode functions.
> >>>
> >>> For sure, it does not replace proper handling of bounds, but it would be
> >>> quite useful. It is what we suggested as a fallback solution to several
> >>> users who needed constrained optimization.
> >>>
> >>> If you agree with this, I could implement it in the next few days, so
> >>> Gilles could set up the proper handling for CMA-ES and fine-tune the API.
> >>>
> >>> What do you think about this ?
> >
> > I wonder whether this feature should be "prominent" rather than "internal".
> > By having it an implementation detail we run the risk of giving a false
> > impression of an algorithm's ability to correctly/efficiently deal with the
> > constraints. It seems dangerous to hide a feature that is in fact not part
> > of the "standard" implementation (cf. another discussion where this point
> > was also raised).
>
> In this case, the new API with boundaries setting should not be set at
> the level of the abstract class that is share by CMA-ES, Bobyqa,
> Nelder-Mead and MultiDirectional.
You are right but this was considered as a compromise in order to avoid an
additional level in the hierarchy:
BaseAbstractSimpleBoundsScalarOptimizer<FUNC extends MultivariateRealFunction>
extends BaseAbstractScalarOptimizer<FUNC>
Shall I add it?
If there aren't any drawbacks apart from an additional class, it is indeed
clearer.
> I proposed this implementation, as a way to provide this even for the
> last two methods. Of course, we should document this. In this case, it
> is not a modification of the algorithm, and in fact we do rely on the
> original ones. We simply add another method, which uses an internal adapter.
>
> > An alternative would be to create an adapter class (which users would have
> > to explicitly instantiate) that would take care of the conversion from
> > bounded to unbounded.
With the new class, I think that it will be necessary to figure out how to use
the "adapter" pattern instead of hiding the "poor man's" handling of bounds.
Do you agree?
> > Concerning the mapping itself, it migh be useful to be able to select the
> > "encode" and "decode" functions.[1]
>
> Fine, I missed this.
>
> >
> > 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.
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] constrained optimization
Posted by Luc Maisonobe <Lu...@free.fr>.
Hi Gilles,
Le 08/11/2011 16:29, Gilles Sadowski a écrit :
>>> Hi all,
>
> Hi Luc.
>
>>>
>>> Gilles has started adding an API for simple bounds constraints in
>>> optimization, which will soo be available for both Bobyqa and CMA-ES, as
>>> both method naturally support such constraints.
>>>
>>> I wondered if we could take the opportunity to set up a poor man
>>> implementation in the abstract base class for optimizers that do not
>>> support constraints, such as Nelder-Mead and Virginia Torczon's
>>> multi-directional algorithm. Gilles work on the proper API plus this
>>> poor man implementation would allow solving the old issue MATH-196 I
>>> created 3 years and an half ago ...
>>>
>>> A basic implementation can be based on an array of mappers inserted
>>> between the user variables and the variables the optimizer manages. For
>>> each component of the current point x[i] considered in user space, we
>>> would map it to an optimizer variable y[i] using:
>>>
>>> for (int i = 0; i < n; ++i) {
>>> y[i] = mapper[i].encode(x[i]);
>>> }
>>>
>>> and a similar setting for retrieving x[i] from y[i] using a decode
>>> function. The x[i] variables would be subject to bounds (some may be
>>> bounded and others not bouded), whereas y[i] would all be unbounded.
>>>
>>> Mapper would be an interface with four implementations, depending on bounds.
>>>
>>> NoBoundsMapper would be used for components x[i] which are nturally
>>> unbounded, encode and decode would be the identity function.
>>>
>>> LowerBoundMapper would be used for components x[i] that must be larger
>>> than a lower bound a:
>>> encode(x) = ln(x - a)
>>> decode(y) = a + exp(y).
>>>
>>> UpperBoundMapper would be used for components x[i] that must be lesser
>>> than an upper bound b:
>>> encode(x) = -ln(b -x)
>>> decode(y) = b - exp(-y).
>>>
>>> LowerUpperBoundMapper would be used for components x[i] that must be
>>> betwee lower bound a and upper bound b:
>>> encode(x) = ln((x - a) / (b - x))
>>> decode(y) = (a + b exp(y)) / (1 + exp(y))
>>
>> I forgot to say all these classes would be internal ones, the user would
>> never see them, he will simply see Gilles API with the bounds arrays,
>> where some elements of the array could be set to infinity, or some
>> arrays could be null which would be equivalent to set all their
>> components to infinity with the proper sign.
>>
>> Luc
>>
>>>
>>> Due to numerical considerations and the fact infinity can be
>>> represented, I'm not sure if the bounds can be reached or not, it
>>> probably depends on how we implement the encode/decode functions.
>>>
>>> For sure, it does not replace proper handling of bounds, but it would be
>>> quite useful. It is what we suggested as a fallback solution to several
>>> users who needed constrained optimization.
>>>
>>> If you agree with this, I could implement it in the next few days, so
>>> Gilles could set up the proper handling for CMA-ES and fine-tune the API.
>>>
>>> What do you think about this ?
>
> I wonder whether this feature should be "prominent" rather than "internal".
> By having it an implementation detail we run the risk of giving a false
> impression of an algorithm's ability to correctly/efficiently deal with the
> constraints. It seems dangerous to hide a feature that is in fact not part
> of the "standard" implementation (cf. another discussion where this point
> was also raised).
In this case, the new API with boundaries setting should not be set at
the level of the abstract class that is share by CMA-ES, Bobyqa,
Nelder-Mead and MultiDirectional.
I proposed this implementation, as a way to provide this even for the
last two methods. Of course, we should document this. In this case, it
is not a modification of the algorithm, and in fact we do rely on the
original ones. We simply add another method, which uses an internal adapter.
> An alternative would be to create an adapter class (which users would have
> to explicitly instantiate) that would take care of the conversion from
> bounded to unbounded.
> Concerning the mapping itself, it migh be useful to be able to select the
> "encode" and "decode" functions.[1]
Fine, I missed this.
>
> 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.
>
> It would be nice to have an optimization specialist's opinion on this whole
> issue.
Sure.
best regards,
Luc
>
>
> Regards,
> Gilles
>
> [1] The classes "Logit" and "Sigmoid" (in "o.a.c.m.analysis.function") were
> introduced for exactly this purpose.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] constrained optimization
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
> > Hi all,
Hi Luc.
> >
> > Gilles has started adding an API for simple bounds constraints in
> > optimization, which will soo be available for both Bobyqa and CMA-ES, as
> > both method naturally support such constraints.
> >
> > I wondered if we could take the opportunity to set up a poor man
> > implementation in the abstract base class for optimizers that do not
> > support constraints, such as Nelder-Mead and Virginia Torczon's
> > multi-directional algorithm. Gilles work on the proper API plus this
> > poor man implementation would allow solving the old issue MATH-196 I
> > created 3 years and an half ago ...
> >
> > A basic implementation can be based on an array of mappers inserted
> > between the user variables and the variables the optimizer manages. For
> > each component of the current point x[i] considered in user space, we
> > would map it to an optimizer variable y[i] using:
> >
> > for (int i = 0; i < n; ++i) {
> > y[i] = mapper[i].encode(x[i]);
> > }
> >
> > and a similar setting for retrieving x[i] from y[i] using a decode
> > function. The x[i] variables would be subject to bounds (some may be
> > bounded and others not bouded), whereas y[i] would all be unbounded.
> >
> > Mapper would be an interface with four implementations, depending on bounds.
> >
> > NoBoundsMapper would be used for components x[i] which are nturally
> > unbounded, encode and decode would be the identity function.
> >
> > LowerBoundMapper would be used for components x[i] that must be larger
> > than a lower bound a:
> > encode(x) = ln(x - a)
> > decode(y) = a + exp(y).
> >
> > UpperBoundMapper would be used for components x[i] that must be lesser
> > than an upper bound b:
> > encode(x) = -ln(b -x)
> > decode(y) = b - exp(-y).
> >
> > LowerUpperBoundMapper would be used for components x[i] that must be
> > betwee lower bound a and upper bound b:
> > encode(x) = ln((x - a) / (b - x))
> > decode(y) = (a + b exp(y)) / (1 + exp(y))
>
> I forgot to say all these classes would be internal ones, the user would
> never see them, he will simply see Gilles API with the bounds arrays,
> where some elements of the array could be set to infinity, or some
> arrays could be null which would be equivalent to set all their
> components to infinity with the proper sign.
>
> Luc
>
> >
> > Due to numerical considerations and the fact infinity can be
> > represented, I'm not sure if the bounds can be reached or not, it
> > probably depends on how we implement the encode/decode functions.
> >
> > For sure, it does not replace proper handling of bounds, but it would be
> > quite useful. It is what we suggested as a fallback solution to several
> > users who needed constrained optimization.
> >
> > If you agree with this, I could implement it in the next few days, so
> > Gilles could set up the proper handling for CMA-ES and fine-tune the API.
> >
> > What do you think about this ?
I wonder whether this feature should be "prominent" rather than "internal".
By having it an implementation detail we run the risk of giving a false
impression of an algorithm's ability to correctly/efficiently deal with the
constraints. It seems dangerous to hide a feature that is in fact not part
of the "standard" implementation (cf. another discussion where this point
was also raised).
An alternative would be to create an adapter class (which users would have
to explicitly instantiate) that would take care of the conversion from
bounded to unbounded.
Concerning the mapping itself, it migh be useful to be able to select the
"encode" and "decode" functions.[1]
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.
It would be nice to have an optimization specialist's opinion on this whole
issue.
Regards,
Gilles
[1] The classes "Logit" and "Sigmoid" (in "o.a.c.m.analysis.function") were
introduced for exactly this purpose.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] constrained optimization
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 07/11/2011 22:38, Luc Maisonobe a écrit :
> Hi all,
>
> Gilles has started adding an API for simple bounds constraints in
> optimization, which will soo be available for both Bobyqa and CMA-ES, as
> both method naturally support such constraints.
>
> I wondered if we could take the opportunity to set up a poor man
> implementation in the abstract base class for optimizers that do not
> support constraints, such as Nelder-Mead and Virginia Torczon's
> multi-directional algorithm. Gilles work on the proper API plus this
> poor man implementation would allow solving the old issue MATH-196 I
> created 3 years and an half ago ...
>
> A basic implementation can be based on an array of mappers inserted
> between the user variables and the variables the optimizer manages. For
> each component of the current point x[i] considered in user space, we
> would map it to an optimizer variable y[i] using:
>
> for (int i = 0; i < n; ++i) {
> y[i] = mapper[i].encode(x[i]);
> }
>
> and a similar setting for retrieving x[i] from y[i] using a decode
> function. The x[i] variables would be subject to bounds (some may be
> bounded and others not bouded), whereas y[i] would all be unbounded.
>
> Mapper would be an interface with four implementations, depending on bounds.
>
> NoBoundsMapper would be used for components x[i] which are nturally
> unbounded, encode and decode would be the identity function.
>
> LowerBoundMapper would be used for components x[i] that must be larger
> than a lower bound a:
> encode(x) = ln(x - a)
> decode(y) = a + exp(y).
>
> UpperBoundMapper would be used for components x[i] that must be lesser
> than an upper bound b:
> encode(x) = -ln(b -x)
> decode(y) = b - exp(-y).
>
> LowerUpperBoundMapper would be used for components x[i] that must be
> betwee lower bound a and upper bound b:
> encode(x) = ln((x - a) / (b - x))
> decode(y) = (a + b exp(y)) / (1 + exp(y))
I forgot to say all these classes would be internal ones, the user would
never see them, he will simply see Gilles API with the bounds arrays,
where some elements of the array could be set to infinity, or some
arrays could be null which would be equivalent to set all their
components to infinity with the proper sign.
Luc
>
> Due to numerical considerations and the fact infinity can be
> represented, I'm not sure if the bounds can be reached or not, it
> probably depends on how we implement the encode/decode functions.
>
> For sure, it does not replace proper handling of bounds, but it would be
> quite useful. It is what we suggested as a fallback solution to several
> users who needed constrained optimization.
>
> If you agree with this, I could implement it in the next few days, so
> Gilles could set up the proper handling for CMA-ES and fine-tune the API.
>
> What do you think about this ?
>
> Luc
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org