[Rd] optim-Bug (PR#6720)

[Douglas Bates]

Prof Brian Ripley <ripley at stats.ox.ac.uk> writes:
...
> Zeroing the workspace is not a requirement of the original L-BFGS-B code 
> that I can see.  Given that it was originally in Fortran, and Fortran 
> often does zero it seems a likely symptom, but it does mean that a 
> variable is being used uninitialized somewhere in the code (converted to 
> C).  It would be better to leave vect alone and to zero the workspace with 
> a memset call in lbfgsb.  (Incidentally, I don't know why S_alloc does not 
> use memset -- we do require standard C and use in seeral other places.)

I had planned to suggest that we use memset more widely and perhaps
add a macro Memset, defined like the current Memcpy, to R_ext/RS.h.  I
felt that memset was likely to be more efficient for zeroing large
areas of memory than running a loop would be.  Recently Peter Dalgaard
and Andy Liaw and I discussed this with regard to a test to see if
vectors using more than 4 GB of memory could be allocated on an
Opteron.  Andy installed my suggested modification to do_makevector to
use memset for zeroing freshly allocated vectors and found that the
running time for a test on an Opteron/Linux system actually increased.
It appears that, at least on that system, memset runs a loop at the
level of characters.

I still think it would be a good idea to use memset but we would want
to do some timing comparisons to make sure we don't slow things down.