This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Is there a way how to fit and predict ARMA using this package?

It might useful to Julia users, sice there are not many ways/packages to do it.

Thanks.

I wonder if compilation speed can be improved.

Suppose I load a Julia package ACME with one function f(x,y).
The first time I use f(x,y) is usually slow for a given set of argument types. But it is usually much faster after that.

using ACME
f(1,2)   # usually slow
f(1,2)   # much faster
f(2,5)   # equally fast 
f(2.0,5) # slow again, bc it prev compiled f(Int,Int), now it must compile f(Float,Int)
f(2.0,5) # faster

When I run:

using ARCHModels
@time selectmodel(TGARCH,BG96,minlags=1,maxlags=1)
@time selectmodel(TGARCH,BG96,minlags=1,maxlags=1)
@time selectmodel(TGARCH,BG96,minlags=2,maxlags=2)
@time selectmodel(TGARCH,BG96,minlags=2,maxlags=2)
@time selectmodel(TGARCH,BG96,minlags=3,maxlags=3)
@time selectmodel(TGARCH,BG96,minlags=3,maxlags=3)
@time selectmodel(TGARCH,BG96,minlags=1,maxlags=3)
@time selectmodel(TGARCH,BG96,minlags=1,maxlags=3)

The compilation time becomes slow every time I change the number of lags, even though the types of each argument is the same:

julia> 
  5.247489 seconds (18.78 M allocations: 927.158 MiB, 6.23% gc time)
  0.005477 seconds (2.68 k allocations: 212.594 KiB)
  1.121684 seconds (3.90 M allocations: 183.957 MiB, 4.12% gc time)
  0.012191 seconds (10.07 k allocations: 1.081 MiB)
  1.179797 seconds (4.01 M allocations: 188.687 MiB, 5.05% gc time)
  0.018243 seconds (10.68 k allocations: 1.540 MiB)
 25.694519 seconds (90.85 M allocations: 4.179 GiB, 3.69% gc time)
  0.098000 seconds (282.74 k allocations: 32.622 MiB)

julia> 

Can this be improved?

The rugarch R package allows users to add external regressors to the mean and variance specifications of GARCH models. Does ARCHModels.jl have this feature?

Hello, do you plan to implement Generalized Autoregressive Score (GAS) models in the future? In particular, I am interested in estimating the GAS-t model because its variance is less responsive to a large realization of error than the GARCH-t model.

http://www.gasmodel.com/background.htm

On version 2.2.0.

The following throws when trying to display the model (in a notebook)

X = [-49.78749999996362, 2951.7375000000347, 1496.437499999923, 973.8375, 2440.662500000128, 2578.062500000019, 1064.42500000032, 3378.0625000002415, -1971.5000000001048, 4373.899999999894]
am = fit(GARCH{2, 2}, X; meanspec = ARMA{2, 2})

Outputs:

LAPACKException(1)

Stacktrace:
  [1] chklapackerror(ret::Int64)
    @ LinearAlgebra.LAPACK ~/julia-1.7.3/share/julia/stdlib/v1.7/LinearAlgebra/src/lapack.jl:43
  [2] trtrs!(uplo::Char, trans::Char, diag::Char, A::Matrix{Float64}, B::Matrix{Float64})
    @ LinearAlgebra.LAPACK ~/julia-1.7.3/share/julia/stdlib/v1.7/LinearAlgebra/src/lapack.jl:3431
  [3] ldiv!
    @ ~/julia-1.7.3/share/julia/stdlib/v1.7/LinearAlgebra/src/triangular.jl:727 [inlined]
  [4] inv(A::UpperTriangular{Float64, Matrix{Float64}})
    @ LinearAlgebra ~/julia-1.7.3/share/julia/stdlib/v1.7/LinearAlgebra/src/triangular.jl:809
  [5] inv(A::Matrix{Float64})
    @ LinearAlgebra ~/julia-1.7.3/share/julia/stdlib/v1.7/LinearAlgebra/src/dense.jl:872
  [6] vcov(am::UnivariateARCHModel{Float64, GARCH{2, 2, Float64}, StdNormal{Float64}, ARMA{2, 2, Float64}})
    @ ARCHModels ~/.julia/packages/ARCHModels/2J17E/src/general.jl:45
  [7] stderror(am::UnivariateARCHModel{Float64, GARCH{2, 2, Float64}, StdNormal{Float64}, ARMA{2, 2, Float64}})
    @ ARCHModels ~/.julia/packages/ARCHModels/2J17E/src/general.jl:63
  [8] show(io::IOContext{IOBuffer}, am::UnivariateARCHModel{Float64, GARCH{2, 2, Float64}, StdNormal{Float64}, ARMA{2, 2, Float64}})
    @ ARCHModels ~/.julia/packages/ARCHModels/2J17E/src/univariatearchmodel.jl:586
[...]

Digging a little deeper, volatilities(am) returns an empty vector.

Tracking further, from volatilities():

T = Float64
VS = GARCH{2, 2, Float64}
SD = StdNormal{Float64}
ht = Vector{T}(undef, 0)
lht = Vector{T}(undef, 0)
zt = Vector{T}(undef, 0)
at = Vector{T}(undef, 0)
loglik!(ht, lht, zt, at, VS, SD, am.meanspec, am.data, vcat(am.spec.coefs, am.dist.coefs, am.meanspec.coefs))

Returns -Inf and doesn't fill the ht vector.

Not sure where to go from there. Random changes to the input make it work or not work and seems quite brittle.

It would be great if this package could provide some rolling estimation features. rugarch has this feature: https://cran.r-project.org/web/packages/rugarch/vignettes/Introduction_to_the_rugarch_package.pdf

Hi,

First of all, thank you for this great package! I've started delving into DCC models, and one feature I'd love to see is to be able to predict a multi-variate model using time-steps different from just next-period. One potential implementation can be found in section 3.3 of Factor Models for Portfolio Selection in Large Dimensions.

I'd imagine the API would look very similar to the predict implementation for univariate models, e.g. predict(model, :covariance, 3) for a three-period prediction.

Multi-step forecasts (for returns etc) were implemented in #61
The following works

using ARCHModels;

BG96
am = fit(GARCH{1, 1}, BG96)
predict.(am, :volatility, 1:3)
predict.(am, :return, 1:3)

am = fit(ARCH{0}, BG96)
predict.(am, :volatility, 1:3)
predict.(am, :return, 1:3)

am = fit(ARCH{0}, BG96, meanspec=ARMA{12,0})
predict.(am, :volatility, 1:3)

I get the following errors:

julia> predict.(am, :return, 1:3)
ERROR: BoundsError: attempt to access 1974-element Array{Float64,1} at index [1975]

Hi @s-broda !

Not sure if you want to make it that verbose, but you could consider calling your package ARCHModels.jl or GARCHModels.jl to allow exporting ARCH. Since you're exporting things like ARCHModels.jl this would actually follow the "old" (I don't think they're active anymore) pkg name guidelines. Could also just be ARCHs.jl

Is it possible to simulate a fixed length time series from a given starting point? Say I have a GARCH specification, now I want to simulate potential paths forward from a specific point in time, how can I do that right now? Or is it not possible?

Thanks for the great package!

I noticed a discrepancy with the rugarch package for multi-step predictions of volatility, and I think there might be an issue with the calculation of this in the ARCHModels package.

Taking the documentation example (https://s-broda.github.io/ARCHModels.jl/stable/usage/) of the GARCH(1, 1) fit on the BG96 data: the long run volatility estimate is sqrt(omega / (1 - alpha1 - beta1) which is about 0.514. However, the example on that page for predictions for horizons 1:3 shows a sequence of volatilities 0.384, 0.360, 0.339 (one would expect it to converge to 0.514).

I think the issue is caused by taking zt and at equal to zero in the predict function, while E[at^2] is equal to the variance and larger than zero.

Another "am I using this right" issue:

julia> using ARCHModels, MarketData, DataFrames

julia> d = dropmissing(DataFrame(yahoo("^FTSE")));

julia> rs = log.(d.AdjClose[end-251:end]) .- log.(d.AdjClose[end-252:end-1]);

julia> garch_model_NI = fit(GARCH{1, 1}, rs, meanspec = NoIntercept);

julia> garch_model_NI.meanspec
NoIntercept{Float64}(Float64[])

julia> garch_model_I0 = fit(GARCH{1, 1}, rs, meanspec = Intercept(0.0));

julia> garch_model_I0.meanspec
Intercept{Float64}([0.000645515581577216])

I was expecting garch_model_I0 to have zero mean as well, but it seems that it ignores the 0 and just estimates the mean from the data? Similarly, I can't work out how to set means for multivariate models, passing something like meanspec = [Intercept(0.0), Intercept(0.0), Intercept(0.0)] errors.

My usecase - I want to simulate paths for underlying assets of derivatives in MC simulations and therefore manually pass the drift parameter based on risk free rate, dividend yield, and Ito correction. So far the only way I've managed to do this is to first estimate the model with an intercept and then do

julia> garch_model_I0.meanspec = Intercept(0.001)
Intercept{Float64}([0.001])

after estimation, but I feel like this is what should happen in the first place when using the kwarg? Unfortunately I couldn't find examples in the docs of using meanspec in fit.

Hello,

I did my thesis on a comparative analysis of Value-at-Risk methodologies and I used this package quite a lot (thank you!)

One addition I had to make was to include skewed distributions for the innovation terms since this usually leads to superior VaR forecasting performance (see: https://doi.org/10.1002/for.2303). The distribution I implemented was Hansen's Standardized Skewed T Distribution (see: https://doi.org/10.2307/2527081) which is defined as:

Its analytical quantile function is provided in https://doi.org/10.1016/s0165-1889(02)00079-9 and is defined as:

with A_η^-1 being the inverse cdf of a t-distribution with η dof

Another approach that could be taken is to adopt the framework found in (https://dx.doi.org/10.2139/ssrn.821) under which any unimodal continuous symmetric distribution can become asymmetric by changing the scale at each side of the mode. In the same paper they demonstrate their framework by creating a skewed version of the Standardized GED.

If you think that any of the above would be a worthwhile addition to this package, I provide as a starting point my implementation of Hansen's SKT-Distribution. (#86) There are at least two problems with my code:

• startingvals is essentially duplicated from the corresponding function for StdT. I tried to do
  startingvals(::Type{<:StdSkewT}, data::Array{T}) where {T<:AbstractFloat} = [startingvals(StdT,data), zero(T)] but it didn't work
• performance is bad. On the BG96 dataset fitting a GARCH(1,1) with StdSkewT errors was almost 10 times slower than the same model with StdT errors.

While I'm here and looking over the code, another thing that would be useful is the addition of a MeanSpec which includes the variance (or volatility or log volatility -- I'm not sure which is the most common convention).

I'm guessing it wouldn't represent a huge change? Would it be mostly a copy-paste of the code for Intercept?

Consider the following example.

using ARCHModels
X = BG96[773:1272]
fit(EGARCH{1,1,1},X,meanspec=AR{1},dist=StdT)

This fails instantly with the following error:

ERROR: AssertionError: isfinite(phi_d) && isfinite(gphi)
Stacktrace:
  [1] bisect!(ϕdϕ::LineSearches.var"#ϕdϕ#6"{Optim.ManifoldObjective{NLSolversBase.OnceDifferentiable{Float64, Vector{Float64}, Vector{Float64}}}, Vector{Float64}, Vector{Float64}, Vector{Float64}}, alphas::Vector{Float64}, values::Vector{Float64}, slopes::Vector{Float64}, ia::Int64, ib::Int64, phi_lim::Float64, display::Int64)
    @ LineSearches ~/.julia/packages/LineSearches/Ki4c5/src/hagerzhang.jl:503
  [2] (::LineSearches.HagerZhang{Float64, Base.RefValue{Bool}})(ϕ::Function, ϕdϕ::LineSearches.var"#ϕdϕ#6"{Optim.ManifoldObjective{NLSolversBase.OnceDifferentiable{Float64, Vector{Float64}, Vector{Float64}}}, Vector{Float64}, Vector{Float64}, Vector{Float64}}, c::Float64, phi_0::Float64, dphi_0::Float64)
    @ LineSearches ~/.julia/packages/LineSearches/Ki4c5/src/hagerzhang.jl:201
  [3] HagerZhang
    @ ~/.julia/packages/LineSearches/Ki4c5/src/hagerzhang.jl:101 [inlined]
  [4] perform_linesearch!(state::Optim.BFGSState{Vector{Float64}, Matrix{Float64}, Float64, Vector{Float64}}, method::Optim.BFGS{LineSearches.InitialStatic{Float64}, LineSearches.HagerZhang{Float64, Base.RefValue{Bool}}, Nothing, Nothing, Optim.Flat}, d::Optim.ManifoldObjective{NLSolversBase.OnceDifferentiable{Float64, Vector{Float64}, Vector{Float64}}})
    @ Optim ~/.julia/packages/Optim/TNmSw/src/utilities/perform_linesearch.jl:56
  [5] update_state!(d::NLSolversBase.OnceDifferentiable{Float64, Vector{Float64}, Vector{Float64}}, state::Optim.BFGSState{Vector{Float64}, Matrix{Float64}, Float64, Vector{Float64}}, method::Optim.BFGS{LineSearches.InitialStatic{Float64}, LineSearches.HagerZhang{Float64, Base.RefValue{Bool}}, Nothing, Nothing, Optim.Flat})
    @ Optim ~/.julia/packages/Optim/TNmSw/src/multivariate/solvers/first_order/bfgs.jl:110
  [6] optimize(d::NLSolversBase.OnceDifferentiable{Float64, Vector{Float64}, Vector{Float64}}, initial_x::Vector{Float64}, method::Optim.BFGS{LineSearches.InitialStatic{Float64}, LineSearches.HagerZhang{Float64, Base.RefValue{Bool}}, Nothing, Nothing, Optim.Flat}, options::Optim.Options{Float64, Nothing}, state::Optim.BFGSState{Vector{Float64}, Matrix{Float64}, Float64, Vector{Float64}})
    @ Optim ~/.julia/packages/Optim/TNmSw/src/multivariate/optimize/optimize.jl:57
  [7] optimize
    @ ~/.julia/packages/Optim/TNmSw/src/multivariate/optimize/optimize.jl:33 [inlined]
  [8] #optimize#89
    @ ~/.julia/packages/Optim/TNmSw/src/multivariate/optimize/interface.jl:116 [inlined]
  [9] _fit!(garchcoefs::Vector{Float64}, distcoefs::Vector{Float64}, meancoefs::Vector{Float64}, ::Type{EGARCH{1, 1, 1, T} where T<:AbstractFloat}, ::Type{StdT}, meanspec::AR{1, Float64}, data::Vector{Float64}; algorithm::Optim.BFGS{LineSearches.InitialStatic{Float64}, LineSearches.HagerZhang{Float64, Base.RefValue{Bool}}, Nothing, Nothing, Optim.Flat}, autodiff::Symbol, kwargs::Base.Iterators.Pairs{Union{}, Union{}, Tuple{}, NamedTuple{(), Tuple{}}})
    @ ARCHModels ~/.julia/packages/ARCHModels/iIiJW/src/univariatearchmodel.jl:371
 [10] fit(::Type{EGARCH{1, 1, 1, T} where T<:AbstractFloat}, data::Vector{Float64}; dist::Type{StdT}, meanspec::Type{AR{1, T} where T}, algorithm::Optim.BFGS{LineSearches.InitialStatic{Float64}, LineSearches.HagerZhang{Float64, Base.RefValue{Bool}}, Nothing, Nothing, Optim.Flat}, autodiff::Symbol, kwargs::Base.Iterators.Pairs{Union{}, Union{}, Tuple{}, NamedTuple{(), Tuple{}}})
    @ ARCHModels ~/.julia/packages/ARCHModels/iIiJW/src/univariatearchmodel.jl:431
 [11] top-level scope
    @ REPL[2]:1

The data was specifically chosen to demonstrate this error. The error however isn't related to just that specific data; it happens often when EGARCH (and sometimes TGARCH) models are combined with AR mean specifications and StdT/StdSkewT distribution of errors

At present, my code that depends on ARCHModels is handling this error in a very naive manner:

try
    fit(EGARCH{1,1,1}, data, meanspec=AR{1}, dist=StdT)
catch e
    if isa(e,AssertionError)
        @warn ("Could not fit model, falling back to GARCH{1,1}")
        fit(GARCH{1,1}, data, meanspec=AR{1}, dist=StdT)
    else
        rethrow()
    end
end

It would be very helpful if
- 1) this error was handled "gracefully" by ARCHModels, perhaps falling back to simpler models like in my code snippet,
or maybe even better if
- 2) the source of the error could be found and corrected.

In either case sadly I cannot be of much help. For case 1 I'm not familiar enough with the codebase in order to suggest remedies and for case 2 I do not have the required expertise/familiarity with optimizers in order to help

I wanna write a blog post along the lines of "which variables are harder to forecast"...

auto_arma works great:

using FredData;
f = Fred("Personal api_key");  
#
d = get_data(f, "GDP");     y=d.df[:,4]
d = get_data(f, "PCEC");    c=d.df[:,4]
d = get_data(f, "GPDI");    i=d.df[:,4]
d = get_data(f, "GCE");     g=d.df[:,4]
d = get_data(f, "NETEXP");  nx=d.df[:,4]
[filter!(x -> ! isnan(x), dd) for dd in [y, c, i, g, nx]]; # REMOVE NaN

using ARCHModels;
auto_arma(df, ic) = selectmodel(ARCH{0}, df, meanspec=ARMA, criterion=ic, minlags=0, maxlags=3);
#
sc_aic=[]
for dd in [y, c, i, g, nx]
	a=auto_arma(dd, aic)
	push!(sc_aic,(a.spec,a.meanspec,aic(a),bic(a),a))
end
sc_aic

Is there a convenient way to include controls together with ARMA?
y_{t+1} = \mu + \rho_y * y_t + \rho_c * c_t +\rho_i1 * i_{t-1} + \epsilon_{t+1}

Congrats to a nice package.

Two small suggestions wrt. the documention

1. mention somewhere that the vcov is from the robust (sandwich) estimator, not just the inverse of the information matrix.

2. early on, give a simple example like fit(GARCH{1,1}, data; meanspec=AR{1}, dist=StdNormal)

Would you prefer a PR?

This might be a usage / "am I doing something wrong" question rather than an actual issue, but I'm trying to use ARCHModels in Monte Carlo pricing of some exotic derivatives, and am seeing quite a performance gap between simulating returns from a univariate compared to a multivariate model. An example:

using ARCHModels, MarketData, DataFrames
d = dropmissing(DataFrame(yahoo("^FTSE")))
rs = log.(d.AdjClose[end-251:end]) .- log.(d.AdjClose[end-252:end-1])
garch_model = fit(GARCH{1, 1}, rs)

@btime simulate(garch_model, 252)

gives 11.400 μs (8 allocations: 1.39 KiB) on my machine. By comparison:

d2 = dropmissing(DataFrame(yahoo("^SSMI")))
rs2 = log.(d2.AdjClose[end-251:end]) .- log.(d2.AdjClose[end-252:end-1])

d3 = dropmissing(DataFrame(yahoo("NQ=F")))
rs3 = log.(d2.AdjClose[end-251:end]) .- log.(d3.AdjClose[end-252:end-1])

dcc_model = fit(DCC, [rs rs2 rs3])

@btime simulate(dcc_model, 252)

gives 1.608 ms (22932 allocations: 5.13 MiB) so more than a 100-time slowdown. Is this expected or am I doing something wrong here?

Could I use this package with high-frequency data? Intraday stock prices display complex seasonalities.

I am using your package with the book Financial Risk Forecasting. The only model in this book unavailable in your package is GOGARCH. It would be great if you could add it to your great package.

https://www.financialriskforecasting.com/code/RJulia3.html

This will allow us to get rid of the CircularBuffers.

How much of a pain would it be to try to implement Realized GARCH models, or should that go in a different package? My gut feelings suggest that they are just different enough that it would be a pain to try to fit them in with the existing code here.

https://onlinelibrary.wiley.com/doi/abs/10.1002/jae.1234

Hello Simon. If a future release were to include integrated fitting of ARMA-EGARCH or ARIMA-EGARCH, it could increase scope/ease of application to some financial data series, hence to usage of the package.

Currently:

julia> using ARCHModels

julia> v=GARCH{1, 1}; df=BG96; m=Intercept; F=StdT;

julia> f0= fit(v, df, meanspec=m, dist=F)

TGARCH{0,1,1} model with Student's t errors, T=1974.

Mean equation parameters:
─────────────────────────────────────────────
     Estimate   Std.Error   z value  Pr(>|z|)
─────────────────────────────────────────────
μ  0.00227251  0.00686797  0.330885    0.7407
─────────────────────────────────────────────

Volatility parameters:
──────────────────────────────────────────────
      Estimate   Std.Error   z value  Pr(>|z|)
──────────────────────────────────────────────
ω   0.00232225  0.00163588   1.41958    0.1557
β₁  0.884488    0.0369039   23.9673     <1e-99
α₁  0.124866    0.0404843    3.08429    0.0020
──────────────────────────────────────────────

Distribution parameters:
─────────────────────────────────────────
   Estimate  Std.Error  z value  Pr(>|z|)
─────────────────────────────────────────
ν   4.11211   0.400396  10.2701    <1e-24
─────────────────────────────────────────

The first line of output TGARCH{0,1,1} model with Student's t errors, T=1974. does not give the mean model.

The tag name "0.1.0" is not of the appropriate SemVer form (vX.Y.Z).
cc: @s-broda

Hi @s-broda,
is there a change ARCHModels.jl will be updated?
It seems to be conflicting w/ other packages:

(@v1.5) pkg> add ARCHModels
  Resolving package versions...
ERROR: Unsatisfiable requirements detected for package Optim [429524aa]:
 Optim [429524aa] log:
 ├─possible versions are: [0.15.3, 0.16.0, 0.17.0-0.17.2, 0.18.0-0.18.1, 0.19.0-0.19.7, 0.20.0-0.20.6, 0.21.0, 0.22.0, 1.0.0, 1.1.0, 1.2.0-1.2.3] or uninstalled
 ├─restricted to versions * by SynthControl [a73a6d50], leaving only versions [0.15.3, 0.16.0, 0.17.0-0.17.2, 0.18.0-0.18.1, 0.19.0-0.19.7, 0.20.0-0.20.6, 0.21.0, 0.22.0, 1.0.0, 1.1.0, 1.2.0-1.2.3]
 │ └─SynthControl [a73a6d50] log:
 │   ├─possible versions are: 0.1.0 or uninstalled
 │   └─SynthControl [a73a6d50] is fixed to version 0.1.0
 ├─restricted to versions 1.2.0-1 by MatrixCompletion [ed8b4348], leaving only versions 1.2.0-1.2.3
 │ └─MatrixCompletion [ed8b4348] log:
 │   ├─possible versions are: 0.1.0 or uninstalled
 │   └─MatrixCompletion [ed8b4348] is fixed to version 0.1.0
 └─restricted by compatibility requirements with ARCHModels [6d3278bc] to versions: [0.15.3, 0.16.0, 0.17.0-0.17.2, 0.18.0-0.18.1, 0.19.0-0.19.7, 0.20.0-0.20.6, 0.21.0, 0.22.0] — no versions left
   └─ARCHModels [6d3278bc] log:
     ├─possible versions are: [0.1.0, 0.2.0, 0.3.0, 0.4.0, 0.5.0-0.5.3, 0.6.0, 1.0.0-1.0.7, 1.1.0, 1.2.0-1.2.2] or uninstalled
     └─restricted to versions * by an explicit requirement, leaving only versions [0.1.0, 0.2.0, 0.3.0, 0.4.0, 0.5.0-0.5.3, 0.6.0, 1.0.0-1.0.7, 1.1.0, 1.2.0-1.2.2]

(@v1.5) pkg> 

Hi and thanks for the awesome package!
It's becoming common to automate time-series models.
Forecast.R has auto.arima() which returns the "best" Arima model according to some criteria defined by the user.

It would be awesome if your package has some options to select the "best" ARCH model.
Here is some discussion about doing this in R.
Also check out this post.

Thanks again for your awesome package.

A PkgEval run for a PR which changes the generated numbers for randn! indicates that the tests of this package might fail in Julia 1.5 (and on Julia current master). Apologies if this is a false positive.
cf. https://github.com/JuliaCI/NanosoldierReports/blob/7de24e455342298cbef56826b5827f0d7640d2c1/pkgeval/by_hash/b89e35c_vs_098ef24/logs/ARCHModels/1.5.0-DEV-71a4a114c2.log