[Rd] R's copying of arguments (Re: Julia)
oliver at first.in-berlin.de
Tue Mar 20 22:14:16 CET 2012
On Tue, Mar 20, 2012 at 12:08:12PM -0700, Hervé Pagès wrote:
> >So the situation is somewhere between: "it is possible" and
> >"R does not support a safe decision if, what is possible, also
> >can be recommended".
> >At the moment R rather deprecates in-place modification by default
> >(the save way, and I agree with this default).
> >But it's not true, that R in general copies arguments.
> >But this seems to be true for the .C interface.
> >Maybe a lot of performance-/memory-problems can be solved
> >by rewriting already existing packages, by providing them
> >via .Call instead of .C.
> My understanding is that most packages use the .C interface
> because it's simpler to deal with and because they don't need
> to pass complicated objects at the C level, just atomic vectors.
> My guess is that it's probably rarely the case that the cost
> of copying the arguments passed to .C is significant, but,
> if that was the case, then they could always call .C() with
> DUP=FALSE. However, using DUP=FALSE is dangerous (see Warning
> section in the man page).
Yes. I have seen that (DUP=FALSE) in the docs, but while I was
writing the answer like a maniac, I forgot it. ;-)
Thanks for mentionig it.
In the manual also was mentioned, that .Call allows more control.
I did not looked at .C and used .Call from the beginning on.
It did not looked very complicated. But maybe .C would be much easier.
> No need to switch to .Call
OK, at least not for the point of DUP-arg.
But it seems to me, that when later the names-result will
be correctly set to 0, 1 and 2, then such optimisations,
which were asked for, could be done "automagically".
And to do it safely too.
The .C interface with the DUP-arg seems not to allow this.
More information about the R-devel