________________________________
De : Gilles <[email protected]>
À : [email protected]
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
