R devel - Mar 2005 - Write Barrier: was: function-like macros undefined

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);


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?

* 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.

Thanks,
Vadim

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

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

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
>