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