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
Raw File
Tip revision: a077792524646c82540a7cc29ed32fedd6117948 authored by Dirk Eddelbuettel and Romain Francois on 16 October 2010, 07:11:16 UTC
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    
back to top