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

Add cmap argument to pairplot #1159

Closed
rpgoldman opened this issue Apr 20, 2020 · 6 comments
Closed

Add cmap argument to pairplot #1159

rpgoldman opened this issue Apr 20, 2020 · 6 comments

Comments

@rpgoldman
Copy link
Contributor

Tell us about it

The coloring of a hexbin plot is controlled (at least with the matplotlib backend) by a cmap argument. This argument is not exposed to the programmer through the pairplot parameter set, and the backend plotting function ignores the backend_kwargs argument, so the programmer cannot control this except through setting the cmap parameters of the backend, potentially breaking other plots.

Thoughts on implementation

Probably the simplest method is to start using backend_kwargs instead of supporting cmap directly. Supporting cmap directly would be nicer, though, since it doesn't require understanding the backend, and it would expose the cmap to the user in the docstring.

@OriolAbril
Copy link
Member

OriolAbril commented Apr 20, 2020

Similarly to the contour case, it should be passed via hexbin_kwargs={"cmap": "plasma"}. Does this work?

backend_kwargs are passed to plt.subplots at figure-axes creation

@aloctavodia
Copy link
Contributor

The reason we do not expose all argument is that the number easily explodes, instead we use kwargs to allow user customization. I know this could be a little weird at first. Oriol is right hexbin_kwargs={"cmap": "plasma"}should do the trick.

@rpgoldman
Copy link
Contributor Author

Per comments on the PR (#1158), I think it would be a good idea for ArviZ to specify a sensible default choice of cmap so that novice users don't have to worry about it. It's unfortunate that what you get for a colormap depends unpredictably on what other plotting has been done in the same environment.

If it's possible, it might be best to supply a choice that is sensitive to the current style sheet, or specify the default in the style sheet, if that is possible. These matters, unfortunately, exceed my understanding of the backends.

@aloctavodia
Copy link
Contributor

The problem you are seeing is because you are combining two styles by first calling seaborn-darkdrid and then arviz-darkgrid. Styles are applied globally unless they are defined inside a with statement https://matplotlib.org/3.1.1/api/style_api.html

@rpgoldman
Copy link
Contributor Author

Is there a style we expect our Arviz styles to be applied on top of? I guess just the default matplotlib style?

@canyon289
Copy link
Member

@rpgoldman can you confirm this is fixed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants