https://github.com/cran/Rcpp
Revision a077792524646c82540a7cc29ed32fedd6117948 authored by Dirk Eddelbuettel and Romain Francois on 16 October 2010, 07:11:16 UTC, committed by cran-robot on 16 October 2010, 07:11:16 UTC
1 parent fe044c3
Tip revision: a077792524646c82540a7cc29ed32fedd6117948 authored by Dirk Eddelbuettel and Romain Francois on 16 October 2010, 07:11:16 UTC
version 0.8.7
version 0.8.7
Tip revision: a077792
TODO
Documentation
o Bring "Rcpp ? NumericVector" into life. The hook is in place, we just need
to come up with some way to generate useful documentation for it: general
description of the class, related unit test cases, etc ...
o Add a vignette about Rcpp sugar [in progress]
o Finish the quickref vignette
o Maybe a vignette about stats functions
o Add a vignette about the API
API
o Rcpp::Factor and Rcpp::Ordered
o const operators, as requested on Rcpp-devel:
http://permalink.gmane.org/gmane.comp.lang.r.rcpp/494
Modules
o Exposing constructors. For now we can only construct internal objects
with the default constructor of the target class. Maybe we can provide
some R level dispatch. Maybe look at ?selectMethod
o Class inheritance. If we have Foo and Bar : public Foo, and we expose
both Foo and Bar to R, R level class Bar should enjoy methods of Foo
and the S4 inheritance should reflect the C++ level inheritance
o Method overloading: methods are currently stored in a map<string,.>
so there can only be one method for a given name, which defeats C++
overloading. Maybe we can do better than that. This might also need
R level dispatch (?selectMethod)
Syntactic sugar
o recycling : binary operators and math functions of 2 or more arguments
need to recycle their arguments.
o not sure rep should be lazy, i.e. rep( x, 4 ) fetches x[i] 4 times,
maybe we should use LazyVector like in outer to somehow cache the
result when it is judged expensive to calculate
o The current impl of "diff" might cause problems (e.g. with ifelse) due to
laziness, it is probably best to not make it lazy
o crossprod
o SUGAR_MATH: is there overhead in having the function pointer, should
the macro generate code that statically calls the function ? It would
probably be harder to write/debug
o Vector * Matrix, Matrix * Matrix
o duplicated, unique, count, sum
o operator%
o operator/ needs to handle the case of division by 0
o min, max with specialization of the binary operators, so that we can do
things like this lazily:
min( x ) < 4
o matrix functions : apply
o for character vectors: nchar, grepl, sub, gsub
o Compound operators: ++,--,+=, -=, ...
o other statistical distribution functions :
multinom : this only has dmultinom which is handled in R, so maybe we can
skip it
signrank : has the weird call to .C( "signrank_free" ), need to understand that
wilcox : has the weird call to .C( "wilcox_free" ), need to understand that
tukey : only has p and q, no r or d
o sum : deal with missing values
o other random generators:
rmultinom : tricky because it generates a matrix
rnbeta : the R version is implemented in R (not in C),
should we still have it in Rcpp in compile code ?
rnf : idem
rnt : idem
Testing
o all r* functions : rnorm, etc ...
o many dpq functions have not been tested yet
o new autogenerated sugar functions: cos, acosh, atan, cos, cosh, log,
log10, sqrt, sin, sinh, tan, tanh
Computing file changes ...