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

[Prof Brian D Ripley]

On Mon, 16 Jul 2001, Warnes, Gregory R wrote:

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

But the user is you, who knows C.  One can write the wrapper in Fortran
too, as ppr.f exemplifies.

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

Really?  Using R_alloc in C seems exactly equivalent to me.

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

No, but I am suggesting that most package writers should.

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

In most cases it is one or two vectors.  Beyond that, the lack of
type-checking causes a large number of bugs, so I do think using .Call is
the way to keep `bugs down to a minimum'.

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

1) Your code had as I understand it a different arbitrary restriction.

2) We don't know what the OS-specific limits are.  Certainly in the days of
S-PLUS for Windows 3.3 there were quite low limits on the total size of the
arguments in use.  These days I don't even know how to find out such
information.

3) We always have to weigh the support issues of changing the code to
support a rare case.  (I do believe it is rare: this is the first
instance I have seen in ca 14 years of listening to S and R programmers.)

Brian

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