Prof Brian Ripley <[EMAIL PROTECTED]> 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. ______________________________________________ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel