8000 ENH: passing colors (and other optional keyword arguments) to violinplot() by alimuldal · Pull Request #3875 · matplotlib/matplotlib · GitHub
[go: up one dir, main page]

Skip to content

ENH: passing colors (and other optional keyword arguments) to violinplot() #3875

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

Closed
wants to merge 3 commits into from

Conversation

alimuldal
Copy link
Contributor

I'm really glad that matplotlib now has a violinplot() function, but I find the current implementation a bit annoying to customize, since the only way to change the colors, alpha values etc. is to modify each artist after creating the plot. One would ideally want to be able to pass in any arbitrary keyword arguments for the PolyCollection and LineCollection artists in each individual 'violin', but there's a trade-off between flexibility and simplicity.

I think a reasonable compromise is to have the option to specify individual fill colors for each violin (like the color kwarg for hist()), but to have only a single dict for all the other optional kwargs for the fills and lines. For the time being I've stuck to the default colors/alpha values in the original implementation, but it might make more sense to leave these defaults unspecified so that they can be set according to rcParams.

@alimuldal alimuldal closed this Dec 3, 2014
@alimuldal alimuldal deleted the violin_props branch December 3, 2014 00:53
@alimuldal alimuldal restored the violin_props branch December 3, 2014 00:53
@alimuldal alimuldal reopened this Dec 3, 2014
@@ -6870,14 +6870,16 @@ def matshow(self, Z, **kwargs):

def violinplot(self, dataset, positions=None, vert=True, widths=0.5,
showmeans=False, showextrema=True, showmedians=False,
points=100, bw_method=None):
points=100, bw_method=None, color='y', line_kw={},
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no mutable defaults, please. Just set it to None for default and then do an if-check early in the function to replace it with an empty dictionary.

@alimuldal
Copy link
Contributor Author

Sorry about that, deleted my remote branch by mistake

@@ -7113,8 +7152,9 @@ def violin(self, vpstats, positions=None, vert=True, widths=0.5,
bodies += [fill(stats['coords'],
-vals + pos,
vals + pos,
facecolor='y',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(rhetorical question) how did we miss this in our original code review?!

@WeatherGod
Copy link
Member

I definitely agree with this in principle. We probably need to quibble over some of the specifics, but this does address a problem with the current design.
Some things that will be needed: (1) unit tests, (2) entry in whats_new and maybe api_changes

"""Make a violin plot.

Call signature::

violinplot(dataset, positions=None, vert=True, widths=0.5,
showmeans=False, showextrema=True, showmedians=False,
points=100, bw_method=None):
points=100, bw_method=None, color='y', line_kw=None,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should probably change this to None while touching this code.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

definitely would want to change color to None. Who knows? Maybe it might make sense to have color-cycling on this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should I also drop the old default values for the line colors and fill alpha?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a tough one to decide. There are no corollary values in the rcparams to pull from instead of these hard-coded values. But I hate hard-coded values so much!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@WeatherGod I share your hatred for hard-coded values, but I also think all plots ought to look reasonably good with just the default parameters. If I get rid of the hard-coded values for facecolor, linecolor and alpha, the violins look a little bit lacklustre:

default_violins

Do you reckon that's acceptable, or should I go back to the default values?

@tacaswell
Copy link
Member

There are too many images commited, the *-expected files should not be included, can you remove them and rebase so they do not show up in the history?

@breedlun
Copy link
Contributor
breedlun commented Feb 9, 2015

Can I ask if these changes will allow me to set the alpha for the violin body fill color independently of the body edge color?

In matplotlib v1.4.0, the violin body is a PolyCollectionObject which seems to have only one value for alpha. (I can input a RGBA list for facecolor or edgecolor, but the A element gets ignored.) In contrast, if I use patch_artist = True when I create a box plot, the box is a PathPatch object, which allows me to specify different alpha values for facecolor and edge color.

@tacaswell tacaswell modified the milestones: proposed next point release, next point release Feb 19, 2015
@tacaswell tacaswell modified the milestones: next point release, proposed next point release Jul 17, 2015
@tacaswell tacaswell modified the milestone: 2.1 (next point release) Aug 29, 2017
@jklymak
Copy link
Member
jklymak commented May 9, 2018

It still seems violin plots don't allow diff colours? Does anyone want to pick this one up and champion?

This looks 85% of the way there, so marking as good first issue if someone wants to take it on and incoprorate the comments above and rebase...

@jklymak jklymak added Good first issue Open a pull request against these issues if there are no active ones! status: needs rebase labels May 9, 2018
@jklymak jklymak added this to the v3.0 milestone May 9, 2018
@tacaswell tacaswell modified the milestones: v3.0, v3.1 Jul 7, 2018
@jklymak
Copy link
Member
jklymak commented Oct 5, 2018

Closing as abandoned, but does seem potentially useful, so hopefully someone takes it up.

@jklymak jklymak closed this Oct 5, 2018
@timhoffm
Copy link
Member
timhoffm commented Oct 7, 2018

@jklymak Just as a remark: Nobody will find "good first issue" in closed PR. The default search will only go for open issues. If we want to advertise this as a "good first issue", we need to make an open issue that references this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Good first issue Open a pull request against these issues if there are no active ones! status: needs rebase status: needs revision
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants
0