On Fri, Jul 10, 2015 at 12:50 PM, ProfJCNash <profjcn...@gmail.com> wrote: > I have a general question about appropriate design for a fairly > complicated package, as I am redesigning and rebuilding the optimx > package. It will get a new name as it appears that the calls will change > in order to accommodate new functionality. I plan to make it > fairly easy to add new optimization (function minimization) tools. > > The query is whether to use an environment to hold all the common > objects (functions, scaled functions, gradients, scaled gradients, > hessians, scaled hessians, parameters, scaled parameters, program > controls, algorithm tuning parameters, constraints, fixed parametes, > some function value history, etc.) The alternative is a set of very > long calls, especially when the function needing a quantity may be a > couple of layers below the routine that creates or sets the values. > > The negative side is that the functions are not portable outside the > package, so would not be exported. > > Before I dig into the heavy clay of code that this will need, I thought > I should ask if there are issues I might be missing, as the local > environment -- essentially "global" variables within the perimeter of > the package -- would make the code a lot cleaner, and may offer some > useful efficiencies in computation.
If you want to store the same set of things for many optimisers, you might want to consider using reference classes or R6. Hadley -- http://had.co.nz/ ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
