commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From François Laferrière <francoislaferrie...@yahoo.fr>
Subject Re: math : optim package documentation
Date Fri, 31 May 2013 08:39:41 GMT




________________________________
 De : Gilles <gilles@harfang.homelinux.org>
À : user@commons.apache.org 
Envoyé le : Mardi 21 mai 2013 0h09
Objet : Re: math : optim package documentation
 

> [...snip ..]
>
> However, before you start writing code that rely on this API,
> be sure to read that recent thread:
>  http://markmail.org/thread/3fjvucyz7rax4cyi
> What is your opinion on the proposed change?
>
>
> Regards,
> Gilles

I carefully read this thread.

First thing first, I thing it is way better than 3.2 API. Getting rid of the variable param
list it is a great improvement in term of design AND usability. With this old API it was not
possible when using an IDE (like Eclipse) to explore the API through autocompletion. Further,
the convenience class OptimisationData is not very good. This makes necessary to shoehorn
unrelated features in the same class hierarchy, ant thus make heavy use of "instanceof" (which
is generally considered as a symptom of wrong class design)

About immutability

I see the advantages of immutability, but I am not convinced that it should be made mandatory.
In my project, I need to call the same optimizer zillions on times by just changing some parameters
of the objective function and the initial guess. Creating a new instance each time shall,
in this case, put a too heavy load on the memory management (allocation and garbage collection
of zillions of instance of the optimizer).  

Maybe, it is not necessary to choose? maybe it is possible have API with setXXX() (for computer
intensive app) and withXXX() (immutability)? Doing so, the user have the choice.

In this double pattern, setXXX() can also "fluent" so that we can write

  MyOptimizer opt = new MyOptimiser().setXXX().setYYY() ;

A "debuggable" interface?

Always "scratching my own itch", in my project, I do need to compare the performance of different
algorithm. So I need to keep track not only of initial guess, final results and number of
iteration, but also of intermediate results. For instance, it would be gread to have an option
to keep track of the trajectory, for instance as an array of values that can be retrieved
at the end. Something like


class MyOptimizer implement DebuggableOptim ...

MyOptimizer optim = new MyOptimiser().withDebuggable(true) ;
PointValuePair resultPair = optim.optimize(...) ;
PointValuePair [] trajectory = optim.getTrajectory() ;

Development agenda

Is there a date at which I can expect a prototype optim package from the trunk?

My current work

As I wrote before, I am developping implementation of different gradient based optim methods
not available yet with 3.2. 

To do so I also implemented a general purpose 


abstract public class NumericallyDerivableMultivariateFunction implements MultivariateFunction
{
 ...

This class impement the gradient and hessian matrix based on finite differences

If it can be of any use

yours truly

François Laferriere
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message