[Rcpp-devel] vector<int>

[Romain François]

On 12/21/2009 02:59 PM, Dirk Eddelbuettel wrote:
>
> (resending on list, hasn't meant to drop the list --D. )

(me too)

> On 21 December 2009 at 10:15, Romain François wrote:
> | Attaching a patch to current Rcpp to allow playing with vector<int>  at
> | the R level.
> |
> | Here is a transcript to give a feel of what this does:
> |
> |>  require(Rcpp)
> | Loading required package: Rcpp
> | Loading required package: methods
> |
> |>  x<- new(CPP("vector<int>"))
> |
> |>  x$push_back(1)
> |
> |>  x$size()
> | [1] 1
> |
> |>  x$push_back(1:10)
> |
> |>  x$size()
> | [1] 11
> |
> |>  x$capacity()
> | [1] 16
> |
> |>  x$reserve(50)
> |
> |>  x$capacity()
> | [1] 50
> |
> |>  x$max_size()
> | [1] 1073741823
> |
> |>  x$as.vector()
> |   [1]  1  1  2  3  4  5  6  7  8  9 10
> |
> |
> | x if of S4 class "vector<int>" which extends the class "C++Object".
> | "C++Object" holds an external pointer to the C++ object that is wrapped.
> |
> | The "C++Object" defines the "$" method which looks at the "typeof" of
> | its arguments and cooks the name of the c symbol used.
> |
> | For example, when calling x$push_back(1:10), $.C++Object creates this C
> | symbol name: "vector_int____push_back___integer"
> |
> | Then it is a case of implementing these, for example :
> |
> | SEXP vector_int____push_back___integer(SEXP x, SEXP p1){
> | 		std::vector<int>  *p = (std::vector<int>*)EXTPTR_PTR(R_do_slot( x,
> | Rf_install("pointer") ) ) ;
> | 		for( int i=0; i<LENGTH(p1); i++){
> | 			p->push_back( INTEGER(p1)[i] ) ;
> | 		}
> | 		return(R_NilValue) ;
> | 	}
> |
> |
> | I've not commited because it is a relatively unstable idea, so I was
> | hoping to get comments before.
>
> Interesting -- certainly very nice to have all the core parts of vector<int>
> at the R level.  I have to think about how / where I would use that in my
> workflow.  I never think much about the C++ object "per se" -- they are just
> containers to call something, compute something, ...

Sure, you can then do things like this with the inline stuff:


#!/usr/bin/r

suppressMessages(library(Rcpp))

x <- new( CPP("vector<int>") )
x$push_back(sample(1:10))

foo <- '
     std::vector<int> *p = (std::vector<int> 
*)EXTPTR_PTR(R_do_slot(v,Rf_install("pointer"))) ;
     sort( p->begin(), p->end() ) ;
     return( R_NilValue ) ;
'

funx <- cfunction(signature(v="vector<int>"), foo, Rcpp=TRUE, includes = 
"#include <algorithm>")
funx(x)
x$as.vector()


The hairy bit is probably the first line of the code :

std::vector<int> *p = (std::vector<int> 
*)EXTPTR_PTR(R_do_slot(v,Rf_install("pointer"))) ;

but then we could tweak cfunction so that the generated code directly 
gets the vector<int> pointer instead.

> and the S4 mechanism
> neither hurts nor helps here.

You said you did not want S4 before, but then you opened pandora's box 
with the inline experiment, which needs methods.

> And Rcpp is a natural place to play with this.

cool. Is that a go ?


> I need to wrap up a release for RInside later today (ie write a short blog
> post) and maybe post once or twice to r-packages about Rcpp and RInside over
> the next few days.
>
> Dirk
>


-- 
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/HlX9 : new package : bibtex
|- http://tr.im/Gq7i : ohloh
`- http://tr.im/FtUu : new package : highlight