Write Barrier: was: [Rd] function-like macros undefined - R-devel

Wed, Mar 16, 2005 12:33 PM #

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:luke@stat.uiowa.edu] 
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; i<LENGTH(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; i<LENGTH(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 and        Fax:               319-335-3017
    Actuarial Science
241 Schaeffer Hall                  email:      luke@stat.uiowa.edu
Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu