Stan #67
Stan #67
Conversation
|
The tests are passing on Python3 but failing on Python2 on travis. The pymc3 import seems to be failing on Python2; not sure if this is a temporary glitch somewhere or something we need to address, but I guess we can wait and see. |
…ssue I don't have time to debug properly
|
Couldn't figure out the Python2 import issue, but it goes away if I move all the |
… issues. still WIP
There was a problem in the admittedly unusual case where the fixed effects had cell-means coding, but the random effects for that same factor had k-1 dummy coding (e.g., 0+threecats in the fixed effects, 1+threecats in the random effects). This was actually a problem before too, but the prior was just being silently handled in a not-quite-appropriate way. Now it is handled appropriately. The remaining failing tests should be mostly related to consistency between pymc3 and stan.
|
The updated images in the README are not displaying correctly in the Stan branch, but they'll display correctly after merging into master. |
|
Not sure why tests are failing on travis; they were passing on the stan branch just before the merge. They also pass locally. |
|
Looks like this is discussed here, and is fixed on the pymc3 master as of 9 days ago. But evidently not on the pip version. Any thoughts about (or is it even possible to) making travis install pymc3 from github instead of pip? I'm really not sure how many of our users would be installing the pymc3 dependency from pip vs. github, especially since we give instructions for both ways in our README. |
|
It's certainly possible to install pymc3 from master on travis, but the problem with doing that is we then won't know if the current PyPI release fails, which is what most people will be using, and is what we should probably support. We could put both master and latest PyPI in the travis matrix, which would cover all the bases. FWIW, it looks like the fix for that issue is in the latest PyPI release (from 3/30), which was before I merged the Stan branch... so I'm not sure what's going on. Also doesn't explain why the tests passed in the stan branch but not when merged. Let's see if the currently running tests pass. |
|
we'll release 3.1 very soon. there's already a release candidate
…On Apr 5, 2017 8:07 PM, "Tal Yarkoni" ***@***.***> wrote:
It's certainly possible to install pymc3 from master on travis, but the
problem with doing that is we then won't know if the current PyPI release
fails, which is what most people will be using, and is what we should
probably support. We could put both master and latest PyPI in the travis
matrix, which would cover all the bases.
FWIW, it looks like the fix for that issue *is* in the latest PyPI
release (from 3/30), which was before I merged the Stan branch... so I'm
not sure what's going on. Also doesn't explain why the tests passed in the
stan branch but not when merged. Let's see if the currently running tests
pass.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#67 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AApJmAzXJnQIo1kq3IykR6iyKKftlK5lks5rs-ZkgaJpZM4MJkZq>
.
|
|
@twiecki cool, thanks for the update. We'll probably just sit tight and wait for that then, and in the unlikely event that anyone has problems in the meantime, we'll tell them to update from master. |
Release 0.1.0 is here! Full details can be found in the [Changelog](https://github.com/bambinos/bambi/blob/master/Changelog.md).
This PR adds a new
StanBackEndthat should (in theory) do almost everything that thePyMC3BackEnddoes. Using it is as simple as specifyingbackend='stan'when initializing a newModel. TheStanBackEndwraps PyStan, but converts the sampling output into a PyMC3MultiTraceobject, which allows us to use all of the existing plotting/summarizing machinery (at least in principle; in practice, I had to hack my way around the normalMultiTraceinitialization process, so some attributes are probably not set properly).There are some things to iron out before we can merge this. @jake-westfall, maybe you can take a pass at these? We need to do the following:
Test everything more thoroughly to make sure it works.
Modify at least a few of the existing tests to run using the Stan backend. It's probably also worth adding a couple of tests that run with both backends and make sure the resulting estimates are close. We also need to modify the travis config to install PyStan (and maybe add an optional_dependencies.txt file containing PyStan that people can
pip install -rfrom).Add support for all of the PyMC3 distributions we currently support. The trick here is to map PyMC3 distribution names and arguments onto the Stan language. This is accomplished via the
distsdictionary inStanBackEnd, which maps the PyMC3 dist names onto dictionaries containing the Stan names, argument order, and (optionally) and bounds to impose. The latter is required because in Stan there are no separate distributions for clipped distributions; e.g., half-cauchy is just cauchy with a lower bound of 0. In principle I think all we need to do is add new entries to thedistsdictionary; I don't think any of the PyMC3 distributions we currently support should introduce any new complications.One gotcha right now is that PyStan ignores the
incl_warmupargument inextract()ifpermuted=True. This is reasonable in one sense, because the permuted results concatenate all chains together, and it's arguably weird to include the different initialization points. But it's a problem for us, because to make results commensurable with thePyMC3BackEnd, we should really include the burn-in and let the user drop it themselves later. The solution is unfortunately probably going to require us to duplicate some of the PyStan code for reformatting the Stan output, but with the burn-in included.Add support for different error distributions. Right now the
StanBackEndonly supports normally distributed errors, but we should at minimum support the options we support with PyMC3. This shouldn't take much work; I think we just need to modify the specification of theyhatterm and the model error.