matplotlib-devel Mailing List for matplotlib

I'd like to propose an update to the default boxplot symbology: all black
Q: How much more black could the boxplots be?
A: None. None more black.
(sorry, ben)
On Fri, Nov 21, 2014 at 7:18 PM, 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
>
>

On 2014年11月23日, 12:18 PM, Benjamin Root wrote:
> Reading through the backend_wx.py code, I noticed a small deviation from
> the other interactive backends. All other
> new_figure_manager_given_figure() separately creates a canvas and
> manager object (which, in turn, creates the window object) and hooks
> them all up. The manager would handle all window responsibilities such
> as creation/destruction and sizing. However, for the WX backend, this
> function just creates a FigureFrameWx object, which is the window
> widget. This object also becomes responsible for creating the canvas and
> the manager.
>
> This setup seems a bit backwards to me, but I am not entirely sure. It
> is definitely different. Does anybody know if it is merely a remnant of
> older designs (I think WX was the first backend)? What are the
> limitations of this approach, if any? Is there any interest in
> normalizing this backend design with the others (or vice versa)?
Gtk came before Wx, and the mpl drawing model was influenced by that gtk 
heritage. (And on linux, Wx is a layer on top of Gtk.)
I have no idea what the consequences are of the subtle difference you 
point out, or whether it was a deliberate choice for some compelling 
reason, or whether it followed gtk but then gtk was changed later, or what.
In general, making the backends as similar as possible (and factoring 
out as much as possible) is good; but actually messing around with these 
things can be time consuming, painful, and hazardous. It's hard to test 
with all the different platforms and versions.
Eric
>
> Thanks to everybody for putting up with my questions over the last few
> months. Oftentimes, just writing out the questions have been very useful
> to me, along with your responses. The good news is the book is almost
> done, and I hope that it will be an extremely useful reference.
>
> Cheers!
> Ben Root
>
>
> ------------------------------------------------------------------------------
> 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
>

Reading through the backend_wx.py code, I noticed a small deviation from
the other interactive backends. All other new_figure_manager_given_figure()
separately creates a canvas and manager object (which, in turn, creates the
window object) and hooks them all up. The manager would handle all window
responsibilities such as creation/destruction and sizing. However, for the
WX backend, this function just creates a FigureFrameWx object, which is the
window widget. This object also becomes responsible for creating the canvas
and the manager.
This setup seems a bit backwards to me, but I am not entirely sure. It is
definitely different. Does anybody know if it is merely a remnant of older
designs (I think WX was the first backend)? What are the limitations of
this approach, if any? Is there any interest in normalizing this backend
design with the others (or vice versa)?
Thanks to everybody for putting up with my questions over the last few
months. Oftentimes, just writing out the questions have been very useful to
me, along with your responses. The good news is the book is almost done,
and I hope that it will be an extremely useful reference.
Cheers!
Ben Root

On 2014年11月22日, 7:43 PM, Benjamin Root wrote:
> I don't have a mac to double-check, but reading through the
> backend_cocoaagg.py, I don't see any creation of a navigation toolbar?
> Is this assumption right?
Probably so:
from matplotlib import cbook
cbook.warn_deprecated(
 '1.3',
 message="The CocoaAgg backend is not a fully-functioning backend. "
 "It may be removed in matplotlib 1.4.")
Looks like it is time to delete it. I don't think this deprecation 
warning brought forth any cries of pain, so my guess is that no one is 
actually using it, or ever has done so routinely.
Eric
>
> Thanks!
> Ben Root

On 2014年11月22日, 9:06 AM, gary ruben wrote:
> 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.
I think the problem is that the outlines are snapped to pixel 
boundaries, but the color blocks are not. Something like that. I think 
a similar problem is manifest in the small offsets often seen between 
colorbar ticks and colorbar boundaries.
>
> 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?
I don't see why you would want the *default* to be to override the 
rcParams setting for use_mathtext. This just makes it harder to 
document, and harder for people to keep track of what determines what.
To some extent this applies to the rest of your customizations as well. 
 Deviations from the rcParams defaults via special cases, hardwired 
into mpl, should be avoided as much as possible. A richer configuration 
system, building on rcParams or some modification of it, will probably 
be the goal instead. The evolving style module is a step in this direction.
>
> 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.
I agree, but the question is how to make it as easy as possible for each 
user to get their desired result. I don't think this is the time to do 
much in the way of tweaking hard-wired defaults.
>
> 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()
The difference is that matshow is adjusting the figure size based on the 
array dimensions without taking into account the later addition of a 
colorbar. The only way to fix this in our present framework would be to 
use a kwarg to tell matshow to include a colorbar from the start, so it 
would be able to calculate the figure size appropriately.
With imshow plus a colorbar, the "nice" behavior occurs only for a 
particular small range of array dimension ratios, such as the unity 
ratio in your example. For example, try using rand(5, 10).
Eric
>
>
> Gary

I don't have a mac to double-check, but reading through the
backend_cocoaagg.py, I don't see any creation of a navigation toolbar? Is
this assumption right?
Thanks!
Ben Root