search for: iterate_by_region

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); * \ if (px != NULL) { \ R_xlen_t __ibr_n__ = strt + nfull;...

...ally your methods for Dataptr_or_null shouldn't allocate, but you also should not write code that relies on hard assumptions that no one's ever will. Also, a small nitpick, R's internal mean function doesn't hit Dataptr, it hits either INTEGER_ELT (which really should probably be a ITERATE_BY_REGION) or ITERATE_BY_REGION. Anyway, I hope that helps. ~G On Mon, Sep 23, 2019 at 6:12 PM Bob Rudis <bob at rud.is> wrote: > 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...

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

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) ITERATE_BY_REGION calls? # script to demonstrate performance difference if x is an OBJECT or not by using unclass() x.posixct = Sys.time()...

...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, \ strt, nfull, expr) do { \ *const etype *px = (const** etype *)DATAPTR_OR_NULL(sx); * \ if (px != NULL) { \ R_xlen_t __ibr_n__ = strt + nfull;...

...019, 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 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); * \ > > if (px != NULL) { \ > >...

...on Wed, 1 May 2019 03:20:55 -0400 writes: > 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) ITERATE_BY_REGION calls? "necessary ?" : yes, in the following sense : When it was introduced, the idea of a...

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

...EGER! */ SORTED_INCR = 1, SORTED_INCR_NA_1ST = 2, KNOWN_UNSORTED = 0}; The macro names are pretty self-explanatory. The current implementation only supports the ascending sort. 2. For anyNA, it goes to(Real SEXP) ===========coerce.c=========== if(REAL_NO_NA(x)) return FALSE; ITERATE_BY_REGION(x, xD, i, nbatch, double, REAL, { for (int k = 0; k < nbatch; k++) if (ISNAN(xD[k])) return TRUE; }); ===========altrep.c=========== int REAL_NO_NA(SEXP x) { return ALTREP(x) ? ALTREAL_DISPATCH(No_NA, x) : 0; } If the argument x is not an ALTREP, the function will return 0, and a def...

...ose, the ALTREP > being specifically designed to refuse to give you a full DATAPTR), but with > ALTREP in place its no longer what you want to do. > > That said, you don't want to check whether something is an ALTREP yourself > and branch your code, what you want to do is use the ITERATE_BY_REGION > macro in R_ext/Itermacros.h for ALL SEXPs, which will be nearly as for > standard vectors and work safely for ALTREP vectors. > > Basically any time you find yourself wanting to check if something is an > ALTREP and if so, call a specific ALT*_BLAH method, the intention is that &gt...

thanks for clearing that up, so these methods are actually not meant to be exported on Windows and OSX? Some of the ALTREP methods that now use 'attribute_hidden' would be very useful to packages that aim to be ALTREP aware, should the currently (exported) API be considered final? thanks for your time & best, Mark On Tue, Jun 4, 2019 at 6:52 PM Tierney, Luke <luke-tierney at

Hi Martin, Henrik, Thanks for the follow up. @Martin: I vote for 2) without *any* hesitation :-) (and uniformity could be restored at some point in the future by having prod(), rowSums(), colSums(), and others align with the behavior of length() and sum()) Cheers, H. On 01/27/2018 03:06 AM, Martin Maechler wrote: >>>>>> Henrik Bengtsson <henrik.bengtsson at gmail.com>

...tion failure or, I suppose, the ALTREP being specifically designed to refuse to give you a full DATAPTR), but with ALTREP in place its no longer what you want to do. That said, you don't want to check whether something is an ALTREP yourself and branch your code, what you want to do is use the ITERATE_BY_REGION macro in R_ext/Itermacros.h for ALL SEXPs, which will be nearly as for standard vectors and work safely for ALTREP vectors. Basically any time you find yourself wanting to check if something is an ALTREP and if so, call a specific ALT*_BLAH method, the intention is that there should be a universal...

...> being specifically designed to refuse to give you a full DATAPTR), but with >> ALTREP in place its no longer what you want to do. >> >> That said, you don't want to check whether something is an ALTREP yourself >> and branch your code, what you want to do is use the ITERATE_BY_REGION >> macro in R_ext/Itermacros.h for ALL SEXPs, which will be nearly as for >> standard vectors and work safely for ALTREP vectors. >> >> Basically any time you find yourself wanting to check if something is an >> ALTREP and if so, call a specific ALT*_BLAH method, the i...

...y *are* correct))) you get 9*10^18 which is only slightly smaller than 2^63 - 1 which may be the maximal "LONG_INT" integer we have. So, in the end, at least for now, we do not quite go all they way but overflow a bit earlier,... but do potentially gain a bit of speed, notably with the ITERATE_BY_REGION(..) macros (which I did not show above). Will hopefully become available in R-devel real soon now. Martin > Cheers, > H. > On 01/27/2018 03:06 AM, Martin Maechler wrote: >>>>>>> Henrik Bengtsson <henrik.bengtsson at gmail.com> >>&gt...