Can we introduce an user-defined optional lower-bound in the stationary constraint of the variance process?
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
Direzione di ricerca
Start in arch/univariate/volatility.py at the stationarity constraint linked in the issue. Review how that constraint is built and how its bounds are handled; the issue also raises an upper bound on long-term variance as an alternative, so the intended approach needs clarification. Done means supporting the agreed user-defined bound and testing the resulting constraint behavior.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Would it be possible to have a feature to set an EPSILON in the stationarity constraint?
Like:
1 - sum(alpha) - sum(beta) -0.5*sum(gamma) - EPSILON >= 0
The reason it that the optimiser sometimes give solution where the constraint is equal to zero, or very close like 1E-10, and that will give a crazy large long-term variance. This seems to sometimes happen when the return data covers a period of ever increasing variance.
By adding an EPSILON to the constraint we can force the variance process to have a minimal amount of mean reversion, e.g. EPSILON=1E-3 would give a variance half life of at most 1000 days, which is reasonable to impose?
Alternatively, we could also set an upper-bound on the long-term variance?
omega / [ 1 - sum(alpha) - sum(beta) - 0.5*sum(gamma) ] < max_LTV
edit: somewhere around here in the code
https://github.com/bashtage/arch/blob/a61dc7d43a5ef123bee75eae3d3e12b6c472433e/arch/univariate/volatility.py#L1078
- Lingua principale
- Python
- Stelle
- 1.6k
- Fork
- 298
- Merge medio
- 14h 46m
- PR unite (30g)
- 106
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di bashtage/arch
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 12/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 52/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 22/100
bashtage/arch#801 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di bashtage/arch
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
pytest-dev/pyfakefs#1367 · 1 commento ·
I maintainer di solito rispondono entro 2 giorni
-
IFEvalG exclude_word_harder misses the keyword next to punctuation, at the start or end of the text, and in other letter caseForse già presa @damienen l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
allenai/open-instruct#2151 ·
I maintainer di solito rispondono entro 1 giorno
-
feat(plan): support convertorLabels and convertorAffinity in Plan resourceForse già presa @AmenB l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
RedHatQE/openshift-python-wrapper#2849 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
I maintainer di solito rispondono entro 25 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
libnativeapi/nativeapi#21 ·