matplotlib-devel Mailing List for matplotlib

Actually, I think I found it. It looks like each backend defines a
new_figure_manager() function. Then, in backends/__init__.py, not only do
the aliased FigureManager and FigureCanvas objects get imported from the
appropriate module, but so does that function. It is pylab_setup() in the
backends/__init__.py that creates the canvas object, it seems?
I guess this is one of those remaining issues that is keeping us from fully
separating pyplot from the rest of matplotlib?
Cheers!
Ben Root
On Sat, Nov 22, 2014 at 4:30 PM, Benjamin Root <ben...@ou...> wrote:
> I thought I had this understood, but now I am confused while working on my
> last chapter. I know that the Figure object never directly creates its own
> canvas object. It starts off with a None object as a placeholder and waits
> for one to be given to it. However, I can only find one place where the
> figure object's set_canvas() method is called, and that is in the canvas's
> print_figure() method to restore itself as the figure's canvas after
> temporaraily switching to another backend for saving.
>
> I thought that the FigureManager initializes the primary canvas object,
> but that doesn't seem to be the case. Where is it done?
>
> Cheers!
> Ben Root
>

I thought I had this understood, but now I am confused while working on my
last chapter. I know that the Figure object never directly creates its own
canvas object. It starts off with a None object as a placeholder and waits
for one to be given to it. However, I can only find one place where the
figure object's set_canvas() method is called, and that is in the canvas's
print_figure() method to restore itself as the figure's canvas after
temporaraily switching to another backend for saving.
I thought that the FigureManager initializes the primary canvas object, but
that doesn't seem to be the case. Where is it done?
Cheers!
Ben Root

The contents of that talk are also in our documentation
http://matplotlib.org/users/colormaps.html
Tom
On Sat Nov 22 2014 at 9:33:11 AM gary ruben <gar...@gm...> wrote:
> There was a talk by Kristen Thyng at scipy2014 that might be a good
> backgrounder for this:
> http://pyvideo.org/video/2769/perceptions-of-matplotlib-colormaps
>
> At the end she references this site http://mycarta.wordpress.com/ of
> Matteo Niccoli which is full of good content. I wonder if it's worth
> contacting Kristen or Matteo to let them know there's a discussion going on
> here that they might be interested in?
>
>
> On 22 November 2014 at 09:53, Eric Firing <ef...@ha...> wrote:
>
>> On 2014年11月21日, 4:42 PM, Nathaniel Smith wrote:
>> > On Fri, Nov 21, 2014 at 5:46 PM, Darren Dale <dsd...@gm...>
>> wrote:
>> >> On Fri, Nov 21, 2014 at 12:32 PM, Phil Elson <pel...@gm...>
>> wrote:
>> >>>
>> >>> Please use this thread to discuss the best choice for a new default
>> >>> matplotlib colormap.
>> >>>
>> >>> This follows on from a discussion on the matplotlib-devel mailing list
>> >>> entitled "How to move beyond JET as the default matplotlib colormap".
>> >>
>> >>
>> >> I remember reading a (peer-reviewed, I think) article about how "jet"
>> was a
>> >> very unfortunate choice of default. I can't find the exact article
>> now, but
>> >> I did find some other useful ones:
>> >>
>> >>
>> http://cresspahl.blogspot.com/2012/03/expanded-control-of-octaves-colormap.html
>> >> http://www.sandia.gov/~kmorel/documents/ColorMaps/
>> >>
>> http://www.sandia.gov/~kmorel/documents/ColorMaps/ColorMapsExpanded.pdf
>> >
>> > Those are good articles. There's a lot of literature on the problems
>> > with "jet", and lots of links in the matplotlib issue [1]. For those
>> > trying to get up to speed quickly, MathWorks recently put together a
>> > nice review of the literature [2]. One particularly striking paper
>> > they cite studied a group of medical students and found that (a) they
>> > were used to/practiced at using jet, (b) when given a choice of
>> > colormaps they said that they preferred jet, (c) they nonetheless made
>> > more *medical diagnostic errors* when using jet than with better
>> > designed colormaps (Borkin et al, 2011).
>> >
>> > I won't suggest a specific colormap, but I do propose that whatever we
>> > chose satisfy the following criteria:
>> >
>> > - it should be a sequential colormap, because diverging colormaps are
>> > really misleading unless you know where the "center" of the data is,
>> > and for a default colormap we generally won't.
>> >
>> > - it should be perceptually uniform, i.e., human subjective judgements
>> > of how far apart nearby colors are should correspond as linearly as
>> > possible to the difference between the numerical values they
>> > represent, at least locally. There's lots of research on how to
>> > measure perceptual distance -- a colleague and I happen to have
>> > recently implemented a state-of-the-art model of this for another
>> > project, in case anyone wants to play with it [3], or just using
>> > good-old-L*a*b* is a reasonable quick-and-dirty approximation.
>> >
>> > - it should have a perceptually uniform luminance ramp, i.e. if you
>> > convert to greyscale it should still be uniform. This is useful both
>> > in practical terms (greyscale printers are still a thing!) and because
>> > luminance is a very strong and natural cue to magnitude.
>> >
>> > - it should also have some kind of variation in hue, because hue
>> > variation is a really helpful additional cue to perception, having two
>> > cues is better than one, and there's no reason not to do it.
>> >
>> > - the hue variation should be chosen to produce reasonable results
>> > even for viewers with the more common types of colorblindness. (Which
>> > rules out things like red-to-green.)
>> >
>> > And, for bonus points, it would be nice to choose a hue ramp that
>> > still works if you throw away the luminance variation, because then we
>> > could use the version with varying luminance for 2d plots, and the
>> > version with just hue variation for 3d plots. (In 3d plots you really
>> > want to reserve the luminance channel for lighting/shading, because
>> > your brain is *really* good at extracting 3d shape from luminance
>> > variation. If the 3d surface itself has massively varying luminance
>> > then this screws up the ability to see shape.)
>> >
>> > Do these seem like good requirements?
>>
>> Goals, yes, though I wouldn't put much weight on the "bonus" criterion.
>> I would add that it should be aesthetically pleasing, or at least
>> comfortable, to most people. Perfection might not be attainable, and
>> some tradeoffs may be required. Is anyone set up to produce test images
>> and/or metrics for judging existing colormaps, or newly designed ones,
>> on all of these criteria?
>>
>> Eric
>>
>> >
>> > -n
>> >
>> > [1] https://github.com/matplotlib/matplotlib/issues/875
>> > [2]
>> http://uk.mathworks.com/company/newsletters/articles/rainbow-color-map-critiques-an-overview-and-annotated-bibliography.html
>> > [3] https://github.com/njsmith/pycam02ucs ; install (or just run out
>> > of the source tree) and then use pycam02ucs.deltaEp_sRGB to compute
>> > the perceptual distance between two RGB colors. It's also possible to
>> > use the underlying color model stuff to do things like generate colors
>> > with evenly spaced luminance and hues, or draw 3d plots of the shape
>> > of the human color space. It's pretty fun to play with :-)
>> >
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
> ------------------------------------------------------------
> ------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&
> iu=/4140/ostg.clktrk_______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

There was a talk by Kristen Thyng at scipy2014 that might be a good
backgrounder for this:
http://pyvideo.org/video/2769/perceptions-of-matplotlib-colormaps
At the end she references this site http://mycarta.wordpress.com/ of Matteo
Niccoli which is full of good content. I wonder if it's worth contacting
Kristen or Matteo to let them know there's a discussion going on here that
they might be interested in?
On 22 November 2014 at 09:53, Eric Firing <ef...@ha...> wrote:
> On 2014年11月21日, 4:42 PM, Nathaniel Smith wrote:
> > On Fri, Nov 21, 2014 at 5:46 PM, Darren Dale <dsd...@gm...> wrote:
> >> On Fri, Nov 21, 2014 at 12:32 PM, Phil Elson <pel...@gm...>
> wrote:
> >>>
> >>> Please use this thread to discuss the best choice for a new default
> >>> matplotlib colormap.
> >>>
> >>> This follows on from a discussion on the matplotlib-devel mailing list
> >>> entitled "How to move beyond JET as the default matplotlib colormap".
> >>
> >>
> >> I remember reading a (peer-reviewed, I think) article about how "jet"
> was a
> >> very unfortunate choice of default. I can't find the exact article now,
> but
> >> I did find some other useful ones:
> >>
> >>
> http://cresspahl.blogspot.com/2012/03/expanded-control-of-octaves-colormap.html
> >> http://www.sandia.gov/~kmorel/documents/ColorMaps/
> >> http://www.sandia.gov/~kmorel/documents/ColorMaps/ColorMapsExpanded.pdf
> >
> > Those are good articles. There's a lot of literature on the problems
> > with "jet", and lots of links in the matplotlib issue [1]. For those
> > trying to get up to speed quickly, MathWorks recently put together a
> > nice review of the literature [2]. One particularly striking paper
> > they cite studied a group of medical students and found that (a) they
> > were used to/practiced at using jet, (b) when given a choice of
> > colormaps they said that they preferred jet, (c) they nonetheless made
> > more *medical diagnostic errors* when using jet than with better
> > designed colormaps (Borkin et al, 2011).
> >
> > I won't suggest a specific colormap, but I do propose that whatever we
> > chose satisfy the following criteria:
> >
> > - it should be a sequential colormap, because diverging colormaps are
> > really misleading unless you know where the "center" of the data is,
> > and for a default colormap we generally won't.
> >
> > - it should be perceptually uniform, i.e., human subjective judgements
> > of how far apart nearby colors are should correspond as linearly as
> > possible to the difference between the numerical values they
> > represent, at least locally. There's lots of research on how to
> > measure perceptual distance -- a colleague and I happen to have
> > recently implemented a state-of-the-art model of this for another
> > project, in case anyone wants to play with it [3], or just using
> > good-old-L*a*b* is a reasonable quick-and-dirty approximation.
> >
> > - it should have a perceptually uniform luminance ramp, i.e. if you
> > convert to greyscale it should still be uniform. This is useful both
> > in practical terms (greyscale printers are still a thing!) and because
> > luminance is a very strong and natural cue to magnitude.
> >
> > - it should also have some kind of variation in hue, because hue
> > variation is a really helpful additional cue to perception, having two
> > cues is better than one, and there's no reason not to do it.
> >
> > - the hue variation should be chosen to produce reasonable results
> > even for viewers with the more common types of colorblindness. (Which
> > rules out things like red-to-green.)
> >
> > And, for bonus points, it would be nice to choose a hue ramp that
> > still works if you throw away the luminance variation, because then we
> > could use the version with varying luminance for 2d plots, and the
> > version with just hue variation for 3d plots. (In 3d plots you really
> > want to reserve the luminance channel for lighting/shading, because
> > your brain is *really* good at extracting 3d shape from luminance
> > variation. If the 3d surface itself has massively varying luminance
> > then this screws up the ability to see shape.)
> >
> > Do these seem like good requirements?
>
> Goals, yes, though I wouldn't put much weight on the "bonus" criterion.
> I would add that it should be aesthetically pleasing, or at least
> comfortable, to most people. Perfection might not be attainable, and
> some tradeoffs may be required. Is anyone set up to produce test images
> and/or metrics for judging existing colormaps, or newly designed ones,
> on all of these criteria?
>
> Eric
>
> >
> > -n
> >
> > [1] https://github.com/matplotlib/matplotlib/issues/875
> > [2]
> http://uk.mathworks.com/company/newsletters/articles/rainbow-color-map-critiques-an-overview-and-annotated-bibliography.html
> > [3] https://github.com/njsmith/pycam02ucs ; install (or just run out
> > of the source tree) and then use pycam02ucs.deltaEp_sRGB to compute
> > the perceptual distance between two RGB colors. It's also possible to
> > use the underlying color model stuff to do things like generate colors
> > with evenly spaced luminance and hues, or draw 3d plots of the shape
> > of the human color space. It's pretty fun to play with :-)
> >
>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

We now have the style system in-place. I envision the 1.5 release as having
the attempt at encoding the current visual style as "classic" (which would
be default), and to put together a "bleeding" (or "trendy" or "hipster")
style that would encode many of the proposed changes to the defaults. Come
mpl2.0, any remaining bugs in the style system should be ironed out, and we
can canonicalize the "hipster" style into a "stable" style. We can even
then utilize "hipster" as a playground of sorts to get feedback on proposed
changes that would work their way into "stable". Each release could also
alias "stable" with a "mplX.Y" style. Another reason why I like this
approach is that it gives us a way to explicitly deprecate various styles
(with warnings and user notes) if an older style becomes a maintenance
burden as matplotlib evolves.
I am also liking the argument that mpl2.0 should be focused on just visual
changes. And logically organized styles will provide users with the needed
"out" to hang onto most of the old visual styles (they would just need to
add a single line to their programs or maybe a config file somewhere).
I am still not convinced that all of the CXX/AGG issues have been ironed
out. While nominal situations seems to have been fairly straight-forward, I
am concerned about error-handling in the interactive backends. As I have
already discovered, the change did introduce a segfaulting error handling
path that merely errored out previously (seems to be fixed now with the
copy constructor fix). These sorts of things aren't covered by our test
suite and can be very backend-dependent.
Cheers!
Ben Root
On Sat, Nov 22, 2014 at 5:16 AM, Phil Elson <pel...@gm...> wrote:
> Given the workload that making a release causes, is it necessary to put
> out a v1.4.3 at all? On a similar sounding argument, given that the removal
> of CXX doesn't break user APIs, and has been on master for several weeks
> with fewer than anticipated side-effects, do we even need a v1.5?
> Essentially, what is the barrier from moving straight to a v2.0 in Feb?
>
> What I'd like to avoid is this idea of "we're talking about a making a
> major release so let's fix everything that was ever broken" - my definition
> of a v2.0 release is really just v1.5+new default cmap. If there are other
> things that need fixing in a backwards incompatible way then we should
> discuss and plan how we are going to do that, and if there is developer
> appetite, there is no reason not to talk about releasing a v3.0 in 18-24
> months (which is currently ~2 mpl minor release cycles).
>
>
> On 21 November 2014 18:56, Thomas Caswell <tca...@gm...> wrote:
>
>> I am a bit wary of doing a 2.0 _just_ to change the color map, but when
>> every I try to write out why, they don't sound convincing. We may end up
>> with a 3.0 within a year or so due to the possible plotting API/pyplot work
>> that is (hopefully) coming.
>>
>> If we are going to do this, I think we should do the 1.4.3 release
>> (scheduled for Feb 1, RCs in mid January), then put one commit to change
>> the color map on top of that, tag 2.0 and then master turns into 2.1.x
>> (targeted for right after scipy?).
>>
>> There is also the thought to get the major c++ refactor work tagged and
>> released sooner rather than later so maybe we want to do 1.4.3, 1.5.0 and
>> 2.0 in Feb with 2.0 based off of 1.5 not 1.4.
>>
>> On Fri Nov 21 2014 at 12:52:03 PM Benjamin Root <ben...@ou...> wrote:
>>
>>> As a point of clarification, is this proposed 2.0 release different from
>>> the 1.5 release?
>>>
>>> On Fri, Nov 21, 2014 at 12:32 PM, Phil Elson <pel...@gm...>
>>> wrote:
>>>
>>>> Many of you will be aware of there has been an ongoing issue (#875,
>>>> http://goo.gl/xLZvuL) which recommends the removal of Jet as the
>>>> default colormap in matplotlib.
>>>>
>>>> The argument against Jet is compelling and I think that as a group who
>>>> care about high quality visualisation we should be seriously discussing how
>>>> matplotlib can move beyond Jet.
>>>>
>>>> There was recently an open letter to the climate science community
>>>> <http://www.climate-lab-book.ac.uk/2014/end-of-the-rainbow/> asking
>>>> for scientists to "pledge" against using rainbow like colormaps (such as
>>>> Jet), and there are similar initiatives in other scientific fields, as well
>>>> as there being a plethora of well researched literature on the subject.
>>>>
>>>> As such, it's time to agree on a solution on how matplotlib can reach
>>>> the end of the rainbow.
>>>>
>>>>
>>>> The two major hurdles, AFAICS, to replacing the three little characters
>>>> which control the default colormap of matplotlib are:
>>>>
>>>> * We haven't had a clear (decisive) discussion about what we should
>>>> replace Jet with.
>>>> * There are concerns about changing the default as it would change the
>>>> existing widespread behaviour.
>>>>
>>>> To address the first point I'll start a new mailinglist thread
>>>> (entitled "Matplotlib's new default colormap") where new default colormap
>>>> suggestions can be made. The thread should strictly avoid "+1" type
>>>> comments, and generally try to stick to reference-able/demonstrable fact,
>>>> rather than opinion. There *will* be a difference of opinion, however
>>>> the final decision has to come down to the project lead (sorry Mike) who I
>>>> know will do whatever is necessary to make the best choice for matplotlib.
>>>>
>>>> The second point is a reasonable response when we consider that
>>>> matplotlib as a project has no *clear* statement on backwards
>>>> compatibility. As a result, matplotlib is highly change averse between
>>>> minor releases (to use semantic versioning terms) and therefore changing
>>>> the default colormap is unpalatable in the v1.x release series. As a result
>>>> I'd like to propose that the next release of matplotlib be called 2.0, with
>>>> the *only* major backwards-incompatible change be the removal of Jet
>>>> as the default colormap.
>>>>
>>>> As a project matplotlib mustn't get caught up in the trap of shying
>>>> away from a major version release when the need arises, and in my opinion
>>>> helping our users to avoid using a misleading colormap is a worthy cause
>>>> for a v2.0.
>>>>
>>>> Please try to keep this thread on the "how", and not on the "what" of
>>>> the replacement default colormap, for which there is a dedicated thread.
>>>>
>>>> Thanks,
>>>>
>>>> Phil
>>>>
>>>> (#endrainbow)
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>>>> with Interactivity, Sharing, Native Excel Exports, App Integration &
>>>> more
>>>> Get technology previously reserved for billion-dollar corporations, FREE
>>>>
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> Matplotlib-devel mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>
>>>>
>>> ------------------------------------------------------------
>>> ------------------
>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>>> Get technology previously reserved for billion-dollar corporations, FREE
>>> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&
>>> iu=/4140/ostg.clktrk_______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>
>

A few thoughts to add to the excellent ones to date, to do with colorbar
behaviour.
My general comment would be that if the axis tick formatter defaults are
changed not to forget about the colorbar as I typically find it needs more
tweaking than the main axes.
I'll make a couple of suggestions, but these are low on the list compared
to the suggestions that others have made.
1. consider rasterizing colorbar contents by default
2. make colorbar axis sizing for matshow behave like imshow
1. consider rasterizing colorbar contents by default
Eric describes this here
http://matplotlib.1069221.n5.nabble.com/rasterized-colorbar-td39582.html
and suggests that rasterizing the colorbar may not be desirable, although
I'm not totally sure why. Perhaps it is because I have noticed that mixing
rasterized content with vector lines/axes in matplotlib is generally
imperfect. If saving the figure as a pdf or svg with dpi left at default,
you can usually see offsets and scaling problems. For example after
rasterizing a colorbar I usually see white pixels along the top and side
within the vector colorbar frame. This also shows up when using imshow or
matshow to show images. I don't know if this is an agg limitation, a
backend limitation or a bug. If it's a known limitation, maybe avoid this
suggestion, but if it's a bug, maybe it can be fixed and then rasterizing
the colorbar might become a better default option.
For colorbars I usually do lots of tweaking along the lines of:
cb = plt.colorbar(format=ScalarFormatter(useMathText=True))
cb.formatter.set_useOffset(False)
cb.formatter.set_scientific(True)
cb.formatter.set_powerlimits((0,2))
cb.update_ticks()
cb.solids.set_rasterized(True)
although I'm not sure about advocating useMathText and set_scientific for
defaults. I wonder what other think about this?
Things like default powerlimits for the colorbar might be rethought. I
think colorbars typically have too many ticks and associated labels and
they should perhaps favour integer labels over floating point
representation if possible.
In the extreme case, for continuous colormaps, often a tick at just the top
and bottom of the range would be adequate.
2. I'm not sure how much pyplot.matshow is generally used but I still use
it.
Could the colorbar height for matshow pick up the axis height of the main
figure, or maybe imshow could default to interpolation='nearest' so I
wouldn't be tempted to use matshow any more?
For example,
plt.matshow(rand(20,20))
plt.colorbar()
doesn't behave nicely like
plt.imshow(rand(20,20), interpolation='nearest')
plt.colorbar()
Gary
On 22 November 2014 at 19:06, Nicolas P. Rougier <Nic...@in...>
wrote:
>
> I would be also quite interested in having better defaults. My list of
> "complains" are:
>
> * Easy way to get only two lines for axis (left and down, instead of four)
> * Better default font (Source Sans Pro / Source Code Pro for example (open
> source))
> * Better default colormap
> * Better axis limit (when you draw with thick lines, they get cut)
> * Better icons for the toolbar (there are a lot of free icons around)
> * Better colors (more pastel)
> * Less "cluttered" figures
> * Lighter grids
>
> + All Nathaniel's suggestions
>
>
> Ideally, we could have a set of standard figures for each main type (plot,
> scatter, quiver) and tweak parameters to search for the best output.
>
>
> Nicolas
>
>
> > On 22 Nov 2014, at 04:18, Benjamin Root <ben...@ou...> wrote:
> >
> > With regards to defaults for 2.0, I am actually all for breaking them
> for the better. What I find important is giving users an easy mechanism to
> use an older style, if it is important to them. The current behavior isn't
> "buggy" (for the most part) and failing to give users a way to get behavior
> that they found desirable would be alienating. I think this is why projects
> like prettyplotlib and seaborn have been so important to matplotlib. It
> enables those who are in the right position to judge styles to explore the
> possibilities easily without commiting matplotlib to any early decision and
> allowing it to have a level of stability that many users find attractive.
> >
> > At the moment, the plans for the OO interface changes should not result
> in any (major) API breaks, so I am not concerned about that at the moment.
> Let's keep focused on style related issues in this thread.
> >
> > Tabbed figures? Intriguing... And I really do need to review that MEP of
> yours...
> >
> > Cheers!
> > Ben Root
> >
> > On Fri, Nov 21, 2014 at 9:36 PM, Federico Ariza <
> ari...@gm...> wrote:
> > I like the idea of aligning a set of changes for 2.0 even if still far
> away.
> >
> > Regarding to backwards compatibility I think that indeed it is important
> but when changing mayor version (1.x to 2.0) becomes less important and we
> must take care of prioritizing evolution.
> > Take for example the OO interface (not defined yet) this is very
> probable to break the current pyplot interface but still this is a change
> that needs to be done.
> >
> > In terms of defaults. I would like to see the new Navigation as default
> (if it gets merged) and tabbed figures (to come after navigation), having
> separate figures feel kind of ..."old"
> >
> > On 21 Nov 2014 21:23, "Benjamin Root" <ben...@ou...> wrote:
> > Some of your wishes are in progress already:
> https://github.com/matplotlib/matplotlib/pull/3818
> > There is also an issue open about scaling the dashes with the line
> width, and you are right, the spacing for the dashes are terrible.
> >
> > I can definitely see the argument to making a bunch of these visual
> changes together. Preferably, I would like to do these changes via style
> sheets so that we can provide a "classic" stylesheet for backwards
> compatibility.
> >
> > I do actually like the autoscaling system as it exists now. The problem
> is that the data margins feature is applied haphazardly. The power spectra
> example is a good example of where we could "smarten" the system. As for
> the ticks... I think that is a very obscure edge-case. I personally prefer
> inward.
> >
> > It is good to get these grievances enumerated. I am interested in seeing
> where this discussion goes.
> >
> > Cheers!
> > Ben Root
> >
> > On Fri, Nov 21, 2014 at 6:22 PM, Nathaniel Smith <nj...@po...> wrote:
> > Hi all,
> >
> > Since we're considering the possibility of making a matplotlib 2.0
> > release with a better default colormap, it occurred to me that it
> > might make sense to take this opportunity to improve other visual
> > defaults.
> >
> > Defaults are important. Obviously for publication graphs you'll want
> > to end up tweaking every detail, but (a) not everyone does but we
> > still have to read their graphs, and (b) probably only 1% of the plots
> > I make are for publication; the rest are quick one-offs that I make
> > on-the-fly to help me understand my own data. For such plots it's
> > usually not worth spending much/any time tweaking layout details, I
> > just want something usable, quickly. And I think there's a fair amount
> > of low-hanging improvements possible.
> >
> > Batching multiple visual changes like this together seems much better
> > than spreading them out over multiple releases. It keeps the messaging
> > super easy to understand: "matplotlib 2.0 is just like 1.x, your code
> > will still work, the only difference is that your plots will look
> > better by default". And grouping these changes together makes it
> > easier to provide for users who need to revert back to the old
> > defaults -- it's easy to provide simple binary choice between "before
> > 2.0" versus "after 2.0", harder to keep track of a bunch of different
> > changes spread over multiple releases.
> >
> > Some particular annoyances I often run into and that might be
> > candidates for changing:
> >
> > - The default method of choosing axis limits is IME really, really
> > annoying, because of the way it tries to find "round number"
> > boundaries. It's a clever idea, but in practice I've almost never seen
> > this pick axis limits that are particularly meaningful for my data,
> > and frequently it picks particularly bad ones. For example, suppose
> > you want to plot the spectrum of a signal; because of FFT's preference
> > for power-of-two sizes works it's natural to end up with samples
> > ranging from 0 to 255. If you plot this, matplotlib will give you an
> > xlim of (0, 300), which looks pretty ridiculous. But even worse is the
> > way this method of choosing xlims can actually obscure data -- if the
> > extreme values in your data set happen to fall exactly on a "round
> > number", then this will be used as the axis limits, and you'll end up
> > with data plotted directly underneath the axis spine. I frequently
> > encounter this when making scatter plots of data in the 0-1 range --
> > the points located at exactly 0 and 1 are very important to see, but
> > are nearly invisible by default. A similar case I ran into recently
> > was when plotting autocorrelation functions for different signals. For
> > reference I wanted to include the theoretically ideal ACF for white
> > noise, which looks like this:
> > plt.plot(np.arange(1000), [1] + [0] * 999)
> > Good luck reading that plot!
> >
> > R's default rule for deciding axis limits is very simple: extend the
> > data range by 4% on each side; those are your limits. IME this rule --
> > while obviously not perfect -- always produces something readable and
> > unobjectionable.
> >
> > - Axis tickmarks should point outwards rather than inwards: There's
> > really no advantage to making them point inwards, and pointing inwards
> > means they can obscure data. My favorite example of this is plotting a
> > histogram with 100 bins -- that's an obvious thing to do, right? Check
> > it out:
> > plt.hist(np.random.RandomState(0).uniform(size=100000), bins=100)
> > This makes me do a double-take every few months until I remember
> > what's going on: "WTF why is the bar on the left showing a *stacked*
> > barplot...ohhhhh right those are just the ticks, which happen to be
> > exactly the same width as the bar." Very confusing.
> >
> > Seaborn's built-in themes give you the options of (1) no axis ticks at
> > all, just a background grid (by default the white-on-light-grey grid
> > as popularized by ggplot2), (2) outwards pointing tickmarks. Either
> > option seems like a better default to me!
> >
> > - Default line colors: The rgbcmyk color cycle for line plots doesn't
> > appear to be based on any real theory about visualization -- it's just
> > the corners of the RGB color cube, which is a highly perceptually
> > non-uniform space. The resulting lines aren't terribly high contrast
> > against the default white background, and the different colors have
> > varying luminance that makes some lines "pop out" more than others.
> >
> > Seaborn's default is to use a nice isoluminant variant on matplotlib's
> default:
> >
> http://web.stanford.edu/~mwaskom/software/seaborn/tutorial/aesthetics.html
> > ggplot2 uses isoluminant colors with maximally-separated hues, which
> > also works well. E.g.:
> >
> http://www.cookbook-r.com/Graphs/Colors_%28ggplot2%29/ggplot2_scale_hue_colors_l45.png
> >
> > - Line thickness: basically every time I make a line plot I wish the
> > lines were thicker. This is another thing that seaborn simply changes
> > unconditionally.
> >
> > In general I guess we could do a lot worse than to simply adopt
> > seaborn's defaults as the matplotlib defaults :-) Their full list of
> > overrides can be seen here:
> > https://github.com/mwaskom/seaborn/blob/master/seaborn/rcmod.py#L135
> > https://github.com/mwaskom/seaborn/blob/master/seaborn/rcmod.py#L301
> >
> > - Dash styles: a common recommendation for line plots is to
> > simultaneously vary both the color and the dash style of your lines,
> > because redundant cues are good and dash styles are more robust than
> > color in the face of greyscale printing etc. But every time I try to
> > follow this advice I find myself having to define new dashes from
> > scratch, because matplotlib's default dash styles ("-", "--", "-.",
> > ":") have wildly varying weights; in particular I often find it hard
> > to even see the dots in the ":" and "-." styles. Here's someone with a
> > similar complaint:
> >
> http://philbull.wordpress.com/2012/03/14/custom-dashdot-line-styles-in-matplotlib/
> >
> > Just as very rough numbers, something along the lines of "--" = [7,
> > 4], "-." = [7, 4, 3, 4], ":" = [2, 1.5] looks much better to me.
> >
> > It might also make sense to consider baking the advice I mentioned
> > above into matplotlib directly, and having a non-trivial dash cycle
> > enabled by default. (So the first line plotted uses "-", second uses
> > "--" or similar, etc.) This would also have the advantage that if we
> > make the length of the color cycle and the dash cycle relatively
> > prime, then we'll dramatically increase the number of lines that can
> > be plotted on the same graph with distinct appearances. (I often run
> > into the annoying situation where I throw up a quick-and-dirty plot,
> > maybe with something like pandas's dataframe.plot(), and then discover
> > that I have multiple indistinguishable lines.)
> >
> > Obviously one could quibble with my specific proposals here, but does
> > in general seem like a useful thing to do?
> >
> > -n
> >
> > --
> > Nathaniel J. Smith
> > Postdoctoral researcher - Informatics - University of Edinburgh
> > http://vorpus.org
> >
> >
> ------------------------------------------------------------------------------
> > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> > from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> > with Interactivity, Sharing, Native Excel Exports, App Integration & more
> > Get technology previously reserved for billion-dollar corporations, FREE
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
> >
> >
> ------------------------------------------------------------------------------
> > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> > from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> > with Interactivity, Sharing, Native Excel Exports, App Integration & more
> > Get technology previously reserved for billion-dollar corporations, FREE
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
> >
> >
> ------------------------------------------------------------------------------
> > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> > from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> > with Interactivity, Sharing, Native Excel Exports, App Integration & more
> > Get technology previously reserved for billion-dollar corporations, FREE
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk_______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

I think using native icons would be the best scenario, at least whet the
backend and platform support it.
On Nov 22, 2014 9:08 AM, "Nicolas P. Rougier" <Nic...@in...>
wrote:
>
> I would be also quite interested in having better defaults. My list of
> "complains" are:
>
> * Easy way to get only two lines for axis (left and down, instead of four)
> * Better default font (Source Sans Pro / Source Code Pro for example (open
> source))
> * Better default colormap
> * Better axis limit (when you draw with thick lines, they get cut)
> * Better icons for the toolbar (there are a lot of free icons around)
> * Better colors (more pastel)
> * Less "cluttered" figures
> * Lighter grids
>
> + All Nathaniel's suggestions
>
>
> Ideally, we could have a set of standard figures for each main type (plot,
> scatter, quiver) and tweak parameters to search for the best output.
>
>
> Nicolas
>
>
> > On 22 Nov 2014, at 04:18, Benjamin Root <ben...@ou...> wrote:
> >
> > With regards to defaults for 2.0, I am actually all for breaking them
> for the better. What I find important is giving users an easy mechanism to
> use an older style, if it is important to them. The current behavior isn't
> "buggy" (for the most part) and failing to give users a way to get behavior
> that they found desirable would be alienating. I think this is why projects
> like prettyplotlib and seaborn have been so important to matplotlib. It
> enables those who are in the right position to judge styles to explore the
> possibilities easily without commiting matplotlib to any early decision and
> allowing it to have a level of stability that many users find attractive.
> >
> > At the moment, the plans for the OO interface changes should not result
> in any (major) API breaks, so I am not concerned about that at the moment.
> Let's keep focused on style related issues in this thread.
> >
> > Tabbed figures? Intriguing... And I really do need to review that MEP of
> yours...
> >
> > Cheers!
> > Ben Root
> >
> > On Fri, Nov 21, 2014 at 9:36 PM, Federico Ariza <
> ari...@gm...> wrote:
> > I like the idea of aligning a set of changes for 2.0 even if still far
> away.
> >
> > Regarding to backwards compatibility I think that indeed it is important
> but when changing mayor version (1.x to 2.0) becomes less important and we
> must take care of prioritizing evolution.
> > Take for example the OO interface (not defined yet) this is very
> probable to break the current pyplot interface but still this is a change
> that needs to be done.
> >
> > In terms of defaults. I would like to see the new Navigation as default
> (if it gets merged) and tabbed figures (to come after navigation), having
> separate figures feel kind of ..."old"
> >
> > On 21 Nov 2014 21:23, "Benjamin Root" <ben...@ou...> wrote:
> > Some of your wishes are in progress already:
> https://github.com/matplotlib/matplotlib/pull/3818
> > There is also an issue open about scaling the dashes with the line
> width, and you are right, the spacing for the dashes are terrible.
> >
> > I can definitely see the argument to making a bunch of these visual
> changes together. Preferably, I would like to do these changes via style
> sheets so that we can provide a "classic" stylesheet for backwards
> compatibility.
> >
> > I do actually like the autoscaling system as it exists now. The problem
> is that the data margins feature is applied haphazardly. The power spectra
> example is a good example of where we could "smarten" the system. As for
> the ticks... I think that is a very obscure edge-case. I personally prefer
> inward.
> >
> > It is good to get these grievances enumerated. I am interested in seeing
> where this discussion goes.
> >
> > Cheers!
> > Ben Root
> >
> > On Fri, Nov 21, 2014 at 6:22 PM, Nathaniel Smith <nj...@po...> wrote:
> > Hi all,
> >
> > Since we're considering the possibility of making a matplotlib 2.0
> > release with a better default colormap, it occurred to me that it
> > might make sense to take this opportunity to improve other visual
> > defaults.
> >
> > Defaults are important. Obviously for publication graphs you'll want
> > to end up tweaking every detail, but (a) not everyone does but we
> > still have to read their graphs, and (b) probably only 1% of the plots
> > I make are for publication; the rest are quick one-offs that I make
> > on-the-fly to help me understand my own data. For such plots it's
> > usually not worth spending much/any time tweaking layout details, I
> > just want something usable, quickly. And I think there's a fair amount
> > of low-hanging improvements possible.
> >
> > Batching multiple visual changes like this together seems much better
> > than spreading them out over multiple releases. It keeps the messaging
> > super easy to understand: "matplotlib 2.0 is just like 1.x, your code
> > will still work, the only difference is that your plots will look
> > better by default". And grouping these changes together makes it
> > easier to provide for users who need to revert back to the old
> > defaults -- it's easy to provide simple binary choice between "before
> > 2.0" versus "after 2.0", harder to keep track of a bunch of different
> > changes spread over multiple releases.
> >
> > Some particular annoyances I often run into and that might be
> > candidates for changing:
> >
> > - The default method of choosing axis limits is IME really, really
> > annoying, because of the way it tries to find "round number"
> > boundaries. It's a clever idea, but in practice I've almost never seen
> > this pick axis limits that are particularly meaningful for my data,
> > and frequently it picks particularly bad ones. For example, suppose
> > you want to plot the spectrum of a signal; because of FFT's preference
> > for power-of-two sizes works it's natural to end up with samples
> > ranging from 0 to 255. If you plot this, matplotlib will give you an
> > xlim of (0, 300), which looks pretty ridiculous. But even worse is the
> > way this method of choosing xlims can actually obscure data -- if the
> > extreme values in your data set happen to fall exactly on a "round
> > number", then this will be used as the axis limits, and you'll end up
> > with data plotted directly underneath the axis spine. I frequently
> > encounter this when making scatter plots of data in the 0-1 range --
> > the points located at exactly 0 and 1 are very important to see, but
> > are nearly invisible by default. A similar case I ran into recently
> > was when plotting autocorrelation functions for different signals. For
> > reference I wanted to include the theoretically ideal ACF for white
> > noise, which looks like this:
> > plt.plot(np.arange(1000), [1] + [0] * 999)
> > Good luck reading that plot!
> >
> > R's default rule for deciding axis limits is very simple: extend the
> > data range by 4% on each side; those are your limits. IME this rule --
> > while obviously not perfect -- always produces something readable and
> > unobjectionable.
> >
> > - Axis tickmarks should point outwards rather than inwards: There's
> > really no advantage to making them point inwards, and pointing inwards
> > means they can obscure data. My favorite example of this is plotting a
> > histogram with 100 bins -- that's an obvious thing to do, right? Check
> > it out:
> > plt.hist(np.random.RandomState(0).uniform(size=100000), bins=100)
> > This makes me do a double-take every few months until I remember
> > what's going on: "WTF why is the bar on the left showing a *stacked*
> > barplot...ohhhhh right those are just the ticks, which happen to be
> > exactly the same width as the bar." Very confusing.
> >
> > Seaborn's built-in themes give you the options of (1) no axis ticks at
> > all, just a background grid (by default the white-on-light-grey grid
> > as popularized by ggplot2), (2) outwards pointing tickmarks. Either
> > option seems like a better default to me!
> >
> > - Default line colors: The rgbcmyk color cycle for line plots doesn't
> > appear to be based on any real theory about visualization -- it's just
> > the corners of the RGB color cube, which is a highly perceptually
> > non-uniform space. The resulting lines aren't terribly high contrast
> > against the default white background, and the different colors have
> > varying luminance that makes some lines "pop out" more than others.
> >
> > Seaborn's default is to use a nice isoluminant variant on matplotlib's
> default:
> >
> http://web.stanford.edu/~mwaskom/software/seaborn/tutorial/aesthetics.html
> > ggplot2 uses isoluminant colors with maximally-separated hues, which
> > also works well. E.g.:
> >
> http://www.cookbook-r.com/Graphs/Colors_%28ggplot2%29/ggplot2_scale_hue_colors_l45.png
> >
> > - Line thickness: basically every time I make a line plot I wish the
> > lines were thicker. This is another thing that seaborn simply changes
> > unconditionally.
> >
> > In general I guess we could do a lot worse than to simply adopt
> > seaborn's defaults as the matplotlib defaults :-) Their full list of
> > overrides can be seen here:
> > https://github.com/mwaskom/seaborn/blob/master/seaborn/rcmod.py#L135
> > https://github.com/mwaskom/seaborn/blob/master/seaborn/rcmod.py#L301
> >
> > - Dash styles: a common recommendation for line plots is to
> > simultaneously vary both the color and the dash style of your lines,
> > because redundant cues are good and dash styles are more robust than
> > color in the face of greyscale printing etc. But every time I try to
> > follow this advice I find myself having to define new dashes from
> > scratch, because matplotlib's default dash styles ("-", "--", "-.",
> > ":") have wildly varying weights; in particular I often find it hard
> > to even see the dots in the ":" and "-." styles. Here's someone with a
> > similar complaint:
> >
> http://philbull.wordpress.com/2012/03/14/custom-dashdot-line-styles-in-matplotlib/
> >
> > Just as very rough numbers, something along the lines of "--" = [7,
> > 4], "-." = [7, 4, 3, 4], ":" = [2, 1.5] looks much better to me.
> >
> > It might also make sense to consider baking the advice I mentioned
> > above into matplotlib directly, and having a non-trivial dash cycle
> > enabled by default. (So the first line plotted uses "-", second uses
> > "--" or similar, etc.) This would also have the advantage that if we
> > make the length of the color cycle and the dash cycle relatively
> > prime, then we'll dramatically increase the number of lines that can
> > be plotted on the same graph with distinct appearances. (I often run
> > into the annoying situation where I throw up a quick-and-dirty plot,
> > maybe with something like pandas's dataframe.plot(), and then discover
> > that I have multiple indistinguishable lines.)
> >
> > Obviously one could quibble with my specific proposals here, but does
> > in general seem like a useful thing to do?
> >
> > -n
> >
> > --
> > Nathaniel J. Smith
> > Postdoctoral researcher - Informatics - University of Edinburgh
> > http://vorpus.org
> >
> >
> ------------------------------------------------------------------------------
> > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> > from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> > with Interactivity, Sharing, Native Excel Exports, App Integration & more
> > Get technology previously reserved for billion-dollar corporations, FREE
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
> >
> >
> ------------------------------------------------------------------------------
> > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> > from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> > with Interactivity, Sharing, Native Excel Exports, App Integration & more
> > Get technology previously reserved for billion-dollar corporations, FREE
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
> >
> >
> ------------------------------------------------------------------------------
> > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> > from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> > with Interactivity, Sharing, Native Excel Exports, App Integration & more
> > Get technology previously reserved for billion-dollar corporations, FREE
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk_______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Given the workload that making a release causes, is it necessary to put out
a v1.4.3 at all? On a similar sounding argument, given that the removal of
CXX doesn't break user APIs, and has been on master for several weeks with
fewer than anticipated side-effects, do we even need a v1.5? Essentially,
what is the barrier from moving straight to a v2.0 in Feb?
What I'd like to avoid is this idea of "we're talking about a making a
major release so let's fix everything that was ever broken" - my definition
of a v2.0 release is really just v1.5+new default cmap. If there are other
things that need fixing in a backwards incompatible way then we should
discuss and plan how we are going to do that, and if there is developer
appetite, there is no reason not to talk about releasing a v3.0 in 18-24
months (which is currently ~2 mpl minor release cycles).
On 21 November 2014 18:56, Thomas Caswell <tca...@gm...> wrote:
> I am a bit wary of doing a 2.0 _just_ to change the color map, but when
> every I try to write out why, they don't sound convincing. We may end up
> with a 3.0 within a year or so due to the possible plotting API/pyplot work
> that is (hopefully) coming.
>
> If we are going to do this, I think we should do the 1.4.3 release
> (scheduled for Feb 1, RCs in mid January), then put one commit to change
> the color map on top of that, tag 2.0 and then master turns into 2.1.x
> (targeted for right after scipy?).
>
> There is also the thought to get the major c++ refactor work tagged and
> released sooner rather than later so maybe we want to do 1.4.3, 1.5.0 and
> 2.0 in Feb with 2.0 based off of 1.5 not 1.4.
>
> On Fri Nov 21 2014 at 12:52:03 PM Benjamin Root <ben...@ou...> wrote:
>
>> As a point of clarification, is this proposed 2.0 release different from
>> the 1.5 release?
>>
>> On Fri, Nov 21, 2014 at 12:32 PM, Phil Elson <pel...@gm...>
>> wrote:
>>
>>> Many of you will be aware of there has been an ongoing issue (#875,
>>> http://goo.gl/xLZvuL) which recommends the removal of Jet as the
>>> default colormap in matplotlib.
>>>
>>> The argument against Jet is compelling and I think that as a group who
>>> care about high quality visualisation we should be seriously discussing how
>>> matplotlib can move beyond Jet.
>>>
>>> There was recently an open letter to the climate science community
>>> <http://www.climate-lab-book.ac.uk/2014/end-of-the-rainbow/> asking for
>>> scientists to "pledge" against using rainbow like colormaps (such as Jet),
>>> and there are similar initiatives in other scientific fields, as well as
>>> there being a plethora of well researched literature on the subject.
>>>
>>> As such, it's time to agree on a solution on how matplotlib can reach
>>> the end of the rainbow.
>>>
>>>
>>> The two major hurdles, AFAICS, to replacing the three little characters
>>> which control the default colormap of matplotlib are:
>>>
>>> * We haven't had a clear (decisive) discussion about what we should
>>> replace Jet with.
>>> * There are concerns about changing the default as it would change the
>>> existing widespread behaviour.
>>>
>>> To address the first point I'll start a new mailinglist thread (entitled
>>> "Matplotlib's new default colormap") where new default colormap suggestions
>>> can be made. The thread should strictly avoid "+1" type comments, and
>>> generally try to stick to reference-able/demonstrable fact, rather than
>>> opinion. There *will* be a difference of opinion, however the final
>>> decision has to come down to the project lead (sorry Mike) who I know will
>>> do whatever is necessary to make the best choice for matplotlib.
>>>
>>> The second point is a reasonable response when we consider that
>>> matplotlib as a project has no *clear* statement on backwards
>>> compatibility. As a result, matplotlib is highly change averse between
>>> minor releases (to use semantic versioning terms) and therefore changing
>>> the default colormap is unpalatable in the v1.x release series. As a result
>>> I'd like to propose that the next release of matplotlib be called 2.0, with
>>> the *only* major backwards-incompatible change be the removal of Jet as
>>> the default colormap.
>>>
>>> As a project matplotlib mustn't get caught up in the trap of shying away
>>> from a major version release when the need arises, and in my opinion
>>> helping our users to avoid using a misleading colormap is a worthy cause
>>> for a v2.0.
>>>
>>> Please try to keep this thread on the "how", and not on the "what" of
>>> the replacement default colormap, for which there is a dedicated thread.
>>>
>>> Thanks,
>>>
>>> Phil
>>>
>>> (#endrainbow)
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>>> Get technology previously reserved for billion-dollar corporations, FREE
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>>
>> ------------------------------------------------------------
>> ------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&
>> iu=/4140/ostg.clktrk_______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>

I would be also quite interested in having better defaults. My list of "complains" are:
* Easy way to get only two lines for axis (left and down, instead of four)
* Better default font (Source Sans Pro / Source Code Pro for example (open source))
* Better default colormap
* Better axis limit (when you draw with thick lines, they get cut)
* Better icons for the toolbar (there are a lot of free icons around)
* Better colors (more pastel)
* Less "cluttered" figures
* Lighter grids
+ All Nathaniel's suggestions
Ideally, we could have a set of standard figures for each main type (plot, scatter, quiver) and tweak parameters to search for the best output.
Nicolas
> On 22 Nov 2014, at 04:18, Benjamin Root <ben...@ou...> wrote:
> 
> With regards to defaults for 2.0, I am actually all for breaking them for the better. What I find important is giving users an easy mechanism to use an older style, if it is important to them. The current behavior isn't "buggy" (for the most part) and failing to give users a way to get behavior that they found desirable would be alienating. I think this is why projects like prettyplotlib and seaborn have been so important to matplotlib. It enables those who are in the right position to judge styles to explore the possibilities easily without commiting matplotlib to any early decision and allowing it to have a level of stability that many users find attractive.
> 
> At the moment, the plans for the OO interface changes should not result in any (major) API breaks, so I am not concerned about that at the moment. Let's keep focused on style related issues in this thread.
> 
> Tabbed figures? Intriguing... And I really do need to review that MEP of yours...
> 
> Cheers!
> Ben Root
> 
> On Fri, Nov 21, 2014 at 9:36 PM, Federico Ariza <ari...@gm...> wrote:
> I like the idea of aligning a set of changes for 2.0 even if still far away.
> 
> Regarding to backwards compatibility I think that indeed it is important but when changing mayor version (1.x to 2.0) becomes less important and we must take care of prioritizing evolution. 
> Take for example the OO interface (not defined yet) this is very probable to break the current pyplot interface but still this is a change that needs to be done.
> 
> In terms of defaults. I would like to see the new Navigation as default (if it gets merged) and tabbed figures (to come after navigation), having separate figures feel kind of ..."old"
> 
> On 21 Nov 2014 21:23, "Benjamin Root" <ben...@ou...> wrote:
> Some of your wishes are in progress already: https://github.com/matplotlib/matplotlib/pull/3818
> There is also an issue open about scaling the dashes with the line width, and you are right, the spacing for the dashes are terrible.
> 
> I can definitely see the argument to making a bunch of these visual changes together. Preferably, I would like to do these changes via style sheets so that we can provide a "classic" stylesheet for backwards compatibility.
> 
> I do actually like the autoscaling system as it exists now. The problem is that the data margins feature is applied haphazardly. The power spectra example is a good example of where we could "smarten" the system. As for the ticks... I think that is a very obscure edge-case. I personally prefer inward.
> 
> It is good to get these grievances enumerated. I am interested in seeing where this discussion goes.
> 
> Cheers!
> Ben Root
> 
> On Fri, Nov 21, 2014 at 6:22 PM, Nathaniel Smith <nj...@po...> wrote:
> Hi all,
> 
> Since we're considering the possibility of making a matplotlib 2.0
> release with a better default colormap, it occurred to me that it
> might make sense to take this opportunity to improve other visual
> defaults.
> 
> Defaults are important. Obviously for publication graphs you'll want
> to end up tweaking every detail, but (a) not everyone does but we
> still have to read their graphs, and (b) probably only 1% of the plots
> I make are for publication; the rest are quick one-offs that I make
> on-the-fly to help me understand my own data. For such plots it's
> usually not worth spending much/any time tweaking layout details, I
> just want something usable, quickly. And I think there's a fair amount
> of low-hanging improvements possible.
> 
> Batching multiple visual changes like this together seems much better
> than spreading them out over multiple releases. It keeps the messaging
> super easy to understand: "matplotlib 2.0 is just like 1.x, your code
> will still work, the only difference is that your plots will look
> better by default". And grouping these changes together makes it
> easier to provide for users who need to revert back to the old
> defaults -- it's easy to provide simple binary choice between "before
> 2.0" versus "after 2.0", harder to keep track of a bunch of different
> changes spread over multiple releases.
> 
> Some particular annoyances I often run into and that might be
> candidates for changing:
> 
> - The default method of choosing axis limits is IME really, really
> annoying, because of the way it tries to find "round number"
> boundaries. It's a clever idea, but in practice I've almost never seen
> this pick axis limits that are particularly meaningful for my data,
> and frequently it picks particularly bad ones. For example, suppose
> you want to plot the spectrum of a signal; because of FFT's preference
> for power-of-two sizes works it's natural to end up with samples
> ranging from 0 to 255. If you plot this, matplotlib will give you an
> xlim of (0, 300), which looks pretty ridiculous. But even worse is the
> way this method of choosing xlims can actually obscure data -- if the
> extreme values in your data set happen to fall exactly on a "round
> number", then this will be used as the axis limits, and you'll end up
> with data plotted directly underneath the axis spine. I frequently
> encounter this when making scatter plots of data in the 0-1 range --
> the points located at exactly 0 and 1 are very important to see, but
> are nearly invisible by default. A similar case I ran into recently
> was when plotting autocorrelation functions for different signals. For
> reference I wanted to include the theoretically ideal ACF for white
> noise, which looks like this:
> plt.plot(np.arange(1000), [1] + [0] * 999)
> Good luck reading that plot!
> 
> R's default rule for deciding axis limits is very simple: extend the
> data range by 4% on each side; those are your limits. IME this rule --
> while obviously not perfect -- always produces something readable and
> unobjectionable.
> 
> - Axis tickmarks should point outwards rather than inwards: There's
> really no advantage to making them point inwards, and pointing inwards
> means they can obscure data. My favorite example of this is plotting a
> histogram with 100 bins -- that's an obvious thing to do, right? Check
> it out:
> plt.hist(np.random.RandomState(0).uniform(size=100000), bins=100)
> This makes me do a double-take every few months until I remember
> what's going on: "WTF why is the bar on the left showing a *stacked*
> barplot...ohhhhh right those are just the ticks, which happen to be
> exactly the same width as the bar." Very confusing.
> 
> Seaborn's built-in themes give you the options of (1) no axis ticks at
> all, just a background grid (by default the white-on-light-grey grid
> as popularized by ggplot2), (2) outwards pointing tickmarks. Either
> option seems like a better default to me!
> 
> - Default line colors: The rgbcmyk color cycle for line plots doesn't
> appear to be based on any real theory about visualization -- it's just
> the corners of the RGB color cube, which is a highly perceptually
> non-uniform space. The resulting lines aren't terribly high contrast
> against the default white background, and the different colors have
> varying luminance that makes some lines "pop out" more than others.
> 
> Seaborn's default is to use a nice isoluminant variant on matplotlib's default:
> http://web.stanford.edu/~mwaskom/software/seaborn/tutorial/aesthetics.html
> ggplot2 uses isoluminant colors with maximally-separated hues, which
> also works well. E.g.:
> http://www.cookbook-r.com/Graphs/Colors_%28ggplot2%29/ggplot2_scale_hue_colors_l45.png
> 
> - Line thickness: basically every time I make a line plot I wish the
> lines were thicker. This is another thing that seaborn simply changes
> unconditionally.
> 
> In general I guess we could do a lot worse than to simply adopt
> seaborn's defaults as the matplotlib defaults :-) Their full list of
> overrides can be seen here:
> https://github.com/mwaskom/seaborn/blob/master/seaborn/rcmod.py#L135
> https://github.com/mwaskom/seaborn/blob/master/seaborn/rcmod.py#L301
> 
> - Dash styles: a common recommendation for line plots is to
> simultaneously vary both the color and the dash style of your lines,
> because redundant cues are good and dash styles are more robust than
> color in the face of greyscale printing etc. But every time I try to
> follow this advice I find myself having to define new dashes from
> scratch, because matplotlib's default dash styles ("-", "--", "-.",
> ":") have wildly varying weights; in particular I often find it hard
> to even see the dots in the ":" and "-." styles. Here's someone with a
> similar complaint:
> http://philbull.wordpress.com/2012/03/14/custom-dashdot-line-styles-in-matplotlib/
> 
> Just as very rough numbers, something along the lines of "--" = [7,
> 4], "-." = [7, 4, 3, 4], ":" = [2, 1.5] looks much better to me.
> 
> It might also make sense to consider baking the advice I mentioned
> above into matplotlib directly, and having a non-trivial dash cycle
> enabled by default. (So the first line plotted uses "-", second uses
> "--" or similar, etc.) This would also have the advantage that if we
> make the length of the color cycle and the dash cycle relatively
> prime, then we'll dramatically increase the number of lines that can
> be plotted on the same graph with distinct appearances. (I often run
> into the annoying situation where I throw up a quick-and-dirty plot,
> maybe with something like pandas's dataframe.plot(), and then discover
> that I have multiple indistinguishable lines.)
> 
> Obviously one could quibble with my specific proposals here, but does
> in general seem like a useful thing to do?
> 
> -n
> 
> --
> Nathaniel J. Smith
> Postdoctoral researcher - Informatics - University of Edinburgh
> http://vorpus.org
> 
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk_______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

With regards to defaults for 2.0, I am actually all for breaking them for
the better. What I find important is giving users an easy mechanism to use
an older style, if it is important to them. The current behavior isn't
"buggy" (for the most part) and failing to give users a way to get behavior
that they found desirable would be alienating. I think this is why projects
like prettyplotlib and seaborn have been so important to matplotlib. It
enables those who are in the right position to judge styles to explore the
possibilities easily without commiting matplotlib to any early decision and
allowing it to have a level of stability that many users find attractive.
At the moment, the plans for the OO interface changes should not result in
any (major) API breaks, so I am not concerned about that at the moment.
Let's keep focused on style related issues in this thread.
Tabbed figures? Intriguing... And I really do need to review that MEP of
yours...
Cheers!
Ben Root
On Fri, Nov 21, 2014 at 9:36 PM, Federico Ariza <ari...@gm...>
wrote:
> I like the idea of aligning a set of changes for 2.0 even if still far
> away.
>
> Regarding to backwards compatibility I think that indeed it is important
> but when changing mayor version (1.x to 2.0) becomes less important and we
> must take care of prioritizing evolution.
> Take for example the OO interface (not defined yet) this is very probable
> to break the current pyplot interface but still this is a change that needs
> to be done.
>
> In terms of defaults. I would like to see the new Navigation as default
> (if it gets merged) and tabbed figures (to come after navigation), having
> separate figures feel kind of ..."old"
> On 21 Nov 2014 21:23, "Benjamin Root" <ben...@ou...> wrote:
>
>> Some of your wishes are in progress already:
>> https://github.com/matplotlib/matplotlib/pull/3818
>> There is also an issue open about scaling the dashes with the line width,
>> and you are right, the spacing for the dashes are terrible.
>>
>> I can definitely see the argument to making a bunch of these visual
>> changes together. Preferably, I would like to do these changes via style
>> sheets so that we can provide a "classic" stylesheet for backwards
>> compatibility.
>>
>> I do actually like the autoscaling system as it exists now. The problem
>> is that the data margins feature is applied haphazardly. The power spectra
>> example is a good example of where we could "smarten" the system. As for
>> the ticks... I think that is a very obscure edge-case. I personally prefer
>> inward.
>>
>> It is good to get these grievances enumerated. I am interested in seeing
>> where this discussion goes.
>>
>> Cheers!
>> Ben Root
>>
>> On Fri, Nov 21, 2014 at 6:22 PM, Nathaniel Smith <nj...@po...> wrote:
>>
>>> Hi all,
>>>
>>> Since we're considering the possibility of making a matplotlib 2.0
>>> release with a better default colormap, it occurred to me that it
>>> might make sense to take this opportunity to improve other visual
>>> defaults.
>>>
>>> Defaults are important. Obviously for publication graphs you'll want
>>> to end up tweaking every detail, but (a) not everyone does but we
>>> still have to read their graphs, and (b) probably only 1% of the plots
>>> I make are for publication; the rest are quick one-offs that I make
>>> on-the-fly to help me understand my own data. For such plots it's
>>> usually not worth spending much/any time tweaking layout details, I
>>> just want something usable, quickly. And I think there's a fair amount
>>> of low-hanging improvements possible.
>>>
>>> Batching multiple visual changes like this together seems much better
>>> than spreading them out over multiple releases. It keeps the messaging
>>> super easy to understand: "matplotlib 2.0 is just like 1.x, your code
>>> will still work, the only difference is that your plots will look
>>> better by default". And grouping these changes together makes it
>>> easier to provide for users who need to revert back to the old
>>> defaults -- it's easy to provide simple binary choice between "before
>>> 2.0" versus "after 2.0", harder to keep track of a bunch of different
>>> changes spread over multiple releases.
>>>
>>> Some particular annoyances I often run into and that might be
>>> candidates for changing:
>>>
>>> - The default method of choosing axis limits is IME really, really
>>> annoying, because of the way it tries to find "round number"
>>> boundaries. It's a clever idea, but in practice I've almost never seen
>>> this pick axis limits that are particularly meaningful for my data,
>>> and frequently it picks particularly bad ones. For example, suppose
>>> you want to plot the spectrum of a signal; because of FFT's preference
>>> for power-of-two sizes works it's natural to end up with samples
>>> ranging from 0 to 255. If you plot this, matplotlib will give you an
>>> xlim of (0, 300), which looks pretty ridiculous. But even worse is the
>>> way this method of choosing xlims can actually obscure data -- if the
>>> extreme values in your data set happen to fall exactly on a "round
>>> number", then this will be used as the axis limits, and you'll end up
>>> with data plotted directly underneath the axis spine. I frequently
>>> encounter this when making scatter plots of data in the 0-1 range --
>>> the points located at exactly 0 and 1 are very important to see, but
>>> are nearly invisible by default. A similar case I ran into recently
>>> was when plotting autocorrelation functions for different signals. For
>>> reference I wanted to include the theoretically ideal ACF for white
>>> noise, which looks like this:
>>> plt.plot(np.arange(1000), [1] + [0] * 999)
>>> Good luck reading that plot!
>>>
>>> R's default rule for deciding axis limits is very simple: extend the
>>> data range by 4% on each side; those are your limits. IME this rule --
>>> while obviously not perfect -- always produces something readable and
>>> unobjectionable.
>>>
>>> - Axis tickmarks should point outwards rather than inwards: There's
>>> really no advantage to making them point inwards, and pointing inwards
>>> means they can obscure data. My favorite example of this is plotting a
>>> histogram with 100 bins -- that's an obvious thing to do, right? Check
>>> it out:
>>> plt.hist(np.random.RandomState(0).uniform(size=100000), bins=100)
>>> This makes me do a double-take every few months until I remember
>>> what's going on: "WTF why is the bar on the left showing a *stacked*
>>> barplot...ohhhhh right those are just the ticks, which happen to be
>>> exactly the same width as the bar." Very confusing.
>>>
>>> Seaborn's built-in themes give you the options of (1) no axis ticks at
>>> all, just a background grid (by default the white-on-light-grey grid
>>> as popularized by ggplot2), (2) outwards pointing tickmarks. Either
>>> option seems like a better default to me!
>>>
>>> - Default line colors: The rgbcmyk color cycle for line plots doesn't
>>> appear to be based on any real theory about visualization -- it's just
>>> the corners of the RGB color cube, which is a highly perceptually
>>> non-uniform space. The resulting lines aren't terribly high contrast
>>> against the default white background, and the different colors have
>>> varying luminance that makes some lines "pop out" more than others.
>>>
>>> Seaborn's default is to use a nice isoluminant variant on matplotlib's
>>> default:
>>>
>>> http://web.stanford.edu/~mwaskom/software/seaborn/tutorial/aesthetics.html
>>> ggplot2 uses isoluminant colors with maximally-separated hues, which
>>> also works well. E.g.:
>>>
>>> http://www.cookbook-r.com/Graphs/Colors_%28ggplot2%29/ggplot2_scale_hue_colors_l45.png
>>>
>>> - Line thickness: basically every time I make a line plot I wish the
>>> lines were thicker. This is another thing that seaborn simply changes
>>> unconditionally.
>>>
>>> In general I guess we could do a lot worse than to simply adopt
>>> seaborn's defaults as the matplotlib defaults :-) Their full list of
>>> overrides can be seen here:
>>> https://github.com/mwaskom/seaborn/blob/master/seaborn/rcmod.py#L135
>>> https://github.com/mwaskom/seaborn/blob/master/seaborn/rcmod.py#L301
>>>
>>> - Dash styles: a common recommendation for line plots is to
>>> simultaneously vary both the color and the dash style of your lines,
>>> because redundant cues are good and dash styles are more robust than
>>> color in the face of greyscale printing etc. But every time I try to
>>> follow this advice I find myself having to define new dashes from
>>> scratch, because matplotlib's default dash styles ("-", "--", "-.",
>>> ":") have wildly varying weights; in particular I often find it hard
>>> to even see the dots in the ":" and "-." styles. Here's someone with a
>>> similar complaint:
>>>
>>> http://philbull.wordpress.com/2012/03/14/custom-dashdot-line-styles-in-matplotlib/
>>>
>>> Just as very rough numbers, something along the lines of "--" = [7,
>>> 4], "-." = [7, 4, 3, 4], ":" = [2, 1.5] looks much better to me.
>>>
>>> It might also make sense to consider baking the advice I mentioned
>>> above into matplotlib directly, and having a non-trivial dash cycle
>>> enabled by default. (So the first line plotted uses "-", second uses
>>> "--" or similar, etc.) This would also have the advantage that if we
>>> make the length of the color cycle and the dash cycle relatively
>>> prime, then we'll dramatically increase the number of lines that can
>>> be plotted on the same graph with distinct appearances. (I often run
>>> into the annoying situation where I throw up a quick-and-dirty plot,
>>> maybe with something like pandas's dataframe.plot(), and then discover
>>> that I have multiple indistinguishable lines.)
>>>
>>> Obviously one could quibble with my specific proposals here, but does
>>> in general seem like a useful thing to do?
>>>
>>> -n
>>>
>>> --
>>> Nathaniel J. Smith
>>> Postdoctoral researcher - Informatics - University of Edinburgh
>>> http://vorpus.org
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>>> Get technology previously reserved for billion-dollar corporations, FREE
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>

I like the idea of aligning a set of changes for 2.0 even if still far
away.
Regarding to backwards compatibility I think that indeed it is important
but when changing mayor version (1.x to 2.0) becomes less important and we
must take care of prioritizing evolution.
Take for example the OO interface (not defined yet) this is very probable
to break the current pyplot interface but still this is a change that needs
to be done.
In terms of defaults. I would like to see the new Navigation as default (if
it gets merged) and tabbed figures (to come after navigation), having
separate figures feel kind of ..."old"
On 21 Nov 2014 21:23, "Benjamin Root" <ben...@ou...> wrote:
> Some of your wishes are in progress already:
> https://github.com/matplotlib/matplotlib/pull/3818
> There is also an issue open about scaling the dashes with the line width,
> and you are right, the spacing for the dashes are terrible.
>
> I can definitely see the argument to making a bunch of these visual
> changes together. Preferably, I would like to do these changes via style
> sheets so that we can provide a "classic" stylesheet for backwards
> compatibility.
>
> I do actually like the autoscaling system as it exists now. The problem is
> that the data margins feature is applied haphazardly. The power spectra
> example is a good example of where we could "smarten" the system. As for
> the ticks... I think that is a very obscure edge-case. I personally prefer
> inward.
>
> It is good to get these grievances enumerated. I am interested in seeing
> where this discussion goes.
>
> Cheers!
> Ben Root
>
> On Fri, Nov 21, 2014 at 6:22 PM, Nathaniel Smith <nj...@po...> wrote:
>
>> Hi all,
>>
>> Since we're considering the possibility of making a matplotlib 2.0
>> release with a better default colormap, it occurred to me that it
>> might make sense to take this opportunity to improve other visual
>> defaults.
>>
>> Defaults are important. Obviously for publication graphs you'll want
>> to end up tweaking every detail, but (a) not everyone does but we
>> still have to read their graphs, and (b) probably only 1% of the plots
>> I make are for publication; the rest are quick one-offs that I make
>> on-the-fly to help me understand my own data. For such plots it's
>> usually not worth spending much/any time tweaking layout details, I
>> just want something usable, quickly. And I think there's a fair amount
>> of low-hanging improvements possible.
>>
>> Batching multiple visual changes like this together seems much better
>> than spreading them out over multiple releases. It keeps the messaging
>> super easy to understand: "matplotlib 2.0 is just like 1.x, your code
>> will still work, the only difference is that your plots will look
>> better by default". And grouping these changes together makes it
>> easier to provide for users who need to revert back to the old
>> defaults -- it's easy to provide simple binary choice between "before
>> 2.0" versus "after 2.0", harder to keep track of a bunch of different
>> changes spread over multiple releases.
>>
>> Some particular annoyances I often run into and that might be
>> candidates for changing:
>>
>> - The default method of choosing axis limits is IME really, really
>> annoying, because of the way it tries to find "round number"
>> boundaries. It's a clever idea, but in practice I've almost never seen
>> this pick axis limits that are particularly meaningful for my data,
>> and frequently it picks particularly bad ones. For example, suppose
>> you want to plot the spectrum of a signal; because of FFT's preference
>> for power-of-two sizes works it's natural to end up with samples
>> ranging from 0 to 255. If you plot this, matplotlib will give you an
>> xlim of (0, 300), which looks pretty ridiculous. But even worse is the
>> way this method of choosing xlims can actually obscure data -- if the
>> extreme values in your data set happen to fall exactly on a "round
>> number", then this will be used as the axis limits, and you'll end up
>> with data plotted directly underneath the axis spine. I frequently
>> encounter this when making scatter plots of data in the 0-1 range --
>> the points located at exactly 0 and 1 are very important to see, but
>> are nearly invisible by default. A similar case I ran into recently
>> was when plotting autocorrelation functions for different signals. For
>> reference I wanted to include the theoretically ideal ACF for white
>> noise, which looks like this:
>> plt.plot(np.arange(1000), [1] + [0] * 999)
>> Good luck reading that plot!
>>
>> R's default rule for deciding axis limits is very simple: extend the
>> data range by 4% on each side; those are your limits. IME this rule --
>> while obviously not perfect -- always produces something readable and
>> unobjectionable.
>>
>> - Axis tickmarks should point outwards rather than inwards: There's
>> really no advantage to making them point inwards, and pointing inwards
>> means they can obscure data. My favorite example of this is plotting a
>> histogram with 100 bins -- that's an obvious thing to do, right? Check
>> it out:
>> plt.hist(np.random.RandomState(0).uniform(size=100000), bins=100)
>> This makes me do a double-take every few months until I remember
>> what's going on: "WTF why is the bar on the left showing a *stacked*
>> barplot...ohhhhh right those are just the ticks, which happen to be
>> exactly the same width as the bar." Very confusing.
>>
>> Seaborn's built-in themes give you the options of (1) no axis ticks at
>> all, just a background grid (by default the white-on-light-grey grid
>> as popularized by ggplot2), (2) outwards pointing tickmarks. Either
>> option seems like a better default to me!
>>
>> - Default line colors: The rgbcmyk color cycle for line plots doesn't
>> appear to be based on any real theory about visualization -- it's just
>> the corners of the RGB color cube, which is a highly perceptually
>> non-uniform space. The resulting lines aren't terribly high contrast
>> against the default white background, and the different colors have
>> varying luminance that makes some lines "pop out" more than others.
>>
>> Seaborn's default is to use a nice isoluminant variant on matplotlib's
>> default:
>>
>> http://web.stanford.edu/~mwaskom/software/seaborn/tutorial/aesthetics.html
>> ggplot2 uses isoluminant colors with maximally-separated hues, which
>> also works well. E.g.:
>>
>> http://www.cookbook-r.com/Graphs/Colors_%28ggplot2%29/ggplot2_scale_hue_colors_l45.png
>>
>> - Line thickness: basically every time I make a line plot I wish the
>> lines were thicker. This is another thing that seaborn simply changes
>> unconditionally.
>>
>> In general I guess we could do a lot worse than to simply adopt
>> seaborn's defaults as the matplotlib defaults :-) Their full list of
>> overrides can be seen here:
>> https://github.com/mwaskom/seaborn/blob/master/seaborn/rcmod.py#L135
>> https://github.com/mwaskom/seaborn/blob/master/seaborn/rcmod.py#L301
>>
>> - Dash styles: a common recommendation for line plots is to
>> simultaneously vary both the color and the dash style of your lines,
>> because redundant cues are good and dash styles are more robust than
>> color in the face of greyscale printing etc. But every time I try to
>> follow this advice I find myself having to define new dashes from
>> scratch, because matplotlib's default dash styles ("-", "--", "-.",
>> ":") have wildly varying weights; in particular I often find it hard
>> to even see the dots in the ":" and "-." styles. Here's someone with a
>> similar complaint:
>>
>> http://philbull.wordpress.com/2012/03/14/custom-dashdot-line-styles-in-matplotlib/
>>
>> Just as very rough numbers, something along the lines of "--" = [7,
>> 4], "-." = [7, 4, 3, 4], ":" = [2, 1.5] looks much better to me.
>>
>> It might also make sense to consider baking the advice I mentioned
>> above into matplotlib directly, and having a non-trivial dash cycle
>> enabled by default. (So the first line plotted uses "-", second uses
>> "--" or similar, etc.) This would also have the advantage that if we
>> make the length of the color cycle and the dash cycle relatively
>> prime, then we'll dramatically increase the number of lines that can
>> be plotted on the same graph with distinct appearances. (I often run
>> into the annoying situation where I throw up a quick-and-dirty plot,
>> maybe with something like pandas's dataframe.plot(), and then discover
>> that I have multiple indistinguishable lines.)
>>
>> Obviously one could quibble with my specific proposals here, but does
>> in general seem like a useful thing to do?
>>
>> -n
>>
>> --
>> Nathaniel J. Smith
>> Postdoctoral researcher - Informatics - University of Edinburgh
>> http://vorpus.org
>>
>>
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Some of your wishes are in progress already:
https://github.com/matplotlib/matplotlib/pull/3818
There is also an issue open about scaling the dashes with the line width,
and you are right, the spacing for the dashes are terrible.
I can definitely see the argument to making a bunch of these visual changes
together. Preferably, I would like to do these changes via style sheets so
that we can provide a "classic" stylesheet for backwards compatibility.
I do actually like the autoscaling system as it exists now. The problem is
that the data margins feature is applied haphazardly. The power spectra
example is a good example of where we could "smarten" the system. As for
the ticks... I think that is a very obscure edge-case. I personally prefer
inward.
It is good to get these grievances enumerated. I am interested in seeing
where this discussion goes.
Cheers!
Ben Root
On Fri, Nov 21, 2014 at 6:22 PM, Nathaniel Smith <nj...@po...> wrote:
> Hi all,
>
> Since we're considering the possibility of making a matplotlib 2.0
> release with a better default colormap, it occurred to me that it
> might make sense to take this opportunity to improve other visual
> defaults.
>
> Defaults are important. Obviously for publication graphs you'll want
> to end up tweaking every detail, but (a) not everyone does but we
> still have to read their graphs, and (b) probably only 1% of the plots
> I make are for publication; the rest are quick one-offs that I make
> on-the-fly to help me understand my own data. For such plots it's
> usually not worth spending much/any time tweaking layout details, I
> just want something usable, quickly. And I think there's a fair amount
> of low-hanging improvements possible.
>
> Batching multiple visual changes like this together seems much better
> than spreading them out over multiple releases. It keeps the messaging
> super easy to understand: "matplotlib 2.0 is just like 1.x, your code
> will still work, the only difference is that your plots will look
> better by default". And grouping these changes together makes it
> easier to provide for users who need to revert back to the old
> defaults -- it's easy to provide simple binary choice between "before
> 2.0" versus "after 2.0", harder to keep track of a bunch of different
> changes spread over multiple releases.
>
> Some particular annoyances I often run into and that might be
> candidates for changing:
>
> - The default method of choosing axis limits is IME really, really
> annoying, because of the way it tries to find "round number"
> boundaries. It's a clever idea, but in practice I've almost never seen
> this pick axis limits that are particularly meaningful for my data,
> and frequently it picks particularly bad ones. For example, suppose
> you want to plot the spectrum of a signal; because of FFT's preference
> for power-of-two sizes works it's natural to end up with samples
> ranging from 0 to 255. If you plot this, matplotlib will give you an
> xlim of (0, 300), which looks pretty ridiculous. But even worse is the
> way this method of choosing xlims can actually obscure data -- if the
> extreme values in your data set happen to fall exactly on a "round
> number", then this will be used as the axis limits, and you'll end up
> with data plotted directly underneath the axis spine. I frequently
> encounter this when making scatter plots of data in the 0-1 range --
> the points located at exactly 0 and 1 are very important to see, but
> are nearly invisible by default. A similar case I ran into recently
> was when plotting autocorrelation functions for different signals. For
> reference I wanted to include the theoretically ideal ACF for white
> noise, which looks like this:
> plt.plot(np.arange(1000), [1] + [0] * 999)
> Good luck reading that plot!
>
> R's default rule for deciding axis limits is very simple: extend the
> data range by 4% on each side; those are your limits. IME this rule --
> while obviously not perfect -- always produces something readable and
> unobjectionable.
>
> - Axis tickmarks should point outwards rather than inwards: There's
> really no advantage to making them point inwards, and pointing inwards
> means they can obscure data. My favorite example of this is plotting a
> histogram with 100 bins -- that's an obvious thing to do, right? Check
> it out:
> plt.hist(np.random.RandomState(0).uniform(size=100000), bins=100)
> This makes me do a double-take every few months until I remember
> what's going on: "WTF why is the bar on the left showing a *stacked*
> barplot...ohhhhh right those are just the ticks, which happen to be
> exactly the same width as the bar." Very confusing.
>
> Seaborn's built-in themes give you the options of (1) no axis ticks at
> all, just a background grid (by default the white-on-light-grey grid
> as popularized by ggplot2), (2) outwards pointing tickmarks. Either
> option seems like a better default to me!
>
> - Default line colors: The rgbcmyk color cycle for line plots doesn't
> appear to be based on any real theory about visualization -- it's just
> the corners of the RGB color cube, which is a highly perceptually
> non-uniform space. The resulting lines aren't terribly high contrast
> against the default white background, and the different colors have
> varying luminance that makes some lines "pop out" more than others.
>
> Seaborn's default is to use a nice isoluminant variant on matplotlib's
> default:
>
> http://web.stanford.edu/~mwaskom/software/seaborn/tutorial/aesthetics.html
> ggplot2 uses isoluminant colors with maximally-separated hues, which
> also works well. E.g.:
>
> http://www.cookbook-r.com/Graphs/Colors_%28ggplot2%29/ggplot2_scale_hue_colors_l45.png
>
> - Line thickness: basically every time I make a line plot I wish the
> lines were thicker. This is another thing that seaborn simply changes
> unconditionally.
>
> In general I guess we could do a lot worse than to simply adopt
> seaborn's defaults as the matplotlib defaults :-) Their full list of
> overrides can be seen here:
> https://github.com/mwaskom/seaborn/blob/master/seaborn/rcmod.py#L135
> https://github.com/mwaskom/seaborn/blob/master/seaborn/rcmod.py#L301
>
> - Dash styles: a common recommendation for line plots is to
> simultaneously vary both the color and the dash style of your lines,
> because redundant cues are good and dash styles are more robust than
> color in the face of greyscale printing etc. But every time I try to
> follow this advice I find myself having to define new dashes from
> scratch, because matplotlib's default dash styles ("-", "--", "-.",
> ":") have wildly varying weights; in particular I often find it hard
> to even see the dots in the ":" and "-." styles. Here's someone with a
> similar complaint:
>
> http://philbull.wordpress.com/2012/03/14/custom-dashdot-line-styles-in-matplotlib/
>
> Just as very rough numbers, something along the lines of "--" = [7,
> 4], "-." = [7, 4, 3, 4], ":" = [2, 1.5] looks much better to me.
>
> It might also make sense to consider baking the advice I mentioned
> above into matplotlib directly, and having a non-trivial dash cycle
> enabled by default. (So the first line plotted uses "-", second uses
> "--" or similar, etc.) This would also have the advantage that if we
> make the length of the color cycle and the dash cycle relatively
> prime, then we'll dramatically increase the number of lines that can
> be plotted on the same graph with distinct appearances. (I often run
> into the annoying situation where I throw up a quick-and-dirty plot,
> maybe with something like pandas's dataframe.plot(), and then discover
> that I have multiple indistinguishable lines.)
>
> Obviously one could quibble with my specific proposals here, but does
> in general seem like a useful thing to do?
>
> -n
>
> --
> Nathaniel J. Smith
> Postdoctoral researcher - Informatics - University of Edinburgh
> http://vorpus.org
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>