R devel - Jun 2004 - bug or correct behaviour ?

This is the general outline of my code::
 
main(argc,argv){
   ...
   Rf_initEmbeddedR(argc,argv);
   ...
   Test_tryEval("source(test.r)");
   ...
}
############# 
# test.r
#############
...
dyn.load("toload.so")

tmp <-matrix(data=1,nrow=narray*2,ncol=nclust)

.Call("Init",tmp,...)
while(...) {
   criteria <-feval(tmp)
   if (criteria < criteria.min) 
        tmp.last <- tmp
   else  
       tmp <- tmp.last
   ...
   .Call("replace",tmp,...)
}
####################################


 When I try to recover tmp 

      tmp <- tmp.last
 
 I got the modified value of tmp.
 It means that tmp.last is modified
 when I modified tmp in the C funciont replace.
 
 The program seems to work fine if I change 
 to this::
            
  tmp.last <- tmp*1.0
  
  tmp <- tmp.last*1.0


 Any comments ?

 Alex

Without seeing your code for the .Call parts it is impossible for us to
know, but as .Call does not duplicate its arguments (unlike .C), it is
possible for it to change both tmp and a copy of tmp, tmp.last.

So it seems likely there is a bug in your C code if that is not your 
intention.  The normal way to use .Call is to return something, and to 
duplicate any arguments which will be changed (possibly only provided 
NAMED(tmp) is true as otherwise there are no named copies around).

In other words, it would be normal to have

tmp <- .Call("Replace", tmp, ...)

and call duplicate() inside the C code for Replace.

On Thu, 10 Jun 2004, Alex Nu wrote:
> 
>  This is the general outline of my code::
>  
> main(argc,argv){
>    ...
>    Rf_initEmbeddedR(argc,argv);
>    ...
>    Test_tryEval("source(test.r)");
>    ...
> }
Not sure of the relevance of this.
> ############# 
> # test.r
> #############
> ...
> dyn.load("toload.so")
> 
> tmp <-matrix(data=1,nrow=narray*2,ncol=nclust)
> 
> .Call("Init",tmp,...)
> while(...) {
>    criteria <-feval(tmp)
>    if (criteria < criteria.min) 
>         tmp.last <- tmp
That makes a potential copy. The actual copying occurs if tmp is changed
and R is aware of it.  This is the purpose of the 'named' element of a
SEXP, but I don't think that is documented anywhere.
>    else  
>        tmp <- tmp.last
>    ...
>    .Call("replace",tmp,...)
> }
> ####################################
> 
> 
>  When I try to recover tmp 
> 
>       tmp <- tmp.last
>  
>  I got the modified value of tmp.
>  It means that tmp.last is modified
>  when I modified tmp in the C funciont replace.
>  
>  The program seems to work fine if I change 
>  to this::
>             
>   tmp.last <- tmp*1.0
>   
>   tmp <- tmp.last*1.0
Those do definitely make new objects.

-- 
Brian D. Ripley,                  ripley@stats.ox.ac.uk
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, UK                Fax:  +44 1865 272595