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. Don't know. > > 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. Ciao, Oliver ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
