similar to: Bug report with patch: `stats:::regularize.values()` always creates full copies of `x` and `y`

This is intended to be a bug report with proposed patch. I am posting to this mailing list as described in NOTE in "Bug Reporting in R". Function `stats:::regularize.values()` is meant to preprocess `x` and `y` arguments to have "proper" values for later use during interpolation. If input is already "proper", I would expect it to reuse the same objects without

Hi Kylie, As an alternative in the short term, you could consider deriving from S4Vector's List class, implementing the getListElement() method to lazily create the objects. Michael On Tue, Jul 23, 2019 at 9:09 AM Bemis, Kylie <k.bemis at northeastern.edu> wrote: > > Hello, > > I was wondering if there were any plans for ALTREP lists (VECSXP)? > > It seems to me that

If one of you wanted to try to create a patch to support ALTREP generic vectors here are some notes: The main challenge I am aware of (there might be others): Allowing DATAPTR to return a writable pointer would be too dangerous because the GC write barrier needs to see all mutations. So it would be best if Dataptr and Dataptr_or_null methods were not allowed to be defined. The default methods in

Hello, I was wondering if there were any plans for ALTREP lists (VECSXP)? It seems to me that they could be supported in a similar way to how ALTSTRING works, with Elt() and Set_elt() methods, or would there be some problems with that I?m not seeing due to lists not being atomic vectors? I was taking an approach of converting each list element (of a file-based list data structure) to an ALTREP

I can work on this. Thanks Luke. ~G On Wed, Jul 24, 2019 at 8:25 AM Tierney, Luke <luke-tierney at uiowa.edu> wrote: > If one of you wanted to try to create a patch to support ALTREP > generic vectors here are some notes: > > The main challenge I am aware of (there might be others): Allowing > DATAPTR to return a writable pointer would be too dangerous because > the GC

Hello, Doing typeof() on an object appears to reset the "named" field in its sxpinfo header to 2, which can change the way that subsequent subassignment operations are carried out: X <- 1:5e7 .Internal(inspect(X)) # @4eeb0008 13 INTSXP g0c7 [NAM(1)] (len=50000000, tl=0) 1,2,3,4,5,... system.time(X[1] <- 9L) # user system elapsed # 0 0 0 typeof(X)

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

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]

On Fri, 5 Aug 2016, Winston Chang wrote: > My understanding is that R will not make copies of lists if there is > only one reference to the object. However, I've encountered a case > where R does make copies, even though (I think) there should be only > one reference to the object. I hope that someone could shed some light > on why this is happening. > > I'll start

Hi all, The coercion function defined for the ALTREP object will not be called by R when an assignment operation implicitly introduces coercion for a large ALTREP object. For example, If I create a vector of length 10, the ALTREP coercion function seems to work fine. ``` > x <- 1:10 > y <- wrap_altrep(x) > .Internal(inspect(y)) @0x000000001f9271c0 13 INTSXP g0c0 [REF(2)] I am

Hi It seems that selecting an element of a factor will copy its levels (Ubuntu 13.04, R 3.0.2). Below is the output of a script that creates a factor with 10000 elements and then calls as.list() on it. The new object seems to use more than 700 MB, and inspection of the levels of the individual elements of the list suggest that they are distinct objects. Perhaps some performance gain could

Hi Gabriel, here is a simple package for reproducing the problem. https://github.com/Jiefei-Wang/testPkg Best, Jiefei On Thu, Oct 8, 2020 at 5:04 AM Gabriel Becker <gabembecker at gmail.com> wrote: > Jiefei, > > Where does the code for your altrep class live? > > Thanks, > ~G > > On Wed, Oct 7, 2020 at 4:25 AM Jiefei Wang <szwjf08 at gmail.com> wrote: >

Jiefei, Where does the code for your altrep class live? Thanks, ~G On Wed, Oct 7, 2020 at 4:25 AM Jiefei Wang <szwjf08 at gmail.com> wrote: > Hi all, > > The coercion function defined for the ALTREP object will not be called by R > when an assignment operation implicitly introduces coercion for a large > ALTREP object. > > For example, If I create a vector of length

Hi, I would like to know if it's ok to use .Internal(inspect(x)) in order to detect vector copying. Take for example the following silly code: f <- function() { x = seq(10) print(.Internal(inspect(x))) for(i in seq(10)) { x[i] <- x[i] + 1 print(.Internal(inspect(x))) } } The output of f() was: @bd7acf0 13 INTSXP g0c4 [NAM(1)] (len=10, tl=0) 1,2,3,4,5,... [1] 1 2

Hi Kylie, For your question, I don't think a wrapper can completely solve your problem. The duplication occurs since your variable y has more than 1 reference number( Please see highlighted), so even you have a wrapper, any changes on the value of the wrapper still can trigger the duplication. > .Internal(inspect(y)) > @7fb0ce78c0f0 13 INTSXP g0c0 *[NAM(7)]* matter vector (mode=3,

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

I ran into strange behavior when removing names. Two ways of removing names: i <- rep(1:4, length.out=20000) k <- c(a=1, b=2, c=3, d=4) x1 <- unname(k[i]) x2 <- k[i] x2 <- unname(x2) Are they identical? identical(x1,x2) # TRUE but no identical(serialize(x1,NULL),serialize(x2,NULL)) # FALSE But problem is with serialization type 3, cause:

>>>>> Travers Ching >>>>> on Tue, 15 Jan 2019 12:50:45 -0800 writes: > I have a toy alt-rep string package that generates > randomly seeded strings. example: library(altstringisode) > x <- altrandomStrings(1e8) head(x) [1] > "2PN0bdwPY7CA8M06zVKEkhHgZVgtV1" > "5PN2qmWqBlQ9wQj99nsQzldVI5ZuGX" ... etc

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

I think that object.size() is most commonly used to answer the question, "what R objects are consuming the most memory currently in my R session?" and for that reason I think returning the size of the internal representations of objects (for e.g. ALTREP objects; unevaluated promises) is the right default behavior. I also agree it would be worth considering adding arguments that control