[Rcpp-devel] passing lists to c++

Dirk Eddelbuettel edd at debian.org
Fri Nov 13 16:05:35 CET 2009


Hi Ott,

On 13 November 2009 at 15:42, Ott Toomet wrote:
| Dear Dirk,
| 
| I currently just sent you the modified API.  I havent included any checks or anything and don't want to put too much effort on that until we agree on what to do and what not to do.
| 
| Actually, I have problems with accessing anonymous svn (because the firewall blocks most of the stuff).  Developer svn works (as ssh port is open).  But the tarball at r-forge is pretty up-to-date?
| 
| About getting SEXP-s from the list...  My arguments:
| 
| * It feels more complete to be able to handle all types of R objects (well, excluding more esoteric ones)

Yes, we want to get there.  Romain and I are thinking about extensions in the
context of RProtoBuf.  And there may well be needs for things like
environments, external pointers, ...

Matrices and vectors of int, double, strings, ... were the obvious start, and
we want to go further.  But it needs to be done right, and you will have to
earn some credibility first that "you're doing it right". That said, I have
neither time nor patience for a debate club.  So let's get back to patches.

| * It makes it easier to switch from R to C++ if the task is to boost the
|    speed while maintaining the API.  Unwrapping a list is possible but you
|    have to re-design the arguments.  This may be complicated if the list is
|    of complex structure.

One motivation is to keep the use of Rcpp easy and simple. The interface
matters. Complicating is not necessaily a win.

A test case could be helpful.

| * What about variable number of list components?  My problem is that one of the sublists of my list have varying number of components (being lists of 2 numeric vectors each).

Yes, we are currently more restrictive but I am not convinced that we need to
change.   Some local needs or changes also do not have to flow back to the
package -- I have use case where I fill a C++ vector < pair < string, string >
from a SEXP. That didn't fit the package, and I felt it wasn't of enough
general interest so I never included it.

| About extracting by position:
| 
| * If you have variable number of components, you would rather want to know the total number of them, and thereafter extract them by position than paste string to someting like "comp1", "comp2" etc.

I disagree. And so does the prior design of Rcpp which uses STL's find to
look up arguments. That allows for reordering etc.

| * It feels more R-sh to be able to index both by names and positions.

Agreed. But by-name is safer. And Chambers (2008) 'prime directive' still
holds. We want reliable software.

| So, what do you think?  My motivation is to use a stable API which fits my
| needs (not to depend on my own hacks).  Perhaps to introduce another
| extractor instead of RcppParams to deal with lists (RcppListVector)?  Or
| can this be done by the new internal SEXP structure? 

We can definitely experiment.  At the interface level it still is 

   RcppExport SEXP myFunction(SEXP a, SEXP p, SEXP c)  {

so the nested list don't have to go into RcppParams either.  

As I said, a concrete usage example and a patch may make this more concrete.

Thanks for taking the time to post all this. I truly appreciate the interst
in Rcpp, but as I have been working with it since 2005 I don't feel we need
to rush changes in.

Dirk

-- 
Three out of two people have difficulties with fractions.


More information about the Rcpp-devel mailing list