On 18 November 2012 at 15:25, Thell Fowler wrote:
| Is there some kind of a stance against 'auto'?
For the CRAN gatekeepers, '-std=c++0x' and '-std=c++11' are considered
non-portable. We simply have to wait til this becomes a) the g++ default
and b) that that g++ version because the default inst
On 18 November 2012 at 15:04, Thell Fowler wrote:
| When you say we get the whole SEXP and can 'access' it, that doesn't mean we
| can setup a template type against it for 'wrap' and 'as' though; right? If
| so, can you think of a reference for me?
Generally speaking you template on types the co
On 18 November 2012 at 21:17, Romain Francois wrote:
| You don't need to wrap an "Rcpp::S4", as these are already R objects, so
| an implicit conversion to SEXP already exists.
|
| Same here:
|
| vS4.slot("exp") = wrap( exp );
|
| you don't need this wrap, you should be able to just use:
|
|
On Sun, Nov 18, 2012 at 2:17 PM, Romain Francois
wrote:
> Hello,
>
> You don't need to wrap an "Rcpp::S4", as these are already R objects, so
> an implicit conversion to SEXP already exists.
>
> Same here:
>
>
> vS4.slot("exp") = wrap( exp );
>
> you don't need this wrap, you should be able to jus
-- Forwarded message --
From: Thell Fowler
Date: Sun, Nov 18, 2012 at 3:03 PM
Subject: Re: [Rcpp-devel] Rcpp RMpfr mpreal to mpfr wrapping
To: Dirk Eddelbuettel
On Sun, Nov 18, 2012 at 1:59 PM, Dirk Eddelbuettel wrote:
>
> Hi Thell,
>
> On 18 November 2012 at 13:03, Thell F
Hello,
You don't need to wrap an "Rcpp::S4", as these are already R objects, so
an implicit conversion to SEXP already exists.
Same here:
vS4.slot("exp") = wrap( exp );
you don't need this wrap, you should be able to just use:
vS4.slot("exp") = exp ;
for the same reason, exp is already an
Hi Thell,
On 18 November 2012 at 13:03, Thell Fowler wrote:
| Hi all.
|
| I've been doing some testing on how to get arbitrary precision numbers out of
| c++ and into R. The following example inline Rcpp code generates an RcppMpfr
| cxxfunction plugin for wrapping to the Rmpfr S4 "mpfr1" objec
Forgot to mention I don't have access to 64bit at the moment, so that
hasn't been tested at all, and just the 32bit stuff has been played with.
___
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/
Hi all.
I've been doing some testing on how to get arbitrary precision numbers out
of c++ and into R. The following example inline Rcpp code generates an
RcppMpfr cxxfunction plugin for wrapping to the Rmpfr S4 "mpfr1"
object. There are local include paths that need adjusting (for now) to
your
>> recycle(x, y, z);
>>
>> Hadley
>
>
> In a way, we can already use sugar rep_len.
>
> rep_len( x, 30 )
>
> will recycle x into a vector of length 30, lazily.
Agreed, but a helper function would automate this process:
int length = max(x.length(), y.length(), z.length())
# check integer multiples
Le 18/11/12 15:35, Hadley Wickham a écrit :
On Sat, Nov 17, 2012 at 9:23 AM, Romain Francois
wrote:
Le 17/11/12 15:22, Hadley Wickham a écrit :
Hi all,
Am I doing something wrong with the functions below, or has this
behaviour not yet been implemented in Rcpp?
cppFunction('std::string
Le 18/11/12 16:12, Hadley Wickham a écrit :
microbenchmark(
pdist1(0.5, ys),
pdist2(0.5, ys),
pdist3(0.5, ys)
)
# 10-fold slower?? Maybe it's because I'm using a double instead of
# a numeric vector?
That's weird. Not sure where the ineffiency is. Some hunting.
My guess is that sug
>> microbenchmark(
>>pdist1(0.5, ys),
>>pdist2(0.5, ys),
>>pdist3(0.5, ys)
>> )
>> # 10-fold slower?? Maybe it's because I'm using a double instead of
>> # a numeric vector?
>
> That's weird. Not sure where the ineffiency is. Some hunting.
> My guess is that sugar pow needs a refresh.
On Sat, Nov 17, 2012 at 9:23 AM, Romain Francois
wrote:
> Le 17/11/12 15:22, Hadley Wickham a écrit :
>>
>> Hi all,
>>
>> Am I doing something wrong with the functions below, or has this
>> behaviour not yet been implemented in Rcpp?
>>
>> cppFunction('std::string first_char(const CharacterVe
14 matches
Mail list logo
