You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Log linearization
BK condition check
Kalman filter
Statsmodels uses numerical approximation of gradients for (3), which I have found to be very unstable. Gradients are available if a ScanOp 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?
The text was updated successfully, but these errors were encountered:
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:
Should the current prior declaration API be removed in favor of a PyMC model block?
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.
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:
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 aScan
.Perhaps a jax scan could be faster?
The text was updated successfully, but these errors were encountered: