search for: sortedness

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 the vector, so R will loop over the vector and find the answer. However, what should we return in these functions to indicate w...

...n. 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 have a binary answer for NO_NA (since the return value is actually bool). For making the code more readable, and for possibly working with the future R release, is it possible to define a macro for NO_NA function in RInternal.h? So if there is any change in NO_NA func...

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

...e, which is an R level function that calls down to .Internal(wrap_meta(...)), which you can use, but it doesn't look general enough for what I think you need (it was written for things that have just been sorted, thus the name). Specifically, its not able to indicate that things are of unknown sortedness as currently written. If matter vectors are guaranteed to be sorted for some reason, though, you can use this. I'll talk to Luke about whether we want to generalize this, it would be easy to have this support the full space of metadata for wrappers and be a general purpose wrapper-maker, but t...

In the code of functions 'order' and 'sort.list' in R 3.5.0 alpha (in https://svn.r-project.org/R/branches/R-3-5-branch/src/library/base/R/sort.R), in "fastpass, take advantage of ALTREP metadata", there is "try the reverse since that's easy too...". If it succeeds, ties are reordered, violating stability of sorting. Example: x <- sort(c(1, 1, 3)) x # 1

...Most ALTREP objects do not > have wrappers. See, e.g., > > > .Internal(inspect(1:4)) > > @7fb727d6be50 13 INTSXP g0c0 [NAM(3)] 1 : 4 (compact) > > > That's an ALTREP with no wrapper (a compact sequence). The wrapper ALTREP > class is for attaching metadata (known sortedness, known lack of NAs) to R > vectors. Its primary use currently is on the return value of sort(). > > >> This makes the problem even more >> difficult since we cannot predict when would the wrapper appear. >> > > As currently factored, its not intended that you would...

...fundamental aspect of ALTREPs themselves. Most ALTREP objects do not have wrappers. See, e.g., > .Internal(inspect(1:4)) @7fb727d6be50 13 INTSXP g0c0 [NAM(3)] 1 : 4 (compact) That's an ALTREP with no wrapper (a compact sequence). The wrapper ALTREP class is for attaching metadata (known sortedness, known lack of NAs) to R vectors. Its primary use currently is on the return value of sort(). > This makes the problem even more > difficult since we cannot predict when would the wrapper appear. > As currently factored, its not intended that you would be or need to predict when a wrapp...

Hello, I have encountered two bugs when using ALTREP APIs. 1. STDVEC_DATAPTR >From RInternal.h file it has a comment: /* ALTREP support */ > void *(STDVEC_DATAPTR)(SEXP x); However, this comment might not be true, the easiest way to verify it is to define a C++ function: void C_testFunc(SEXP a) > { > STDVEC_DATAPTR(a); > } and call it in R via > a=1:10 > >

...have wrappers. See, e.g., >> >> > .Internal(inspect(1:4)) >> >> @7fb727d6be50 13 INTSXP g0c0 [NAM(3)] 1 : 4 (compact) >> >> >> That's an ALTREP with no wrapper (a compact sequence). The wrapper ALTREP >> class is for attaching metadata (known sortedness, known lack of NAs) to R >> vectors. Its primary use currently is on the return value of sort(). >> >> >>> This makes the problem even more >>> difficult since we cannot predict when would the wrapper appear. >>> >> >> As currently factored,...

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)

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

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