Re: Write Barrier: was: [Rd] function-like macros undefined
On Mar 16, 2005, at 1:34 PM, Vadim Ogranovich wrote: * suppose that inside a C function I have a SEXP vector x of integers and I want to increment each element by one. I understand that Please correct me if I'm wrong, but I thought that the write barrier applies to assignments of SEXP values only (from the doc: ... must be used for all assignments of SEXP pointers ... - note it says of, not to). When dealing with REAL/INTEGER, I believe it's still safe to use INTEGER(x)[0]=... IMHO that's logical, too, because primitive types have no 'age' to be inherited when using ggc. Cheers, Simon __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: Write Barrier: was: [Rd] function-like macros undefined
Your original question was about macro-like functions. INTEGER is available to internal R code as a macro; it is also available as a function. Code in packages that uses standard hearders will see the function, which is declared as int *(INTEGER)(SEXP x); I have no idea why you wanted to check whether INTEGER is a macro or not. The value returned is a pointer to the raw int data which you can (ab)use like any other such pointer. On Wed, 16 Mar 2005, Vadim Ogranovich wrote: Hi, Thank you to Duncan Murdoch for pointing to http://www.stat.uiowa.edu/~luke/R/barrier.html. I have a couple of questions in this regard: * suppose that inside a C function I have a SEXP vector x of integers and I want to increment each element by one. I understand that int * xIPtr = INTEGER(x); int i; for (i=0; iLENGTH(x); ++i) SET_VECTOR_ELT(x, i, xIPtr[i]+1); The declaration of SET_VECTOR_ELT is SEXP (SET_VECTOR_ELT)(SEXP x, int i, SEXP v); Your compiler had better complain about your third argument. is the recommended way of doing it. However it seems that only the very first call to SET_VECTOR_ELT, i.e. the one that corresponds to i=0, is strictly necessary. For example, and this is my question, the following should be perfectly safe: SET_VECTOR_ELT(x, 0, xIPtr[0]); for (i=0; iLENGTH(x); ++i) ++xIPtr[i]; Admittedly this looks a bit odd and breaks if LENGTH(x) is zero, but it illustrates the point. * Now, if the above variation is safe, maybe there is a macro that simply marks atomic SEXP-s, i.g. integers and doubles, for modification? Vectors of non-SEXP objects are not a problem--that is why REAL, INTEGER, etc are available as functions to access the raw data pointers. Only vectors of SEXP's (i.e. generic and character vector objects) need to go through the write barrier. * The Write Barrier document has a section Changing the Representation of String Vectors. Is this something which is in works, or planned, for future versions? It would be great if it were, this should give R considerable speed boost. This was considered at the time but is not on the table now. luke -- Luke Tierney Chair, Statistics and Actuarial Science Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: [EMAIL PROTECTED] Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
RE: Write Barrier: was: [Rd] function-like macros undefined
Luke, My actual problem was with the RAW() macro, it is not available as a function. I used INTEGER as an illustration because it was in the same group of macros, I guess I shouldn't have. Thank you for your other comments. I was confused, somehow I thought that in 2.0.x ALL access, even to the atomic vectors, should be done via macros/functions. Thanks, Vadim -Original Message- From: Luke Tierney [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 16, 2005 11:08 AM To: Vadim Ogranovich Cc: r-devel@stat.math.ethz.ch Subject: Re: Write Barrier: was: [Rd] function-like macros undefined Your original question was about macro-like functions. INTEGER is available to internal R code as a macro; it is also available as a function. Code in packages that uses standard hearders will see the function, which is declared as int *(INTEGER)(SEXP x); I have no idea why you wanted to check whether INTEGER is a macro or not. The value returned is a pointer to the raw int data which you can (ab)use like any other such pointer. On Wed, 16 Mar 2005, Vadim Ogranovich wrote: Hi, Thank you to Duncan Murdoch for pointing to http://www.stat.uiowa.edu/~luke/R/barrier.html. I have a couple of questions in this regard: * suppose that inside a C function I have a SEXP vector x of integers and I want to increment each element by one. I understand that int * xIPtr = INTEGER(x); int i; for (i=0; iLENGTH(x); ++i) SET_VECTOR_ELT(x, i, xIPtr[i]+1); The declaration of SET_VECTOR_ELT is SEXP (SET_VECTOR_ELT)(SEXP x, int i, SEXP v); Your compiler had better complain about your third argument. is the recommended way of doing it. However it seems that only the very first call to SET_VECTOR_ELT, i.e. the one that corresponds to i=0, is strictly necessary. For example, and this is my question, the following should be perfectly safe: SET_VECTOR_ELT(x, 0, xIPtr[0]); for (i=0; iLENGTH(x); ++i) ++xIPtr[i]; Admittedly this looks a bit odd and breaks if LENGTH(x) is zero, but it illustrates the point. * Now, if the above variation is safe, maybe there is a macro that simply marks atomic SEXP-s, i.g. integers and doubles, for modification? Vectors of non-SEXP objects are not a problem--that is why REAL, INTEGER, etc are available as functions to access the raw data pointers. Only vectors of SEXP's (i.e. generic and character vector objects) need to go through the write barrier. * The Write Barrier document has a section Changing the Representation of String Vectors. Is this something which is in works, or planned, for future versions? It would be great if it were, this should give R considerable speed boost. This was considered at the time but is not on the table now. luke -- Luke Tierney Chair, Statistics and Actuarial Science Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: [EMAIL PROTECTED] Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
RE: Write Barrier: was: [Rd] function-like macros undefined
On Wed, 16 Mar 2005, Vadim Ogranovich wrote: My actual problem was with the RAW() macro, it is not available as a function. I used INTEGER as an illustration because it was in the same group of macros, I guess I shouldn't have. It *is* available in R-devel, soon to be 2.1.0: the function was overlooked for 2.0.x. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
