From therneau at mayo.edu  Tue Oct  4 19:28:38 2011
From: therneau at mayo.edu (Terry Therneau)
Date: Tue, 04 Oct 2011 12:28:38 -0500
Subject: [Rd] number of copies - summary
In-Reply-To: <EC695904-C0DC-49DA-9F8D-F2EA071A6E62@r-project.org>
References: <1317652357.979.25.camel@nemo>
	<7182A7C5-0FAC-423D-8B97-B84DCD623408@r-project.org>
	<1317658585.979.48.camel@nemo>
	<873E1DFD-610E-4683-8633-78FC55507A62@r-project.org>
	<1317667429.979.55.camel@nemo>
	<EC695904-C0DC-49DA-9F8D-F2EA071A6E62@r-project.org>
Message-ID: <1317749318.28402.24.camel@nemo>

My thanks to Bill Dunlap and Simon Urbanek for clarifying many of the
details.  This gives me what I need to go forward.  

  Yes, I will likely convert more and more things to .Call over time.
This clearly gives the most control over excess memory copies. I am
getting more comments from people using survival on huge data sets so
memory usage is an issue I'll be spending more thought on.

  I'm not nearly as negative about .C as Simon.  Part of this is long
experience with C standalone code: one just gets used to the idea that
mismatched args to a subroutine are deadly. A test of all args to .C
(via insertion of a browser call) is part of initial code development.
Another is that constructing the return argument from .Call (a list with
names) is a bit of a pain.  So I will sometimes use dup=F. However, the
opion of R core about .C is clear, so it behooves me to move away from
it.

Thanks again for the useful comments.

Terry Therneau



[Rd] number of copies - summary
Terry Therneau