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