[Rd] often unnecessary duplicate in sapply / as.vector

[Thomas Lumley]

On Tue, 11 Jul 2006, Martin Morgan wrote:

> This is because RObjToCPtr is not quite careful enough with NAMED,
> rather than an issue with as.XXX

But DUP=FALSE is documented to be dangerous for this very reason. It never 
copies, and ?.C makes it clear that .C(,DUP=FALSE) can modify variables 
that it should not have any access to by normal rules.  The example of 
safe use modifies only a newly created, anonymous numeric vector.

 	-thomas

>
> tmp.c: void tmp(double *x) { x[0]=1; return; }
>
>> f <- function(x) x
>> x <- 0
>> .C("tmp", f(x), DUP=FALSE)
> [[1]]
> [1] 1
>
>> x
> [1] 1
>
>> x <- 0
>> y <- x
>> .C("tmp", x, DUP=FALSE)
> [[1]]
> [1] 1
>
>> y
> [1] 1
>
> Martin
>
> Prof Brian Ripley <ripley at stats.ox.ac.uk> writes:
>
>> On Tue, 11 Jul 2006, Prof Brian Ripley wrote:
>>
>>> On Fri, 7 Jul 2006, Thomas Lumley wrote:
>>
>>>> On Fri, 7 Jul 2006, Martin Morgan wrote:
>>
>> [...]
>>
>>>>> More generally, perhaps as.vector might not duplicate when mode(x) == mode ?
>>>>
>>>> This isn't a trivial change, because  mode(x)==mode does not guarantee
>>>> that as.vector(x, mode) has no effect.  For example, with mode="numeric" it
>>>> removes attributes.
>>>
>>> And with mode="list" it does not (although that is not as documented).
>>> We can certainly do better.  [This is another of those cases where 'mode'
>>> is confusing, and in fact it would be typeof(x) == mode.]
>>
>> Aargh: of course I should have guessed that quite a few people have
>> written code that assumes that e.g. as.double() duplicates.  The first I
>> came across is a .Fortran call in smooth.spline with DUP=FALSE which
>> despite all the warnings changes its 'w' argument and hence the return
>> result from smooth.spline if as.double is made more efficient.
>>
>> I really have no desire to spend any more time tracking down problems
>> caused by such rogue code, so I am going to leave this as is (with as.list
>> somewhat more efficient but the as.vector functions always duplicating).
>>
>> --
>> Brian D. Ripley,                  ripley at 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
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

Thomas Lumley			Assoc. Professor, Biostatistics
tlumley at u.washington.edu	University of Washington, Seattle