The RATS Software Forum

ac_1 wrote:Hi Tom,

Questions regarding GARCH models:

1) I can estimate an EWMA model using ESMOOTH, however an EWMA is a special version of an IGARCH with fixed parameters e.g. alpha=0.06, beta=(1-0.06). How do I specify and estimate an IGARCH model with fixed parameters, equivalently?

ac_1 wrote: 2) To generate rolling one-step forecast sd's, the following produces a TRUE OOS forecast i.e. %allocend()+1

Code: Select all

garch(p=1,q=1,resids=u,hseries=h,noprint,nomean) tstart+i tend+i y
*
* Compute the one-step forecast for the sqrt(variance)
*
compute hhat = sqrt( %beta(1) + %beta(2)*u(tend+i)^2 + %beta(3)*h(tend+i) )

But RATS 10.0 UG says use group

Code: Select all

garch(p=1,q=1,hseries=ht,resids=at) / y
*
* Compute the one-step forecast for the variance
*
set uu tstart+i tend+i = at^2
*
compute vc=%beta(2), vb=%beta(4), va=%beta(3)
frml hfrml ht = vc + vb*ht{tend+i} + va*uu{tend+i}
frml uufrml uu = ht
group garchmod hfrml>>ht uufrml>>uu
forecast(model=garchmod,from=tend+1+i,to=tend+1+i,steps=1)

The forecast variance being the ht series, but I cannot generate a TRUE OOS forecast? Why?

ac_1 wrote: 3) Also, the manual says for EGARCH models simulate/bootstrap to generate forecasts. How do I do those recursively/rolling for EGARCH models with normal and t-distributed errors?

TomDoan wrote:

ac_1 wrote:Hi Tom,

Questions regarding GARCH models:

1) I can estimate an EWMA model using ESMOOTH, however an EWMA is a special version of an IGARCH with fixed parameters e.g. alpha=0.06, beta=(1-0.06). How do I specify and estimate an IGARCH model with fixed parameters, equivalently?

ESMOOTH can "estimate" an EWMA model by applying it to squared "residuals", but where are you getting the residuals? Also, it uses a different objective function (the squared difference between the predicted variance and the squared residuals) than does GARCH, where the log likelihood combines a term in ratio of squared residuals to the predicted variance with a term that penalizes a high variance.

Why wouldn't you just estimate that using GARCH. EWMA applies to univariate models as well.

TomDoan wrote:

ac_1 wrote: 2) To generate rolling one-step forecast sd's, the following produces a TRUE OOS forecast i.e. %allocend()+1

Code: Select all

garch(p=1,q=1,resids=u,hseries=h,noprint,nomean) tstart+i tend+i y
*
* Compute the one-step forecast for the sqrt(variance)
*
compute hhat = sqrt( %beta(1) + %beta(2)*u(tend+i)^2 + %beta(3)*h(tend+i) )

But RATS 10.0 UG says use group

Code: Select all

garch(p=1,q=1,hseries=ht,resids=at) / y
*
* Compute the one-step forecast for the variance
*
set uu tstart+i tend+i = at^2
*
compute vc=%beta(2), vb=%beta(4), va=%beta(3)
frml hfrml ht = vc + vb*ht{tend+i} + va*uu{tend+i}
frml uufrml uu = ht
group garchmod hfrml>>ht uufrml>>uu
forecast(model=garchmod,from=tend+1+i,to=tend+1+i,steps=1)

The forecast variance being the ht series, but I cannot generate a TRUE OOS forecast? Why?

The description in the manual is for any number of out-of-sample steps. It even says explicitly that when k=0 you can do the calculation using just sample data. So I don't understand why you are trying to hack out the formulas in the text to do one-step forecasts. The procedure in the UG will work fine if you leave it as is---the whole point of FRML's is that they automatically adjust their calculations as the entries change. You're trying to change a FRML to hard code entry calculations.

TomDoan wrote:You're doing one-step, which are deterministic, so yes, all the stats are the same.

As written, if you extend it beyond one step, you'll be overwriting the 2 to H step forecasts with the next pass through the loop---you can't wait until after the outer loop to do the calculations of the means.

TomDoan wrote: Convergence issues are covered in the User's Guide---the GARCHBACKTEST.RPF example shows how to handle that (see the last part of the section before that). Moving window estimation of GARCH models is, in general, a really bad idea. (Extending the sample is fine; the problem is removing the front of the sample). It creates all kinds of estimation issues and has no tangible effect on the estimated variances at the end of the sample other than through the changes in the estimated coefficients. (Given a particular set of GARCH estimates, the H at T=1000 will be the same to any reasonable standard whether you start the recursion at T=1 or T=500---initial conditions wash long before that).

*===============================
clear(len=iend+1) lower
clear(len=iend+1) upper
clear(len=iend+1) median
clear(len=iend+1) mean
set lower ibegin+1 iend+1 = %fractiles(hdraws(t),||.05||)(1)
set upper ibegin+1 iend+1 = %fractiles(hdraws(t),||.95||)(1)
set median ibegin+1 iend+1 = %fractiles(hdraws(t),||.50||)(1)
set mean ibegin+1 iend+1 = %avg(hdraws(t))

prin / dlogdm h lower upper median mean


*===============================
set fmean ibegin+1 %allocend()+1 = mean
set VaR ibegin+1 %allocend()+1 = -%invnormal(.01)*fmean*value

prin / fmean VaR


graph(header="Bootstrapped Forecasts for EGARCH model")
# VaR   ibegin+1 %allocend()+1 2


set minusVaR ibegin+1 %allocend()+1 = -VaR
graph(header="Bootstrapped Forecasts for EGARCH model")
# minusVaR   ibegin+1 %allocend()+1 2


*===============================
set ftrigger ibegin+1 iend = VaR/value
set trigger ibegin+1 iend = dlogdm < -ftrigger; * return is less than VaR
prin / dlogdm ftrigger trigger

sstats ibegin+1 iend trigger>>ntrigger
disp ntrigger
table ibegin+1 iend trigger

comp vr = ntrigger/((%allocend()-window)*.01); *  violation ratio (vr)
disp vr

ac_1 wrote:

TomDoan wrote:You're doing one-step, which are deterministic, so yes, all the stats are the same.

As written, if you extend it beyond one step, you'll be overwriting the 2 to H step forecasts with the next pass through the loop---you can't wait until after the outer loop to do the calculations of the means.

To change to a fixed starting point window instead (recursive scheme) remove t1 from istart+t1? Right? Although, the UG says to be very careful about making an estimation window too narrow for a moving window.

ac_1 wrote: How else could I improve the loop to (maybe) include multistep ahead bootstrapped forecasts?

ac_1 wrote: I also want to backtest EGARCH with t-errors:

garch(p=1,q=1,exp,asymmetric,hseries=h,noprint,DIST=T)

ac_1 wrote:

TomDoan wrote: Convergence issues are covered in the User's Guide---the GARCHBACKTEST.RPF example shows how to handle that (see the last part of the section before that). Moving window estimation of GARCH models is, in general, a really bad idea. (Extending the sample is fine; the problem is removing the front of the sample). It creates all kinds of estimation issues and has no tangible effect on the estimated variances at the end of the sample other than through the changes in the estimated coefficients. (Given a particular set of GARCH estimates, the H at T=1000 will be the same to any reasonable standard whether you start the recursion at T=1 or T=500---initial conditions wash long before that).

Interestingly, the UG also says:
The calculated value of the GARCH variance rarely depends on more than about the last 100 data points anyway, so the only effect of the rolling sample is to change the parameters, not (necessarily) for the better --- which I didn't know.

ac_1 wrote: I have removed the 100.0 from the return calculation, to adjust the scaling, and have set a portfolio value = 100

set dlogdm = log(dm/dm{1})
comp value = 100

And calculated VaR without the expected return (as from descriptive statistics SE >> Sample Mean, which is almost always very near zero in daily financial returns). So, VaR = -quantile * sigma * portfolio value.

Further, I have plotted -VaR i.e. upside-down VaR and calculated a violation ratio vr.

How do I graph Exceedence plots: 2 scale with returns as a cloud of small dots rather than traditionally as a 'sound-wave', -VaR forecasts as a line, and the trigger/exceedence values as dots?

ac_1 wrote:[1] Exceedence Graph

I am having problems plotting the Exceedence Graph. I have plotted the graph as follows:

Code: Select all

set xdots ibegin+1 %allocend() = %if(trigger>=1,dlogdm,%na)
prin / xdots

graph(key=upleft,style=line,overlay=dots,ovsamescale,ovcount=1) 2
# dlogdm ibegin+1 %allocend()
# xdots ibegin+1 %allocend() 4

I want to include the minusVaR line, but cannot get the scaling right. The returns are plotted as a line, ideally I'd like them as a cloud of small dots.

ac_1 wrote: [2] Convergence Filter

If there are convergence errors, rather than having an "odd" or NA volatility forecast, hence an erroneous VaR=0; an idea (Bollerslev et al) is to impute/filter the volatility forecast: the non-convergent forecast being replaced by the unconditional mean over EACH in-sample rolling window. So something like:

if %converged == 1

*** bootstrap as I have ***

if %converged == 0
comp gstart=istart+t1,gend=ibegin+t1
sstats(noprint) gstart gend dlogdm>>fimpmu
disp "replaced at ENTRY:" t1
set fmean gstart gend = fimpmu

How to implement within the moving window loop?

TomDoan wrote: I have no idea what you are asking for. You are graphing the series using a line graph and then "dotting" the elements that have trigger>=1. So, yes, the returns are plotted as a line, as that's what you asked for. I'm not sure what "cloud" means when you're graphing time series---whatever you graph has to move with time. If you want two different colored dots, just use STYLE=DOTS,OVERLAY=DOTS.

set xdots ibegin+1 %allocend() = %if(trigger==1,dlogdm,%na); * exceedence's or violations
prin / xdots

set dlogdm = log(dm/dm{1})

compute ndraws=10000

comp window = 1000; * 1867 to match Dynamic
comp value = 100

compute ibegin = 1500; * end of 1st regression, 1st forecast is for 1501
                       * OR ibegin = 1867; * end of 1st regression, 1st forecast is for 1868 to match Dynamic
compute istart = (2+ibegin-window-1)
compute iend   = %allocend()

graph(key=upleft,style=line,overlay=dots,ovsamescale,ovcount=1) 2
# dlogdm ibegin+1 %allocend()
# xdots ibegin+1 %allocend() 4

TomDoan wrote: That seems like a bad idea. Why wouldn't you just use the most recent converged estimates? If there are major problems with non-convergence, I would seriously question whether the model is reasonable for the data set. (There's a good reason for RiskMetrics using a fixed parameter IGARCH model---it probably isn't too far off, and eliminates the possibility of "adjusting" the model to produce the results that you want).

ac_1 wrote: I would like a graph plotting the returns, minusVaR, and the xdots. The xdots are plotted at the end of the violated return, and the minusVaR line should be above it, i.e. the return has been violated.

Code: Select all

graph(key=upleft,style=line,overlay=dots,ovsamescale,ovcount=1) 2
# dlogdm ibegin+1 %allocend()
# xdots ibegin+1 %allocend() 4

How do I add the minusVaR line on the correct scale? Attached is the graph.

ac_1 wrote:

TomDoan wrote: That seems like a bad idea. Why wouldn't you just use the most recent converged estimates? If there are major problems with non-convergence, I would seriously question whether the model is reasonable for the data set. (There's a good reason for RiskMetrics using a fixed parameter IGARCH model---it probably isn't too far off, and eliminates the possibility of "adjusting" the model to produce the results that you want).

There's at least the following ways to deal with non-convergence:
1) Replace with the unconditional mean of the moving in-sample window --- if it's good enough for them it's good enough for me.
2) Use the most recent converged estimates.
3) If %converged = 0 use a different optimizer within the loop --- but that may lead to too many if statements.
4) Those covered in the Users Guide.

For either 1) and 2) how within the t1 loop?

TomDoan wrote:

ac_1 wrote: I would like a graph plotting the returns, minusVaR, and the xdots. The xdots are plotted at the end of the violated return, and the minusVaR line should be above it, i.e. the return has been violated.

Code: Select all

graph(key=upleft,style=line,overlay=dots,ovsamescale,ovcount=1) 2
# dlogdm ibegin+1 %allocend()
# xdots ibegin+1 %allocend() 4

How do I add the minusVaR line on the correct scale? Attached is the graph.

The minusVAR is a line, and it's a line in the same scale as the return series. So why isn't it just a second series covered by STYLE=LINE? You only need overlay if either the style changes or the scale changes.

graph(header="VaR Exceedence Graph",key=upleft,style=line,overlay=dots,ovsamescale,ovcount=1) 3
# dlogdm ibegin+1 iend
# minusVaR ibegin+1 iend 2
# xdots ibegin+1 iend 4

TomDoan wrote:

ac_1 wrote:

TomDoan wrote: That seems like a bad idea. Why wouldn't you just use the most recent converged estimates? If there are major problems with non-convergence, I would seriously question whether the model is reasonable for the data set. (There's a good reason for RiskMetrics using a fixed parameter IGARCH model---it probably isn't too far off, and eliminates the possibility of "adjusting" the model to produce the results that you want).

There's at least the following ways to deal with non-convergence:
1) Replace with the unconditional mean of the moving in-sample window --- if it's good enough for them it's good enough for me.
2) Use the most recent converged estimates.
3) If %converged = 0 use a different optimizer within the loop --- but that may lead to too many if statements.
4) Those covered in the Users Guide.

For either 1) and 2) how within the t1 loop?

(1) The unconditional mean of WHAT? Whatever it is, just do a SSTATS instruction on it over the sample that you are using for the failed GARCH model.

(2) If you are feeding in the previous values, just do a new GARCH with METHOD=EVAL rather than METHOD=estimation method.

 if (%converged == 0); garch(p=1,q=1,exp,asymmetric,hseries=h,print,METHOD=BHHH) istart+t1 ibegin+t1 dlogdm
 if (%converged == 0); garch(p=1,q=1,exp,asymmetric,hseries=h,print,METHOD=SIMPLEX) istart+t1 ibegin+t1 dlogdm
 *etc etc