[Rd] number of copies

[William Dunlap]

> -----Original Message-----
> From: r-devel-bounces at r-project.org [mailto:r-devel-bounces at r-project.org] On Behalf Of Terry Therneau
> Sent: Monday, October 03, 2011 11:44 AM
> To: Simon Urbanek
> Cc: r-devel at r-project.org
> Subject: Re: [Rd] number of copies
> 
> 
> On Mon, 2011-10-03 at 12:31 -0400, Simon Urbanek wrote:
> > > Thanks.  I was hoping that x[,sorted] would act like "double(n)"
> > does in a .C call, and have no extra copies made since it has no local
> > assignment.
> >
> > Yes it does act the same way, you get an extra copy with double(n) as
> > well - there is no difference.
> >
> 
> That is surprising.  This is not true of Splus.  Since Chambers mentions
> it as a specific case as well (Programming with Data, p421) I assumed
> that R would be at least as intellegent.  He also used the unset()
> function to declare that something could be treated like double(n),
> i.e., need no further copies. But that always looked like a dangerous
> assertion to me and unset has disappeared, perhaps deservedly, from R.

Terry,
  In SV4 and the version of S+ based on it, unset(x) removed
the name "x" from the currently active evaluation frame and returned
the value of "x".  This decremented the reference count of the
data by 1.  The .C() and .Call() functions would copy an input only
if its reference count was positive.  If the data pointed to by "x"
was not also referenced by another name (in any frame) then
   .C("Cfunc", unset(x))
would not copy x, but otherwise it would.  Hence unset() was not dangerous
but it could be difficult to make sure it actually avoided a copy.
E.g., if you had
   f <- function(y) g(y)
   g <- function(x) .C("Cfunc", unset(x))
and called
   f(1:1e6)
then g's call to .C would copy the 1:1e6 because it was pointed to
by f's "y".  Changing f to
   f <- function(y) g(unset(y))
would let
   f(1:1e6)
avoid the copy, but if you did
   z <- 1:1e6
   f(z)
you would get the copy.

Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com 

> 
> Terry T.
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel