You can of course print out the values in your objective function, as that is where you want the information. In any case, using R's debugging facilities (e.g. dump.frames & debugger) would have enabled you to find the input values are which your function was failing. Please see the chapter in `Writing R Extensions'.
One way out is to return NA if the objective cannot be evaluated: that often works (not L-BFGS). Another would be to work with log(standard deviation) and atanh(correlation). On Mon, 23 Apr 2007, DEEPANKAR BASU wrote: > Ravi, > > Thanks a lot for your detailed reply. It clarifies many of the > confusions in my mind. > > I want to look at the parameter estimates at each iteration because the > full model that I am trying to estimate is not converging; a smaller > version of the model converges but the results are quite meaningless. > The problem in the estimation of the full model is the following: my > likelihood function contains the elements of a (bivariate normal) > covariance matrix as parameters. To compute the likelihood, I have to > draw random samples from the bivariate normal distribution. But no > matter what starting values I give, I cannot ensure that the covariance > matrix remains positive definite at each iteration of the optimization > exercise. Moreover, as soon as the covariance matrix fails to be > positive definite, I get an error message (because I can no longer draw > from the bivariate normal distribution) and the program stops. Faced > with this problem, I wanted to see exactly at which parameter estimates > the covariance matrix fails to remain positive definite. From that I > would think of d evising a method to get around the problem, at least I > would try to. > > Probably there is some other way to solve this problem. I would like > your opinion on the following question: is there some way I can > transform the three parametrs of my (2 by 2) covariance matrix (the two > standard devaitions and the correlation coefficient) to ensure that the > covariance matrix remains positive definite at each iteration of the > optimization. Is there any method other than transforming the parameters > to ensure this? > > Deepankar > > > > ----- Original Message ----- > From: Ravi Varadhan <[EMAIL PROTECTED]> > Date: Monday, April 23, 2007 12:21 pm > Subject: RE: [R] Estimates at each iteration of optim()? > >> Deepankar, >> >> Here is an example using BFGS: >> >>> fr <- function(x) { ## Rosenbrock Banana function >> + x1 <- x[1] >> + x2 <- x[2] >> + 100 * (x2 - x1 * x1)^2 + (1 - x1)^2 >> + } >>> grr <- function(x) { ## Gradient of 'fr' >> + x1 <- x[1] >> + x2 <- x[2] >> + c(-400 * x1 * (x2 - x1 * x1) - 2 * (1 - x1), >> + 200 * (x2 - x1 * x1)) >> + } >>> optim(c(-1.2,1), fr, grr, method = "BFGS", control=list(trace=TRUE)) >> initial value 24.200000 >> iter 10 value 1.367383 >> iter 20 value 0.134560 >> iter 30 value 0.001978 >> iter 40 value 0.000000 >> final value 0.000000 >> converged >> $par >> [1] 1 1 >> >> $value >> [1] 9.594955e-18 >> >> $counts >> function gradient >> 110 43 >> >> $convergence >> [1] 0 >> >> $message >> NULL >> >>> >> >> This example shows that the parameter estimates are printed out >> every 10 >> iterations. However, trying different integer values for trace >> from 2 to 10 >> (trace = 1 behaves the same as trace=TRUE) did not change anything. >> If you >> want to get estimates at every iteration, look at the source code >> for BFGS >> (which I assume is in FORTRAN). You may have to modify the source >> code and >> recompile it yourself to get more detailed trace for BFGS. >> >> However, you can get parameter iterates at every step for "L-BFGS- >> B" using >> trace=6, although this gives a lot more information than just the >> parameterestimates. Alternatively, you can use the "CG" methods >> with trace=TRUE or >> trace=1, which is a generally a lot slower than BFGS or L-BFGS-B. >> >> Why do you want to look at parameter estimates for each step, anyway? >> >> >> Ravi. >> >> -------------------------------------------------------------------- >> -------- >> ------- >> >> Ravi Varadhan, Ph.D. >> >> Assistant Professor, The Center on Aging and Health >> >> Division of Geriatric Medicine and Gerontology >> >> Johns Hopkins University >> >> Ph: (410) 502-2619 >> >> Fax: (410) 614-9625 >> >> Email: [EMAIL PROTECTED] >> >> Webpage: >> http://www.jhsph.edu/agingandhealth/People/Faculty/Varadhan.html >> >> >> -------------------------------------------------------------------- >> -------- >> -------- >> >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [EMAIL PROTECTED] On Behalf Of DEEPANKAR BASU >> Sent: Monday, April 23, 2007 11:34 AM >> To: Peter Dalgaard >> Cc: r-help@stat.math.ethz.ch >> Subject: Re: [R] Estimates at each iteration of optim()? >> >> I read the description of the trace control parameter in ?optim and >> thenalso looked at the examples given at the end. In one of the >> examples I found >> that they had used "trace=TRUE" with the method "SANN". I am using >> themethod "BFGS" and I tried using "trace=TRUE" too but I did not >> get the >> parameter estimates at each iteration. As you say, it might be method >> dependent. I tried reading the source code for "optim" but could >> not find >> out what I was looking for. Hence, I was wondering if anyone could >> tell me >> what option to use with the method "BFGS" to get the parameter >> estimates at >> each iteration of the optimization. >> >> Deepankar >> >> >> ----- Original Message ----- >> From: Peter Dalgaard <[EMAIL PROTECTED]> >> Date: Monday, April 23, 2007 2:46 am >> Subject: Re: [R] Estimates at each iteration of optim()? >> >>> DEEPANKAR BASU wrote: >>>> I am trying to maximise a complicated loglikelihood function >> with >>> the "optim" command. Is there some way to get to know the >> estiamtes >>> at each iteration? When I put "control=list(trace=TRUE)" as an >>> option in "optim", I just got the initial and final values of the >>> loglikelihood, number of iterations and whether the routine has >>> converged or not. I need to know the estimate values at each >>> iteration.> >>>> >>> It might help if you actually _read_ the description of the trace >>> control parameter (hint: it is not an on/off switch) in ?optim... >>> And, >>> as it says, this is method dependent, so you may have to study >> the >>> source code. >>> >>>> Deepankar >>>> >>>> ______________________________________________ >>>> R-help@stat.math.ethz.ch mailing list >>>> https://stat.ethz.ch/mailman/listinfo/r-help >>>> PLEASE do read the posting guide http://www.R- >> project.org/posting- >>> guide.html> and provide commented, minimal, self-contained, >>> reproducible code. >>>> >>> >>> >> >> ______________________________________________ >> R-help@stat.math.ethz.ch mailing list >> https://stat.ethz.ch/mailman/listinfo/r-help >> PLEASE do read the posting guide http://www.R-project.org/posting- >> guide.htmland provide commented, minimal, self-contained, >> reproducible code. >> > > ______________________________________________ > R-help@stat.math.ethz.ch mailing list > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide http://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code. > -- 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 ______________________________________________ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.