Konrad Siek
2021-Jul-01 10:16 UTC
[Rd] [External] SET_COMPLEX_ELT and SET_RAW_ELT missing from Rinternals.h
Thanks! So what would be the prescribed way of assigning elements to a CPLXSXP if I needed to? One way I see is to do what most of the code inside the interpreter does and grab the vector's data pointer: COMPLEX(sexp)[index] = value; COMPLEX0(sexp)[index] = value; This will materialize an ALTREP CPLXSXP though, so maybe the best way would be to mirror what SET_COMPLEX_ELT does in Rinlinedfuns.h? if (ALTREP(sexp)) ALTCOMPLEX_SET_ELT(sexp, index, value); else COMPLEX0(sexp)[index] = vector; This seems better, but it's not used in the interpreter anywhere as far as I can tell, presumably because of the setter interface not being complete, as you point out. But should I be avoiding this second approach for some reaosn? k On Tue, Jun 29, 2021 at 4:06 AM <luke-tierney at uiowa.edu> wrote:> The setter interface for atomic types is not yer implemented. It may > be some day. > > Best, > > luke > > On Fri, 25 Jun 2021, Konrad Siek wrote: > > > Hello, > > > > I am working on a package that works with various types of R vectors, > > implemented in C. My code has a lot of SET_*_ELT operations in it for > > various types of vectors, including for CPLXSXPs and RAWSXPs. > > > > I noticed SET_COMPLEX_ELT and SET_RAW_ELT are defined in Rinlinedfuns.h > but > > not declared in Rinternals.h, so they cannot be used in packages. I was > > going to re-implement them or extern them in my package, however, > > interestingly, ALTCOMPLEX_SET_ELT and ALTRAW_SET_ELT are both declared > in > > Rinternals.h, making me think SET_COMPLEX_ELT and SET_RAW_ELT could be > > purposefully obscured. Otherwise it may just be an oversight and I should > > bring it to someone's attention anyway. > > > > I have three questions that I hope R-devel could help me with. > > > > 1. Is this an oversight, or are SET_COMPLEX_ELT and SET_RAW_ELT not > exposed > > on purpose? 2. If they are not exposed on purpose, I was wondering why. > > 3. More importantly, what would be good ways to set elements of these > > vectors while playing nice with ALTREP and avoiding whatever pitfalls > > caused these functions to be obscured in the first place? > > > > Best regards, > > Konrad, > > > > [[alternative HTML version deleted]] > > > > ______________________________________________ > > R-devel at r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > -- > Luke Tierney > Ralph E. Wareham Professor of Mathematical Sciences > University of Iowa Phone: 319-335-3386 > Department of Statistics and Fax: 319-335-3017 > Actuarial Science > 241 Schaeffer Hall email: luke-tierney at uiowa.edu > Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu >[[alternative HTML version deleted]]
iuke-tier@ey m@iii@g oii uiow@@edu
2021-Jul-03 00:37 UTC
[Rd] [External] SET_COMPLEX_ELT and SET_RAW_ELT missing from Rinternals.h
On Thu, 1 Jul 2021, Konrad Siek wrote:> Thanks! > > So what would be the prescribed way of assigning elements to a CPLXSXP if I > needed to?The first question is whether you need to do this. Or, more to the point, whether it is safe to do this. In R objects should behave as if they are not mutable. Mutation in C code may be OK if the objects are not reachable from any R variables, but that almost always means they are private to your code so yo can use what you know about internal structure. If it is legitimate to mutate you can use SET_COMPLEX_ELT. I've added the declaration to Rinternals in R-devel and R-patched. For SET_COMPLEX_ELT(x, in v) is equivalent to COMPLEX(sexp)[index] = value, but that could change in the future it Set methods are supported. This does materialize a potentially compact object, but again the most important question is whether mutation is legitimate at all.> One way I see is to do what most of the code inside the interpreter does and > grab the vector's data pointer: > > ??? COMPLEX(sexp)[index] = value; > ??? COMPLEX0(sexp)[index] = value; >COMPLEX0 is not in the API; it will probably be removed from the installed header files as we clean these up.> This will materialize an ALTREP CPLXSXP though, so maybe the best way would > be to mirror what SET_COMPLEX_ELT does in Rinlinedfuns.h? > > ??? if (ALTREP(sexp)) ALTCOMPLEX_SET_ELT(sexp, index, value); else > COMPLEX0(sexp)[index] = vector;ALTCOMPLEX_SET_ELT is an internal implementation feature and not in the API. Again, it will probably be removed from the installed headers. Best, luke> This seems better, but it's not used in the interpreter anywhere as far as I > can tell, presumably because of the setter interface not being complete, as > you point out. But should I be avoiding this second approach for some > reaosn? > > k > > On Tue, Jun 29, 2021 at 4:06 AM <luke-tierney at uiowa.edu> wrote: > The setter interface for atomic types is not yer implemented. It > may > be some day. > > Best, > > luke > > On Fri, 25 Jun 2021, Konrad Siek wrote: > > > Hello, > > > > I am working on a package that works with various types of R > vectors, > > implemented in C. My code has a lot of SET_*_ELT operations in > it for > > various types of vectors, including for CPLXSXPs and RAWSXPs. > > > > I noticed SET_COMPLEX_ELT and SET_RAW_ELT are defined in > Rinlinedfuns.h but > > not declared in Rinternals.h, so they cannot be used in > packages. I was > > going to re-implement them or extern them in my package, > however, > > interestingly, ALTCOMPLEX_SET_ELT and ALTRAW_SET_ELT? are both > declared in > > Rinternals.h, making me think SET_COMPLEX_ELT and SET_RAW_ELT > could be > > purposefully obscured. Otherwise it may just be an oversight > and I should > > bring it to someone's attention anyway. > > > > I have three questions that I hope R-devel could help me with. > > > > 1. Is this an oversight, or are SET_COMPLEX_ELT and > SET_RAW_ELT not exposed > > on purpose? 2. If they are not exposed on purpose, I was > wondering why. > > 3. More importantly, what would be good ways to set elements > of these > > vectors while playing nice with ALTREP and avoiding whatever > pitfalls > > caused these functions to be obscured in the first place? > > > > Best regards, > > Konrad, > > > >? ? ? ?[[alternative HTML version deleted]] > > > > ______________________________________________ > > R-devel at r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > -- > Luke Tierney > Ralph E. Wareham Professor of Mathematical Sciences > University of Iowa? ? ? ? ? ? ? ? ? Phone:? ? ? ? ? ? > ?319-335-3386 > Department of Statistics and? ? ? ? Fax:? ? ? ? ? ? ? > ?319-335-3017 > ? ? Actuarial Science > 241 Schaeffer Hall? ? ? ? ? ? ? ? ? email:? > ?luke-tierney at uiowa.edu > Iowa City, IA 52242? ? ? ? ? ? ? ? ?WWW:? > http://www.stat.uiowa.edu > > >-- Luke Tierney Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics and Fax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: luke-tierney at uiowa.edu Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu