similar to: [ALTREP] What is the meaning of the return value of Is_sorted and No_NA function?

Hi Jiefei, The meanings of the return values for sortedness can be found in RInternals.h, and are as follows: /* ALTREP sorting support */ enum {SORTED_DECR_NA_1ST = -2, SORTED_DECR = -1, UNKNOWN_SORTEDNESS = INT_MIN, /*INT_MIN is NA_INTEGER! */ SORTED_INCR = 1, SORTED_INCR_NA_1ST = 2, KNOWN_UNSORTED = 0}; The default value there is NA_INTEGER (ie INT_MIN),

Hi Gabriel, Thanks for your answer and future update plan. Somehow this email has been delayed for a week, so there might be a wired reply from me saying that I have found the answer from the R source code, it was sent from me last week. Hopefully, this reply will not cost another week to post:) As a side note, I like the idea that defining a macro for sortedness, and I can see why we can only

Hi, I would like to figure out the meaning of the return value of these two functions. Here are the default definitions I find from R source code: static int altreal_Is_sorted_default(SEXP x) { return UNKNOWN_SORTEDNESS; } static int altreal_No_NA_default(SEXP x) { return 0; } I guess the macro *UNKNOWN_SORTEDNESS *in *Is_sorted* and 0 in *No_NA *simply means unknown sorted/NA status of

>>>>> Harvey Smith >>>>> 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

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)

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,

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 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

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 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 the implicit type conversion #define ITERATE_BY_REGION_PARTIAL(sx, px, idx, nb, etype,

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

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

I have hit a problem with the design of the mcmc package I can't figure out, possibly because I don't really understand the R function call mechanism. The function metrop in the mcmc package has a ... argument that it passes to one or two user-supplied functions, which are other arguments to metrop. When the two functions don't have the same arguments, this doesn't work.

Jiefei, Inline. On Thu, May 16, 2019 at 2:30 PM ??? <szwjf08 at gmail.com> wrote: > Hello Luke and Gabriel, > > Thank you very much for your quick responses. The explanation of STDVEC is > very helpful and I appreciate it! For the wrapper, I have a few new > questions. > > > 1. Like Luke said a mutable object is not possible. However, I noticed > that there is

Hi Mark, So depending pretty strongly on what you mean by "ALTREP aware", packages aren't necessarily supposed to be ALTREP aware. What I mean by this is that as of right now, ALTREP objects are designed to be interacted with by non-ALTREP-implementing package code, *more-or-less *exactly as standard (non-AR) SEXPs are: via the published C API. The more or less comes from the fact

Hello Luke and Gabriel, Thank you very much for your quick responses. The explanation of STDVEC is very helpful and I appreciate it! For the wrapper, I have a few new questions. 1. Like Luke said a mutable object is not possible. However, I noticed that there is one extra argument *deep* in the function duplicate. I've googled all the available documentation for ALTREP but I did not find

Very interesting: > .Internal(inspect(k[i])) @10a4bc000 14 REALSXP g0c7 [ATT] (len=20000, tl=0) 1,2,3,4,1,... ATTRIB: @7fa24f07fa58 02 LISTSXP g0c0 [REF(1)] TAG: @7fa24b803e90 01 SYMSXP g0c0 [MARK,REF(5814),LCK,gp=0x6000] "names" (has value) @10a4e4000 16 STRSXP g0c7 [REF(1)] (len=20000, tl=0) @7fa24ba575c8 09 CHARSXP g0c1 [MARK,REF(35005),gp=0x61] [ASCII] [cached]

Hello, I?m experimenting with ALTREP and was wondering if there is a preferred way to create an ALTREP wrapper vector without using .Internal(wrap_meta(?)), which R CMD check doesn?t like since it uses an .Internal() function. I was trying to create a factor that used an ALTREP integer, but attempting to set the class and levels attributes always ended up duplicating and materializing the

Hi Jiefei, Thanks for tryingout the ALTREP stuff and letting us know how it is going. That said I don't think either of these are bugs, per se, but rather a misunderstanding of the API. Details inline. On Thu, May 16, 2019 at 11:57 AM ??? <szwjf08 at gmail.com> wrote: > Hello, > > I have encountered two bugs when using ALTREP APIs. > > 1. STDVEC_DATAPTR > > From