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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
