Re: [matplotlib-devel] Better defaults all around?

[Nicolas P. R. <Nic...@in...>]

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