Correction to Nomenclature in Volatility Model#2978
Merged
springcoil merged 1 commit intopymc-devs:masterfrom May 18, 2018
aaronjmaxwell:feature/nomenclature-fix-in-notebook
Merged
Correction to Nomenclature in Volatility Model#2978springcoil merged 1 commit intopymc-devs:masterfrom aaronjmaxwell:feature/nomenclature-fix-in-notebook
springcoil merged 1 commit intopymc-devs:masterfrom
aaronjmaxwell:feature/nomenclature-fix-in-notebook
Conversation
This small correction is in response to issue Stochastic Volatility Example #2566. It concerns the two different examples of the Volatility Model used in the PyMC3 notebooks to introduce users to the wonder that is Bayesian modeling. In getting_started.ipynb, under: --Case Study 1: Stochastic volatility ---The Model the model specification uses `y_i` to represent the daily precentage returns. However, later on in the `with pm.Model() as sp500_model:` block the dummy variable `r` is used to represent the daily returns as well as the tensor variable name. The second correction also concerns the useage of `s_i` to represent the volatility process in daily returns. In both Volatility Process walkthroughs (there is a stand-alone notebook dedicated to it) the model specs treat `s_i` as the standard deviation of the StudentT distribution used to model the log-returns. In the PyMC3 API docs on the StudentT, the distribution is defined with `lambda` representing the precision. This is why the `volatility_process` variable is mapped from `pm.math.exp(-2 * s)` in the `pm.Model()` block. However, when the returns were defined in the model block the **kwarg was `lambda=1/volatility_process`. This has been fixed. Thanks to @twiecki and the OP for highlighting this error.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This small correction is in response to issue Stochastic Volatility Example #2566. It concerns the two different examples of the Volatility Model used in the PyMC3 notebooks to introduce users to the
wonder that is Bayesian modeling. In getting_started.ipynb, under:
Case Study 1: Stochastic volatility
The Model
the model specification uses
y_ito represent the daily precentage returns. However, later on inthe
with pm.Model() as sp500_model:block the dummy variableris used to represent the dailyreturns as well as the tensor variable name.
The second correction also concerns the useage of
s_ito represent the volatility process in dailyreturns. In both Volatility Process walkthroughs (there is a stand-alone notebook dedicated to it)
the model specs treat
s_ias the standard deviation of the StudentT distribution used to model thelog-returns. In the PyMC3 API docs on the StudentT, the distribution is defined with
lambdarepresenting the precision. This is why the
volatility_processvariable is mapped frompm.math.exp(-2 * s)in thepm.Model()block. However, when the returns were defined in themodel block the **kwarg was
lambda=1/volatility_process. This has been fixed.Thanks to @twiecki and the OP for highlighting this error. Alternatively, if there is apprehension to the second change since model specs will not correspond to the trace that was returned, one could simply keep
lambda=1/volatility_processand change the model specification tolog(r_i) \sim t(\nu, 0, exp(2s_{i}). Then at least the MCMC sampler would not need to be re-run (difficult considering that Google has blocked requests to the historical finance data API).