[R] Re: your mail

[Thomas Lumley]

On Thu, 27 May 1999, Jonathan Myles wrote:
> 
> I am currently preparing an R library to estimate 
> approximate posterior distributions for parameters in
> Generalised Linear Mixed Models by Gibbs Sampling
> which includes a lot of dynamically loaded C code.
> I'm pleased with the way in which it is working and am 
> now hammering out some documentation, but closer consideration
> of some R documentation has led me to worry that my code
> a) may not achieve certain standards of R and C programming
> and b) may not work on all systems. (I'm using 0.64.1
> on a UNIX system)
> 
> My worries are
> 
> a) That I've used calloc rather than S_alloc throughout.
> 
> b) That I've used the following technique: I've
>    calls to different C programs held together in a single
>    file which looks like:
> 
<snip>
>  
> and I rely on the fact that "g" and "o" remain the same between the successive
> calls (there's a C call at the end to free up all the memory).  is this:
> 
>       1) bad,
>       2) so bad (-;) that the R archive wouldn't really be interested in code
>          that worked in this way?


The same technique is used in the survival5 library, which seems to work
on a number of platforms. I think it's undesirable, but not disastrous.  
Basically, if you do (b) you have to do (a) since R does not preserve
S_alloc memory across calls (I believe this differs from S-PLUS)

The two reasons why it's undesirable are: 
  1. it means that R can use much more memory than the specified heap
sizes, making it harder to tell how big these can safely be set without
swapping.

  2. If the program is interrupted (ctrl-c) between calloc() and free() it
will leak memory.

The second problem should be fixable with on.exit().


> I *think* I can do it without using this technique, but it will need a lot
> of re-programming.  One way round it in S v5 uses the new .Call() 
> function---is anything similar on the agenda for future versions of R?

One way around this problem is to use the new and almost undocumented
.External() interface, which allows you to write "internal" R commands and
allocate memory on the R heap. This can save a lot of copying and gives
you more control over the allocation of memory. The disadvantages are that
the API is unstable and largely undocumented, and that it gives you more
control over the allocation of memory (so you need to be aware of things
like garbage collection).

 
> On another note, where in the library structure would be a good     
> place to put a LaTeX document describing the function and showing
> some examples?

I would put it at the top level, or possibly in a doc/ subdirectory. I
don't think there are even informal standards on this.



-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-help-request at stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._