similar to: Unexpected behavior when using macro to loop over vector

On 10/25/19 11:01 AM, Tomas Kalibera wrote: > On 10/23/19 6:45 AM, Wang Jiefei wrote: >> Hi all, >> >> I found an unexpected behavior when I was trying to use the macro >> defined >> in "R_ext/Itermacros.h"? to loop over an atomic vector. Here is a >> minimum >> example: >> >> C++ code >> ``` >> #include

Sorry for post a lot of things, for the first part of code, I copied my C++ iter macro by mistake(and you can see an explicit type casting). Here is the macro definition from R_exts/Itermacros.h #define ITERATE_BY_REGION_PARTIAL(sx, px, idx, nb, etype, vtype, \ strt, nfull, expr) do { \ * const** etype *px = DATAPTR_OR_NULL(sx); *

Hi devel team, I'm working on C/C++ level ALTREP compatibility for a package. The package previously used pointers to access the data of a SEXP, so it would not work for some ALTREP objects which do not have a pointer. I plan to rewrite the code and use functions like get_elt, get_region, and get_subset to access the values of a vector, so I have a few questions for ALTREP: 1. Since an

Hi Bob, Thanks for sending around the link to that. It looks mostly right and looks like a useful onramp. There are a few things to watch out for though (I've cc'ed Romain so he's aware of these comments). @romain I hope you taake the following comments as they are intended, as help rather than attacks. The largest issue I see is that the contract for Get_region is that it *populates

On 10/23/19 6:45 AM, Wang Jiefei wrote: > Hi all, > > I found an unexpected behavior when I was trying to use the macro defined > in "R_ext/Itermacros.h" to loop over an atomic vector. Here is a minimum > example: > > C++ code > ``` > #include "R_ext/Itermacros.h" > #define GET_REGION_BUFSIZE 2 > //Redefine the macro since C++ is not happy with

Thank you, Tomas. I appreciate your help. BTW, could you also add an explicit type conversion in " ITERATE_BY_REGION_PARTIAL" macro while you are fixing the bug? C++ compiler does not happy with the implicit conversion from void* to T* somehow and I have to redefine it before using the macro. Best, Jiefei On Fri, Oct 25, 2019 at 11:13 AM Tomas Kalibera <tomas.kalibera at

Not sure if you're using just C++ or Rcpp for C++ access but https://purrple.cat/blog/2018/10/14/altrep-and-cpp/ has some tips on using C++ w/ALTREP. > On Sep 23, 2019, at 3:17 PM, Wang Jiefei <szwjf08 at gmail.com> wrote: > > Sorry for post a lot of things, for the first part of code, I copied my C++ > iter macro by mistake(and you can see an explicit type casting). Here

Hi Gabriel, I have tried the macro and found a small issue, it seems like the macro is written in C and does an implicit type conversion(const void * to const int *), see below. While it is allowed in C, C++ seems not happy with it. Is it possible to add an explicit type casting so that it can be compatible with both language? #define ITERATE_BY_REGION_PARTIAL(sx, px, idx, nb, etype, vtype,

I believe the performance of isUnsorted() in sort.c could be improved by calling REAL() once (outside of the for loop), rather than calling it twice inside the loop. As an aside, it is implemented in the faster way in doSort() (sort.c line 401). The example below shows the performance improvement for a vectors of double of moving REAL() outside the for loop. # example as implemented in

Inside of the anyNA() function, it will use the legacy any(is.na()) code if x is an OBJECT(). If x is a vector of POSIXct, it will be an OBJECT(), but it is also TYPEOF(x) == REALSXP. Therefore, it will skip the faster ITERATE_BY_REGION, which is typically 5x faster in my testing. Is the OBJECT() condition really necessary, or could it be moved after the switch() for the individual TYPEOF(x)

I'm trying to use boot.stepAIC for feature selection; I need to be able to specify the name of the dependent variable programmatically, but this appear to fail: In R-Studio with MS R Open 3.4: library(bootStepAIC) #Fake data n<-200 x1 <- runif(n, -3, 3) x2 <- runif(n, -3, 3) x3 <- runif(n, -3, 3) x4 <- runif(n, -3, 3) x5 <- runif(n, -3, 3) x6 <- runif(n, -3, 3) x7

Until I get a fix that works, a work-around would be to rename the 'y1' column, used a fixed formula, and rename it back afterwards. Thanks for your help. SGO. -----Original Message----- From: Bert Gunter [mailto:bgunter.4567 at gmail.com] Sent: 22 August 2017 20:38 To: Stephen O'hagan <SOhagan at manchester.ac.uk> Cc: r-help at r-project.org Subject: Re: [R] boot.stepAIC

It seems that if you build the formula as a character string, and postpone the "as.formula" into the lm call, it works. instead of frm1 <- as.formula(paste(trg,"~1")) use frm1a <- paste(trg,"~1") and then strt <- lm(as.formula(frm1a),dat) regards, Heinz Stephen O'hagan wrote/hat geschrieben on/am 23.08.2017 12:07: > Until I get a fix that works, a

Is there a missing value constant defined for R_xlen_t, cf. NA_INTEGER (== R_NaInt == INT_MIN) for int(eger)? If not, is it correct to assume that missing values should be taken care/tested for before coercing from int or double? Thank you, Henrik

OK, here's the problem. Continuing with your example: strt1 <- lm(y1 ~1, dat) strt2 <- lm(frm1,dat) > strt1 Call: lm(formula = y1 ~ 1, data = dat) Coefficients: (Intercept) 41.73 > strt2 Call: lm(formula = frm1, data = dat) Coefficients: (Intercept) 41.73 Note that the formula objects of the lm object are different: strt2 does not evaluate the formula. So

Failed? What was the error message? Cheers, Bert Bert Gunter "The trouble with having an open mind is that people keep coming along and sticking things into it." -- Opus (aka Berkeley Breathed in his "Bloom County" comic strip ) On Tue, Aug 22, 2017 at 8:17 AM, Stephen O'hagan <SOhagan at manchester.ac.uk> wrote: > I'm trying to use boot.stepAIC for

The error is "the model fit failed in 50 bootstrap samples Error: non-character argument" Cheers, SOH. On 22/08/2017 17:52, Bert Gunter wrote: > Failed? What was the error message? > > Cheers, > > Bert > > > Bert Gunter > > "The trouble with having an open mind is that people keep coming along > and sticking things into it." > -- Opus (aka

SImplify your call to lm using the "." argument instead of manipulating formulas. > strt <- lm(y1 ~ ., data = dat) and you do not need to explicitly specify the "1+" on the rhs for lm, so > frm2<-as.formula(paste(trg," ~ ", paste(xvars,collapse = "+"))) works fine, too. Anyway, doing this gives (but see end of output)" bst <-

With a recent SVN build (R Under development (unstable) (2013-07-10 r63264) -- "Unsuffered Consequences"), I'm having trouble installing the robustbase package. The bottom line is that I *think* it's a 32-bit-system problem, but I could easily be mistaken. robustbase is passing its package checks: http://cran.r-project.org/web/checks/check_results_robustbase.html ... but from

I'm observing that base::sum(x, na.rm=FALSE) for typeof(x) == "double" is much more time consuming when there are missing values versus when there are not. I'm observing this on both Window and Linux, but it's quite surprising to me. Currently, my main suspect is settings in on how R was built. The second suspect is my brain. I hope that someone can clarify the below