[Rd] DUP=FALSE

[Prof Brian D Ripley]

On Mon, 26 Mar 2001, Paul Gilbert wrote:

> Thomas
>
> >> Another thing I find I do not understand is how many copies of an
> >> argument are made. For example, in a call to a function like
> >>
> >> f <- function(x){ .C("goodidea", y=double(1),  x, DUP=TRUE)[[y]] }
> >>
> >> there is the original x and the duplicated x in the argument to .C,
> but
> >> is there a third in the list returned by .C, or is that somehow the
> same
> >> one as in the argument to .C.  My problem is that my x is very big.
>
> >There's a third one. In dotcode.c the following happens
>
> >a) x is copied to a C array at the top of the R heap
> >b) the C function is called
> >c) the C array is copied into a newly created R object
> >d) this new R object is returned.
>
> It seems like there is an unnecessary extra copy here, unless of course
> the array in the R object cannot be the C array (but your example of
> messing up things in the parent environment suggests it can be). If

Well, in current R internals there is no simple way to create an R array
out of data held in a C array.  (It can be done, but is messy AFAIK.)
Also, with DUP=TRUE, you need protection.  The C routine might have cached
that address and use it next time it was called, thereby working with part
of the `newly created R object'.

> DUP=TRUE then there should be no harm in the result being just a pointer
> to the copy which is the argument, and if DUP=FALSE then the result is
> already in the copy as illustrated in the example circulated by Martin
> Schlather on Martin Maechler suggestion a few days ago, so again there
> is no harm. I won't pretend to understand the internals of R but I know
> I am getting clobbered by a big array in an argument.

Why are you using .C not .Call anyway?  These things are much easier to
control with .Call.

> >I don't know why you are getting slightly different results with
> >DUP=FALSE. I can't think of any good explanation.
>
> I'll try to track this down sometime. If you think of anything please
> let me know.

Linux? If so I think this is probably due to forced stores or not.  gcc on
Linux is getting notorious with me for not doing IEEE-compatible
arithmetic, and so getting inconsistent results. Compiling with
-fforce-store seems to solve this (at some performance expense).

Brian

-- 
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 272860 (secr)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._