commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Berlin <>
Subject Re: [Math] Old to new API ("MultivariateDifferentiable(Vector)Function")
Date Tue, 04 Dec 2012 10:47:09 GMT

I think this is getting silly. What I am saying is not a matter of opinions but of textbook
optimizations. This is not a matter of use cases, but of something that is already well established.
I feel like this package is trying to reinvent the wheel, in a subject that is already well
known, and very settled.

I am not going to present myself as some expert in optimizations, however I am familiar with
different optimization methods, why they exists, how they work and relate to each other, and
how constraints (be they equality and inequality, bounds, linear constraints, and nonlinear
constrains) are added to optimization. Knowing what I know, I can't help but to feel it is
important to have this perspective before trying to properly engineer an optimization package,
even if you do not have most of these features implemented yet.

If you are curious about how to add constraints to optimization methods or optimizations in
general, you can read some slides here

I have issues with the suggestions that I am presented with, since IMHO they are missing the
big picture. I feel like least-squares methods are presented here as though as they are an
extension of optimization into multiple dimensions. That is incorrect, and even if you know
that, you are misleading the user. Least-squares is a limited case of a general optimization
problem. This expression will get you an F in a math class:
ValueAndGradient[] computeValueAndJacobian(double[] parameters);

The vector value and the matrix Jacobian should be separated, not combined together. They
are not mathematically defined like this, nor are they used like this in optimizations, and
would require extraction inside the optimization method. This expression prevents the use
of sparse matrices, if that would be desired in the future.

> Chi2 values are only used (and subsequently made accessible to the caller)
> in the "AbstractLeastSquaresOptimizer" hierarchy.
> In the current design, it would not make any sense to just change the return
> value type and force every algorithm to fill in data they don't use.
> Discussion is open but should be based on actual cases, or on patches that
> demonstrate how the change is applied to all the implementations which are
> supposed to be affected.

This is a perfect example of why inherence was created.

You guys are free to proceed how you want. I am trying to save you guys the trouble of having
to redesign your optimization package in the near future.

I will be happy to comment on proposals, but I no longer have the time to argue about fundamentals
of optimizations. I do not mean to sound like this, but I am really out of personal time.
I hope you take a "users" view point seriously.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message