From p.dalgaard at biostat.ku.dk  Wed Apr 21 14:23:37 2004
From: p.dalgaard at biostat.ku.dk (p.dalgaard@biostat.ku.dk)
Date: Wed Apr 21 14:23:39 2004
Subject: [Rd] optim-Bug (PR#6720)
Message-ID: <20040421122337.B9BCF1042E@slim.kubism.ku.dk>

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.

-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907


[Rd] optim-Bug (PR#6720)
p.dalgaard@biostat.ku.dk