# MLE error in R: initial value in 'vmmin' is not finite

I am trying to fit an ARIMA(1,1)-GARCH(1,1) model. I changed the starting values a lot but still its returning the same error. Below is my code which contains two functions LL, i.e. the Likelihood calculator and call_mle, which calls LL.

phi1 and si1 are AR(1) and MA(1) parameters, alpha1 and beta1 are GARCH(1,1) parameters. const and omega are ARIMA and GARCH constants.

In the Likelihood function, R[] is the residual, sigmasq[] is sigma squared, and sigmasqrt is the square root of sigma:

LL <- function(const, phi1 ,si1 , alpha1 ,beta1,omega , mu , sigma)
{
R    = c()
R = mean(abs(train.data))

### ARIMA terms
for( i in 2:length(train.data))
{
R[i] = train.data[i] - const -  phi1*train.data[i-1] - si1*R[i-1]
}

### GARCH terms
sigmasq    = c()
sigmasq = sd(train.data)
for(i in 2:length(train.data))
{
sigmasq[i] = alpha1*sigmasq[i-1] + beta1*(R[i-1])^2 + omega
}
sigmasqrt = sqrt(sigmasq)

logL = suppressWarnings(-sum(dnorm(R , mu , sigmasqrt , log = TRUE)))
return( logL)
}

caller_mle = function()
{
start_params = list(const = 0 ,phi1 =0.00,si1 = 0.00 ,alpha1 = 0.00 ,beta1 = 0.0 ,omega = 0, mu =0  , sigma =1)
fixed_params = list(mu = 0  , const = 0)
fit = mle(LL , start = start_params , fixed = fixed_params)
return(fit)
}


Can you suggest what is wrong? Also since alpha1 + beta1 < 1, can you suggest some other optimization tool which will take care of this?

EDIT : I used "garchfit" function from fgarch package to simulate the model. It worked and gave me the parameter values. I used these params as starting values of my Log likelihood and after running some iterations it yielded : Error in optim(start, f, method = method, hessian = TRUE, ...) : non-finite finite-difference value .

Can someone please suggest how to proceed further or should i use the pre-defined library?

Edit2 : non- finite - difference was because of sigmasqrt becomes Nan(sqrt of negative numbers). Can i write a condition in my Likelihood function to try the next value if this happens. Will it affect the accuracy of estimates.

Can i use a similar procedure to ensure alpha1 + beta1 <1 ?

Edit3 : Tried this and it never converges. I received the following error : Error in solve.default(oout\$hessian) : Lapack routine dgesv: system is exactly singular: U[1,1] = 0

Can anyone suggest the next steps??

• Could you please make a MCVE out of this? The question is currently needlessly hard to answer. – Bob Jansen Feb 17 '19 at 17:36
• An MCVE would really help, how does sigmasqrt become negative? – Bob Jansen Feb 18 '19 at 18:25
• Sigmasqrt doesn't becomes negative it becomes nan when sigmasq becomes negative.I have modified the code to enhance readability. – Abhishek Kumar Feb 19 '19 at 3:06

I traced the error. It is a C language routine implemented in R that appears to have been functionally obsolesced, so it is called by other routines, but I don't think it is still implemented as its own routine. Some information on it is at ftp://cran.r-project.org/pub/R/doc/manuals/r-devel/R-exts.html

Given the underlying math, there is one of three problems that could be present.

The first is that the true distribution either lack moments above the zeroth or the first. There is no defined mean and variance, or there is no variance, but there is a mean. A heavy-tailed distribution such as the Cauchy would cause this. There are real-world cases where the distribution can never settle as there will always be a higher point somewhere. There doesn't exist a squares minimizing routine that will ever produce a valid answer.

The second possibility is that your model is very badly misspecified in the sense that you may have the general distribution correct, but not the terms and so you are looking for the MLE of a very distant likelihood function. It isn't that your model isn't in the ballpark. It isn't in the same city, state or region.

The third is that the true values of the parameter are near the edges of the data and the routine, which is a hill climbing routine, keeps going uphill and never stops. Imagine that you are in Kansas City and going to walk to the global maximum in North America, but it is on Mt. McKinley. It is so far away from the center of the continent that the routine surrenders and says "I give up."

If you were to try and keep the same general algorithm, then I would manually construct the algorithm and visualize the joint density of the point estimators with an elevation equal to the likelihood. Switching standard packages could readily result in two equally bad outcomes.

The first is that you get the same class of message. The second is that you should get the same class of message, but no warning is provided, and you get very false parameter estimates.