commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <Luc.Maison...@free.fr>
Subject Re: [math] constrained optimization
Date Sun, 27 Nov 2011 17:48:54 GMT
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


Mime
View raw message