search for: r_altrep_data1

...ut I did not find any explanation of it. Could you please give some detail on it? 2. > The first one correctly returns its internal data structure, but the second > one returns the ALTREP object it wraps since the wrapper itself is an > ALTREP. This behavior is unexpected. I disagree. R_altrep_data1 returns whatever THAT altrep SEXP stores in its > "data1" part. There is no recursion/descent going on, and there shouldn't > be. This is might be a bug since in R release 3.6 it will return the ALTREP instead of the data of the ALTREP. I'm not sure if it has been fixed in...

...Does that make sense? Best, ~G > > 2. > >> The first one correctly returns its internal data structure, but the >> second >> one returns the ALTREP object it wraps since the wrapper itself is an >> ALTREP. This behavior is unexpected. > > > I disagree. R_altrep_data1 returns whatever THAT altrep SEXP stores in its >> "data1" part. There is no recursion/descent going on, and there shouldn't >> be. > > > This is might be a bug since in R release 3.6 it will return the ALTREP > instead of the data of the ALTREP. I'm not su...

...48,no_na=0] > @0x00000000156f4d18 14 REALSXP g0c0 [NAM(7)] It seems like the object alt2 automatically gets wrapped by R. Although at the R level it seems fine because there are no differences between alt1 and alt2, if we define a C function as: SEXP C_peekSharedMemory(SEXP x) { > return(R_altrep_data1(x)); } and call it in R to get the internal data structure of an ALTREP object. C_peekSharedMemory(alt1) > C_peekSharedMemory(alt2) The first one correctly returns its internal data structure, but the second one returns the ALTREP object it wraps since the wrapper itself is an ALTREP. This...

...39;,' from when as.character was called. Note that the behavior is different with the 'scipen' option: The deferred_string object records the scipen=-5 value when as.character is called, and uses this value when xx is printed. Looking at the deferred_string object, it appears that CDR(R_altrep_data1(<obj>)) is set to a scalar integer containing the scipen value at the time the deferred_string was created. Ideally, the deferred_string object would save both the scipen and OutDec option values. I'd suggest saving these values as regular pairlist values, say by setting the data1 field...

...define a C function as: > So I'm not sure what is happening here, because it depends on what your createAltrep function does. R automatically creates wrappers in some cases but not nearly all (or even very many currently) cases. > > SEXP C_peekSharedMemory(SEXP x) { > > return(R_altrep_data1(x)); > > } > > > and call it in R to get the internal data structure of an ALTREP object. > > C_peekSharedMemory(alt1) > > C_peekSharedMemory(alt2) > > > The first one correctly returns its internal data structure, but the second > one returns the ALTREP objec...

...aracter was called. > > Note that the behavior is different with the 'scipen' option: The > deferred_string object records the scipen=-5 value when as.character > is called, and uses this value when xx is printed.? Looking at the > deferred_string object, it appears that CDR(R_altrep_data1(<obj>)) is > set to a scalar integer containing the scipen value at the time the > deferred_string was created. > > Ideally, the deferred_string object would save both the scipen and > OutDec option values.? I'd suggest saving these values as regular > pairlist values,...

Hi Kylie, Is it a list with only numerics in it? (I only see REALSXPs there, but obviously inspect isn't showing all of them). If so, you could load it up into one big vector and then also keep partitioning information around. Bioconductor does this (see ?IRanges::CompressedList ). The potential benefit here being that the underlying large vector could then be a big out-of-memory altrep. How