[R] RE: [Rd] too many arguments in foreign function call

[John Chambers]

Prof Brian D Ripley wrote:
> 
> On Mon, 16 Jul 2001, Warnes, Gregory R wrote:
> 
> >
> >   Duncan Murdoch <murdoch@stats.uwo.ca> wrote:
> >   > Gregory R. Warnes <gregory_r_warnes@groton.pfizer.com> wrote
> >   > >
> >   > >I would like to create an R package that will depend on
> >   > the ability to use
> >   > >more than 65 parameters.  Would it be reasonable to expect
> >   > this patch (or
> >   > >something equivalent) to be part of , say R > 1.3.1 ?
> >   >
> >   > People are slow to upgrade, so you might be better off in the short
> >   > run to somehow reduce the number of parameters below 65.
> >   > For example,
> >   > write a wrapper function that groups a number of scalar parameters
> >   > into one vector.
> >
> > Actually, the whole point of the patch was to get out of this.  I want to
> > keep the code as close to what was written by the original author and as
> > simple as possible...
> 
> Sorry, but I don't see that.  You want to write the wrapper in R?  Why is
> it not as simple to write it in C?  I really don't see the need to remove
> the limitation in R (or even to have it as high as 65) since R now has
> .External() which allows an unlimited list of arguments to be passed to C
> code.  I can't believe that the natural R representation is 85 separate
> objects, so the natural way looks like a C wrapper translating between R
> objects and Fortran pointers.  You can even copy selectively.
> 
> The argument is that new code should probably be using .Call (if S
> compatibility is relevant) or .External rather than .C, at least provided
> that a C wrapper is feasible.  Those interfaces seem very much under-used.
> (Including by me, for S3-compatibility reasons.)
> 
> --
> Brian D. Ripley,                  ripley@stats.ox.ac.uk
> Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
> University of Oxford,             Tel:  +44 1865 272861 (self)
> 1 South Parks Road,                     +44 1865 272860 (secr)
> Oxford OX1 3TG, UK                Fax:  +44 1865 272595
> 
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
> r-help 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-help-request@stat.math.ethz.ch
> _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

The limitation to 65 arguments (or at any rate some fixed number) is
imposed by pretty fundamental limitations of C.  It applies to .External
and .Call as well as to .C, and any S language interface will have such
a limit unless it goes around the C calling mechanism (which in turn
would likely be devastating for portability).

It's understandable to want to create as little new C code as possible,
but since there has to be a limit, at some point we're saying "More than
N arguments to a subroutine are too confusing.  Simplify it before you
expose the interface to users."  65 seems a plausible value for N to me.

The example Greg describes with a bunch of scratch arrays is, in my
experience, usually best handled by a .Call to a C wrapper that uses C
macros from Appendix A of the green book to allocate the scratch space
(NEW_NUMERIC and NUMERIC_POINTER, for example).  That is usually only
marginally more work than writing the wrapper in R, is a good deal more
efficient, and hides the grosser ugliness from the end user better.

John

-- 
John M. Chambers                  jmc@bell-labs.com
Bell Labs, Lucent Technologies    office: (908)582-2681
700 Mountain Avenue, Room 2C-282  fax:    (908)582-3340
Murray Hill, NJ  07974            web: http://www.cs.bell-labs.com/~jmc
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._