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

[Warnes, Gregory R]

  From: Prof Brian D Ripley [mailto:ripley@stats.ox.ac.uk]
  > 
  > 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?  

It is, in fact *not* as simple to write it in C.  Now the user must go from
2 languages (R and FORTRAN) to 3.  

  > 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, 

No the actual R representation isn't anywhere near 85 separate objects.  The
actual R representation is more like 10 objects.  The point is that existing
FORTRAN code---which is used for R, S-Plus, and for a stand alone
program---makes use of some 60 objects which need to be dynamically sized,
hence the other 25 parameters specifying object sizes.  Indeed many of these
objects are merely 'scratch space' for the code to work in.  Still, its
easier for the user to allocate these in R (and have R manage the memory)
than to write the equivalent code in C. 

  > 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, do you really expect everyone to get in the habit of writing C code
to translate R SEXP into appropriate C or Fortran objects?   For the large
number of cases where the objects to be passed to and from C/Fortran are
simple scalars and vectors it really makes sense to keep the code to do the
translation in a standard library routine like do_dotcode().  This keeps the
bugs down to a minimum and makes it as easy as possible for people to
interface code.

All I suggested doing was removing the arbitrary restriction to <= 65
parameters.  I even provided the code.  What's the problem?

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


LEGAL NOTICE
Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._