commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Sterijevski <>
Subject Re: BOBYQA Question
Date Thu, 29 Sep 2011 23:25:50 GMT
Thank you.

I am working on making my Limited Dependent Variable Regressions agnostic to
the optimizer used. Plug and play (to the extent it is possible) is my aim.
I will try to concoct a test which hits this code path. I have used the C
version of BOBYQA under the COIN infrastructure. It is a deceptively good
solver-without gradients it flies quickly to a solution.

The one issue (and I can't remember if it is present in the C versions) is
that you do not get lagrangian estimates on the constraints. It would be
nice to have the solver output lagrangians.


On Thu, Sep 29, 2011 at 6:06 PM, Gilles Sadowski <> wrote:

> Hi.
> The work to be done on "BOBYQAOptimizer" is discussed in issue 621:
> There is still a lot to do on this code. And I wouldn't advise you to use
> it
> as is because the interface is likely to change: In fact, CM lacks an
> interface/base class for optimizers with constraints.
> >
> > I am testing some Limited Dependent Variable regressions and in shopping
> for
> > an optimizer I ran BOBYQA. I got the following exception:
> >
> > If this exception is thrown, just remove it from the code
> > If
> this
> > exception is thrown, just remove it from the code
> >     at
> >
> >     at
> >
> >
> > What is this message? Is it significant?
> Please see the issue referred to above.
> In short, the current set of unit tests does not cover all code paths. I've
> added "throw" statements at those places which I've currently spotted
> (probably not all of them yet).
> So, you've run a case that exercises a branch not covered by any of the
> current tests: Hence, it would be very useful if you could make a unit test
> out of your use case, and add it to "BOBYQAOptimizerTest"!
> But please, do read the issue page: the unit tests that we have now are
> supposed to reproduce the behaviour of the original Fortran code. I think
> that any additional test (and the more the better and ideally covering all
> the code) should become part of this baseline, intended to ensure that the
> incremental code changes do not alter the efficiency (i.e. the number of
> function evalutations).
> Thanks,
> Gilles
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message