Re: [matplotlib-devel] Better defaults all around?
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 -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] cocoaagg figure not have a navigation toolbar?
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 -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] subtle design difference with Wx backend from others
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 -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] subtle design difference with Wx backend from others
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 > [email protected] > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Better defaults all around?
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 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 > 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" 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 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
