I appreciate the comment. I would like to help, but currently my schedule is full. Maybe towards the end of the year.
I think the first approach should be do no harm. The optimization package keeps getting refactored every few months without much thinking involved. We had the discuss previously, with Gilles unilaterally deciding on the current tree, which he now wants to change again. As someone who uses optimization regular I would say the current API state (not just package naming) leaves a lot to be desired, and is not amenable to the various modification that people might need for larger problems. So if you are going to modify it, you should at least open up the API to the possibility that different optimization steps can be done using various techniques, depending on the problem. We should also accept that not everything can fit neatly into a package tree and a single set of APIs. A good example is least squares. Linear least squares does not require an initial guess at a solution, and by performing decomposition ahead of time you can quickly recompute the solution given different input values. However, an iterative least squares method might not have these properties. There are probably countless of other examples. Because optimization problems are really computationally hard all the little specific differences matter, that is why Gilles approach of sweeping everything under the rug and into some rigid not thought out hierarchical API forces these methods to adapt (or drop) numerical aspects that should not be there (e.x. polynomial fits). This has *huge* performance implications, but the issue is treated as some OO design 101 class, with the focus on how to force everything into a simple inheritance structure, numerics be damned. I would gladly help with the feedback when I can. Ajo and I provided code for adaptive integration, yet the whole issue was completely ignored. So I am not sure how much effort is required for the developers to take an idea or mostly completed code and make a change, rather than reject even the most basic numerical approaches that are taught in introduction classes as something that needs to be benchmarked. Here are some helpful webpages on optimization http://plato.asu.edu/sub/pns.html http://www.neos-guide.org/optimization-tree On Jul 18, 2013, at 10:33 AM, Phil Steitz <phil.ste...@gmail.com> wrote: > On 7/18/13 7:12 AM, Patrick Meyer wrote: >>> You have done a pretty good job in making the optimization package >> non-sensical to user. >> >> +1 > > We have definitely struggled with the design of the optimization > package. It would be great if we could get to a stable API for 4.0 > onwards. If you guys are willing to help get to a structure that > makes sense from a user's perspective, we are all ears. If you > have time to help make or at least fully think through the changes > necessary to get there, that would be most appreciated. > > I am not an optimization expert. I do know, however, that what we > are dealing with in this package is well-understood theoretically. > We should listen carefully to those who have the knowledge and > background to help. And those providing the "help" should be > patient and provide references (online, wherever possible) that we > can use to get to a common understanding of the mathematical > principles and terminology involved. > > We all want the same thing here - a high-quality library that is > both maintainable and easy to use. We are all volunteers with > limited time and of course limited knowledge. Lets work together on > this. > > Phil >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
