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