[Rd] optim/vmmin and R_alloc

Göran Broström gb at tal.stat.umu.se
Thu Dec 30 18:24:19 CET 2004


On Thu, Dec 30, 2004 at 04:27:59PM +0000, Prof Brian Ripley wrote:
> On Thu, 30 Dec 2004, Thomas Lumley wrote:
> 
> >On Thu, 30 Dec 2004, [iso-8859-1] Göran Broström wrote:
> >>
> >>However, and that is my question/suggestion: Why not use Calloc+Free
> >>instead of R_alloc in vmmin (and maybe in other places)? I made the
> >>changes in 'optim.c' in the functions 'vmmin' and 'Lmatrix'. Then I 
> >>rebuilt
> >>and reinstalled R-2.0.1. The result was great! My function ran very fast 
> >>and
> >>without any memory problems.
> >>
> >>So why not? Or will this change create other problems?
> >
> >Memory will leak permanently if the functions are interrupted or an error 
> >occurs.  This may be less serious now than it was in the past, since R can 
> >be interrupted in fewer places.
> 
> An error in the objective function would also cause a leak. Goran *should* 
> be managing the heap himself by vmax[gs]et, as discussed in Writing R 
> Extensions.

So Brian thinks of me as an expert?:-) In 'R-exts' I read about using
vmax[gs]et: "This is only recommended for experts." Seriously, do you really
suggest that amateurs like myself should ignore the written documentation?

More seriously, how should I interpret the word 'expert' in the
documentation? I always think of guys like Brian, Peter, Thomas, and
the rest of the core team when I read warnings like that. And the
consequence is that I automatically avoid such tricks. Maybe warnings
should be written in such a way that they don't discourage
from using the right tools?

> So why not read the manual and use the documented mechanism?  

See above. I will try your suggestion and be an expert.

Thanks,

Göran
-- 
 Göran Broström                    tel: +46 90 786 5223
 Department of Statistics          fax: +46 90 786 6614
 Umeå University                   http://www.stat.umu.se/egna/gb/
 SE-90187 Umeå, Sweden             e-mail: gb at stat.umu.se



More information about the R-devel mailing list