[R-SIG-Finance] timout using "evalWithTimeout" in looped rugarch estimation

alexios ghalanos alexios at 4dscape.com
Sat May 10 11:34:38 CEST 2014


Johannes,

I suggest the following:

1. Don't use hybrid, use instead solnp or nlminb.

2. You can control a number of solver convergence criteria (e.g. number
of iterations) using the solver.control argument.

3. Before running the code, do consider a little more how reasonable it
is to be modelling a TGARCH(7,8) model. Investigate the model first
(don't just return the AIC or BIC). Are any of the higher order
ARCH/GARCH parameters different from zero or even significant? I have
not seen a single study which shows that such very high order GARCH
models have better performance than more parsimonious alternatives.

4. At the best of times it takes a considerable amount of data to
estimate the GARCH persistence. Try running a simulation exercise using
for example the ugarchdistribution function to obtain some insight into
higher order GARCH models.

5. Finally, as mentioned numerous times on this forum, the fGARCH model
is a highly parameterized omnibus model. Imposing stationarity during
the optimization, particularly for non-symmetric distributions such as
the ged, is a costly exercise.  Consider using the GJR instead and a
distribution which is a little faster to evaluate such as the JSU.
Alternatively consider using the normal distribution to estimate the
GARCH parameters for the purpose of model comparison.

-Alexios

On 10/05/2014 08:23, Johannes Moser wrote:
> I guess that the problem is due to the processing in C as part of the
> ugarchfit routine.
> 
> Is there any way to timeout a ugarchfit command or to constrain the
> number if iterations?
> 
> At one time the loop seems to be stuck completely.
> I waited for several hours for a single ugarchfit step which just didn`t
> complete. Then I manually stopped the process.
> 
> Separate calculation of the respective model also seems to be "stuck"
> (CPU is still working, the "hybrid" algorithms seem to find no solution
> though and just keep running).
> 
> As I want to set up a GARCH model-preselection battery there hopefully
> is a way to handle such problems?
> 
> Best, Johannes
> 
> 
> 
> 
> 
> Am 09.05.2014 13:58, schrieb Johannes Moser:
>> Dear all,
>>
>> I`ve set up a double loop which loops through different GARCH-orders
>> and ARMA-orders in a rugarch estimation (of several models and error
>> distributions) and each time writes the AIC and other information into
>> a data frame.
>> The resulting data frame should be used for the pre-selection of a
>> model, which then will be examined manually.
>>
>> A small part of the model estimation steps using "ugarchfit" take very
>> long time. So I implemented a timeout function using "evalWithTimeout"
>> which stops the current estimation step and proceeds with the next
>> step in the loop and estimates the next model.
>>
>> The timeout function is wrapped into a "tryCatch" function which
>> assures thet the loop keeps running after e.g. convergence problems.
>>
>> A small toy model works fine:
>>
>>
>> #######################################################################
>> require('R.utils')
>> abc <- matrix(NA,10,3)
>>
>> foo <- function() {
>>      print("Tic");
>>      for (kk in 1:50) {
>>           print(kk);
>>           Sys.sleep(0.1);
>>      }
>>      print("Tac");
>> }
>>
>>
>> for (i in 1:10){
>>      ptm <- proc.time()
>> tryCatch( { abc[i,1] <- evalWithTimeout({foo()} ,timeout=(4+i*0.2)
>> ,onTimeout="silent" )
>>             abc[i,2] <- 1
>> }
>> , error = function(x) x)
>> tt<- proc.time() - ptm
>> abc[i,3]<-tt[3]
>> }
>>
>> abc
>> #####################################################################
>>
>>
>> However, in the rugarch setup the "evalWithTimeout" doesn't seem to
>> stop the "ugarchfit" estimation reliably. E.g. in one instance the
>> recorded time for a step was 1388.03 seconds even though the limit was
>> set to be 300 seconds. The next example illustrates my setup in a
>> simplified version (unfortunately my results depend on the data I have
>> used, so you will not be able to reproduce them):
>>
>>
>> #####################################################################
>> require('rugarch')
>> quiet1 <- read.table( "dax_quiet1.txt" , header=T)
>> tempdata <- quiet1$logreturns
>>
>> g_order <- matrix(NA,5,2)
>> g_order[1,]<-c(1,1)
>> g_order[2,]<-c(1,8)
>> g_order[3,]<-c(9,6)
>> g_order[4,]<-c(9,8)
>> g_order[5,]<-c(3,10)
>>
>> overview <- data.frame(matrix(NA,5,2))
>>
>> for(i in 1:5){
>>      ptm <- proc.time()
>>
>>      spec <- ugarchspec(
>>           variance.model = list(model = "fGARCH", garchOrder =
>> g_order[i,], submodel = "TGARCH", external.regressors = NULL,
>> variance.targeting = FALSE),
>>           mean.model = list(armaOrder = c(0,0), external.regressors =
>> NULL), distribution.model = "sged")
>>
>>      tryCatch( {tempgarch <- evalWithTimeout({ugarchfit(spec=spec,
>> data=tempdata ,solver="hybrid")} ,timeout=20 ,onTimeout="silent" )
>>                 overview[i,1]<-infocriteria(tempgarch)[1]
>>      }
>>      , error = function(x) x)
>>
>>      tt<- proc.time() - ptm
>>      overview[i,2]<-tt[3]
>> }
>>
>> overview
>>
>> # If the timeout is set set to 20, this setup leads to:
>> # 2.87 sec.
>> # 6.95 sec.
>> # 125 sec.     ... here, tryCatch interrupted the process
>> # 51.73 sec.
>> # 27.11 sec.
>> # for the 5 different estimation steps.
>>
>> # timeout set to 300:
>> # 2.81 sec.
>> # 6.85 sec.
>> # 743.58 sec.
>> # 41.70 sec.
>> # 26.85 sec.
>> # no process was interrupted by tryCatch
>> #######################################################################
>>
>>
>> As can be seen even from this simplified example, when the timeout was
>> set to be 20 there still was a process that took 125 seconds (which is
>> more than 5 times longer!).
>> I would be very thankful for any ideas or comments!
>>
>> Best, Johannes
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
> 
> -- 
> 
> _______________________________________________
> R-SIG-Finance at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-sig-finance
> -- Subscriber-posting only. If you want to post, subscribe first.
> -- Also note that this is not the r-help list where general R questions
> should go.
> 
>



More information about the R-SIG-Finance mailing list