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
Sorry for this not getting a response for so long.
Tagged an 1.4.0, but it might slip. I am not very enthusiastic about adding this (I think of scatter as in a different class that the other plotting tools as it can be colormapped).
I'm using scatter() to plot independent variables, as such I expect each call to have it's own color automatically. I came to expect this behavior after using R mostly (both base graphics and ggplot).
In fact, I would expect every "high level" plotting command to cycle colors by default, since cycling colors or choosing a specific color from the RC index (from the user's perspective) is not convenient.
But it would be perfectly fine for me to have another command for having scatter plots. It's a shame that I have to use another library on top of MPL just for such convenience.
I use pyplot all the time, even in scripts :). Only very few methods using the color cycle at the moment (plot and hist, anything else?) and improving this would be nice, but i think this a 2.0 change due to
backward incompatibility.
@Tillsten The danger of using pyplot in scripts is that if the state machine gets out of sync you can get some really strange results. There is a genre of questions on SO that consist of 'the state machine hates me!'
fig, ax = plt.subplots(1, 1)
ax.plot(...)
is less typing, gives you better control, and gives you access to more functions (as pyplot does not wrap everything).
I know, but a) the state is really small: current axis and figure b) i even use pylab 😱, so it is less typing. Note, this is for making figures only, for complicated cases and interaction i change to the oo-interface.
But i complete agree, that beginner should learn learn the oo-interface!
I think we're losing the focus on the issue here.
My argument is that high-level plotting functions should cycle colors by default.
So far, hist() and plot() cycle colors, but nothing else.
scatter() seems high-level enough to me, especially considering that an useful addition to scatter would be the option to have some jitter, which would not be very logical on plot().
I see the argument of backward compatibility, but I was hoping there was some direction in cleaning the API a bit. If not now, a new relase?
The choice of colors is not uniform (box plots for instance do not respect the color index), there's no decent way to get/set the current index color conveniently, and generally speaking I keep having to look at the documentation all the time due to the lack of consistency here and there.
@wavexx I think we all agreeing, that more functions should use color cycling. But there
is probably a lot of code depending on it, breaking it with 1.4 is not worth it imo. One
way address this in the future could be adding an additional rcParam use_color_cycle and defaulting this to true in the following release.
I like this suggestion. Though if we introduce this variable, I'd like to know some things:
What other functions could benefit from color cycling? Otherwise we will end-up in the same situation as someone else finds that X should also color-cycle be we cannot break the API again.
We need a public method to get/set the current color index.
We also need a convenient method to get a valid color from an index.
I never specify colors directly on the various calls. I copy the values myself from the RC into a variable, and keep reusing the variable to have consistent colors. I'm not sure if an integer (as opposed to float) could be distinguished on it's type() and be accepted as a valid color, in the form of rc[color_cycle][index % len(rc[color_cycle])] as gnuplot does. I find this behavior very convenient, especially when producing consistent plots for the same publication, and changing style later is easier.
We should also pull @olgabot (prettyplot), @JanSchultz (yhat ggplot), @mwaskom (seaborn), and @tonyyu (style sheets) in on this conversation. I any work on this should make their lives easier so getting their input sooner rather than later would be good. I also think that the discussions of how/if to change rcparams (ex #2637 ) should be folded in with this.
How many of you all are going to be at scipy?
@wavexx Sorry for completely hi-jacking your (seemingly simple) issue to be 'refactor all the things!'
I will be at SciPy, and my vote is to transition to fixing the default for
scatter so that it can cycle colors in the future. Btw, in case it hasn't
been mentioned yet, the workaround is to pass a Python "None" to the color
argument, IIRC.
We don't use color cycling but either specify our own colors (which uses mpl color cycling in some themes) or use just one default color.
What would be nice is to specify more than one color/point style (linestlye/...) during the ax.something(...) call, as we currently have to do multiple calls and do a groupby with the data for such things. But that's out of scope in this bugreport and also probably completly different than mpl works right now.
from matplotlib import colours
import random
clist = [i for i in colors.ColorConverter.colors if i != 'w']
colour = (i for i in random.sample(clist, len(clist)))
I randomise the names because life is too short to have the same colours also I filter out w which stands for u'wheredmydatago'
import matplotlib.pyplot as plt
from matplotlib import colors
import numpy as np
import random
x = np.random.random(20)
test_list = [(x, x**i) for i in range(1,5)]
fig = plt.figure(figsize=(8, 8)) # make plot
ax =[]
ax.append(fig.add_subplot(111))
clist = [i for i in colors.ColorConverter.colors if i != 'w']
colour = (i for i in random.sample(clist, len(clist)))
for xy in test_list:
c = next(colour)
ax[0].scatter(*xy, marker='o', color = c, label=c)
ax[0].legend(loc='best', shadow=True, fancybox=True)
plt.show()
Finally if you are feeling like a risk taker then replace as clist = [c for c in colors.cnames if c not in ['white', 'snow']] and you might just get a plot coloured by u'palegoldenrod
As a side comment it will break if you have more lines than colours. I leave that to someone else to figure out as I don't require it.
Activity
tacaswell commentedon May 17, 2014
Sorry for this not getting a response for so long.
Tagged an 1.4.0, but it might slip. I am not very enthusiastic about adding this (I think of scatter as in a different class that the other plotting tools as it can be colormapped).
efiring commentedon May 17, 2014
I agree; is there any compelling use case for having scatter cycle the color? Sufficiently compelling to change long-established behavior?
wavexx commentedon May 18, 2014
I'm using scatter() to plot independent variables, as such I expect each call to have it's own color automatically. I came to expect this behavior after using R mostly (both base graphics and ggplot).
In fact, I would expect every "high level" plotting command to cycle colors by default, since cycling colors or choosing a specific color from the RC index (from the user's perspective) is not convenient.
But it would be perfectly fine for me to have another command for having scatter plots. It's a shame that I have to use another library on top of MPL just for such convenience.
tacaswell commentedon May 18, 2014
If you are not varying the size of the markers your are far better off using
plotwith no line than usingscatter.If you are writing loops anyway throwing an extra variable in is not a huge deal (and your not using the pyplot interface in a script are you? ;) ).
Tillsten commentedon May 19, 2014
I use pyplot all the time, even in scripts :). Only very few methods using the color cycle at the moment (plot and hist, anything else?) and improving this would be nice, but i think this a 2.0 change due to
backward incompatibility.
tacaswell commentedon May 19, 2014
@Tillsten The danger of using pyplot in scripts is that if the state machine gets out of sync you can get some really strange results. There is a genre of questions on SO that consist of 'the state machine hates me!'
is less typing, gives you better control, and gives you access to more functions (as pyplot does not wrap everything).
Tillsten commentedon May 19, 2014
I know, but a) the state is really small: current axis and figure b) i even use pylab 😱, so it is less typing. Note, this is for making figures only, for complicated cases and interaction i change to the oo-interface.
But i complete agree, that beginner should learn learn the oo-interface!
pelson commentedon May 20, 2014
Or just understand what the difference is. It's not so complicated. When I teach mpl, I introduce the Axes methods, and then demonstrate that pyplot is just a think wrapper to those. At the end of it, newbie Python developers can describe the pros&cons of pyplot, which I think is a result... (http://nbviewer.ipython.org/github/SciTools/courses/blob/master/course_content/matplotlib_intro.ipynb).
wavexx commentedon May 21, 2014
I think we're losing the focus on the issue here.
My argument is that high-level plotting functions should cycle colors by default.
So far, hist() and plot() cycle colors, but nothing else.
scatter() seems high-level enough to me, especially considering that an useful addition to scatter would be the option to have some jitter, which would not be very logical on plot().
I see the argument of backward compatibility, but I was hoping there was some direction in cleaning the API a bit. If not now, a new relase?
The choice of colors is not uniform (box plots for instance do not respect the color index), there's no decent way to get/set the current index color conveniently, and generally speaking I keep having to look at the documentation all the time due to the lack of consistency here and there.
Tillsten commentedon May 21, 2014
@wavexx I think we all agreeing, that more functions should use color cycling. But there
is probably a lot of code depending on it, breaking it with 1.4 is not worth it imo. One
way address this in the future could be adding an additional rcParam
use_color_cycleand defaulting this to true in the following release.wavexx commentedon May 21, 2014
I like this suggestion. Though if we introduce this variable, I'd like to know some things:
What other functions could benefit from color cycling? Otherwise we will end-up in the same situation as someone else finds that X should also color-cycle be we cannot break the API again.
We need a public method to get/set the current color index.
We also need a convenient method to get a valid color from an index.
I never specify colors directly on the various calls. I copy the values myself from the RC into a variable, and keep reusing the variable to have consistent colors. I'm not sure if an integer (as opposed to float) could be distinguished on it's type() and be accepted as a valid color, in the form of rc[color_cycle][index % len(rc[color_cycle])] as gnuplot does. I find this behavior very convenient, especially when producing consistent plots for the same publication, and changing style later is easier.
11 remaining items
wavexx commentedon May 23, 2014
I like the overall concept, and using decorators.
This could easily be extended to line style as well, which would make generating B/W plots easier.
tacaswell commentedon May 23, 2014
We should also pull @olgabot (prettyplot), @JanSchultz (yhat ggplot), @mwaskom (seaborn), and @tonyyu (style sheets) in on this conversation. I any work on this should make their lives easier so getting their input sooner rather than later would be good. I also think that the discussions of how/if to change rcparams (ex #2637 ) should be folded in with this.
How many of you all are going to be at scipy?
@wavexx Sorry for completely hi-jacking your (seemingly simple) issue to be 'refactor all the things!'
tacaswell commentedon May 23, 2014
Again meant to ping @JanSchulz, sorry for the noise.
mwaskom commentedon May 23, 2014
I won't be at scipy.
Whether or not
scattershould cycle, I would at the very least advocate for the default color being configurable somehow.WeatherGod commentedon May 23, 2014
I will be at SciPy, and my vote is to transition to fixing the default for
scatter so that it can cycle colors in the future. Btw, in case it hasn't
been mentioned yet, the workaround is to pass a Python "None" to the color
argument, IIRC.
On Fri, May 23, 2014 at 11:32 AM, Michael Waskom
notifications@github.comwrote:
jankatins commentedon May 24, 2014
We don't use color cycling but either specify our own colors (which uses mpl color cycling in some themes) or use just one default color.
What would be nice is to specify more than one color/point style (linestlye/...) during the
ax.something(...)call, as we currently have to do multiple calls and do agroupbywith the data for such things. But that's out of scope in this bugreport and also probably completly different than mpl works right now.tacaswell commentedon Jun 19, 2015
@JanSchulz I think #4258 + discussion at end of #3818 will get you towards what you want.
I am closing this issue as it has been quiet for over a year and what of this thread will be addressed is being is being addressed elsewhere.
flipdazed commentedon Jul 10, 2016
This works, taken straight from my own code.
I randomise the
namesbecause life is too short to have the same colours also I filter outwwhich stands foru'wheredmydatago'Finally if you are feeling like a risk taker then replace as
clist = [c for c in colors.cnames if c not in ['white', 'snow']]and you might just get a plot coloured byu'palegoldenrodAs a side comment it will break if you have more lines than colours. I leave that to someone else to figure out as I don't require it.
tacaswell commentedon Jul 10, 2016
This actually went in to 2.0 via #6291 You should checkout the 2.0.0b1 release.