I think using native icons would be the best scenario, at least whet the
backend and platform support it.
On Nov 22, 2014 9:08 AM, "Nicolas P. Rougier" <nicolas.roug...@inria.fr>
wrote:
>
> 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
>
------------------------------------------------------------------------------
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
