Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PyMC Integration #8

Open
jessegrabowski opened this issue Feb 3, 2023 · 1 comment
Open

PyMC Integration #8

jessegrabowski opened this issue Feb 3, 2023 · 1 comment
Labels
enhancement New feature or request important Fix this ASAP

Comments

@jessegrabowski
Copy link
Owner

Ideally, all the model estimation should be handled by PyMC. I'm currently using Emcee because gradients aren't available for several steps in the solution process, including:

  1. Log linearization
  2. BK condition check
  3. Kalman filter

Statsmodels uses numerical approximation of gradients for (3), which I have found to be very unstable. Gradients are available if a Scan Op is used, but I have found this to be extremely slow (see here) (2) requires a QZ decomposition, which is non-differentiable. (1) is differentiable if is solved via cycle reduction, but this also requires a Scan.

Perhaps a jax scan could be faster?

@jessegrabowski jessegrabowski added the enhancement New feature or request label Feb 3, 2023
@jessegrabowski jessegrabowski added the important Fix this ASAP label Apr 21, 2023
@jessegrabowski
Copy link
Owner Author

jessegrabowski commented Apr 22, 2023

I want to up the importance of this, without worrying about gradients. PyMC should be front and center for sampling and estimation. Still, two questions:

  1. Should the current prior declaration API be removed in favor of a PyMC model block?
  2. Is pm.sample_smc strictly superior to emcee?

I'm leaning towards yes for (1), because the infrastructure to handle many different distributions etc is getting quite heavy. It would also promote decoupling to remove anything to do with sampling from the gEconModel object and into a pm.draw style API that could be called internally where needed.

With respect to (2), early tests suggest that yes, it is better. But I am having some trouble with multiple chains and my numba linear algebra overloads.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request important Fix this ASAP
Projects
None yet
Development

No branches or pull requests

1 participant