[Rd] Suggestion for an extension of the API

Adrian Trapletti adrian@olsen.ch
Mon, 29 Jan 2001 10:03:08 +0100

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

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.


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