Full_Name: Dr. Hans A. Kestler
Version: 1.8.1.
OS: Linux, Win, Mac OSX
Submission from: (NULL) (134.60.73.116)
The code below produces after a different number of iterations i the following
error:
Error in optim(par = rep(0.5, length(edges)), loglik, method =
"L-BFGS-B", :
non-finite value supplied by optim
This was reproducible on different machines (Mac G4 OSX, AMD Opteron Linux SUSE
9.0, Intel P4 Suse 9.0, P4 Windows XP Prof), only with different i.
The non-deterministic behaviour made us recompile R with debug options and use
valgrind for memory-leak checking. The result was horrible. We are now in the
process of going through the f2c code of lbfgsb.c. The problem seems to be a
access violation of wn1 at run time.
Cheers
Hans
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
for (i in 1:1000) {
set.seed(0,NULL)
cat(i,"\n")
pvec<-c(19,1,1,5,5,6,4,6,15,7,15,2,16,2,5,6,25,1,3,1,5,3,5,5,20,31)
qvec<-c(6,24,4,0,2,0,2,1,0,8,1,14,4,4,1,19,6,30,0,2,0,2,15,15,11,10)
edges<-c(1,2,16)
loglik <- function(q) {
y = pvec[edges]%*%log(1-q) + qvec[edges]%*%log(q) -
(pvec[edges[1]]+qvec[edges[1]])*log(1-prod(q))
tt<-format(c(y, q),nsmall=20)
# cat(tt,"\n")
return(-y)
}
result <- optim(par=rep(0.5, length(edges)), loglik,
method="L-BFGS-B", lower=rep(0.001,length(edges)),
upper=rep(0.999,length(edges)))
}
Hi Hans,
I've been able to reproduce your error (version see below). The
non-deterministic behavior is indeed worrying.
This is not directly related to your bug report, but constrained
optimization can be fickle, especially if the objective function is
singular somewhere close to the boundaries. In your case, you may be
able to circumvent some problems by transforming q to a new variable eq,
eg.
eq = exp(q)/(1+exp(q)),
do the unbounded optimization, and backtransform. It may also be
worthwhile to provide the gradient to optim.
Best regards
-------------------------------------
Wolfgang Huber
Division of Molecular Genome Analysis
German Cancer Research Center
Heidelberg, Germany
Phone: +49 6221 424709
Fax: +49 6221 42524709
Http: www.dkfz.de/abt0840/whuber
-------------------------------------
> version
_
platform i686-pc-linux-gnu
arch i686
os linux-gnu
system i686, linux-gnu
status alpha
major 1
minor 9.0
year 2004
month 03
day 08
language R
kestler@neuro.informatik.uni-ulm.de wrote:> Full_Name: Dr. Hans A. Kestler
> Version: 1.8.1.
> OS: Linux, Win, Mac OSX
> Submission from: (NULL) (134.60.73.116)
>
>
> The code below produces after a different number of iterations i the
following
> error:
>
> Error in optim(par = rep(0.5, length(edges)), loglik, method =
"L-BFGS-B", :
> non-finite value supplied by optim
>
> This was reproducible on different machines (Mac G4 OSX, AMD Opteron Linux
SUSE
> 9.0, Intel P4 Suse 9.0, P4 Windows XP Prof), only with different i.
>
> The non-deterministic behaviour made us recompile R with debug options and
use
> valgrind for memory-leak checking. The result was horrible. We are now in
the
> process of going through the f2c code of lbfgsb.c. The problem seems to be
a
> access violation of wn1 at run time.
>
> Cheers
> Hans
>
>
kestler@neuro.informatik.uni-ulm.de writes:> Full_Name: Dr. Hans A. Kestler > Version: 1.8.1. > OS: Linux, Win, Mac OSX > Submission from: (NULL) (134.60.73.116) > > > The code below produces after a different number of iterations i the following > error: > > Error in optim(par = rep(0.5, length(edges)), loglik, method = "L-BFGS-B", : > non-finite value supplied by optim > > This was reproducible on different machines (Mac G4 OSX, AMD Opteron Linux SUSE > 9.0, Intel P4 Suse 9.0, P4 Windows XP Prof), only with different i. > > The non-deterministic behaviour made us recompile R with debug options and use > valgrind for memory-leak checking. The result was horrible. We are now in the > process of going through the f2c code of lbfgsb.c. The problem seems to be a > access violation of wn1 at run time.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? -- 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
On 21 Apr 2004, Peter Dalgaard wrote:> kestler@neuro.informatik.uni-ulm.de writes: > > > Full_Name: Dr. Hans A. Kestler > > Version: 1.8.1. > > OS: Linux, Win, Mac OSX > > Submission from: (NULL) (134.60.73.116) > > > > > > The code below produces after a different number of iterations i the following > > error: > > > > Error in optim(par = rep(0.5, length(edges)), loglik, method = "L-BFGS-B", : > > non-finite value supplied by optim > > > > This was reproducible on different machines (Mac G4 OSX, AMD Opteron Linux SUSE > > 9.0, Intel P4 Suse 9.0, P4 Windows XP Prof), only with different i. > > > > The non-deterministic behaviour made us recompile R with debug options and use > > valgrind for memory-leak checking. The result was horrible. We are now in the > > process of going through the f2c code of lbfgsb.c. The problem seems to be a > > access violation of wn1 at run time. > > 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.) -- 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
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
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