Re: [Rcpp-devel] setdiff
I've commited an initial version of setdiff.
Cool - thanks! It might be useful in general to expose some of the
STL sorted range commands - I'm not sure if that's general enough for
base Rcpp or not.
There is room for improvement given the R version:
setdiff
function (x, y)
{
x - as.vector(x)
y - as.vector(y)
unique(if (length(x) || length(y))
x[match(x, y, 0L) == 0L]
else x)
}
'initial' because it does not yet deal with missing values correctly.
Is the behavior of R's setdiff what we would want to reproduce:
setdiff( c(1), c(NA,1) )
numeric(0)
# that looks odd
setdiff( c(1), c(NA,2) )
[1] 1
# this too
setdiff( c(1,NA), c(1,2) )
[1] NA
# not sure what we should expect
setdiff( c(NA_integer_), c(NA_integer_) )
integer(0)
That seems reasonable to me. What are you thinking?
Hadley
--
RStudio / Rice University
http://had.co.nz/
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Missing values
On Fri, Nov 16, 2012 at 2:25 AM, Romain Francois rom...@r-enthusiasts.com wrote: Thanks for exploring these issue. This looks very useful. I get: str( first_log(NA) ) logi TRUE str( first_int(NA_integer_) ) int NA str( first_num(NA_real_) ) num NA str( first_char(NA_character_) ) chr NA For first_log: a bool can either be true or false. In R logical vectors are represented as arrays of ints. When we coerce to bool, we test whether the value is not 0. This works for most cases. I guess conversion to bool should be avoided. There's obviously no perfect solution, and that seems to be consistent with C++'s treatment of NAs in logical expression: evalCpp(NAN || FALSE) == TRUE We have the is_na template function that can help: evalCpp( 'traits::is_naLGLSXP( NA_LOGICAL )' ) [1] TRUE evalCpp( 'traits::is_naREALSXP( NA_REAL )' ) [1] TRUE And from this I can see we don't have is_naSTRSXP, will fix this. str( evalCpp( 'traits::get_naREALSXP()' ) ) num NA str( evalCpp( 'traits::get_naINTSXP()' ) ) int NA I guess we could come up with a nicer syntax for these, maybe static functions in Vector so that we could do : IntegerVector::is_na( ) NumericVector::get_na( ) Yes, that would be very nice. str( evalCpp( 'std::numeric_limitsint::min()' ) ) int NA This is how NA_integer_ is represented. Thanks - the danger is that you might do something like: evalCpp( 'traits::get_naINTSXP() + 1' ) I'll make a note. As said above, I'll add ...Vector::is_na ...Vector::get_na to have something more consistent and not as cryptic as traits::is_na...( ). People should not need to know what REALSXP, INTSXP, LGLSXP, ... mean. Great, thanks! Hadley -- RStudio / Rice University http://had.co.nz/ ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Missing values
Le 16/11/12 14:00, Hadley Wickham a écrit : On Fri, Nov 16, 2012 at 2:25 AM, Romain Francois rom...@r-enthusiasts.com wrote: Thanks for exploring these issue. This looks very useful. I get: str( first_log(NA) ) logi TRUE str( first_int(NA_integer_) ) int NA str( first_num(NA_real_) ) num NA str( first_char(NA_character_) ) chr NA For first_log: a bool can either be true or false. In R logical vectors are represented as arrays of ints. When we coerce to bool, we test whether the value is not 0. This works for most cases. I guess conversion to bool should be avoided. There's obviously no perfect solution, and that seems to be consistent with C++'s treatment of NAs in logical expression: evalCpp(NAN || FALSE) == TRUE We have the is_na template function that can help: evalCpp( 'traits::is_naLGLSXP( NA_LOGICAL )' ) [1] TRUE evalCpp( 'traits::is_naREALSXP( NA_REAL )' ) [1] TRUE And from this I can see we don't have is_naSTRSXP, will fix this. str( evalCpp( 'traits::get_naREALSXP()' ) ) num NA str( evalCpp( 'traits::get_naINTSXP()' ) ) int NA I guess we could come up with a nicer syntax for these, maybe static functions in Vector so that we could do : IntegerVector::is_na( ) NumericVector::get_na( ) Yes, that would be very nice. Done. str( evalCpp( 'std::numeric_limitsint::min()' ) ) int NA This is how NA_integer_ is represented. Thanks - the danger is that you might do something like: evalCpp( 'traits::get_naINTSXP() + 1' ) I'll make a note. Yes. NA are particularly annoying in integer vector. As said above, I'll add ...Vector::is_na ...Vector::get_na to have something more consistent and not as cryptic as traits::is_na...( ). People should not need to know what REALSXP, INTSXP, LGLSXP, ... mean. Great, thanks! Hadley -- Romain Francois Professional R Enthusiast +33(0) 6 28 91 30 30 R Graph Gallery: http://gallery.r-enthusiasts.com `- http://bit.ly/SweN1Z : SuperStorm Sandy blog:http://romainfrancois.blog.free.fr |- http://bit.ly/RE6sYH : OOP with Rcpp modules `- http://bit.ly/Thw7IK : Rcpp modules more flexible ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
[Rcpp-devel] Debugging Rcpp code
Hi all,
I'm attempting to write a simple version of tapply in C++ (see
attached). However, when I run tapply2(1, 1, sum) (which should
return 1), R segfaults. If I run R with gdb, I get the following
stack trace:
#0 0x03942120 in tapply2 (x=@0xbfffda68, i=@0xbfffda58,
fun=@0xbfffda50) at tapply.cpp:22
#1 0x0394298a in Rcpp::CppFunction_WithFormals3Rcpp::Vector14,
Rcpp::Vector14, Rcpp::Vector13, Rcpp::Function::operator()
(this=0x7f71c0, args=0xbfffdabc) at Module_generated_CppFunction.h:311
#2 0x0385b8b1 in InternalFunction_invoke ()
...
where line 22 is return out;
I suspect it's something to do with the my coercion between
std::vector and NumericVector to call the function, or between the
SEXP output and NumericVector to store the output:
std::vector std::vectordouble ::iterator g_it = groups.begin();
NumericVector::iterator o_it = out.begin();
for(; g_it != groups.end(); ++g_it, ++o_it) {
*o_it = asdouble(fun(wrap(*g_it)));
}
I'd appreciate any hints as to how to solve this particular problem,
as well as any general debugging strategies.
Thanks!
Hadley
--
RStudio / Rice University
http://had.co.nz/
#include Rcpp.h
using namespace Rcpp;
// [[Rcpp::export]]
NumericVector tapply2(NumericVector x, IntegerVector i, Function fun) {
std::vector std::vectordouble groups;
NumericVector::iterator x_it;
IntegerVector::iterator i_it;
for(x_it = x.begin(), i_it = i.begin(); x_it != x.end(); ++x_it, ++i_it) {
groups[*i_it].push_back(*x_it);
}
NumericVector out(groups.size());
std::vector std::vectordouble ::iterator g_it = groups.begin();
NumericVector::iterator o_it = out.begin();
for(; g_it != groups.end(); ++g_it, ++o_it) {
*o_it = asdouble(fun(wrap(*g_it)));
}
return out;
}___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Debugging Rcpp code
Ooops, I completely misinterpreted the std::vector API. To insert the
elements I need to do:
for(x_it = x.begin(), i_it = i.begin(); x_it != x.end(); ++x_it, ++i_it) {
int i = *i_it;
if (i groups.size()) {
groups.resize(i);
}
groups[i - 1].push_back(*x_it);
}
Hadley
On Fri, Nov 16, 2012 at 8:36 AM, Hadley Wickham h.wick...@gmail.com wrote:
Hi all,
I'm attempting to write a simple version of tapply in C++ (see
attached). However, when I run tapply2(1, 1, sum) (which should
return 1), R segfaults. If I run R with gdb, I get the following
stack trace:
#0 0x03942120 in tapply2 (x=@0xbfffda68, i=@0xbfffda58,
fun=@0xbfffda50) at tapply.cpp:22
#1 0x0394298a in Rcpp::CppFunction_WithFormals3Rcpp::Vector14,
Rcpp::Vector14, Rcpp::Vector13, Rcpp::Function::operator()
(this=0x7f71c0, args=0xbfffdabc) at Module_generated_CppFunction.h:311
#2 0x0385b8b1 in InternalFunction_invoke ()
...
where line 22 is return out;
I suspect it's something to do with the my coercion between
std::vector and NumericVector to call the function, or between the
SEXP output and NumericVector to store the output:
std::vector std::vectordouble ::iterator g_it = groups.begin();
NumericVector::iterator o_it = out.begin();
for(; g_it != groups.end(); ++g_it, ++o_it) {
*o_it = asdouble(fun(wrap(*g_it)));
}
I'd appreciate any hints as to how to solve this particular problem,
as well as any general debugging strategies.
Thanks!
Hadley
--
RStudio / Rice University
http://had.co.nz/
--
RStudio / Rice University
http://had.co.nz/
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] setdiff
On 16 November 2012 at 06:54, Hadley Wickham wrote: | Cool - thanks! It might be useful in general to expose some of the | STL sorted range commands - I'm not sure if that's general enough for | base Rcpp or not. Even having really good documentation on all the STL goodness would be good. There is an entire chapter in (free, pdf and other formats) book 'C++ Annotations' which Doug and I often recommend; and I scooped up a free-to-me paper copy of Austern's book recently -- but am still looking for something to go with Rcpp documentation. Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] setdiff
| Cool - thanks! It might be useful in general to expose some of the | STL sorted range commands - I'm not sure if that's general enough for | base Rcpp or not. Even having really good documentation on all the STL goodness would be good. There is an entire chapter in (free, pdf and other formats) book 'C++ Annotations' which Doug and I often recommend; and I scooped up a free-to-me paper copy of Austern's book recently -- but am still looking for something to go with Rcpp documentation. I've been using (e.g.) http://www.cplusplus.com/reference/stl/map/ a lot - it has plenty of examples, which is really helpful for getting started. Hadley -- RStudio / Rice University http://had.co.nz/ ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Debugging Rcpp code
That's the one;
You might like to di something like:
std::vector std::vectordouble groups( max(i) ) ;
you'll pay for the traversal of the max, but then you don't need to resize.
Calling fun() is going to be costly too (probably what will dominate).
specially because of our internal::try_catch thing. See in
Evaluator.cpp. that's a mess.
We should have something for faster evaluations, so that we would make
the call and just use Rf_eval.
It will become more fun when we apply c++ functions. ^^
Romain
Le 16/11/12 16:03, Hadley Wickham a écrit :
Ooops, I completely misinterpreted the std::vector API. To insert the
elements I need to do:
for(x_it = x.begin(), i_it = i.begin(); x_it != x.end(); ++x_it, ++i_it) {
int i = *i_it;
if (i groups.size()) {
groups.resize(i);
}
groups[i - 1].push_back(*x_it);
}
Hadley
On Fri, Nov 16, 2012 at 8:36 AM, Hadley Wickham h.wick...@gmail.com wrote:
Hi all,
I'm attempting to write a simple version of tapply in C++ (see
attached). However, when I run tapply2(1, 1, sum) (which should
return 1), R segfaults. If I run R with gdb, I get the following
stack trace:
#0 0x03942120 in tapply2 (x=@0xbfffda68, i=@0xbfffda58,
fun=@0xbfffda50) at tapply.cpp:22
#1 0x0394298a in Rcpp::CppFunction_WithFormals3Rcpp::Vector14,
Rcpp::Vector14, Rcpp::Vector13, Rcpp::Function::operator()
(this=0x7f71c0, args=0xbfffdabc) at Module_generated_CppFunction.h:311
#2 0x0385b8b1 in InternalFunction_invoke ()
...
where line 22 is return out;
I suspect it's something to do with the my coercion between
std::vector and NumericVector to call the function, or between the
SEXP output and NumericVector to store the output:
std::vector std::vectordouble ::iterator g_it = groups.begin();
NumericVector::iterator o_it = out.begin();
for(; g_it != groups.end(); ++g_it, ++o_it) {
*o_it = asdouble(fun(wrap(*g_it)));
}
I'd appreciate any hints as to how to solve this particular problem,
as well as any general debugging strategies.
Thanks!
Hadley
--
RStudio / Rice University
http://had.co.nz/
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
R Graph Gallery: http://gallery.r-enthusiasts.com
`- http://bit.ly/SweN1Z : SuperStorm Sandy
blog:http://romainfrancois.blog.free.fr
|- http://bit.ly/RE6sYH : OOP with Rcpp modules
`- http://bit.ly/Thw7IK : Rcpp modules more flexible
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] setdiff
On 16 November 2012 at 09:22, Hadley Wickham wrote: | | Cool - thanks! It might be useful in general to expose some of the | | STL sorted range commands - I'm not sure if that's general enough for | | base Rcpp or not. | | Even having really good documentation on all the STL goodness would be good. | There is an entire chapter in (free, pdf and other formats) book 'C++ | Annotations' which Doug and I often recommend; and I scooped up a free-to-me | paper copy of Austern's book recently -- but am still looking for something | to go with Rcpp documentation. | | I've been using (e.g.) http://www.cplusplus.com/reference/stl/map/ a | lot - it has plenty of examples, which is really helpful for getting | started. It seems that site has a bit of an uncool reputation among the cognoscenti on SO. I usually go back to http://www.sgi.com/tech/stl/ which is what has been there since the dawn of time. Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Debugging Rcpp code
You might like to di something like:
std::vector std::vectordouble groups( max(i) ) ;
you'll pay for the traversal of the max, but then you don't need to resize.
I ended up going with:
NumericVector tapply3(NumericVector x, IntegerVector i, Function fun) {
std::mapint, std::vectordouble groups;
NumericVector::iterator x_it;
IntegerVector::iterator i_it;
for(x_it = x.begin(), i_it = i.begin(); x_it != x.end(); ++x_it, ++i_it) {
groups[*i_it].push_back(*x_it);
}
NumericVector out(groups.size());
std::mapint, std::vectordouble ::const_iterator g_it = groups.begin();
NumericVector::iterator o_it = out.begin();
for(; g_it != groups.end(); ++g_it, ++o_it) {
NumericVector res = fun(g_it-second);
*o_it = res[0];
}
return out;
}
which I think is much easier to understand. It's slightly slower when
i is small and dense, but orders of magnitude faster when i is sparse.
Calling fun() is going to be costly too (probably what will dominate).
specially because of our internal::try_catch thing. See in Evaluator.cpp.
that's a mess.
We should have something for faster evaluations, so that we would make the
call and just use Rf_eval.
That'll be nice - but here I'm more interested in showing off how to
use the STL, not in highly performant code (although this special case
is ~4x than tapply), so it's not a big deal.
It will become more fun when we apply c++ functions. ^^
Definitely!
Hadley
--
RStudio / Rice University
http://had.co.nz/
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] setdiff
Le 16/11/12 16:52, Dirk Eddelbuettel a écrit : On 16 November 2012 at 09:36, Hadley Wickham wrote: | | I've been using (e.g.) http://www.cplusplus.com/reference/stl/map/ a | | lot - it has plenty of examples, which is really helpful for getting | | started. | | It seems that site has a bit of an uncool reputation among the cognoscenti on SO. | | So you're saying it's good? ;) No I wasn't referring to the SO trolls. They do recommend the site :) | | I usually go back to http://www.sgi.com/tech/stl/ which is what has been | there since the dawn of time. | | I had steered away from that because I was a bit worried about | non-standard SGI extensions to the STL. I fear you have that upside down: what was long known as HP STL, then SGI STL _became_ the standard STL, in fact now called C++ Std Library or something. So this /is/ actually the reference implementation AFAIK. Not the greatest site though. And hey, if the cplusplus.com reference is good enough for Romain who am I to argue. I surely know hos to find my ways there. The site gives information about complexity of operations, etc... I like it. Although at first I also learned many tricks from Meyers' Effective STL. Romain -- Romain Francois Professional R Enthusiast +33(0) 6 28 91 30 30 R Graph Gallery: http://gallery.r-enthusiasts.com `- http://bit.ly/SweN1Z : SuperStorm Sandy blog:http://romainfrancois.blog.free.fr |- http://bit.ly/RE6sYH : OOP with Rcpp modules `- http://bit.ly/Thw7IK : Rcpp modules more flexible ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
[Rcpp-devel] inline plug-in linking
Hi All, I'm attempting to get inline up and running for my package, but am having some trouble. My plug in statement is: inlineErnmPlugin - Rcpp:::Rcpp.plugin.maker( include.before = #include ernm.h, libs = , package= ernm ) This works for some things. for example: library(ernm) library(inline) registerPlugin(ernm,inlineErnmPlugin) src - Rcpp::IntegerMatrix tmp(0,2); ernm::BinaryNeternm::Directed net(tmp,Rcpp::asint(n)); return net; emptyNetwork - cxxfunction(signature(n=integer), src, plugin=ernm) net - emptyNetwork(10) net[1:10,1:10] but for others it doesn't work. In particular, I keep a list of available model statistics in a static class StatController, which I want my user to be able to add to. When I try to interact with this list (well, map technically), I get linking errors. I found a work around where the user could bring an XPtr to the stat up to R, and then pass it down to add to the list with an exposed Module function. This worked fine until the user quit R, at which point a memory not mapped seg fault occurred. Anyhow, I think I am probably missing some linking info from my inlinePlugIn statement. I tried to hard code the library (perhaps naively), but got image not found errors. ip - Rcpp:::Rcpp.plugin.maker( include.before = #include ernm.h, libs = /Library/Frameworks/R.framework/Resources/library/ernm/libs/i386/ernm.so, package= ernm ) A reproducible example is located at http://fellstat.com/files/ernmInlineTests.R for use with http://fellstat.com/files/ernm_1.0.tar.gz . The only code in the package that the examples interact with is StatController.h and StatController.cpp. Any guidance would be greatly appreciated. Best, Ian ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] inline plug-in linking
Anyhow, I think I am probably missing some linking info from my
inlinePlugIn statement.
This is the key -- plugins that do linking are much more complicated than
ones that rely on headers only. You can look at the Rcpp and RcppGSL
packages as examples -- in short there needs to be a function inside the
package that can cough up the correct library locations. If you get this
far then your stuff will work with inline and Rcpp::cppFunction, however
people developing packages that want to link against your stuff will need
custom Makevars entries (which you can configure the inline plugin to
produce, but by now things have gotten pretty complicated for your users).
If you can manage to do header-only linking that will be much, much
simpler. At the lowest level the key to this is R_GetCCallable. In Rcpp
land there is a GetCppCallable equivalent that works with modules. You can
see the use of this in the header file which is generated by
Rcpp::interfaces(r, cpp).
If you want to expose the data structure using this mechanism then you
could write a function like this:
// [[Rcpp::export]]
Rcpp::List getModelStatistics() {
return StatController::getModelStatistics();
}
And then compileAttributes will automatically generate the shim that calls
GetCppCallable.
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Rcpp version of R's match function
Ouch. Simon wins: expr minlqmedianuq max 1 fmatch(xx, letters) 59.4727 60.29989 74.18049 77.94288 112.2938 2 match__(xx, letters) 137.3878 137.77486 138.33766 152.14018 193.3748 3 match_(xx, letters) 147.7115 148.36442 149.20221 162.82343 171.3181 4 match(xx, letters) 288.4345 293.10380 294.58833 296.26125 333.1210 But only because he builds up the hash table once - the others have to do it every time. Hadley -- RStudio / Rice University http://had.co.nz/ ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] inline plug-in linking
On 16 November 2012 at 08:50, JJ Allaire wrote:
| Anyhow, I think I am probably missing some linking info from my
| inlinePlugIn statement.
|
|
| This is the key -- plugins that do linking are much more complicated than ones
| that rely on headers only. You can look at the Rcpp and RcppGSL packages as
| examples
+1 --- at this point I can only offer RcppGSL as (working!!) example. I
have a blog post planned to illustrate Rcpp attribute with it. We have no
other example using a library.
| -- in short there needs to be a function inside the package that can
| cough up the correct library locations. If you get this far then your stuff
Exactly. Romain coughed up a very clever (as usual) but not-obvious-follow
(no comment ;-) scheme where the plugins essentially act as callback. For
RcppGSL we have the added fun of needed to know where libgsl.* and
libgslcblas.* live -- which I solve with a detection at package load (when we
call the external gsl-config script) and storing the data in a package-global
little environment.
That works. On windows, as always, you need more magic and I rely on the
sort-of plugic knowledge of where CRAN keeps its support libraries so that
packages can build against it.
If you supply your library with the package, then the callbacks are
self-contained within the package. A bit of work but a) doable and b) a good
chance of being reliable.
| will work with inline and Rcpp::cppFunction, however people developing
packages
| that want to link against your stuff will need custom Makevars entries (which
| you can configure the inline plugin to produce, but by now things have gotten
| pretty complicated for your users).
|
| If you can manage to do header-only linking that will be much, much simpler.
| At the lowest level the key to this is R_GetCCallable. In Rcpp land there is a
| GetCppCallable equivalent that works with modules. You can see the use of this
| in the header file which is generated by Rcpp::interfaces(r, cpp).
|
| If you want to expose the data structure using this mechanism then you could
| write a function like this:
|
| // [[Rcpp::export]]
| Rcpp::List getModelStatistics() {
| return StatController::getModelStatistics();
| }
|
| And then compileAttributes will automatically generate the shim that calls
| GetCppCallable.
That is a fresh alternative. And all this is work in progress, and your
feedback in testing and pushing it would also be appreciated.
So in short you can make it work, but you have to put in some work before it
all falls into place.
Dirk
--
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] inline plug-in linking
Wow, that was terrible. Once again, now proofread and edited.
On 16 November 2012 at 08:50, JJ Allaire wrote:
| Anyhow, I think I am probably missing some linking info from my
| inlinePlugIn statement.
|
|
| This is the key -- plugins that do linking are much more complicated than ones
| that rely on headers only. You can look at the Rcpp and RcppGSL packages as
| examples
+1 --- at this point I can only offer RcppGSL as a (working!!) example. I
have a blog post planned to illustrate using the new Rcpp attributes with
it. We have no other example using a library.
| -- in short there needs to be a function inside the package that can
| cough up the correct library locations. If you get this far then your stuff
Exactly. Romain coughed up a very clever (as usual) that is
not-obvious-to-follow
(no comment ;-) scheme where the plugins essentially act as callbacks. For
RcppGSL we have the added fun of needing to know where libgsl.* and
libgslcblas.* live -- which I solve with a detection at package load-time (when
we
call the external gsl-config script) and storing the data in a package-global
little environment.
That works. On windows, as always, you need more magic and I rely on the
sort-of public knowledge of where CRAN keeps its support libraries so that
packages can build against these. A generic Windows solution against
third-party libraries is impossible.
If you supply your library with the package, then the callbacks are
self-contained within the package. A bit of work but a) doable and b) a good
chance of being reliable.
| will work with inline and Rcpp::cppFunction, however people developing
packages
| that want to link against your stuff will need custom Makevars entries (which
| you can configure the inline plugin to produce, but by now things have gotten
| pretty complicated for your users).
|
| If you can manage to do header-only linking that will be much, much simpler.
| At the lowest level the key to this is R_GetCCallable. In Rcpp land there is a
| GetCppCallable equivalent that works with modules. You can see the use of this
| in the header file which is generated by Rcpp::interfaces(r, cpp).
|
| If you want to expose the data structure using this mechanism then you could
| write a function like this:
|
| // [[Rcpp::export]]
| Rcpp::List getModelStatistics() {
| return StatController::getModelStatistics();
| }
|
| And then compileAttributes will automatically generate the shim that calls
| GetCppCallable.
That is a fresh alternative. And all this is work in progress, and your
feedback in testing and pushing it would also be appreciated -- for either
solution.
So in short you can make it work, but you have to put in some extra blood,
sweat and tears before it all falls into place.
Dirk
--
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
[Rcpp-devel] const not allowed for Matrix arguments?
More on const arguments:
the first will compile and work, the second will not compile, even if we
do not modify anything. As far as I can tell, in this case the culprit is
related to having the reference to the Column, because f3 does compile and
work.
I guess the problem is the *this, returned by Column; is there another
way of making sure the caller does not modify the matrix, while enjoying
the usage of Column (and Row)?
Best,
R.
// [[Rcpp::export]]
int f1(Rcpp::IntegerMatrix m1) {
const Rcpp::IntegerMatrix::Column c1 = m1(_, 1);
int dd = c1[0] * 2;
return dd;
}
// [[Rcpp::export]]
int f2(const Rcpp::IntegerMatrix m1) {
const Rcpp::IntegerMatrix::Column c1 = m1(_, 1);
int dd = c1[0] * 2;
return dd;
}
// [[Rcpp::export]]
int f3(const Rcpp::IntegerMatrix m1) {
int dd = m1(0, 0) * 2;
return dd;
}
--
Ramon Diaz-Uriarte
Department of Biochemistry, Lab B-25
Facultad de Medicina
Universidad Autónoma de Madrid
Arzobispo Morcillo, 4
28029 Madrid
Spain
Phone: +34-91-497-2412
Email: rdia...@gmail.com
ramon.d...@iib.uam.es
http://ligarto.org/rdiaz
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] const not allowed for Matrix arguments?
I've tried to be better about const-ness in revision 3986. Please keep
investigating.
Thanks.
Romain
Le 16/11/12 19:53, Ramon Diaz-Uriarte a écrit :
More on const arguments:
the first will compile and work, the second will not compile, even if we
do not modify anything. As far as I can tell, in this case the culprit is
related to having the reference to the Column, because f3 does compile and
work.
I guess the problem is the *this, returned by Column; is there another
way of making sure the caller does not modify the matrix, while enjoying
the usage of Column (and Row)?
Best,
R.
// [[Rcpp::export]]
int f1(Rcpp::IntegerMatrix m1) {
const Rcpp::IntegerMatrix::Column c1 = m1(_, 1);
int dd = c1[0] * 2;
return dd;
}
// [[Rcpp::export]]
int f2(const Rcpp::IntegerMatrix m1) {
const Rcpp::IntegerMatrix::Column c1 = m1(_, 1);
int dd = c1[0] * 2;
return dd;
}
// [[Rcpp::export]]
int f3(const Rcpp::IntegerMatrix m1) {
int dd = m1(0, 0) * 2;
return dd;
}
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
R Graph Gallery: http://gallery.r-enthusiasts.com
`- http://bit.ly/SweN1Z : SuperStorm Sandy
blog:http://romainfrancois.blog.free.fr
|- http://bit.ly/RE6sYH : OOP with Rcpp modules
`- http://bit.ly/Thw7IK : Rcpp modules more flexible
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Rcpp version of R's match function
Le 16/11/12 18:03, Hadley Wickham a écrit :
Ouch. Simon wins:
expr minlqmedianuq max
1 fmatch(xx, letters) 59.4727 60.29989 74.18049 77.94288 112.2938
2 match__(xx, letters) 137.3878 137.77486 138.33766 152.14018 193.3748
3 match_(xx, letters) 147.7115 148.36442 149.20221 162.82343 171.3181
4 match(xx, letters) 288.4345 293.10380 294.58833 296.26125 333.1210
But only because he builds up the hash table once - the others have to
do it every time.
Hadley
I don't think that's it. here, we have to create a table for 26 entries.
this takes no time at all:
sourceCpp( code = '
#include Rcpp.h
using namespace Rcpp ;
// [[Rcpp::export]]
void match_create_hash( const CharacterVector x, const CharacterVector
table){
typedef std::tr1::unordered_mapSEXP,int MAP ;
typedef MAP::value_type VALUE ;
// populate the hash
MAP hash ;
int n = table.size() ;
SEXP* ptr = get_string_ptr(table) ;
for( int i=0 ; in; i++){
hash.insert( std::make_pairSEXP,int(ptr[i], i + 1) ) ;
}
}
' )
xx - sample( letters, 1000, replace = TRUE )
system.time( match_create_hash( xx, letters ) )
utilisateur système écoulé
0.000 0.000 0.001
Also, in this example, there is no difference between the first and
second time fmatch is used:
system.time( fmatch( xx, letters ) )
utilisateur système écoulé
0.060 0.000 0.061
system.time( fmatch( xx, letters ) )
utilisateur système écoulé
0.059 0.000 0.060
system.time( fmatch( xx, letters ) )
utilisateur système écoulé
0.060 0.000 0.059
...
This is about looking up in the hash table. We need to do it 10 million
times in this example, so I guess his hashing function performs better.
...
Not giving up
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
R Graph Gallery: http://gallery.r-enthusiasts.com
`- http://bit.ly/SweN1Z : SuperStorm Sandy
blog:http://romainfrancois.blog.free.fr
|- http://bit.ly/RE6sYH : OOP with Rcpp modules
`- http://bit.ly/Thw7IK : Rcpp modules more flexible
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Fwd: latest incompatible changes for package developers?
First time I see this email. Sorry your package does not work. R CMD check --no-vignettes worked. (this is how I tested), but indeed something in the vignette makes it crash. I guess I should check the vignettes too :/ I get an error in demo(dimer_linear) regarding something that does not look like it is related to Rcpp, in this mdply call : comparison - mdply(params, onedimer, .progress=none) Not sure what the next steps are ... Romain Le 16/11/12 22:56, baptiste auguie a écrit : Hi, Forwarded to you directly just in case it never makes it to the list for whatever reason (shouldn't I get an error message if it it is bounced?) Best, baptiste -- Forwarded message -- From: *baptiste auguie* baptiste.aug...@gmail.com mailto:baptiste.aug...@gmail.com Date: 17 November 2012 09:29 Subject: Fwd: latest incompatible changes for package developers? To: rcpp-devel rcpp-de...@r-forge.wu-wien.ac.at mailto:rcpp-de...@r-forge.wu-wien.ac.at Not sure what happened to this email I sent yesterday; I can't find it in the list archives? Thanks, b. -- Forwarded message -- From: *baptiste auguie* baptiste.aug...@gmail.com mailto:baptiste.aug...@gmail.com Date: 16 November 2012 09:18 Subject: latest incompatible changes for package developers? To: rcpp-devel rcpp-devel@lists.r-forge.r-project.org mailto:rcpp-devel@lists.r-forge.r-project.org Dear list, I haven't yet had time to read much about the new exciting changes introduced in Rcpp 0.10, but I got an email from B. Ripley this morning warning me that my cda package* was broken as a result of this CRAN update. It uses modules and RcppArmadillo. Indeed, a quick glance at the broken demos after having updated the package suggest that most if not all my functions are currently broken. Is there a specific document I should read first to speed up this recovery and be compatible with the new version? How much change should I expect? Thanks. All the best, baptiste * https://github.com/baptiste/cda http://cran.r-project.org/web/packages/cda/index.html -- Romain Francois Professional R Enthusiast +33(0) 6 28 91 30 30 R Graph Gallery: http://gallery.r-enthusiasts.com `- http://bit.ly/SweN1Z : SuperStorm Sandy blog:http://romainfrancois.blog.free.fr |- http://bit.ly/RE6sYH : OOP with Rcpp modules `- http://bit.ly/Thw7IK : Rcpp modules more flexible ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Fwd: latest incompatible changes for package developers?
Hi Romain, Dirk, all, Thanks for the quick replies. I think the list problem was due to a change in my gmail address (from googlemail); still puzzling that I didn't get a warning. Hopefully someone can figure out why a function that returned an arma matrix has now become a vector: I've posted a minimal package on dropbox, https://dl.dropbox.com/u/352834/cda_1.2.1.tar.gz with a test in inst/testing that used to return a 3x3 matrix (Euler rotation), now a vector after the Rcpp update. The lesson for me is that I should really get into a proper testing framework. In the meantime, I'll be writing a few tests with Hadley's testthat. All the best, baptiste On 17 November 2012 11:20, Romain Francois rom...@r-enthusiasts.com wrote: First time I see this email. Sorry your package does not work. R CMD check --no-vignettes worked. (this is how I tested), but indeed something in the vignette makes it crash. I guess I should check the vignettes too :/ I get an error in demo(dimer_linear) regarding something that does not look like it is related to Rcpp, in this mdply call : comparison - mdply(params, onedimer, .progress=none) Not sure what the next steps are ... Romain Le 16/11/12 22:56, baptiste auguie a écrit : Hi, Forwarded to you directly just in case it never makes it to the list for whatever reason (shouldn't I get an error message if it it is bounced?) Best, baptiste -- Forwarded message -- From: *baptiste auguie* baptiste.aug...@gmail.com mailto:baptiste.auguie@gmail.**com baptiste.aug...@gmail.com Date: 17 November 2012 09:29 Subject: Fwd: latest incompatible changes for package developers? To: rcpp-devel rcpp-de...@r-forge.wu-wien.**ac.atrcpp-de...@r-forge.wu-wien.ac.at mailto:rcpp-de...@r-forge.wu-**wien.ac.atrcpp-de...@r-forge.wu-wien.ac.at Not sure what happened to this email I sent yesterday; I can't find it in the list archives? Thanks, b. -- Forwarded message -- From: *baptiste auguie* baptiste.aug...@gmail.com mailto:baptiste.auguie@gmail.**com baptiste.aug...@gmail.com Date: 16 November 2012 09:18 Subject: latest incompatible changes for package developers? To: rcpp-devel rcpp-devel@lists.r-forge.r-**project.orgrcpp-devel@lists.r-forge.r-project.org mailto:rcpp-devel@lists.r-**forge.r-project.orgrcpp-devel@lists.r-forge.r-project.org Dear list, I haven't yet had time to read much about the new exciting changes introduced in Rcpp 0.10, but I got an email from B. Ripley this morning warning me that my cda package* was broken as a result of this CRAN update. It uses modules and RcppArmadillo. Indeed, a quick glance at the broken demos after having updated the package suggest that most if not all my functions are currently broken. Is there a specific document I should read first to speed up this recovery and be compatible with the new version? How much change should I expect? Thanks. All the best, baptiste * https://github.com/baptiste/**cda https://github.com/baptiste/cda http://cran.r-project.org/web/**packages/cda/index.htmlhttp://cran.r-project.org/web/packages/cda/index.html -- Romain Francois Professional R Enthusiast +33(0) 6 28 91 30 30 R Graph Gallery: http://gallery.r-enthusiasts.**comhttp://gallery.r-enthusiasts.com `- http://bit.ly/SweN1Z : SuperStorm Sandy blog: http://romainfrancois.blog.**free.frhttp://romainfrancois.blog.free.fr |- http://bit.ly/RE6sYH : OOP with Rcpp modules `- http://bit.ly/Thw7IK : Rcpp modules more flexible ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Fwd: latest incompatible changes for package developers?
Le 16/11/12 23:51, baptiste auguie a écrit : Hi Romain, Dirk, all, Thanks for the quick replies. I think the list problem was due to a change in my gmail address (from googlemail); still puzzling that I didn't get a warning. Hopefully someone can figure out why a function that returned an arma matrix has now become a vector: I've posted a minimal package on dropbox, https://dl.dropbox.com/u/352834/cda_1.2.1.tar.gz with a test in inst/testing that used to return a 3x3 matrix (Euler rotation), now a vector after the Rcpp update. The lesson for me is that I should really get into a proper testing framework. In the meantime, I'll be writing a few tests with Hadley's testthat. All the best, baptiste I'm looking at this issue now. Thanks for providing the example with euler. This is helpful. On 17 November 2012 11:20, Romain Francois rom...@r-enthusiasts.com mailto:rom...@r-enthusiasts.com wrote: First time I see this email. Sorry your package does not work. R CMD check --no-vignettes worked. (this is how I tested), but indeed something in the vignette makes it crash. I guess I should check the vignettes too :/ I get an error in demo(dimer_linear) regarding something that does not look like it is related to Rcpp, in this mdply call : comparison - mdply(params, onedimer, .progress=none) Not sure what the next steps are ... Romain Le 16/11/12 22:56, baptiste auguie a écrit : Hi, Forwarded to you directly just in case it never makes it to the list for whatever reason (shouldn't I get an error message if it it is bounced?) Best, baptiste -- Forwarded message -- From: *baptiste auguie* baptiste.aug...@gmail.com mailto:baptiste.aug...@gmail.com mailto:baptiste.auguie@gmail.__com mailto:baptiste.aug...@gmail.com Date: 17 November 2012 09:29 Subject: Fwd: latest incompatible changes for package developers? To: rcpp-devel rcpp-de...@r-forge.wu-wien.__ac.at mailto:rcpp-de...@r-forge.wu-wien.ac.at mailto:rcpp-de...@r-forge.wu-__wien.ac.at mailto:rcpp-de...@r-forge.wu-wien.ac.at Not sure what happened to this email I sent yesterday; I can't find it in the list archives? Thanks, b. -- Forwarded message -- From: *baptiste auguie* baptiste.aug...@gmail.com mailto:baptiste.aug...@gmail.com mailto:baptiste.auguie@gmail.__com mailto:baptiste.aug...@gmail.com Date: 16 November 2012 09:18 Subject: latest incompatible changes for package developers? To: rcpp-devel rcpp-devel@lists.r-forge.r-__project.org mailto:rcpp-devel@lists.r-forge.r-project.org mailto:rcpp-devel@lists.r-__forge.r-project.org mailto:rcpp-devel@lists.r-forge.r-project.org Dear list, I haven't yet had time to read much about the new exciting changes introduced in Rcpp 0.10, but I got an email from B. Ripley this morning warning me that my cda package* was broken as a result of this CRAN update. It uses modules and RcppArmadillo. Indeed, a quick glance at the broken demos after having updated the package suggest that most if not all my functions are currently broken. Is there a specific document I should read first to speed up this recovery and be compatible with the new version? How much change should I expect? Thanks. All the best, baptiste * https://github.com/baptiste/__cda https://github.com/baptiste/cda http://cran.r-project.org/web/__packages/cda/index.html http://cran.r-project.org/web/packages/cda/index.html -- Romain Francois Professional R Enthusiast +33(0) 6 28 91 30 30 tel:%2B33%280%29%206%2028%2091%2030%2030 R Graph Gallery: http://gallery.r-enthusiasts.__com http://gallery.r-enthusiasts.com `- http://bit.ly/SweN1Z : SuperStorm Sandy blog: http://romainfrancois.blog.__free.fr http://romainfrancois.blog.free.fr |- http://bit.ly/RE6sYH : OOP with Rcpp modules `- http://bit.ly/Thw7IK : Rcpp modules more flexible -- Romain Francois Professional R Enthusiast +33(0) 6 28 91 30 30 R Graph Gallery: http://gallery.r-enthusiasts.com `- http://bit.ly/SweN1Z : SuperStorm Sandy blog:http://romainfrancois.blog.free.fr |- http://bit.ly/RE6sYH : OOP with Rcpp modules `- http://bit.ly/Thw7IK : Rcpp modules more flexible ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] broken package after udpate
On 17 November 2012 at 11:31, baptiste auguie wrote:
| Hi,
|
| (Hopefully this makes it to the list; I believe I've had problems reaching it
| because of a recent change between @gmail and @googlemail).
Looks like it.
| I made a minimal package * to illustrate the problem of my recently broken
| package cda (since yesterday's update of Rcpp). There's only one function
euler
| () in a Module named cda. It used to return a 3x3 matrix, but after updating
to
| Rcpp 0.10 it returns a vector. You can run the example with
|
| $ R -f inst/testing/test.r
|
| What am I doing wrong?
|
| Best,
|
| baptiste
|
| * https://dl.dropbox.com/u/352834/cda_1.2.1.tar.gz
Good example. I added one line
Rcpp::Rcout In Euler, Rot is std::endl Rot std::endl;
and the end of 'Euler' and we see that the dimension is in fact there, but
then gets lost on the way out:
edd@max:/tmp/baptiste$ r -lcda -p -e'M - cda$euler(1.1, 2.0, 3.1); dim(M);
class(M); M'
[1] cda grid reshape2 randtoolbox
[5] rngWELL statmod plyr RcppArmadillo
[9] Rcpp methods base
In Euler, Rot is
-0.4378 -0.8983 0.0378
-0.3894 0.1515 -0.9085
0.8104 -0.4125 -0.4161
[1] -0.43778268 -0.38941320 0.81037256 -0.89828547 0.15154235 -0.41245379
[7] 0.03780919 -0.90851102 -0.41614684
NULL
[1] numeric
[1] -0.43778268 -0.38941320 0.81037256 -0.89828547 0.15154235 -0.41245379
[7] 0.03780919 -0.90851102 -0.41614684
edd@max:/tmp/baptiste$
That is with the newest Rcpp and RcppArmadillo. So somewhere we are loosing
the matrix attribute.
If I 'make the whole thing slower' by explicitly converting, it works -- I
just add euler2 as
NumericMatrix euler2(const double phi, const double theta, const double psi) {
arma::mat M(3,3);
M = euler(phi, theta, psi);
return Rcpp::wrap(M);
}
// [...]
function( euler2, euler2, Constructs a 3x3 Euler rotation matrix ) ;\
as seen here:
edd@max:/tmp/baptiste$ r -lcda -p -e'M - cda$euler2(1.1, 2.0, 3.1); dim(M);
class(M); M'
[1] cda grid reshape2 randtoolbox
[5] rngWELL statmod plyr RcppArmadillo
[9] Rcpp methods base
In Euler, Rot is
-0.4378 -0.8983 0.0378
-0.3894 0.1515 -0.9085
0.8104 -0.4125 -0.4161
[,1] [,2][,3]
[1,] -0.4377827 -0.8982855 0.03780919
[2,] -0.3894132 0.1515423 -0.90851102
[3,] 0.8103726 -0.4124538 -0.41614684
[1] 3 3
[1] matrix
[,1] [,2][,3]
[1,] -0.4377827 -0.8982855 0.03780919
[2,] -0.3894132 0.1515423 -0.90851102
[3,] 0.8103726 -0.4124538 -0.41614684
edd@max:/tmp/baptiste$
So somewhere between the compiler getting smarter, Conrad optimising
expression and us, an attribute got lost.
Maybe Romain can find a way to make this explicit.
Cheers, Dirk
--
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
[Rcpp-devel] Feedining an IntegerVector into Rcout?
Dear list,
Sorry for a trivial question: I have created the function below which calls
match on each vector in a list and returns the result as a list. The function
does what I want it to, but I am puzzled by this:
+ IntegerVector out = R_match(wrap(ee), V_);
+ Rcout out std::endl;
which prints
0xca858e0
0xca85cd0
0xd715d80
0xd715db8
- which proves that there is something not clear to me: Can't I print an entire
vector with Rcout - or must I exctract each element and print separately (which
seems kludgy)?
Best regards
Søren
get_index_ - cxxfunction(signature(x_ = SEXP, V_=SEXP), plugin = Rcpp,
+ body = '
+ using namespace Rcpp;
+ using namespace std;
+ Function R_match(match);
+ CharacterVector V(V_);
+ List x(x_);
+ List res=List::create();
+ for (int ii=0; iix.length(); ii++){
+ CharacterVector ee = asCharacterVector(x[ii]);
+ IntegerVector out = R_match(wrap(ee), V_);
+ Rcout out std::endl;
+ res.push_back(out);
+ }
+ return(wrap(res));
+ ')
get_index_(list(c(a,b),c(b,c), c(a,c,e), c(a,c,q)),
letters[1:10])
0xca858e0
0xca85cd0
0xd715d80
0xd715db8
[[1]]
[1] 1 2
[[2]]
[1] 2 3
[[3]]
[1] 1 3 5
[[4]]
[1] 1 3 NA
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Feedining an IntegerVector into Rcout?
This is not implemented. You can use Rf_PrintValue( out ) which prints
just like R's print.
Le 17/11/12 00:28, Søren Højsgaard a écrit :
Dear list,
Sorry for a trivial question: I have created the function below which calls
match on each vector in a list and returns the result as a list. The function
does what I want it to, but I am puzzled by this:
+ IntegerVector out = R_match(wrap(ee), V_);
+ Rcout out std::endl;
which prints
0xca858e0
0xca85cd0
0xd715d80
0xd715db8
- which proves that there is something not clear to me: Can't I print an entire
vector with Rcout - or must I exctract each element and print separately (which
seems kludgy)?
Best regards
Søren
get_index_ - cxxfunction(signature(x_ = SEXP, V_=SEXP), plugin = Rcpp,
+ body = '
+ using namespace Rcpp;
+ using namespace std;
+ Function R_match(match);
+ CharacterVector V(V_);
+ List x(x_);
+ List res=List::create();
+ for (int ii=0; iix.length(); ii++){
+ CharacterVector ee = asCharacterVector(x[ii]);
+ IntegerVector out = R_match(wrap(ee), V_);
+ Rcout out std::endl;
+ res.push_back(out);
+ }
+ return(wrap(res));
+ ')
get_index_(list(c(a,b),c(b,c), c(a,c,e), c(a,c,q)),
letters[1:10])
0xca858e0
0xca85cd0
0xd715d80
0xd715db8
[[1]]
[1] 1 2
[[2]]
[1] 2 3
[[3]]
[1] 1 3 5
[[4]]
[1] 1 3 NA
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
R Graph Gallery: http://gallery.r-enthusiasts.com
`- http://bit.ly/SweN1Z : SuperStorm Sandy
blog:http://romainfrancois.blog.free.fr
|- http://bit.ly/RE6sYH : OOP with Rcpp modules
`- http://bit.ly/Thw7IK : Rcpp modules more flexible
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] broken package after udpate
This is about one of C++ most annoying things. order of includes.
To make it short, the function that is responsible for making an R
object out of the returned arma::mat is module_wrap, which calls wrap,
Where module_wrap is currently written, it does not see the wrap()
overloads from RcpppArmadillo so it just uses a version that uses
begin() and end() and therefor just creates a vector.
So, alright. I broke this. This is an easy fix, although I'm afraid one
that has to happen in Rcpp.
A contingency measure might be to write your euler function like this:
SEXP euler(const double phi, const double theta, const double psi)
{
arma::mat Rot(3,3);
const double cosphi = cos(phi), cospsi = cos(psi), costheta =
cos(theta);
const double sinphi = sin(phi), sinpsi = sin(psi), sintheta =
sin(theta);
Rot(0,0) = cospsi*cosphi - costheta*sinphi*sinpsi;
Rot(0,1) = cospsi*sinphi + costheta*cosphi*sinpsi;
Rot(0,2) = sinpsi*sintheta;
Rot(1,0) = -sinpsi*cosphi - costheta*sinphi*cospsi;
Rot(1,1) = -sinpsi*sinphi + costheta*cosphi*cospsi;
Rot(1,2) = cospsi*sintheta;
Rot(2,0) = sinphi*sintheta;
Rot(2,1) = -cosphi*sintheta;
Rot(2,2) = costheta;
return wrap(Rot);
}
because there you call the right wrap.
Of course, the desired behaviour of having arma::mat as returned type
will be brought back.
Romain
Le 17/11/12 00:08, Dirk Eddelbuettel a écrit :
On 17 November 2012 at 11:31, baptiste auguie wrote:
| Hi,
|
| (Hopefully this makes it to the list; I believe I've had problems reaching it
| because of a recent change between @gmail and @googlemail).
Looks like it.
| I made a minimal package * to illustrate the problem of my recently broken
| package cda (since yesterday's update of Rcpp). There's only one function
euler
| () in a Module named cda. It used to return a 3x3 matrix, but after updating
to
| Rcpp 0.10 it returns a vector. You can run the example with
|
| $ R -f inst/testing/test.r
|
| What am I doing wrong?
|
| Best,
|
| baptiste
|
| * https://dl.dropbox.com/u/352834/cda_1.2.1.tar.gz
Good example. I added one line
Rcpp::Rcout In Euler, Rot is std::endl Rot std::endl;
and the end of 'Euler' and we see that the dimension is in fact there, but
then gets lost on the way out:
edd@max:/tmp/baptiste$ r -lcda -p -e'M - cda$euler(1.1, 2.0, 3.1); dim(M);
class(M); M'
[1] cda grid reshape2 randtoolbox
[5] rngWELL statmod plyr RcppArmadillo
[9] Rcpp methods base
In Euler, Rot is
-0.4378 -0.8983 0.0378
-0.3894 0.1515 -0.9085
0.8104 -0.4125 -0.4161
[1] -0.43778268 -0.38941320 0.81037256 -0.89828547 0.15154235 -0.41245379
[7] 0.03780919 -0.90851102 -0.41614684
NULL
[1] numeric
[1] -0.43778268 -0.38941320 0.81037256 -0.89828547 0.15154235 -0.41245379
[7] 0.03780919 -0.90851102 -0.41614684
edd@max:/tmp/baptiste$
That is with the newest Rcpp and RcppArmadillo. So somewhere we are loosing
the matrix attribute.
If I 'make the whole thing slower' by explicitly converting, it works -- I
just add euler2 as
NumericMatrix euler2(const double phi, const double theta, const double psi) {
arma::mat M(3,3);
M = euler(phi, theta, psi);
return Rcpp::wrap(M);
}
// [...]
function( euler2, euler2, Constructs a 3x3 Euler rotation matrix ) ;\
as seen here:
edd@max:/tmp/baptiste$ r -lcda -p -e'M - cda$euler2(1.1, 2.0, 3.1); dim(M);
class(M); M'
[1] cda grid reshape2 randtoolbox
[5] rngWELL statmod plyr RcppArmadillo
[9] Rcpp methods base
In Euler, Rot is
-0.4378 -0.8983 0.0378
-0.3894 0.1515 -0.9085
0.8104 -0.4125 -0.4161
[,1] [,2][,3]
[1,] -0.4377827 -0.8982855 0.03780919
[2,] -0.3894132 0.1515423 -0.90851102
[3,] 0.8103726 -0.4124538 -0.41614684
[1] 3 3
[1] matrix
[,1] [,2][,3]
[1,] -0.4377827 -0.8982855 0.03780919
[2,] -0.3894132 0.1515423 -0.90851102
[3,] 0.8103726 -0.4124538 -0.41614684
edd@max:/tmp/baptiste$
So somewhere between the compiler getting smarter, Conrad optimising
expression and us, an attribute got lost.
Maybe Romain can find a way to make this explicit.
Cheers, Dirk
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
R Graph Gallery: http://gallery.r-enthusiasts.com
`- http://bit.ly/SweN1Z : SuperStorm Sandy
blog:http://romainfrancois.blog.free.fr
|- http://bit.ly/RE6sYH : OOP with Rcpp modules
`- http://bit.ly/Thw7IK : Rcpp modules more flexible
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] broken package after udpate
I see, thanks a lot for tracking this down.
In practical terms, should I change all such functions to use SEXP +
explicit wrap, or will you submit a new CRAN version soon enough fixing
this? Personally I don't mind waiting a bit for the CRAN fix of cda;
probably noone else uses my package and I'd rather avoid making unnecessary
workaround fixes. That being said, I would be surprised if no other
packages broke because of this.
All the best,
baptiste
On 17 November 2012 12:44, Romain Francois rom...@r-enthusiasts.com wrote:
This is about one of C++ most annoying things. order of includes.
To make it short, the function that is responsible for making an R object
out of the returned arma::mat is module_wrap, which calls wrap,
Where module_wrap is currently written, it does not see the wrap()
overloads from RcpppArmadillo so it just uses a version that uses begin()
and end() and therefor just creates a vector.
So, alright. I broke this. This is an easy fix, although I'm afraid one
that has to happen in Rcpp.
A contingency measure might be to write your euler function like this:
SEXP euler(const double phi, const double theta, const double psi)
{
arma::mat Rot(3,3);
const double cosphi = cos(phi), cospsi = cos(psi), costheta =
cos(theta);
const double sinphi = sin(phi), sinpsi = sin(psi), sintheta =
sin(theta);
Rot(0,0) = cospsi*cosphi - costheta*sinphi*sinpsi;
Rot(0,1) = cospsi*sinphi + costheta*cosphi*sinpsi;
Rot(0,2) = sinpsi*sintheta;
Rot(1,0) = -sinpsi*cosphi - costheta*sinphi*cospsi;
Rot(1,1) = -sinpsi*sinphi + costheta*cosphi*cospsi;
Rot(1,2) = cospsi*sintheta;
Rot(2,0) = sinphi*sintheta;
Rot(2,1) = -cosphi*sintheta;
Rot(2,2) = costheta;
return wrap(Rot);
}
because there you call the right wrap.
Of course, the desired behaviour of having arma::mat as returned type will
be brought back.
Romain
Le 17/11/12 00:08, Dirk Eddelbuettel a écrit :
On 17 November 2012 at 11:31, baptiste auguie wrote:
| Hi,
|
| (Hopefully this makes it to the list; I believe I've had problems
reaching it
| because of a recent change between @gmail and @googlemail).
Looks like it.
| I made a minimal package * to illustrate the problem of my recently
broken
| package cda (since yesterday's update of Rcpp). There's only one
function euler
| () in a Module named cda. It used to return a 3x3 matrix, but after
updating to
| Rcpp 0.10 it returns a vector. You can run the example with
|
| $ R -f inst/testing/test.r
|
| What am I doing wrong?
|
| Best,
|
| baptiste
|
| *
https://dl.dropbox.com/u/**352834/cda_1.2.1.tar.gzhttps://dl.dropbox.com/u/352834/cda_1.2.1.tar.gz
Good example. I added one line
Rcpp::Rcout In Euler, Rot is std::endl Rot std::endl;
and the end of 'Euler' and we see that the dimension is in fact there, but
then gets lost on the way out:
edd@max:/tmp/baptiste$ r -lcda -p -e'M - cda$euler(1.1, 2.0, 3.1);
dim(M); class(M); M'
[1] cda grid reshape2 randtoolbox
[5] rngWELL statmod plyr RcppArmadillo
[9] Rcpp methods base
In Euler, Rot is
-0.4378 -0.8983 0.0378
-0.3894 0.1515 -0.9085
0.8104 -0.4125 -0.4161
[1] -0.43778268 -0.38941320 0.81037256 -0.89828547 0.15154235
-0.41245379
[7] 0.03780919 -0.90851102 -0.41614684
NULL
[1] numeric
[1] -0.43778268 -0.38941320 0.81037256 -0.89828547 0.15154235
-0.41245379
[7] 0.03780919 -0.90851102 -0.41614684
edd@max:/tmp/baptiste$
That is with the newest Rcpp and RcppArmadillo. So somewhere we are
loosing
the matrix attribute.
If I 'make the whole thing slower' by explicitly converting, it works -- I
just add euler2 as
NumericMatrix euler2(const double phi, const double theta, const double
psi) {
arma::mat M(3,3);
M = euler(phi, theta, psi);
return Rcpp::wrap(M);
}
// [...]
function( euler2, euler2, Constructs a 3x3 Euler rotation matrix ) ;\
as seen here:
edd@max:/tmp/baptiste$ r -lcda -p -e'M - cda$euler2(1.1, 2.0, 3.1);
dim(M); class(M); M'
[1] cda grid reshape2 randtoolbox
[5] rngWELL statmod plyr RcppArmadillo
[9] Rcpp methods base
In Euler, Rot is
-0.4378 -0.8983 0.0378
-0.3894 0.1515 -0.9085
0.8104 -0.4125 -0.4161
[,1] [,2][,3]
[1,] -0.4377827 -0.8982855 0.03780919
[2,] -0.3894132 0.1515423 -0.90851102
[3,] 0.8103726 -0.4124538 -0.41614684
[1] 3 3
[1] matrix
[,1] [,2][,3]
[1,] -0.4377827 -0.8982855 0.03780919
[2,] -0.3894132 0.1515423 -0.90851102
[3,] 0.8103726 -0.4124538 -0.41614684
edd@max:/tmp/baptiste$
So somewhere between the compiler getting smarter, Conrad optimising
expression and us, an attribute got lost.
Maybe Romain can find a way to make this explicit.
Cheers, Dirk
--
Romain Francois
Professional R
Re: [Rcpp-devel] broken package after udpate
Le 17/11/12 00:59, baptiste auguie a écrit :
I see, thanks a lot for tracking this down.
In practical terms, should I change all such functions to use SEXP +
explicit wrap, or will you submit a new CRAN version soon enough fixing
this?
I don't know.
Personally I don't mind waiting a bit for the CRAN fix of cda;
probably noone else uses my package and I'd rather avoid making
unnecessary workaround fixes. That being said, I would be surprised if
no other packages broke because of this.
Well. We'll only know when people tell us I guess.
All the best,
baptiste
On 17 November 2012 12:44, Romain Francois rom...@r-enthusiasts.com
mailto:rom...@r-enthusiasts.com wrote:
This is about one of C++ most annoying things. order of includes.
To make it short, the function that is responsible for making an R
object out of the returned arma::mat is module_wrap, which calls wrap,
Where module_wrap is currently written, it does not see the wrap()
overloads from RcpppArmadillo so it just uses a version that uses
begin() and end() and therefor just creates a vector.
So, alright. I broke this. This is an easy fix, although I'm afraid
one that has to happen in Rcpp.
A contingency measure might be to write your euler function like this:
SEXP euler(const double phi, const double theta, const double psi)
{
arma::mat Rot(3,3);
const double cosphi = cos(phi), cospsi = cos(psi), costheta =
cos(theta);
const double sinphi = sin(phi), sinpsi = sin(psi), sintheta =
sin(theta);
Rot(0,0) = cospsi*cosphi - costheta*sinphi*sinpsi;
Rot(0,1) = cospsi*sinphi + costheta*cosphi*sinpsi;
Rot(0,2) = sinpsi*sintheta;
Rot(1,0) = -sinpsi*cosphi - costheta*sinphi*cospsi;
Rot(1,1) = -sinpsi*sinphi + costheta*cosphi*cospsi;
Rot(1,2) = cospsi*sintheta;
Rot(2,0) = sinphi*sintheta;
Rot(2,1) = -cosphi*sintheta;
Rot(2,2) = costheta;
return wrap(Rot);
}
because there you call the right wrap.
Of course, the desired behaviour of having arma::mat as returned
type will be brought back.
Romain
Le 17/11/12 00:08, Dirk Eddelbuettel a écrit :
On 17 November 2012 at 11:31, baptiste auguie wrote:
| Hi,
|
| (Hopefully this makes it to the list; I believe I've had
problems reaching it
| because of a recent change between @gmail and @googlemail).
Looks like it.
| I made a minimal package * to illustrate the problem of my
recently broken
| package cda (since yesterday's update of Rcpp). There's only
one function euler
| () in a Module named cda. It used to return a 3x3 matrix, but
after updating to
| Rcpp 0.10 it returns a vector. You can run the example with
|
| $ R -f inst/testing/test.r
|
| What am I doing wrong?
|
| Best,
|
| baptiste
|
| * https://dl.dropbox.com/u/__352834/cda_1.2.1.tar.gz
https://dl.dropbox.com/u/352834/cda_1.2.1.tar.gz
Good example. I added one line
Rcpp::Rcout In Euler, Rot is std::endl Rot
std::endl;
and the end of 'Euler' and we see that the dimension is in fact
there, but
then gets lost on the way out:
edd@max:/tmp/baptiste$ r -lcda -p -e'M - cda$euler(1.1, 2.0,
3.1); dim(M); class(M); M'
[1] cda grid reshape2 randtoolbox
[5] rngWELL statmod plyr
RcppArmadillo
[9] Rcpp methods base
In Euler, Rot is
-0.4378 -0.8983 0.0378
-0.3894 0.1515 -0.9085
0.8104 -0.4125 -0.4161
[1] -0.43778268 -0.38941320 0.81037256 -0.89828547 0.15154235
-0.41245379
[7] 0.03780919 -0.90851102 -0.41614684
NULL
[1] numeric
[1] -0.43778268 -0.38941320 0.81037256 -0.89828547 0.15154235
-0.41245379
[7] 0.03780919 -0.90851102 -0.41614684
edd@max:/tmp/baptiste$
That is with the newest Rcpp and RcppArmadillo. So somewhere we
are loosing
the matrix attribute.
If I 'make the whole thing slower' by explicitly converting, it
works -- I
just add euler2 as
NumericMatrix euler2(const double phi, const double theta, const
double psi) {
arma::mat M(3,3);
M = euler(phi, theta, psi);
return Rcpp::wrap(M);
}
// [...]
function( euler2, euler2, Constructs a 3x3 Euler rotation
matrix ) ;\
as seen here:
edd@max:/tmp/baptiste$ r -lcda -p -e'M - cda$euler2(1.1, 2.0,
3.1); dim(M); class(M); M'
[1] cda grid reshape2 randtoolbox
[5] rngWELL statmod plyr
Re: [Rcpp-devel] broken package after udpate
On 17 November 2012 at 01:06, Romain Francois wrote: | | Le 17/11/12 00:59, baptiste auguie a écrit : | I see, thanks a lot for tracking this down. Seconded -- nicely done. | In practical terms, should I change all such functions to use SEXP + | explicit wrap, or will you submit a new CRAN version soon enough fixing | this? | | I don't know. We are doing _a lot_ of work on Rcpp right now, so I'd say we will have a new release sooner rather than later -- maybe in two or three weeks. But there is no guarantee. | Personally I don't mind waiting a bit for the CRAN fix of cda; | probably noone else uses my package and I'd rather avoid making | unnecessary workaround fixes. That being said, I would be surprised if | no other packages broke because of this. | | Well. We'll only know when people tell us I guess. With infinite time, we would have an infinite number of use cases. I think we have a simple case that test return of matrices, but (and I have not yet checked) the include order that Romain identified is of course not something we check. Cheers, Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] Feedining an IntegerVector into Rcout?
On 16 November 2012 at 23:28, Søren Højsgaard wrote: | Dear list, | | Sorry for a trivial question: I have created the function below which calls match on each vector in a list and returns the result as a list. The function does what I want it to, but I am puzzled by this: | | + IntegerVector out = R_match(wrap(ee), V_); | + Rcout out std::endl; | | which prints | | 0xca858e0 | 0xca85cd0 | 0xd715d80 | 0xd715db8 As Romain said, it is simply not there. You need to define an operator for this which we don;t have --- an easy avenue for someone to contribute something meaningful but not too complicated (hopefully...). What I do is to use Armadillo's containers -- they have this and a few other input / output facilities. | - which proves that there is something not clear to me: Can't I print an entire vector with Rcout - or must I exctract each element and print separately (which seems kludgy)? a) Define a print function, or b) define operator, or c) cast to arma::vec and print that or d) use the kludge of printing via a loop. Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] broken package after udpate
I've tested my package with the latest Rcpp svn commit (3987) on r-forge and that fixes it. I'm therefore keen to just wait for the next Rcpp release; I'll write the CRAN maintainers to see what they want to do with temporarily broken cda in the meantime. Thanks again for the very responsive help, baptiste On 17 November 2012 13:13, Dirk Eddelbuettel e...@debian.org wrote: On 17 November 2012 at 01:06, Romain Francois wrote: | | Le 17/11/12 00:59, baptiste auguie a écrit : | I see, thanks a lot for tracking this down. Seconded -- nicely done. | In practical terms, should I change all such functions to use SEXP + | explicit wrap, or will you submit a new CRAN version soon enough fixing | this? | | I don't know. We are doing _a lot_ of work on Rcpp right now, so I'd say we will have a new release sooner rather than later -- maybe in two or three weeks. But there is no guarantee. | Personally I don't mind waiting a bit for the CRAN fix of cda; | probably noone else uses my package and I'd rather avoid making | unnecessary workaround fixes. That being said, I would be surprised if | no other packages broke because of this. | | Well. We'll only know when people tell us I guess. With infinite time, we would have an infinite number of use cases. I think we have a simple case that test return of matrices, but (and I have not yet checked) the include order that Romain identified is of course not something we check. Cheers, Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com ___ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
Re: [Rcpp-devel] broken package after udpate
On 17 November 2012 at 16:18, baptiste auguie wrote:
| I've tested my package with the latest Rcpp svn commit (3987) on r-forge and
| that fixes it. I'm therefore keen to just wait for the next Rcpp release; I'll
| write the CRAN maintainers to see what they want to do with temporarily broken
| cda in the meantime.
I think it is not a good idea to leave things hanging in cannot quite build
limbo. That is probably also what the CRAN maintainers will tell you. You
may even risk getting relegated.
For argument's sake, could just define the function bound by the module
declaration as returning SEXP, ie
// general rotation matrix
SEXP euler(const double phi, const double theta, const double psi) {
[...]
RCPP_MODULE(cda){
using namespace Rcpp ;
function( euler, euler, Constructs a 3x3 Euler rotation matrix ) ;\
}
which would circumvent the issue, and work with the current not-quite-ideal
Rcpp as well as future ones? OTOH you seem to have 14 functions defined in
cda_1.2.1 so maybe that is too much work?
| Thanks again for the very responsive help,
Yes, that was nice late-night work by Romain.
Sorry again for the breakage.
Dirk
| baptiste
|
|
|
|
| On 17 November 2012 13:13, Dirk Eddelbuettel e...@debian.org wrote:
|
|
| On 17 November 2012 at 01:06, Romain Francois wrote:
| |
| | Le 17/11/12 00:59, baptiste auguie a écrit :
| | I see, thanks a lot for tracking this down.
|
| Seconded -- nicely done.
|
| | In practical terms, should I change all such functions to use SEXP +
| | explicit wrap, or will you submit a new CRAN version soon enough
fixing
| | this?
| |
| | I don't know.
|
| We are doing _a lot_ of work on Rcpp right now, so I'd say we will have a
| new
| release sooner rather than later -- maybe in two or three weeks. But there
| is
| no guarantee.
|
| | Personally I don't mind waiting a bit for the CRAN fix of cda;
| | probably noone else uses my package and I'd rather avoid making
| | unnecessary workaround fixes. That being said, I would be surprised if
| | no other packages broke because of this.
| |
| | Well. We'll only know when people tell us I guess.
|
| With infinite time, we would have an infinite number of use cases. I think
| we
| have a simple case that test return of matrices, but (and I have not yet
| checked) the include order that Romain identified is of course not
| something
| we check.
|
| Cheers, Dirk
|
| --
| Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
|
|
--
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
