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.r...@ou.edu> 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 <ariza.feder...@gmail.com> > 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.r...@ou.edu> 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 <n...@pobox.com> 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 > Matplotlib-devel@lists.sourceforge.net > 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 > Matplotlib-devel@lists.sourceforge.net > 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 > Matplotlib-devel@lists.sourceforge.net > 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
