Suggestion for an extension of the API
Prof Brian D Ripley wrote:
On Fri, 26 Jan 2001, Adrian Trapletti wrote:
Dear R Developers (I think in particular Brian) Especially for larger optimization problems, it would be nice to have an entry point for C/C++ code to the R optimizers (the ones which are called when using optim()), where the client just has to provide the functions fminfn() and fmingr() and calls directly, e.g., vmmin() (all from $RHOME/src/main/optim.c). Are there any plans for providing such an entry point?
No, but there can be. There are at least some problems with error-handling that need to be thought about. Is what you want essentially to make vmmin (...) a public entry point, avoiding having to deal with OptStruct's? If that suffices, it would be easy.
No, my intention was to have a standard entry point from C/C++ to all of these
functions and, hence, give the package developers more flexibility. E.g., in
tseries I currently use for the garch() some fortran optimizer which directly
calls C functions for calculating the gradient and likelihood. arma from
tseries uses the optim function from R and uses the call back mechanism to
calculate the SSE. In these case, I would like to have the same solution for
both the arma and garch classes, ideally using the optimizers from R, but for
performance reasons without the indirection of back-calling R to calculate the
likelihood etc. (I know, I could use optif9, but it would be nicer if all
available optimizers could be used that way.)
For example, having something like
void
vmmin(int n0, double *b, double *Fmin, int maxit, int trace, int *mask,
double abstol, double reltol, int nREPORT, OptStruct OS,
int *fncount, int *grcount, int *fail,
int (*fminfn)(int, double *, OptStruct),
void (*fmingr)(int, double *, double *, OptStruct))
and so on
in R_ext/Applic.h (as for optif9) would probably be enough. Or as Doug (Thanks
Doug! see below) explained me, additionally introducing a pointer to a state
variable which brings information into the likelihood or gradient evaluation,
like in optif9.
Douglas Bates wrote:
...
optif9(ntheta, ntheta, theta, (fcn_p) mixed_fcn, (fcn_p)
mixed_grad, (d2fcn_p) 0, st, typsiz, 1.0 /*fscale*/,
1 /*method*/,1 /*iexp*/, &msg, -1 /*ndigit*/, 50 /*itnlim*/,
iagflg, 0 /*iahflg*/, -1. /*dlt*/, pow(epsm, 1.0/3.0)
/*gradtl*/, 0. /*stepmx*/, sqrt(epsm) /*steptl*/, newtheta,
logLik, grad, &itrmcd, a, work, &itncnt);
This is not the most transparent code but one point to note is that
you can pass a pointer to a structure like "state" to the call to
optif9 and it will be passed unmodified when calling the function or
gradient evaluation. Often it is very difficult to get information
into the function and gradient evaluations and one has to resort to
global identifiers, which is risky. Being able to pass that pointer
through is very convenient. (We modified the code to do that.) For
C++ you could pass through a pointer to an instance of a class then
invoke a class method through that pointer.
best Adrian -- Dr. Adrian Trapletti, Olsen & Associates Ltd. Seefeldstrasse 233, CH-8008 Zürich, Switzerland Phone: +41 (1) 386 48 47 Fax: +41 (1) 422 22 82 E-mail: adrian@olsen.ch WWW: http://www.olsen.ch -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._