-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Use arviz for plotting #3338
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
Use arviz for plotting #3338
Conversation
Deleted code is debugged code!! |
The documentation will be updated as part of this PR, or a separated one? |
Wellll, the code has just shifted :) But it has become more general purpose which is still a win! |
|
pymc3/plots/__init__.py
Outdated
az = _ArviZ() | ||
|
||
|
||
autocorrplot = az.plot_autocorr |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Its tempting to reconcile the names, but I suppose we should just leave things be.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
from running through the first notebook, varnames --> var_names
is the worst right now. I am a little tempted to add a decorator just for that case:
def map_args(func):
@functools.wraps(func)
def wrapped(*args, **kwargs):
if 'varnames' in kwargs and 'var_names' not in kwargs:
warnings.warn('Keyword argument `varnames` renamed to `var_names`, and will be removed in pymc3 3.8.0')
kwargs['var_names'] = kwargs.pop('varnames')
return func(*args, **kwargs)
return wrapped
Thoughts on that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that's a good idea.
As the plan is to eventually remove this, we should probably also raise deprecation warnings. Ideally with the new call if that's not too cumbersome to do. |
Wait... is the plan to eventually remove this? I guess in favor of just using |
I think we should have I don't think we should deprecate |
ah, neat -- I think I can just dump |
6d1a618
to
6462000
Compare
Sorry for the long pause. I addressed these two issues:
Here's a traceplot using both |
Is this still a WIP? |
Oops, changed the title - I think it is ready. Tab completion and docs come from arviz, and look ok to me. I will mess with the tests tomorrow to get them passing. I haven't played around too much without arviz installed, which might be causing CI problems. |
|
Looks great. Needs a prominent line in the release notes. We should probably also fix the docs, but certainly can do that in a separate PR. |
We should have a docathon week for update all docs ;-) |
Looks like there was a surprising test failure because we are now picking up numpy 1.16. |
This looks ready to merge again. There was a travis failure from trying to send data to coveralls. |
I'm hitting the big green button! |
Thanks @ColCarroll! |
Niceeeee! |
This starts moving pymc3 plotting over to arviz. Other things I'd like to include in this PR:
setup.py
to include arviz as optional (pip install pymc3[all]
orpip install pymc3[plots]
?)This is still WIP because of arviz-devs/arviz#529
I am also making an issue for
plot_posterior_predictive_glm
, which is heavily used in the GLM notebooks, but not yet supported by arviz. I think there's interest in doing so, though!Here's an example running under this PR (and the arviz PR). Note that as a side effect of this change,
traceplot
is more flexible.