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=157005751iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net 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=157005751iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net 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=157005751iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net 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=157005751iu=/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=157005751iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net 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 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
