[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
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._