Hello. > > My opinion is that the package should be organized by what it does rather, > than how it does it.
My proposal is based on what the user wants to do and on what input is required in order to use the tools in the given package, where all algorithms will share the same interface. > My thinking is > > optim > optim.scalar. > optim.scalar.linear > optim.scalar.socp (second order cone programming)' > optim.scalar.qcqp > optim.scalar.nonlinear > optim.scalar.nonlinear.derivfree > optim.scalar.nonlinear.derivfree.Powell, etc > optim.scalar.nonlinear.newton > > optim.scalar.univariate.* > > optim.leastsquares.linear > optim.leastsquares.nonlinear IMHO, the problem with the above is that it is targetted to optimization experts (who would know what all the abbreviations mean and what to look for). In the other approach, a non-expert can go to a package, read the top-level doc and start experimenting, knowing what to plug in. [I know, this is not a strong argument; but it lowers the barrier to entry. :-)] Perhaps there are intersections between the two approaches. > But I am flexible. Perhaps it is worth a look here: > http://www.joptimizer.com/ Thanks for the pointer. Gilles > > > > > Shall we also introduce entirely new packages? > > > > optim > > > > optim.scalar.noderiv > > optim.scalar.noderiv.PowellOptimizer > > optim.scalar.noderiv.SimplexOptimizer > > optim.scalar.noderiv.CMAESOptimizer > > optim.scalar.noderiv.BOBYQAOptimizer > > > > optim.scalar.gradient > > optim.scalar.gradient.NonLinearConjugateGradientOptimizer > > > > optim.vector > > optim.vector.jacobian > > optim.vector.jacobian.AbstractLeastSquaresOptimizer > > optim.vector.jacobian.LevenbergMarquardtOptimizer > > optim.vector.jacobian.GaussNewtonOptimizer > > > > optim.scalar.univariate.noderiv > > optim.scalar.univariate.noderiv.BrentOptimizer > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
