2011/10/27 Gilles Sadowski <gil...@harfang.homelinux.org>:
>> >> 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.
>
>> > [...]
>>
>> 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?
>
> On the principle, you are right of course.
> But I'm not sure that we gain much by adding this layer of data
> encapsulation, because having a single array (instead of three) is not
> enough to prevent a dimensionality error: indeed, the arrays dimension must
> match the expected argument of the function, and this possible mismatch can
> only be detected later, when the function is called (within the "doOptimize"
> method).
>
OK, that's a fair point.
>
> To be completely safe, we would have to introduce an additional method
> ("getDimension") in the "MultivariateFunction" interface. [But this has
> the drawback that it reduces the generality of this interface.]
>
I'm certainly not claiming that such a method *should* be added, but
may I ask why you think it reduces generality? I guess you are
thinking of generic multivariate functions, with unspecified number of
arguments (like sum(), product(), ...), but this could be handled by
returning eg a negative value. Again, I'm not claiming anything, I'm
just wondering (actually, wondering if what I did was wrong --or not
so good--, in a project I'm working on at work...).
>
> Also, keeping it simple (although not totally safe) by using (arrays of)
> primitive type makes the interface closer to what people are accustomed to
> coming from e.g. the C language. This approach is also used in the
> "...VectorialOptimizer" classes (see "BaseAbstractVectorialOptimizer" where
> a check is done to verify that the "target" and "weight" arrays have the
> same length).
>
> That said, I agree that it would be nicer to have a completely uniform and
> integrated set of interfaces. The current design is already quite a rework
> of the previous state of affairs (see versions 2.1 and 2.2) with much of the
> inconsistency and code duplication corrected. However, similarly to other
> design issues raised during the last months, it is not clear that the
> obvious solution at this point will lead to a clear improvement in the
> overall design. I mean that the code might in fact need a more thorough
> refactoring, not some patch here and there. But that work would be for the
> next++ major release. :-)
>
>
> Best,
> Gilles
>
I'm too new to this project to make any statement... We'll talk about
that in a few years...
Best regards,
Sébastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
