Re: [Rcpp-devel] Passing XPtr between functions
Hi Charles, comments inline
2015-06-24 11:03 GMT-04:00 Charles Determan cdeterma...@gmail.com:
The fastLm examples are nice but they don't contain anything relating to
passing an XPtr between functions. Regarding your comment about making an
XPtr around arma::mat 'innards' I'm not sure I fully understand. I tried
creating an XPtr around a arma::mat but no success on passing the object
between functions. It still returns that ~zeros.
// [[Rcpp::export]]
SEXP testXptr(SEXP A)
{
arma::Matdouble armaMat = asarma::mat(A);
XPtrarma::mat pMat(armaMat);
return(pMat);
}
When testXptr returns, armaMat is gone so it doesn't matter what you do
with pMat. You need to use new to create armaMat and hand it over to
XPtr as above. Then XPtr is returned to R. When XPtr is returned to R it's
protected from R's garbage collection by having a reference (reference?
something like that) to it in R. armaMat lives on since it was created
with new. When you delete the XPtr in R, _it_ gets garbage-collected and
the destructor for XPtr calls delete on armaMat. Then armaMat is gone
and you don't have a memory leak. So the scheme is:
1) Create object of class Whatever in C++ using new.
2) Wrap object in XPtrWhatever
3) Return XPTrWhatever to R and save it to a variable.
4) Pass XPtrWhatever to any functions that need the object of class
Whatever
5) When you don't need the object of class Whatever, remove XPtrWhatever
from the R session
6) R does gc on XPtrWhatever, which has a destructor.
7) Destructor from XPtrWhatever does delete on object of class Whatever.
Been a few months since I used this but I'm sure someone will correct me if
I'm not quite right here. There really ought to be (and might already be)
an Rcpp gallery item about this process. I'll sign up to make on later
this summer :)
Krzysztof
// [[Rcpp::export]]
void testReturn(SEXP ptrA, int nr, int nc)
{
XPtrarma::mat ptrB(ptrA);
arma::mat B = arma::mat( (double *) ptrB-memptr(),
nr,
nc,
false);
B.print(copied matrix);
}
Charles
On Wed, Jun 24, 2015 at 8:32 AM, Dirk Eddelbuettel e...@debian.org wrote:
On 24 June 2015 at 08:22, Charles Determan wrote:
| Thank you John,
|
| I am familiar with bigmemory (I am one of the current developers
actually).
| The project I am working on doesn't need the shared memory aspect so was
| intending to avoid the dependency and just leverage the more familiar
and
| developed Armadillo library. However your response informs me that I
did not
| fully understand how armadillo objects are handled. I have some other
ideas
| with how I can address my problem but this was something I was hoping
to apply
| both for this project and for the sake of learning.
Look at more current RcppArmadillo examples, and in particular _all_ the
variants of the fastLm benchmark in examples. By doing the explicit cast,
you _forced_ a copy which may then have destroyed the Xptr link. I
*think*
you could just do XPtr around arma::mat innards. I would actually be
interested in having something somewhere between bigmemory (where I was
one
of the first external users) and what we have in RcppArmadillo.
Dirk, during a break of Rcpp class in Zuerich
| Regards,
| Charles
|
| On Tue, Jun 23, 2015 at 9:29 PM, John Buonagurio
jbuonagu...@exponent.com
| wrote:
|
| Hi Charles,
|
| SEXP testXptr(SEXP A)
| {
| arma::Matdouble armaMat = Rcpp::asarma::Matdouble (A);
| Rcpp::XPtrdouble pMat(armaMat.memptr());
| return(pMat);
| }
|
| armaMat is on the stack, so the Armadillo memptr is no longer valid
when
| you return from the testXptr function.
|
| One simple solution in your case would be to dynamically allocate
with
| new [e.g. arma::mat *A = new arma::mat(...);], though I can't
tell you
| off hand how object lifetime is managed with Armadillo objects.
|
| If you're trying to preserve a matrix across function calls in R,
have you
| looked into bigmemory? http://gallery.rcpp.org/articles/
| using-bigmemory-with-rcpp/
|
| John
|
|
|
| ___
| 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
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
___
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 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] statement about rcpp11 ?
On Tue, Sep 30, 2014 at 1:43 PM, Jonathon Love j...@thon.cc wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 thanks for your response romain, If you want to have a private conversation with Dirk, just email him directly sure, but i expect i'm not the only one interested in his response. Just use whatever version is best for your needs. sure, i get that; but i (and i imagine others) would be interested to hear dirk's take on it. the reality is that we can't read every piece of code to evaluate software projects, and so we often come to rely on the opinion of an experienced professional that we have come to trust; and for me (and others!) that's dirk.\ That makes sense, but if you search the list archives (which is generally requested of folks writing to the list) you would notice some context which makes your original questions look a little bit like trolling---having seen previous exchanges on the topic of Rcpp11, I couldn't tell if you were serious or not. Hope that helps, Krzysztof anyhow, dirk, still keen to hear your thoughts :), and find your silence on this a little perplexing. kind regards jonathon - -- JASP - A Fresh Way to Do Statistics http://jasp-stats.org/ - -- How happy is he born and taught, That serveth not another's will; Whose armour is his honest thought, And simple truth his utmost skill This man is freed from servile bands Of hope to rise, or fear to fall: Lord of himself, though not of lands, And, having nothing, yet hath all. -- Sir Henry Wotton -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUKuvZAAoJEH277gjmPGDY+xAP/iVxsvweH0cIMzb48xPoC/Wf ly4/mdpy8W4tWsm8ykHXmR+AeAfzJMBfzvyDQrigRmt4/Az9swQcntrT8EmpbkZI fp9irfRZXOBApzKKMcfBLeEJrIoUbEhBR1G+qfhGaBpS7au+pS4tCKkJlaLgf0Zk QsSPNB0LrIQURastycBRcAJ9+VxjcKym3TeC/e3fTZJRIeQPtyjHthkpIPFZFzUK bCV2sIHIErWCdZcznZ2CaQD6vDh1fs0glevz6EaWyN2q5UPpJ8E49s8jCXeWc1na Y11D9EBA/Sw+y/gSmUbsDqf7VmW/F29Lz1ExrJaWdo+kILA3ze/TP4yYUnFNGGM6 EiKRlyEoLjULRWKZEtmUBVjk7NqSkhYB5mJCd9sbzWdJQa79UxHsePdfCHSy93MM 02efIY6RqdAQPh6otqGiWtXT1P/qqrcYXvaHWHUO23iVu+Ii8rKgAcreY8bVbR5S 9uKFuAmDNZ/69WEWSld9dD5tqrdgePcc1lEud/fdVGS595Pz9YBfO0evpm12ic/G kcK8O4BwbbZjN18LVzMYHHUl4C+NCiRrT7OShLLsFWVsJSSjFBovq2Z8VHtQyW5j cCMoKLIn268lLCP8mgP0gZwOUM0ZaYMXs5Q1BR/gfB5IyJVmwzCDeCn9xgLOo5Xs BDbIzP2LvNa5qMVo5TNR =k+lg -END PGP SIGNATURE- ___ 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 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] optimizing rcpp iterating code
Hi Steve, One way to get a boost is to avoid allocating memory, so your second message is spot on. If you are serious about making your code fast you need to get used to profiling your code. When it's a small-to-medium bit like this it might not be necessary, but in anything larger it quickly becomes worthwhile... and running a profiler on a small code will make more sense than trying it on something big so this is a great place to start... On linux oprofile is great, on Windows you'll have to ask somebody else... like Stack Overlfow: http://stackoverflow.com/questions/13224322/profiling-rcpp-code-on-os-x Krzysztof On Wed, Jul 16, 2014 at 1:15 PM, Steve Bellan steve.bel...@gmail.com wrote: also, note I just got a slight bump in speed by only doing NumericMatrix serosO=clone(seros); once, outside of the loop and by just doing serosO=seros; inside the loop so that there was no re-initialization of serosO each time. Now I'm 3.5X instead of 2.5X R-speed for 10^4 numcouples, but I keep seeing people talk about 30X increases and I'm hoping to approach that. ___ 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 -- Krzysztof Sakrejda Organismic and Evolutionary Biology University of Massachusetts, Amherst 319 Morrill Science Center South 611 N. Pleasant Street Amherst, MA 01003 work #: 413-325-6555 email: sakre...@cns.umass.edu --- ___ 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] Looking for help with an rstan issue...
Hi, I'm not sure if this is an Rcpp problem or an rstan problem but reading through the rstan code I don't see a reason why the rstan code should be triggering it... so I'm looking for advice about how to debug it further. I think the right etiquette is to just give a link to the issue, but please let me know if it is better to post everything here. This is currently an open issue on the rstan issue tracker: https://github.com/stan-dev/rstan/issues/76 The upshot is that when running a Stan model through Rstan for a small amount of data the code runs fine. With a larger amount of data it segfaults the R session with a stack overflow after getting into infinite recursion immediately after a call to R_ReleaseObject... I left the rest of the details at the link (including code/data which the rstan developers have been able to replicate the issue with). The backtrace (pre infinite recursion) is below and I would appreciate any help in figuring out the next step in debugging this. Sincerely, Krzysztof #521237 0x779bc5c8 in ?? () from /usr/lib64/R/lib/libR.so #521238 0x779bc5c8 in ?? () from /usr/lib64/R/lib/libR.so #521239 0x779bc5c8 in ?? () from /usr/lib64/R/lib/libR.so ---Type return to continue, or q return to quit--- #521240 0x779bd030 in R_ReleaseObject () from /usr/lib64/R/lib/libR.so #521241 0x70d0c67e in void std::_Destroy_auxfalse::__destroyRcpp::Vector14, Rcpp::PreserveStorage*(Rcpp::Vector14, Rcpp::PreserveStorage*, Rcpp::Vector14, Rcpp::PreserveStorage*) () from /tmp/RtmplSIXA8/file3cc170510487.so #521242 0x70d11391 in std::vectorRcpp::Vector14, Rcpp::PreserveStorage, std::allocatorRcpp::Vector14, Rcpp::PreserveStorage ::_M_insert_aux(__gnu_cxx::__normal_iteratorRcpp::Vector14, Rcpp::PreserveStorage*, std::vectorRcpp::Vector14, Rcpp::PreserveStorage, std::allocatorRcpp::Vector14, Rcpp::PreserveStorage , Rcpp::Vector14, Rcpp::PreserveStorage const) () from /tmp/RtmplSIXA8/file3cc170510487.so #521243 0x70cd2748 in void rstan::(anonymous namespace)::execute_samplingmodel3cc116ebc25d_growth_model_namespace::model3cc116ebc25d_growth_model, boost::random::additive_combine_engineboost::random::linear_congruential_engineunsigned int, 40014u, 0u, 2147483563u, boost::random::linear_congruential_engineunsigned int, 40692u, 0u, 2147483399u (rstan::stan_args, 2147483399u model3cc116ebc25d_growth_model_namespace::model3cc116ebc25d_growth_model, 2147483399u Rcpp::Vector19, Rcpp::PreserveStorage, 2147483399u stan::mcmc::base_mcmc*, stan::mcmc::sample, 2147483399u std::vectorunsigned long, std::allocatorunsigned 2147483399u long const, std::vectordouble, 2147483399u long std::allocatordouble , 2147483399u long std::basic_fstreamchar, 2147483399u long std::char_traitschar , 2147483399u long std::basic_fstreamchar, 2147483399u long std::char_traitschar , 2147483399u long std::vectorstd::string, 2147483399u long std::allocatorstd::string const, 2147483399u long boost::random::additive_combine_engineboost::random::linear_congruential_engineunsigned 2147483399u long int, 40014u, 0u, 2147483563u, 2147483399u long boost::random::linear_congruential_engineunsigned 2147483399u long int, 40692u, 0u, 2147483399u ) () 2147483399u long from /tmp/RtmplSIXA8/file3cc170510487.so 2147483399u long #521244 0x70cd7dca in int 2147483399u long rstan::(anonymous 2147483399u long namespace)::sampler_commandmodel3cc116ebc25d_growth_mo---Type 2147483399u long return to continue, or q return to quit--- 2147483399u long del_namespace::model3cc116ebc25d_growth_model, 2147483399u long boost::random::additive_combine_engineboost::random::linear_congruential_engineunsigned 2147483399u long int, 40014u, 0u, 2147483563u, 2147483399u long boost::random::linear_congruential_engineunsigned 2147483399u long int, 40692u, 0u, 2147483399u 2147483399u long (rstan::stan_args, 2147483399u long model3cc116ebc25d_growth_model_namespace::model3cc116ebc25d_growth_model, 2147483399u long Rcpp::Vector19, Rcpp::PreserveStorage, 2147483399u long std::vectorunsigned long, 2147483399u long std::allocatorunsigned long const, 2147483399u long std::vectorstd::string, 2147483399u long std::allocatorstd::string const, 2147483399u long boost::random::additive_combine_engineboost::random::linear_congruential_engineunsigned 2147483399u long int, 40014u, 0u, 2147483563u, 2147483399u long boost::random::linear_congruential_engineunsigned 2147483399u long int, 40692u, 0u, 2147483399u ) () from /tmp/RtmplSIXA8/file3cc170510487.so #521245 0x70d45d8b in rstan::stan_fitmodel3cc116ebc25d_growth_model_namespace::model3cc116ebc25d_growth_model, boost::random::additive_combine_engineboost::random::linear_congruential_engineunsigned int, 40014u, 0u, 2147483563u, boost::random::linear_congruential_engineunsigned int, 40692u, 0u, 2147483399u ::call_sampler(SEXPREC*) () 2147483399u from
Re: [Rcpp-devel] Copying a NumericVector from a list within a list
On Sat, Apr 12, 2014 at 11:06 PM, Dirk Eddelbuettel e...@debian.org wrote:
What can work as a single expression in R sometimes needs to be disentangled
at the C++ level to help the compiler find its way through all the templates.
[snip]
// [[Rcpp::export]]
NumericVector fromList(List outer, std::string name) {
List inner = outer[0];// 0-based offsets in C++
return inner[p];
}
I've noticed (I think...) having to do this sort of thing, but I want
to ask a question to clarify: is it possible to have the above code
work, but if you instead try:
NumericVector fromList(List outer, std::string name) {
(outer[0])[p]
}
/*** R
x - c(0.2855202, 0.6731716, 0.8497825, 0.7445254, 0.2382722)
innL - list(p=x)
outL - list(List1=innL)
fromList(outL, p)
*/
--
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
--
Krzysztof Sakrejda
Organismic and Evolutionary Biology
University of Massachusetts, Amherst
319 Morrill Science Center South
611 N. Pleasant Street
Amherst, MA 01003
work #: 413-325-6555
email: sakre...@cns.umass.edu
---
___
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] Copying a NumericVector from a list within a list
Sorry, accidental gmail send... here's what I meant:
On Sat, Apr 12, 2014 at 11:06 PM, Dirk Eddelbuettel e...@debian.org wrote:
What can work as a single expression in R sometimes needs to be disentangled
at the C++ level to help the compiler find its way through all the templates.
[snip]
// [[Rcpp::export]]
NumericVector fromList(List outer, std::string name) {
List inner = outer[0];// 0-based offsets in C++
return inner[p];
}
I've noticed (I think...) having to do this sort of thing, but I want
to ask a question to clarify: is it possible to have the above code
work, but if you instead try:
NumericVector fromList(List outer, std::string name) {
return (outer[0])[p];
}
or even:
NumericVector fromList(List outer, std::string name) {
NumericVector vec = (outer[0])[p];
return vec;
}
It will fail to compile? That's what you mean by needing to help the
compiler? If so,
is there some terminology for these sorts of problems?
Krzysztof
___
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] Question on lme4 book
On Tue, Dec 10, 2013 at 10:00 AM, Kasper Daniel Hansen kasperdanielhan...@gmail.com wrote: It is basically impossible to address these issues without a system. It would be great if someone made a virtual machine with R and everything that I (and others) could download and test with. Isn't that something one could ask the Solaris people for? It seems like a common issue with making their platform more usable w.r.t. R. I imagine that sort of request would only work coming from one of their paying users. Krzysztof ___ 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] Interfacing Rcpp with a C library: memory allocation
Without seeing your code, this is a lot like playing 20 questions, but if your C code is correct, you might get memory-related segfaults by misunderstanding the lifetime of the R objects Rcpp references. Krzysztof On Wed, Nov 20, 2013 at 12:27 PM, Alessandro Mammana mamm...@molgen.mpg.de wrote: Dear all, I'm trying to write some efficient code for analyzing sequencing data in R. To do this I would like to use the C library samtools. I've created a package where the src directory looks like this: src |-- Makevars |-- RcppExports.cpp |-- mysourcecode.cpp `-- samtools |-- all *.c and *.h files as well as an independent Makefile My Makevars file looks like this: PKG_CPPFLAGS = -Isamtools PKG_LIBS = `$(R_HOME)/bin/Rscript -e Rcpp:::LdFlags()` PKG_LIBS += -Lsamtools -lbam -lz -lpthread $(SHLIB): samtools/libbam.a samtools/libbam.a: @(cd samtools-0.1.19 $(MAKE) libbam.a \ CC=$(CC) CFLAGS=$(CFLAGS) $(CPICFLAGS) AR=$(AR) RANLIB=$(RANLIB)) Everything compiles and I get my cpp functions in R, however I am getting some weird segfaults, I think they are due to memory allocation, but it's hard for me to track them. Especially now, these errors are showing up not immediately, but at the second time that I call a Rcpp function. I wanted to ask the following: 1. Is it the right way of using external C libraries? I couldn't find much documentation around 2. The C library uses malloc and free, and so do I (as little as possible, just to interface with the library), is this mechanism clashing against Rcpp/R memory management? Could it happen, for instance, that R tries to free allocated memory that I already manually freed myself? In general I didn't understand much about memory allocation in Rcpp and I couldn't find many resources talking about it. Is there anything R- or Rcpp-specific that I have to keep in mind or should I program as if I were programming in C/C++? Thanks a lot! -- Alessandro Mammana, PhD Student Max Planck Institute for Molecular Genetics Ihnestraße 63-73 D-14195 Berlin, Germany ___ 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 -- Krzysztof Sakrejda Organismic and Evolutionary Biology University of Massachusetts, Amherst 319 Morrill Science Center South 611 N. Pleasant Street Amherst, MA 01003 work #: 413-325-6555 email: sakre...@cns.umass.edu --- ___ 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] inconsistent is_na() vs. is.na()
On Wed, Oct 2, 2013 at 9:36 AM, Dirk Eddelbuettel e...@debian.org wrote: On 2 October 2013 at 21:10, Thomas Tse wrote: | For whatever reason R chose NaN to be a subset of NA_real_, so I think it's | better for Rcpp (which aims to provide C++ functionality in R) to follow the | convention of R ... It makes sense to stick strictly to R for these convenience functions, one can already get at the non-Rcpp values through as to check their meaning on the C++ side. Just please decide on the R or C++ convention and don't mix the two. Krzysztof ___ 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] Dynamic Wrapping and Recursion with Rcpp - using an R function?
Make the wrapper a reference class which has a field for the data. When the wrapper is initialized, pass the data as an argument and it will be copied when the initialize method runs. Works in my project... or am I missing something here? Krzysztof On Fri, Jul 26, 2013 at 4:58 PM, Tal Galili tal.gal...@gmail.com wrote: Hi Hadley, Regarding the cloning of the object in C++: since I will want to use the function recursively, I will either have the cloning in the wrapper R function. And if I discover that is not possible (I haven't tried it yet), my next thought was to split the work into two functions, in one there will be the cloning, and the other will do the recursion. Since the example I gave in the first e-mail doesn't work (help is welcomed), I am not there yet :) As for as.dendrogram, that is the case with hclust object. However, these objects has limitations when it comes to trees which are NOT binary trees. So one of the things I started doing with dendextend is to create various functions that will work for non-binary trees (which I previously had to work with). Tal Contact Details:--- Contact me: tal.gal...@gmail.com | Read me: www.talgalili.com (Hebrew) | www.biostatistics.co.il (Hebrew) | www.r-statistics.com (English) -- On Fri, Jul 26, 2013 at 7:07 PM, Hadley Wickham h.wick...@gmail.com wrote: I understand your point, and am not sure how to proceed without it. Just make sure you clone the initial list once, or use another C++ data structure (e.g. std::vector) that can grow efficiently. Alternatively, you could create your own alternative to as.dendrogram that doesn't create a hierarchical structure. (That's what I'd try first) Hadley -- Chief Scientist, RStudio 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 -- Krzysztof Sakrejda Organismic and Evolutionary Biology University of Massachusetts, Amherst 319 Morrill Science Center South 611 N. Pleasant Street Amherst, MA 01003 work #: 413-325-6555 email: sakre...@cns.umass.edu --- ___ 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] Difference between runif and unif_rand?
On Fri, Jul 12, 2013 at 8:50 PM, Dirk Eddelbuettel e...@debian.org wrote: On 12 July 2013 at 12:28, Neal Fultz wrote: | I've been updating the C in an r package to use Rcpp and started seeing | so odd results from a function that samples from a discrete | distribution. For what it's worth, I can't reproduce this so it may be specific to your versions of R/Rcpp. Krzysztof ___ 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] returning array from C
On Jun 11, 2013 12:33 PM, Steve Jaffe sja...@riskspan.com wrote: The problem with External Pointer is that R will not be able to use it as a numeric vector (sfaik). What I'm looking for -- and perhaps it is impossible -- would be a way to combine the memory semantics of External Pointer with the value semantics of Numeric Vector. Or something along those lines. You can get what you want, but you'll have to use XPtr, then on the R side write a reference class and methods which make the object behave like a numeric vector. No copying necessary. Krzysztof ___ 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] Setting the R random seed from Rcpp
On Jun 7, 2013 12:12 PM, Dirk Eddelbuettel e...@debian.org wrote: Maybe what you want is more easily done with the RNGs from C++ (esp C++11), Boost, ... or something different from R. It may work, but we are (currently) simply not set up for it. If you go with something different from R, I've had good luck with Tina's RNG. (TRNG) It's a fairly complete, fast, and easy to use C++ library... there might even be a reason to wrap it for Rcpp someday. Krzysztof The model is to call set.seed(somenumber) from R before going to C++, and being assured that a) you get the same stream in C++ as you would in R as well as b) that you can continue fine in R once you are back. What you want is a little different. It may well be supported, but maybe just not (yet ?) by us. Or it may not be supported. Please keep working at it, this would be useful to sort this out. Just because you can get the integer seed via R from C++ does yet mean that the generator is a sane state. Just saying... 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 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] Returning Armadillo matrices with dimnames
On May 2, 2013 11:22 PM, Dirk Eddelbuettel e...@debian.org wrote: On 2 May 2013 at 17:24, Dirk Eddelbuettel wrote: | Sorry. It was just a quick guess. | | On second thought, I think your earlier approach was actually pretty good: | Take your arma object, use wrap to turn it into a SEXP (or maybe an RObject) | and you should then be able to set attributes. And on third thought, I think we both overlooked one aspect: -- R and Rcpp can share objects, passing them back and forth efficiently via pointers as _both use the same allocation scheme_. So when Rcpp creates an object, it is as if R created it. Which is why we can generally move them back and forth. -- That does not hold for Armadillo. So to bring an Armadillo object back, we are better off making a copy. Depending on the context, you could pre-create both matrices in R and pass them in to Rcpp/Armadillo as Dirk suggests. Manipulate them as necessary and they are available back in R when you are done. Krzysztof So once again the No Free Lunch theorem at work. Sorry. 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 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] Module with vector of a class with inheritance, how to avoid slicing
([[-,vector_Of_father::vec_set) ; } Dr. Girard Robin Chargé de Recherche MINES-ParisTech / Département Energétique et Procédés / PERSEE / Groupe ERSEI Centre Procédés, Energies Renouvelables et Systèmes Energétiques (PERSEE) Center for Processes, Renewables Energies and Energy Systems Renewable Energies Smartgrids (ERSEI) 1 Rue Claude Daunesse - CS 10207 - F-06904 Sophia Antipolis Cedex Tel: +33.4.93.67.89.64 (~99), Fax: +33.4.93.95.75.35 e-mail : robin.gir...@mines-paristech.fr web page perso http://www.mines-paristech.fr/Services/Annuaire/?id=8828 statoverflow : http://stats.stackexchange.com/users/223/robin-girard web page centre PERSEE : http://www.cep.mines-paristech.fr/ linkedin : http://www.linkedin.com/profile/view?id=14907272trk=tab_pro -- Romain Francois Professional R Enthusiast +33(0) 6 28 91 30 30 R Graph Gallery: http://gallery.r-enthusiasts.com blog:http://blog.r-enthusiasts.com |- http://bit.ly/ZTFLDo : Simpler R help tooltips `- http://bit.ly/YFsziW : R Help tooltips ___ 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 mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel -- Krzysztof Sakrejda-Leavitt Organismic and Evolutionary Biology University of Massachusetts, Amherst 319 Morrill Science Center South 611 N. Pleasant Street Amherst, MA 01003 work #: 413-325-6555 email: sakre...@cns.umass.edu --- ___ 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
