2011/10/27 Luc Maisonobe <luc.maison...@free.fr>:
> Le 27/10/2011 14:45, Gilles Sadowski a écrit :
>> Hi.
>>
>> The BOBYQA optimizer takes simple bound contraints into account:
>> lowerBound(i) <= p(i) <= upperBound(i) 0 <= i < n
>> where "n" is the problem dimension.
>>
>> The parent class ("BaseMultivariateRealOptimizer") currently mandates the
>> following "optimize" method:
>> ---CUT---
>> RealPointValuePair optimize(int maxEval,
>> FUNC f,
>> GoalType goalType,
>> double[] startPoint);
>> ---CUT---
>>
>> I think that the bounds are arguments that should be passed through that
>> method. The current method definition is a special case: no bound
>> constraints (or, equivalently, all lower bounds = -infinity, all upper
>> bounds = +infinity).
>>
>> Thus, it seems that adding the following to the API
>> ---CUT---
>> RealPointValuePair optimize(int maxEval,
>> FUNC f,
>> GoalType goalType,
>> double[] startPoint,
>> double[] lowerBounds,
>> double[] upperBounds);
>> ---CUT---
>> is all there is to do in order to accomodate algorithms like BOBYQA.
>
> Big +1 here ! This is exactly what I need for some ongoing work.
>
>>
>> I'll then add the boiler plate code the concrete base class
>> ("BaseAbstractScalarOptimizer") so that subclasses can access the bounds,
>> similar to what is done for the "startPoint" argument.
>> The concrete implementation of the first "optimize" will just call the new
>> method with "lowerBounds" and "upperBounds" set to null.
>
> Many thanks.
> Luc
>
>>
>>
>> Is that OK?
>>
>>
>> Best regards,
>> Gilles
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
It sounds like a useful addition, which raises one question I'd like
to ask all of you. I guess all three double[] arrays should have the
same size, which must be checked, and also documented in the javadoc.
In order to avoid this, what I tend to do at the moment is to define a
new class --say, BoundedPoint-- which would hold three double:s an
initial value, a lower bound and an upper bound. Then I would just
provide the method with the corresponding array of BoundedPoint,
instead of three arrays of doubles. Then no dimension mismatch can
occur, and no additional information needs be provided in the javadoc.
Of course, the price to pay is that you have to construct a few
BoundedPoint. As I said, this is what I tend to do at the moment, but
I have mixed feelings about this solution vs. passing 3 double[]. Any
thoughts about this side question?
Sébastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
