[#5035] maxBFGS prints positive function values during evaluation

Date:
2013-10-31 11:40 Priority:
3

State:
Closed

Submitted by:
florian oswald (floswald) Assigned to:
Nobody (None)

Hardware:
Macintosh Product:
None

Operating System:
MacOS X Component:
maxBFGS

Version:
None Severity:
minor

Resolution:
Fixed

URL:

Summary:
maxBFGS prints positive function values during evaluation

Detailed description
Hi there! I'm at version 1.1-2 of maxLik. I've noted that maxBFGS prints the absolute value of the objective function at each iteration. This can be a bit confusing if the actual function returns negative numbers which get smaller and smaller. Here is your example: > t <- rexp(100, 2) > loglik <- function(theta) sum(log(theta) - theta*t) > ## Note the log-likelihood and gradient are summed over observations > gradlik <- function(theta) sum(1/theta - t) > hesslik <- function(theta) -100/theta^2 > ## Estimate with finite-difference gradient and Hessian > a <- maxBFGS(loglik, start=1, print.level=1) the final function value is correct. cheers florian

Comments:

Message
Date: 2021-12-17 07:53 Sender: Ott Toomet Added comment in documentation (Rev 1753).
Date: 2013-11-04 08:00 Sender: Ott Toomet Yes, I think we go for this. Should mention this in documentation, and look if it actually constitutes a bug in optim().
Date: 2013-11-04 07:37 Sender: Arne Henningsen I was partly wrong in my previous comment. I thought that the sign of the log-likelihood function was "manually" changed in the code of the maxLik() package but we already use optim()'s argument "control = list( fnscale = -1)". If print.level >= 1 (i.e. optim()'s control parameter "trace" >= 1), optim() reports the value of the objective function multiplied by "fnscale" so that Ott was right when he wrote that we would need to change optim() to fix this bug. Sorry for my mistake! I suggest that we do not change optim() but inform/warn the maxLik users in the documentation and/or maxBFGS() writes a short message if it is called with print.level >= 1. What do you think? We could also consider to file a bug report / feature request for optim().
Date: 2013-10-31 12:43 Sender: Arne Henningsen We should not change optim() and we do not need it. optim() maximises the objective function, if one adds the argument "control = list( fnscale = -1)".
Date: 2013-10-31 12:02 Sender: Ott Toomet I guess the reason is the following: maxBFGS is implemented by optim (in a fortran library AFAIR). These are minimization routines. As we use maximization by default we have to swap the sign. However, printing output at each iteration is done internally in optim() and hence it shows the wrong sign. I don't know if there is any easy remedy except mentioning it in the documentation. An alternative were to hack the original source code, but that would add a substantial isntallation burden to maxLik (currently we stay free from compiled code).
Date: 2013-10-31 11:53 Sender: Arne Henningsen Thank you, Florian, for reporting this bug. It also occurs, when one uses maxBFGS() through maxLik(): b <- maxLik(loglik, start=1, print.level=1, method="BFGS") We'll take a look. /Arne

Attached Files:

Changes

Field	Old Value	Date	By
status_id	Open	2021-12-17 07:54	otoomet
close_date	None	2021-12-17 07:54	otoomet
Resolution	Won't Fix	2021-12-17 07:53	otoomet
Resolution	None	2013-11-04 07:37	arne
Severity	None	2013-10-31 11:53	arne