optim-Bug (PR#6720)
Well, I've spent an hour tracking down exactly that. We need to zero the snd array, and I have tested and am about to commit code to do that. (We need to do it at that point, as lbfgsb is part of the R-API.) I think there is an underlying error in the code logic, but this change causes it to restart and so proceed successfully. Brian
On 21 Apr 2004, Peter Dalgaard wrote:
Prof Brian Ripley <ripley@stats.ox.ac.uk> writes:
On 21 Apr 2004, Peter Dalgaard wrote:
...
I have this down to the use of R_alloc in the vect() function (line 40, optim.c). Replacing with S_alloc (which zeros memory) removes the issue for me on this machine and on the Opteron. Could you please verify on other platforms? And if anyone actually understands the code could you verify that it makes sense to require the workspace to be initialized?
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.)
Yes, sorry but it got a bit late when I sent that. I found this by backtracking, so I know quite well where the problem is: The allocation of "wa" on line 1020 in optim.c, specifically the wa[lsnd] part in setulb which becomes snd in mainlb and wn1 in formk. Parts of wn1 never get initialized. This appears to be *relatively* harmless, except that sometimes there are NaN which propagate to wn and into dpofa(), etc.
Brian D. Ripley, ripley@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595