Hi, 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 http://www.cs.umd.edu/users/oleary/a607/ 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. Thanks, Konstantin --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
