QuantLib › quantlib-dev

Optimizer Discussion

Classic

List

Threaded

7 messages Options

Dimathematician

Optimizer Discussion

1: CostFunction::values()

As far as I see, the values function is not needed anywhere, except in the Levenberg Marquardt
optimizer. Can we change it from a pure virtual function to a virtual which by default returns
a one dimensional array with values(x)? It is confusing and takes a while to understand why
-and if- it is needed at all. For example, if I understand the code correctly, if you optimize with Simplex,
you can set values to any value (e.g.1000). In my opinion it is an overkill to make it pure virtual just in case
somebody uses LM. I'd rather suggest to test in LM whether the function has been overwritten.

2. EndCriteria:

Most of the functions do not use all of the passed values. I haven't found one which uses the gradient
norm. Please correct me if I'm wrong. Most of them use max iterations anf function value epsilon.
I think it might be better to make this clean such that the user doesn't have a wrong impression, that
actually everything is checked. I haven't found one optimizer which checks min stationary value.

For example, in Simplex: endCriteria.checkStationaryPoint(0.0, 0.0,
maxStationaryStateIterations_, ecType);

does that, but maxStationaryStateIterations_ is not increased anywhere during the optimization.

All points above subject to non-blindness of author of this mail :)

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Luigi Ballabio

Re: Optimizer Discussion

On Sat, 2009-09-05 at 13:07 +0200, Dima wrote:
> 1: CostFunction::values()
>
> As far as I see, the values function is not needed anywhere, except in
> the Levenberg Marquardt optimizer. Can we change it from a pure
> virtual function to a virtual which by default returns a one
> dimensional array with values(x)?

Possibly, but I'd rather change it to a function which by default throws
an exception. Also because it wouldn't be easy for LM to check that
it's been overridden.

> 2. EndCriteria:
>
> Most of the functions do not use all of the passed values. [...]
> I think it might be better to make this clean such that the user
> doesn't have a wrong impression, that actually everything is checked.

Yes, we should document that. Have you looked at the solvers already?
Do you have a list of what's checked in what solver?

Later,
Luigi

--

Hanlon's Razor:
Never attribute to malice that which is adequately explained
by stupidity.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Dimathematician

Re: Optimizer Discussion

Why exception? It has its use when LM is used. Or do you

want to make it virtual and throw an exception if its not

overwritten?

Had a look at the optimizers. Just a few End-Criterias

are really checked.

2009/9/11 Luigi Ballabio <[hidden email]>

On Sat, 2009-09-05 at 13:07 +0200, Dima wrote:
> 1: CostFunction::values()
>
> As far as I see, the values function is not needed anywhere, except in
> the Levenberg Marquardt optimizer. Can we change it from a pure
> virtual function to a virtual which by default returns a one
> dimensional array with values(x)?

Possibly, but I'd rather change it to a function which by default throws
an exception. Also because it wouldn't be easy for LM to check that
it's been overridden.

> 2. EndCriteria:
>
> Most of the functions do not use all of the passed values. [...]

> I think it might be better to make this clean such that the user
> doesn't have a wrong impression, that actually everything is checked.

Yes, we should document that. Have you looked at the solvers already?
Do you have a list of what's checked in what solver?

Later,
Luigi

--

Hanlon's Razor:
Never attribute to malice that which is adequately explained
by stupidity.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Luigi Ballabio

Re: Optimizer Discussion

On Sep 11, 2009, at 8:13 PM, Dima wrote:

> Why exception? It has its use when LM is used. Or do you
> want to make it virtual and throw an exception if its not
> overwritten?

The latter.

Luigi

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Dimathematician

Re: Optimizer Discussion

I'm not sure. I'm not happy with the whole setup, I think it is to tightly

coupled. I'd prefer a design which is similar to the root solvers: you

don't need a class for an optimizer whith a "value" function. As in the

root solver, it should be a template that has an operator(...), e.g. a functor

or a boost function. Anything. Makes it much more convenient to use.

The optimizing criteria could go into the constructor, which takes only the

criteria which it really uses. The start value could go into a optimize function,

which takes a template. If we have a multidimensional setup as in the LM

case, the template should return a std::vector<Real>

2009/9/11 Luigi Ballabio <[hidden email]>

On Sep 11, 2009, at 8:13 PM, Dima wrote:

Why exception? It has its use when LM is used. Or do you
want to make it virtual and throw an exception if its not
overwritten?

The latter.

Luigi

Luigi Ballabio

Re: Optimizer Discussion

Dima,
looks ok. Would you be willing to code the new design? We could add it
in a future release.

Luigi

On Sun, 2009-09-13 at 13:10 +0200, Dima wrote:

> I'm not sure. I'm not happy with the whole setup, I think it is to
> tightly
> coupled. I'd prefer a design which is similar to the root solvers: you
> don't need a class for an optimizer whith a "value" function. As in
> the
> root solver, it should be a template that has an operator(...), e.g. a
> functor
> or a boost function. Anything. Makes it much more convenient to use.
> The optimizing criteria could go into the constructor, which takes
> only the
> criteria which it really uses. The start value could go into a
> optimize function,
> which takes a template. If we have a multidimensional setup as in the
> LM
> case, the template should return a std::vector<Real>

--

fix, n.,v.
What one does when a problem has been reported too many times
to be ignored.
-- the Jargon file

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Dimathematician

Re: Optimizer Discussion

I'll try to code an alternative for one of the existing optimizers. This will take
a while though since I've realized that they are tightly coupled with other classes
such as Problem/EndCriteria, which makes it difficult to recode....I'll try to set up
something simple and will post an example as soon as I have it.

2009/9/24 Luigi Ballabio <[hidden email]>

Dima,
looks ok. Would you be willing to code the new design? We could add it
in a future release.

Luigi

On Sun, 2009-09-13 at 13:10 +0200, Dima wrote:
> I'm not sure. I'm not happy with the whole setup, I think it is to
> tightly
> coupled. I'd prefer a design which is similar to the root solvers: you
> don't need a class for an optimizer whith a "value" function. As in
> the
> root solver, it should be a template that has an operator(...), e.g. a
> functor
> or a boost function. Anything. Makes it much more convenient to use.
> The optimizing criteria could go into the constructor, which takes
> only the
> criteria which it really uses. The start value could go into a
> optimize function,
> which takes a template. If we have a multidimensional setup as in the
> LM
> case, the template should return a std::vector<Real>

--

fix, n.,v.
What one does when a problem has been reported too many times
to be ignored.
-- the Jargon file

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev