You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by en...@pnc.com on 2012/12/31 22:23:34 UTC
[Math] BOBYQAOptimizer handle exception
I use BOBYQAOptimizer to do optimization for Black Scholes formula.
maxEval is set to 200000, but I still got TooManyEvaluationsException.
When it throws exception, I get nothing from the optimizer. CurrentBest is
good enough, but it is private and there is no interface to get it.
Generally, how do I handle exception with optimizer? I'd like to use
currentBest in case of TooManyEvaluationsException.
The contents of this email are the property of PNC. If it was not addressed to you, you have no legal right to read it. If you think you received it in error, please notify the sender. Do not forward or copy without permission of the sender. This message may contain an advertisement of a product or service and thus may constitute a commercial electronic mail message under US Law. The postal address for PNC is 249 Fifth Avenue, Pittsburgh, PA 15222. If you do not wish to receive any additional advertising or promotional messages from PNC at this e-mail address, click here to unsubscribe. https://pnc.p.delivery.net/m/u/pnc/uni/p.asp
By unsubscribing to this message, you will be unsubscribed from all advertising or promotional messages from PNC. Removing your e-mail address from this mailing list will not affect your subscription to alerts, e-newsletters or account servicing e-mails.
Re: [Math] BOBYQAOptimizer handle exception
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hi.
On Mon, Dec 31, 2012 at 04:23:34PM -0500, enzhong.fu@pnc.com wrote:
> I use BOBYQAOptimizer to do optimization for Black Scholes formula.
> maxEval is set to 200000, but I still got TooManyEvaluationsException.
> When it throws exception, I get nothing from the optimizer. CurrentBest is
> good enough, but it is private and there is no interface to get it.
> Generally, how do I handle exception with optimizer? I'd like to use
> currentBest in case of TooManyEvaluationsException.
[This question was raised on the "dev" ML a short time ago. Please search
the ML archive and the bug tracking system.]
In summary, "BOBYQAOptimizer" is in "alpha" state, as mentioned in the
release notes of the two latest releases of Commons Math (3.0 and 3.1).
If the "currentBest" is indeed good enough, then it must mean that the
stopping criterion (i.e. your input to the constructor) is too stringent.
Or that there is a bug in the implementation (which is quite possible given
what I wrote above). If you think that the latter is the case, please
provide a working minimal example that displays the unexpected behaviour.
Best regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org
Re: [Math] Remove "BOBYQAOptimizer"
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hi.
> >"BOBYQAOptimizer" is a horrible Java code (e.g. it contains lots of
> >"simili-goto" statements).[2]
> >In a library, the source codes should share coding standards. Consequently,
> >if a code is not following the standard, it should not be part of the
> >library. We simply should not have included it.
> >It is not, and cannot be, maintained; it is just there. You could as well
> >copy/paste it to your personal toolbox.
>
> Although I understand your concern about the (un)maintainability of
> "BOBYQAOptimizer" as a CM contributor/maintainer, I fully share Patrick's
> point of view as a user! Unless CM is a toy for the own pleasure of its
> contributors, it should not make the life of its users miserable every time
> some CM officionados have yet another great idea about how to 'improve'
> the design/implementation of an algorithm already in place, especially if
> the adopted design results essentially from a philosophical orientation.
Actually the issue is: When providing a library, the maintainers implicitly
commit to be able to... maintain it. It follows logically that
unmaintainable code should not be forced on benevolent contributors.
Indeed, as a user, I don't care if the "BOBYQAOptimizer" class is
unmaintainable; as a developer, I don't want to justify in lengthy emails,
every now and then, that users should not use it if they encounter problems
(be they wrong usage or a bug, because we cannot sort it out anyways).
> Following the discussions on the dev ML, I see that some components which
> were to be deprecated are now restored, ... Such a rather unstable API
> is really bad from a user point of view.
Given the low number of contributors, CM is gathering new functionalities at
an impressive rate. Given the low number of contributors, that makes a lot
of code to maintain per regular contributor. If the design is not improved
where it can be, the project will slowly but surely turn to cruft.
Unfortunately not many people seem to be aware or care about this risk.
> As Patrick wrote, we do not want
> to waste hours or days catching up with the deprecations (especially as we
> have to figure out the refactoring ourselves).
But contributors can waste their time trying to understand an obscure code
when someone raises an issue about it?
> We do want to use CM as a
> reliable library but if something works, do not touch it!
When contributors make changes, it is hopefully to improve in one way or
another.
> That is for instance the case with the weights in the least squares methods.
> Those vectorial weights have been very useful in the present API, do not
> touch them. That API does not prevent a tiny subset of users to cope with
> correlated observations while it helps a lot of users coping with simple
> weights. For the latter, there is even a good reason not to premultiply
> the observations and model functions: the 'residuals' would be multiplied
> as well otherwise.
The weight feature is an example where it seems that the design can be
improved towards greater clarity (simplified core algorithm) and efficiency
(no multiplications by 1 in cases where the weights are not used).
But if the consensus (just a few posts ago that weights have no part in the
least-squares minimization algorithms) is reverted, that's fine with me; and
I'll remove that task from the issue tracking system...
But, if so, why should we remove the new feature that would allow to handle
correlated observations, as well as uncorrelated ones (as a sub-case of the
former)?
Best regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Remove "BOBYQAOptimizer"
Posted by Dimitri Pourbaix <po...@astro.ulb.ac.be>.
Hi Gilles,
> "BOBYQAOptimizer" is a horrible Java code (e.g. it contains lots of
> "simili-goto" statements).[2]
> In a library, the source codes should share coding standards. Consequently,
> if a code is not following the standard, it should not be part of the
> library. We simply should not have included it.
> It is not, and cannot be, maintained; it is just there. You could as well
> copy/paste it to your personal toolbox.
Although I understand your concern about the (un)maintainability of
"BOBYQAOptimizer" as a CM contributor/maintainer, I fully share Patrick's
point of view as a user! Unless CM is a toy for the own pleasure of its
contributors, it should not make the life of its users miserable every time
some CM officionados have yet another great idea about how to 'improve'
the design/implementation of an algorithm already in place, especially if
the adopted design results essentially from a philosophical orientation.
Following the discussions on the dev ML, I see that some components which
were to be deprecated are now restored, ... Such a rather unstable API
is really bad from a user point of view. As Patrick wrote, we do not want
to waste hours or days catching up with the deprecations (especially as we
have to figure out the refactoring ourselves). We do want to use CM as a
reliable library but if something works, do not touch it!
That is for instance the case with the weights in the least squares methods.
Those vectorial weights have been very useful in the present API, do not
touch them. That API does not prevent a tiny subset of users to cope with
correlated observations while it helps a lot of users coping with simple
weights. For the latter, there is even a good reason not to premultiply
the observations and model functions: the 'residuals' would be multiplied
as well otherwise.
Best wishes for 2013.
Dim.
----------------------------------------------------------------------------
Dimitri Pourbaix * Don't worry, be happy
Institut d'Astronomie et d'Astrophysique * and CARPE DIEM.
CP 226, office 2.N4.211, building NO *
Universite Libre de Bruxelles * Tel : +32-2-650.35.71
Boulevard du Triomphe * Fax : +32-2-650.42.26
B-1050 Bruxelles * NAC: HBZSC RG2Z6
http://sb9.astro.ulb.ac.be/~pourbaix * mailto:pourbaix@astro.ulb.ac.be
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Remove "BOBYQAOptimizer"
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Tue, Jan 01, 2013 at 12:49:33PM -0500, Patrick Meyer wrote:
> Please do not remove BOBYQAOptimizer from CM. It works quite well for me. I
> have a function that takes two parameters. BOBYQAOptimizer finds the right
> solution. In 3.0 NonlinearConjugateGradientOptimizer (without the multiple
> starts) would never find the right solution. Now that I have switched to
> 3.1, NonlinearConjugategradientOptimizer (with multiple starts) simply
> doesn't work.
>
> I have to express my frustration with all of the changes to the optimization
> procedures. The amount of refactoring since 2.2 has been extensive. First,
> the refactoring to 3.0 and now to 3.1. It looks like there may be even more
> refactoring in 4.0. It is getting very difficult to use the optimization
> part of the library because everything is dissected into so many parts.
> BOBYQAOptimizer may have been ported from FORTRAN and it may not fit an
> object oriented framework, but those older libraries were much easier to
> use.
>
> Some of you may need the flexibility of the flexibility of tailoring every
> aspect of the optimization algorithm. Others such as myself just need
> something that works as simply as the "optim" function in R. I can do in one
> line of R code what takes numerous lines of Java code (that has to be
> recoded with every release of CM). It's frustrating.
That just means that CM is not mature. "It works for me" is not a proof that
the design is sound. People have expressed that the current design is not
good, and point at different things. The previous designs were not better,
for several reasons (which I'm not going to repeat again...).
Some implementations are obscure, and this is in contradiction with the goal
of CM being a repository of maintainable code. Maintainable means that
developers can read and understand the code with a reasonable amount of
work.
I spent numerous hours to clean up the initial port (a direct translation of
a Fortran to C converter IIRC) that became the "BOBYQAOptimizer" class.[1]
The result was included in 3.0 on the promise that the code would not stay
in that state. [And that I made it clear that I could not go on being the
only one working on it.]
Now people start to file issues. Be they supposed bugs or misundertandings,
we cannot help because the code is not sufficiently documented. [Actually, I
suspect that it would be less work to reimplement the algorithm from scratch
(based on the paper by Powell) than trying to understand the current
version...]
"BOBYQAOptimizer" is a horrible Java code (e.g. it contains lots of
"simili-goto" statements).[2]
In a library, the source codes should share coding standards. Consequently,
if a code is not following the standard, it should not be part of the
library. We simply should not have included it.
It is not, and cannot be, maintained; it is just there. You could as well
copy/paste it to your personal toolbox.
Regards,
Gilles
[1] Which implies that I'm probably more sorry than you about the current
situation.
[2] See also
https://analysis.apache.org/dashboard/index/122571?did=2
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [Math] Remove "BOBYQAOptimizer"
Posted by Patrick Meyer <me...@gmail.com>.
Please do not remove BOBYQAOptimizer from CM. It works quite well for me. I
have a function that takes two parameters. BOBYQAOptimizer finds the right
solution. In 3.0 NonlinearConjugateGradientOptimizer (without the multiple
starts) would never find the right solution. Now that I have switched to
3.1, NonlinearConjugategradientOptimizer (with multiple starts) simply
doesn't work.
I have to express my frustration with all of the changes to the optimization
procedures. The amount of refactoring since 2.2 has been extensive. First,
the refactoring to 3.0 and now to 3.1. It looks like there may be even more
refactoring in 4.0. It is getting very difficult to use the optimization
part of the library because everything is dissected into so many parts.
BOBYQAOptimizer may have been ported from FORTRAN and it may not fit an
object oriented framework, but those older libraries were much easier to
use.
Some of you may need the flexibility of the flexibility of tailoring every
aspect of the optimization algorithm. Others such as myself just need
something that works as simply as the "optim" function in R. I can do in one
line of R code what takes numerous lines of Java code (that has to be
recoded with every release of CM). It's frustrating.
Patrick
-----Original Message-----
From: Gilles Sadowski [mailto:gilles@harfang.homelinux.org]
Sent: Monday, December 31, 2012 8:29 PM
To: dev@commons.apache.org
Subject: [Math] Remove "BOBYQAOptimizer"
Hello.
Cross-posting this message from the the "user" ML:
On Mon, Dec 31, 2012 at 04:23:34PM -0500, enzhong.fu@pnc.com wrote:
> I use BOBYQAOptimizer to do optimization for Black Scholes formula.
> maxEval is set to 200000, but I still got TooManyEvaluationsException.
> When it throws exception, I get nothing from the optimizer.
> CurrentBest is good enough, but it is private and there is no interface to
get it.
> Generally, how do I handle exception with optimizer? I'd like to use
> currentBest in case of TooManyEvaluationsException.
IMO, it was a bad idea to include "BOBYQAOptimizer" into CM. [For that
matter, any code recognizably ported from other languages (namely FORTRAN
and C) without thorough adapatation to Java has been the source of
problems.]
If nobody is able to work on "BOBYQAOptimizer" so as to make it a
maintainable and documented code, I request that it be removed from the next
major release (4.0).
Regards,
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
Re: [Math] Remove "BOBYQAOptimizer"
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hi Dietmar.
Good to hear from you![1] :-)
> >If nobody is able to work on "BOBYQAOptimizer" so as to make it a
> >maintainable and documented code, I request that it be removed from the next
> >major release (4.0).
>
> No objections from my side. BOBYQA was again heavily used at
> https://issfd.jpl.nasa.gov/home/GTOC6 (10th place this time), but
>
> for performance reasons I used a C++ variant wrapped via JNI called from Java
> code implementing the CMA optimizer interface. This seems the better solution
> (keep the optimizer implementation outside CMA/Java and use only the interface)|
> as long as we have no real Java implementation.
This is also an important point: the current code in "BOBYQAOptimizer" is in
an intermediate step of the transformation phase; if the evaluation of the
objective function is fast, the computation time will be dominated by the
optimizer's internal working because matrix operations are done with explicit
loops, using the "getEntry" to access each element! Improving efficiency will
be (relatively) easy once CM has specialized matrix implementations (e.g.
symmetric matrix). The not so easy part is that in some places, the code's
behaviour is extremely fragile: changing the ordering of normally
commutative operations make some unit tests fail (hence that may also happen
when the explicit looping is replaced by a method that not necessarily does
the operations in the exact same way). The problem may lie in the unit
tests, we simply don't know...
Regards,
Gilles
[1] Reminder: Dietmar brought the initial Java port of "BOBYQA".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] Remove "BOBYQAOptimizer"
Posted by Dietmar Wolz <dr...@yahoo.de>.
>If nobody is able to work on "BOBYQAOptimizer" so as to make it a
>maintainable and documented code, I request that it be removed from the next
>major release (4.0).
No objections from my side. BOBYQA was again heavily used at
https://issfd.jpl.nasa.gov/home/GTOC6 (10th place this time), but
for performance reasons I used a C++ variant wrapped via JNI called from Java
code implementing the CMA optimizer interface. This seems the better solution
(keep the optimizer implementation outside CMA/Java and use only the interface)|
as long as we have no real Java implementation.
[Math] Remove "BOBYQAOptimizer"
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hello.
Cross-posting this message from the the "user" ML:
On Mon, Dec 31, 2012 at 04:23:34PM -0500, enzhong.fu@pnc.com wrote:
> I use BOBYQAOptimizer to do optimization for Black Scholes formula.
> maxEval is set to 200000, but I still got TooManyEvaluationsException.
> When it throws exception, I get nothing from the optimizer. CurrentBest is
> good enough, but it is private and there is no interface to get it.
> Generally, how do I handle exception with optimizer? I'd like to use
> currentBest in case of TooManyEvaluationsException.
IMO, it was a bad idea to include "BOBYQAOptimizer" into CM. [For that
matter, any code recognizably ported from other languages (namely FORTRAN
and C) without thorough adapatation to Java has been the source of
problems.]
If nobody is able to work on "BOBYQAOptimizer" so as to make it a
maintainable and documented code, I request that it be removed from the next
major release (4.0).
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org