matplotlib-devel

Re: [matplotlib-devel] Plot or Not: voting to create better matplotlibrc

[Chris B. <bea...@ha...>]

Hi,

I thought I'd chime in on this discussion -- Adrian Price-Whelan and I put
together plotornot during the SciPy sprints.

I wouldn't advocate for linking to plotornot from matplotlib -- the idea is
semi tongue-in-cheek, and meant to gauge to what extent there is consensus
about plot styles. It's not set up to teach about rcParams, nor does it
systematically explore all possible styles. The votes (>10K, last I
checked) are saved, and eventually Adrian or I will look over the feedback
and report back to you all. I haven't had time for that yet. I hope the
name didn't *actually* offend anyone.

At the risk of sounding unappreciative of MPL (which I love, and rely upon
daily), I must admit I was disheartened after hearing the MPL devs at SciPy
discuss styles and defaults. I understand that you don't want to change the
default styles without a clearly better alternative. I also understand
that, to some extent, style preferences are subjective. However, there
seemed to be quite a bit of resistance to the idea that MPL defaults should
change *at all.*

Even if you ignore the subjective component of this (which I think is a
mistake, since in my experience there is broad consensus that projects like
ggplot2, d3, tableau, and spotfire do a "better" job than MPL at styling),
there are some well-established visual principles that matplotlib violates.
Some of my biggest pet peeves are:

1) The default 'axes.color_cycle' values should be equally visible, with
similar luminance values. The current defaults (bgrcmyk) do not have this
property -- c and y are harder to see, and thus carry less visual emphasis.
A color table like the "Dark2" color brewer table (
http://learnr.files.wordpress.com/2009/04/colours-dark2.png,
colorbrewer2.org) is more uniform, and carefully designed for visibility
and contrast. 'rgbcmyk' is clearly an arbitrary choice -- why not use a
smarter default?

2) The default 'jet' colormap for images has a lot of poor properties
(which is even mentioned on the MPL docs at
http://matplotlib.org/api/pyplot_summary.html#id1). The brain is bad at
ordering changes in hue (which is bigger -- purple or yellow?), and better
at ordering changes in intensity or saturation. A colleague of mine
designed a visualization tool for doctors, and found that the rainbow color
table had a dramatic negative effect on the effectiveness of the tool (you
can watch her TED talk about this at
https://www.youtube.com/watch?v=kU7veyGGps4&t=440s). The jet default is
especially frustrating, since it *cannot* be modified via rcParams

3) Some of the defaults violate Tufte principles like minimizing "chart
junk." For example, the 'stepfilled' mode for hist is probably better than
the default, which draws vertical lines between every bin. Those lines make
the histogram noisier -- do they convey any extra information? Again, this
can't be tweaked via rcParams.

Sorry for being long-winded -- I just want to make the case that this is an
important (and not *entirely* subjective) issue. If nothing else, it would
be great to see some clear statement about where the MPL devs stand on this
issue -- what criteria must be met to consider a change to the defaults? My
apologies if such a document already exists somewhere!

Cheers,
Chris Beaumont





On Sat, Jul 20, 2013 at 3:03 PM, <
mat...@li...> wrote:

> Send Matplotlib-devel mailing list submissions to
>         mat...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> or, via email, send a message with subject or body 'help' to
>         mat...@li...
>
> You can reach the person managing the list at
>         mat...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Matplotlib-devel digest..."
>
>
> Today's Topics:
>
>    1. Re: Plot or Not: voting to create better  matplotlibrc
>       (Eric Firing)
>    2. Re: How to use STIX fonts in matplotlib plots? (Eric Firing)
>    3. Re: Plot or Not: voting to create better  matplotlibrc
>       (Benjamin Root)
>    4. Re: How to use STIX fonts in matplotlib plots? (Benjamin Root)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 20 Jul 2013 08:20:11 -1000
> From: Eric Firing <ef...@ha...>
> Subject: Re: [matplotlib-devel] Plot or Not: voting to create better
>         matplotlibrc
> To: mat...@li...
> Message-ID: <51E...@ha...>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 2013/07/20 4:18 AM, David P. Sanders wrote:
> > Hi,
> >
> > Probably many of you know about "Plot or Not", a site where we vote on
> > the same plot presented in different ways, to get feedback about better
> > matplotlibrc params:
> >
> > http://warm-escarpment-9042.herokuapp.com/
> >
> > It seems to me an absolutely fantastic idea! I think many people do not
> > realise how fantastic the plots can look with some of this modern
> > styling. (Styling was mentioned several times at SciPy.)
> >
> > Would it be possible to put a link to this site on the matplotlib web
> > page and encourage people to use it?
>
> David,
>
> Interesting, but I'm not sure this is a good approach.  I really don't
> see the point of the voting.  What I think would be more useful would be
> a set of matplotlibrc files with examples of their effect on at least a
> few plot types.
>
> >
> > Definitely time to update the defaults!!
>
> Or maybe include a representative set of rcParams combinations to make
> it easier for people to choose a design that suits their purpose.  This
> could be part of a toolkit.
>
> Eric
>
> >
> > Best wishes,
> > David.
> >
> > --
> > Dr. David P. Sanders
> >
> > Profesor Titular "A" / Associate Professor
> > Departamento de F?sica, Facultad de Ciencias
> > Universidad Nacional Aut?noma de M?xico (UNAM)
> >
> > dps...@ci... <mailto:dps...@ci...>
> > http://sistemas.fciencias.unam.mx/~dsanders
> > <http://sistemas.fciencias.unam.mx/%7Edsanders>
> >
> > Cub?culo / office: #414, 4o. piso del Depto. de F?sica
> > Tel.: +52 55 5622 4965
> >
> >
> >
> ------------------------------------------------------------------------------
> > See everything from the browser to the database with AppDynamics
> > Get end-to-end visibility with application monitoring from AppDynamics
> > Isolate bottlenecks and diagnose root cause in seconds.
> > Start your free trial of AppDynamics Pro today!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> >
> >
> >
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 20 Jul 2013 08:55:37 -1000
> From: Eric Firing <ef...@ha...>
> Subject: Re: [matplotlib-devel] How to use STIX fonts in matplotlib
>         plots?
> To: mat...@li...
> Message-ID: <51E...@ha...>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 2013/07/20 4:41 AM, David P. Sanders wrote:
> > I find the default font used in matplotlib horrible. We should be able
> > to do much better these days.
>
> Which font is being used as default on your installation?  And what are
> the characteristics that earn the rating of "horrible"?
>
> Eric
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 20 Jul 2013 14:58:12 -0400
> From: Benjamin Root <ben...@ou...>
> Subject: Re: [matplotlib-devel] Plot or Not: voting to create better
>         matplotlibrc
> To: Eric Firing <ef...@ha...>
> Cc: matplotlib development list
>         <mat...@li...>
> Message-ID:
>         <CANNq6F=pdWohTRYLqEkG3oy6VoWYJ=
> c4Q...@ma...>
> Content-Type: text/plain; charset="iso-8859-1"
>
> >From discussions with others at SciPy, we found ourselves disagreeing on
> what default we would want. We also weren't sure exactly which params were
> the ones that people tended to change. We have zero data on this. This site
> is intended to help start that data collection process.
>
> We can certainly improve this site to collect other kinds of info, but this
> is just a start. One could also view this as a launching point for teaching
> how to use rcParams (sorry David, i kinda like that name) in mpl. You all
> know I never let a good teaching moment go to waste!
>
> As for linking from matplotlib.org, I am ambivalent. It is a bit gimmicky,
> and I do worry about being counterproductive to efforts in SciPy to be more
> inclusive of women (given the rather anti-feministic undertones of the site
> we are parodying). Of course, that could just be me being overly cautious.
>
> Cheers!
> Ben Root
> On Jul 20, 2013 2:20 PM, "Eric Firing" <ef...@ha...> wrote:
>
> > On 2013/07/20 4:18 AM, David P. Sanders wrote:
> > > Hi,
> > >
> > > Probably many of you know about "Plot or Not", a site where we vote on
> > > the same plot presented in different ways, to get feedback about better
> > > matplotlibrc params:
> > >
> > > http://warm-escarpment-9042.herokuapp.com/
> > >
> > > It seems to me an absolutely fantastic idea! I think many people do not
> > > realise how fantastic the plots can look with some of this modern
> > > styling. (Styling was mentioned several times at SciPy.)
> > >
> > > Would it be possible to put a link to this site on the matplotlib web
> > > page and encourage people to use it?
> >
> > David,
> >
> > Interesting, but I'm not sure this is a good approach.  I really don't
> > see the point of the voting.  What I think would be more useful would be
> > a set of matplotlibrc files with examples of their effect on at least a
> > few plot types.
> >
> > >
> > > Definitely time to update the defaults!!
> >
> > Or maybe include a representative set of rcParams combinations to make
> > it easier for people to choose a design that suits their purpose.  This
> > could be part of a toolkit.
> >
> > Eric
> >
> > >
> > > Best wishes,
> > > David.
> > >
> > > --
> > > Dr. David P. Sanders
> > >
> > > Profesor Titular "A" / Associate Professor
> > > Departamento de F?sica, Facultad de Ciencias
> > > Universidad Nacional Aut?noma de M?xico (UNAM)
> > >
> > > dps...@ci... <mailto:dps...@ci...>
> > > http://sistemas.fciencias.unam.mx/~dsanders
> > > <http://sistemas.fciencias.unam.mx/%7Edsanders>
> > >
> > > Cub?culo / office: #414, 4o. piso del Depto. de F?sica
> > > Tel.: +52 55 5622 4965
> > >
> > >
> > >
> >
> ------------------------------------------------------------------------------
> > > See everything from the browser to the database with AppDynamics
> > > Get end-to-end visibility with application monitoring from AppDynamics
> > > Isolate bottlenecks and diagnose root cause in seconds.
> > > Start your free trial of AppDynamics Pro today!
> > >
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> > >
> > >
> > >
> > > _______________________________________________
> > > Matplotlib-devel mailing list
> > > Mat...@li...
> > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> > >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > See everything from the browser to the database with AppDynamics
> > Get end-to-end visibility with application monitoring from AppDynamics
> > Isolate bottlenecks and diagnose root cause in seconds.
> > Start your free trial of AppDynamics Pro today!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 4
> Date: Sat, 20 Jul 2013 15:03:20 -0400
> From: Benjamin Root <ben...@ou...>
> Subject: Re: [matplotlib-devel] How to use STIX fonts in matplotlib
>         plots?
> To: "David P. Sanders" <dps...@ci...>
> Cc: matplotlib development list
>         <mat...@li...>
> Message-ID:
>         <CANNq6Fm0Oz=
> 3uk...@ma...>
> Content-Type: text/plain; charset="iso-8859-1"
>
> David,
>
> IIRC, we were just starting to investigate how to produce retina graphics.
> Perhaps you might be able to help Mike D and Michael de Hoon with there
> efforts because very few of us have retina displays.
>
> Cheers!
> Ben Root
> On Jul 20, 2013 10:43 AM, "David P. Sanders" <dps...@ci...>
> wrote:
>
> > I find the default font used in matplotlib horrible. We should be able to
> > do much better these days.
> >
> > One very interesting option, at least for standard (paper) publishing, is
> > the STIX fonts, which is a Times-like font set promoted by several
> > publishers.
> >
> > There are various options in matplotlib, such as
> > matplotlib.rcParams["mathtext.fontset"], which allow the option "stix",
> > but I have not been able to get it to work. Can anybody please help me
> with
> > this -- what is required?
> >
> > I have the STIX otf or ttf installed on my Mac, but I don't seem to
> manage
> > to get the LaTeX versions installed -- installing LaTeX fonts is *so*
> > disgusting (is there some helper script for that?).
> >
> > Thanks and best wishes,
> > David.
> >
> > --
> > Dr. David P. Sanders
> >
> > Profesor Titular "A" / Associate Professor
> > Departamento de F?sica, Facultad de Ciencias
> > Universidad Nacional Aut?noma de M?xico (UNAM)
> >
> > dps...@ci...
> > http://sistemas.fciencias.unam.mx/~dsanders
> >
> > Cub?culo / office: #414, 4o. piso del Depto. de F?sica
> >
> > Tel.: +52 55 5622 4965
> >
> >
> >
> ------------------------------------------------------------------------------
> > See everything from the browser to the database with AppDynamics
> > Get end-to-end visibility with application monitoring from AppDynamics
> > Isolate bottlenecks and diagnose root cause in seconds.
> > Start your free trial of AppDynamics Pro today!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>
> ------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
> End of Matplotlib-devel Digest, Vol 86, Issue 17
> ************************************************
>



-- 
************************************
Chris Beaumont
Graduate Student
Institute for Astronomy
University of Hawaii at Manoa
2680 Woodlawn Drive
Honolulu, HI 96822
www.ifa.hawaii.edu/~beaumont
************************************

Re: [matplotlib-devel] Plot or Not: voting to create better matplotlibrc

[David P. S. <dps...@ci...>]

On Sat, Jul 20, 2013 at 7:38 PM, David P. Sanders <
dps...@ci...> wrote:

>
>
>
> On Sat, Jul 20, 2013 at 5:36 PM, <
> mat...@li...> wrote:
>
>> Send Matplotlib-devel mailing list submissions to
>>         mat...@li...
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> or, via email, send a message with subject or body 'help' to
>>         mat...@li...
>>
>> You can reach the person managing the list at
>>         mat...@li...
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Matplotlib-devel digest..."
>>
>>
>> Today's Topics:
>>
>>    1. Re: Plot or Not: voting to create better  matplotlibrc
>>       (Adrian Price-Whelan)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Sat, 20 Jul 2013 18:36:42 -0400
>> From: Adrian Price-Whelan <adr...@gm...>
>> Subject: Re: [matplotlib-devel] Plot or Not: voting to create better
>>         matplotlibrc
>> To: mat...@li...
>> Message-ID:
>>         <CAEUL7mENjKC4ZYeSsm+7Yq7h4oYiA1nMPKi=
>> E9p...@ma...>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> Hi,
>>
>> Definitely don't link from matplotlib. This was a fun hack put together to
>> get people talking about re-styling -- success!
>>
>>
> OK, sorry for the noise. The site is beautiful and functional, and I'm
> very glad that you got the discussion flowing!
>
>
> I have to echo Chris' disappointment about the discussion of defaults in
>> MPL. While there are certainly many subjective elements of style and
>> design, there are also a number of rules that the default settings violate
>> (as Chris mentions below). The way I interpret the push-back to replacing
>> the defaults is: "there are too many better alternatives that we will
>> never
>> agree upon, so let's just keep what's there." To 0th order, just pick one!
>> Fixing the few things that Chris mentions below will go a long way to
>> modernizing the MPL feel and experience. There many other things I would
>> like to change about the defaults, but maybe the right thing to do is just
>> issue a pull request so we can discuss on there?
>>
>
> I agree about the defaults, we desperately need to modernize the look of
> the plots to be competitive with ggplot2 etc.
>
>
>>
>> As a longer term idea, I propose:
>> - normalize what can and can't be modified with an rc file -- right now,
>> it's kind of all over the place
>>
>
> I really do object to the 'rc' terminology.
> According to http://en.wikipedia.org/wiki/Run_commands:
>
> > The term *rc* stands for the phrase "*run commands*". It is used for
> any file that contains startup information for a
> > command. It is believed to have originated somewhere in 1965
>
> And this is my problem with 'rc':  it brings to mind an arcane config file
> hidden away somewhere that has a terrible syntax and must not be touched.
>
> As Chris and Adrian have emphasized, the point is that we *should* be
> tweaking away at the parameters all the time.
> I propose to rename as  mpl_params=rcParams
>
> At https://gist.github.com/dpsanders/6047005 I have uploaded a short
> script which should be added to the matplotlib documentation, where I show
> how it looks to use mpl_params.
> I think it is much clearer and more inviting to tweak!
>

Sorry, I meant to send the nbviewer version, and call it a notebook, not a
script!

http://nbviewer.ipython.org/6047005

David


>
> David.
>
>
>
>>
>> then:
>> - each plot in the matplotlib gallery should have a drop-down menu with
>> ~3-5 style options
>> - these options can be named or whatever, but should be complete
>> matplotlibrc files that can either be a) shipped with matplotlib, or b)
>> very easily downloaded and installed (think:
>>  matplotlib.rc_install('name-of-style'))
>> - on each gallery entry page, selecting an option from the drop-down
>> should
>> show the same plot made with the specified rc style
>>
>> I'm happy to help implement this stuff, but I think this would be a
>> tremendous resource to the community.
>>
>> And if you decide to reject everything from this email, *please* at least
>> change the default colormap :) #downwithJet
>>
>> - Adrian
>>
>> From: Chris Beaumont <bea...@ha...>
>> > Date: Sat, Jul 20, 2013 at 5:47 PM
>> > Subject: Re: Plot or Not: voting to create better matplotlibrc
>> > To: mat...@li...
>> >
>> >
>> > Hi,
>> >
>> > I thought I'd chime in on this discussion -- Adrian Price-Whelan and I
>> put
>> > together plotornot during the SciPy sprints.
>> >
>> > I wouldn't advocate for linking to plotornot from matplotlib -- the idea
>> > is semi tongue-in-cheek, and meant to gauge to what extent there is
>> > consensus about plot styles. It's not set up to teach about rcParams,
>> nor
>> > does it systematically explore all possible styles. The votes (>10K,
>> last I
>> > checked) are saved, and eventually Adrian or I will look over the
>> feedback
>> > and report back to you all. I haven't had time for that yet. I hope the
>> > name didn't *actually* offend anyone.
>> >
>> > At the risk of sounding unappreciative of MPL (which I love, and rely
>> upon
>> > daily), I must admit I was disheartened after hearing the MPL devs at
>> SciPy
>> > discuss styles and defaults. I understand that you don't want to change
>> the
>> > default styles without a clearly better alternative. I also understand
>> > that, to some extent, style preferences are subjective. However, there
>> > seemed to be quite a bit of resistance to the idea that MPL defaults
>> should
>> > change *at all.*
>> >
>> > Even if you ignore the subjective component of this (which I think is a
>> > mistake, since in my experience there is broad consensus that projects
>> like
>> > ggplot2, d3, tableau, and spotfire do a "better" job than MPL at
>> styling),
>> > there are some well-established visual principles that matplotlib
>> violates.
>> > Some of my biggest pet peeves are:
>> >
>> > 1) The default 'axes.color_cycle' values should be equally visible, with
>> > similar luminance values. The current defaults (bgrcmyk) do not have
>> this
>> > property -- c and y are harder to see, and thus carry less visual
>> emphasis.
>> > A color table like the "Dark2" color brewer table (
>> > http://learnr.files.wordpress.com/2009/04/colours-dark2.png,
>> > colorbrewer2.org) is more uniform, and carefully designed for
>> visibility
>> > and contrast. 'rgbcmyk' is clearly an arbitrary choice -- why not use a
>> > smarter default?
>> >
>> > 2) The default 'jet' colormap for images has a lot of poor properties
>> > (which is even mentioned on the MPL docs at
>> > http://matplotlib.org/api/pyplot_summary.html#id1). The brain is bad at
>> > ordering changes in hue (which is bigger -- purple or yellow?), and
>> better
>> > at ordering changes in intensity or saturation. A colleague of mine
>> > designed a visualization tool for doctors, and found that the rainbow
>> color
>> > table had a dramatic negative effect on the effectiveness of the tool
>> (you
>> > can watch her TED talk about this at
>> > https://www.youtube.com/watch?v=kU7veyGGps4&t=440s). The jet default is
>> > especially frustrating, since it *cannot* be modified via rcParams
>> >
>> > 3) Some of the defaults violate Tufte principles like minimizing "chart
>> > junk." For example, the 'stepfilled' mode for hist is probably better
>> than
>> > the default, which draws vertical lines between every bin. Those lines
>> make
>> > the histogram noisier -- do they convey any extra information? Again,
>> this
>> > can't be tweaked via rcParams.
>> >
>> > Sorry for being long-winded -- I just want to make the case that this is
>> > an important (and not *entirely* subjective) issue. If nothing else, it
>> > would be great to see some clear statement about where the MPL devs
>> stand
>> > on this issue -- what criteria must be met to consider a change to the
>> > defaults? My apologies if such a document already exists somewhere!
>> >
>> > Cheers,
>> > Chris Beaumont
>> >
>> >
>> >
>> >
>> >
>> > On Sat, Jul 20, 2013 at 3:03 PM, <
>> > mat...@li...> wrote:
>> >
>> >> Send Matplotlib-devel mailing list submissions to
>> >>         mat...@li...
>> >>
>> >> To subscribe or unsubscribe via the World Wide Web, visit
>> >>         https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> >> or, via email, send a message with subject or body 'help' to
>> >>         mat...@li...
>> >>
>> >> You can reach the person managing the list at
>> >>         mat...@li...
>> >>
>> >> When replying, please edit your Subject line so it is more specific
>> >> than "Re: Contents of Matplotlib-devel digest..."
>> >>
>> >>
>> >> Today's Topics:
>> >>
>> >>    1. Re: Plot or Not: voting to create better  matplotlibrc
>> >>       (Eric Firing)
>> >>    2. Re: How to use STIX fonts in matplotlib plots? (Eric Firing)
>> >>    3. Re: Plot or Not: voting to create better  matplotlibrc
>> >>       (Benjamin Root)
>> >>    4. Re: How to use STIX fonts in matplotlib plots? (Benjamin Root)
>> >>
>> >>
>> >> ----------------------------------------------------------------------
>> >>
>> >> Message: 1
>> >> Date: Sat, 20 Jul 2013 08:20:11 -1000
>> >> From: Eric Firing <ef...@ha...>
>> >> Subject: Re: [matplotlib-devel] Plot or Not: voting to create better
>> >>         matplotlibrc
>> >> To: mat...@li...
>> >> Message-ID: <51E...@ha...>
>> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> >>
>> >> On 2013/07/20 4:18 AM, David P. Sanders wrote:
>> >> > Hi,
>> >> >
>> >> > Probably many of you know about "Plot or Not", a site where we vote
>> on
>> >> > the same plot presented in different ways, to get feedback about
>> better
>> >> > matplotlibrc params:
>> >> >
>> >> > http://warm-escarpment-9042.herokuapp.com/
>> >> >
>> >> > It seems to me an absolutely fantastic idea! I think many people do
>> not
>> >> > realise how fantastic the plots can look with some of this modern
>> >> > styling. (Styling was mentioned several times at SciPy.)
>> >> >
>> >> > Would it be possible to put a link to this site on the matplotlib web
>> >> > page and encourage people to use it?
>> >>
>> >> David,
>> >>
>> >> Interesting, but I'm not sure this is a good approach.  I really don't
>> >> see the point of the voting.  What I think would be more useful would
>> be
>> >> a set of matplotlibrc files with examples of their effect on at least a
>> >> few plot types.
>>
>> >>
>> >> >
>> >> > Definitely time to update the defaults!!
>> >>
>> >> Or maybe include a representative set of rcParams combinations to make
>> >> it easier for people to choose a design that suits their purpose.  This
>> >> could be part of a toolkit.
>> >>
>> >> Eric
>>
>> >>
>> >> >
>> >> > Best wishes,
>> >> > David.
>> >> >
>> >> > --
>> >> > Dr. David P. Sanders
>> >> >
>> >> > Profesor Titular "A" / Associate Professor
>> >> > Departamento de F?sica, Facultad de Ciencias
>> >> > Universidad Nacional Aut?noma de M?xico (UNAM)
>> >> >
>> >> > dps...@ci... <mailto:dps...@ci...>
>> >> > http://sistemas.fciencias.unam.mx/~dsanders
>> >> > <http://sistemas.fciencias.unam.mx/%7Edsanders>
>> >> >
>> >> > Cub?culo / office: #414, 4o. piso del Depto. de F?sica
>>
>> >> > Tel.: +52 55 5622 4965
>> >> >
>> >> >
>> >> >
>> >>
>> ------------------------------------------------------------------------------
>> >> > See everything from the browser to the database with AppDynamics
>> >> > Get end-to-end visibility with application monitoring from
>> AppDynamics
>> >> > Isolate bottlenecks and diagnose root cause in seconds.
>> >> > Start your free trial of AppDynamics Pro today!
>> >> >
>> >>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> >> >
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > Matplotlib-devel mailing list
>> >> > Mat...@li...
>> >> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> >> >
>> >>
>> >>
>> >>
>> >>
>> >> ------------------------------
>> >>
>> >> Message: 2
>> >> Date: Sat, 20 Jul 2013 08:55:37 -1000
>> >> From: Eric Firing <ef...@ha...>
>> >> Subject: Re: [matplotlib-devel] How to use STIX fonts in matplotlib
>> >>         plots?
>> >> To: mat...@li...
>> >> Message-ID: <51E...@ha...>
>> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>> >>
>> >> On 2013/07/20 4:41 AM, David P. Sanders wrote:
>> >> > I find the default font used in matplotlib horrible. We should be
>> able
>> >> > to do much better these days.
>> >>
>> >> Which font is being used as default on your installation?  And what are
>> >> the characteristics that earn the rating of "horrible"?
>> >>
>> >> Eric
>> >>
>> >>
>> >>
>> >> ------------------------------
>> >>
>> >> Message: 3
>> >> Date: Sat, 20 Jul 2013 14:58:12 -0400
>> >> From: Benjamin Root <ben...@ou...>
>> >> Subject: Re: [matplotlib-devel] Plot or Not: voting to create better
>> >>         matplotlibrc
>> >> To: Eric Firing <ef...@ha...>
>> >> Cc: matplotlib development list
>> >>         <mat...@li...>
>> >> Message-ID:
>> >>         <CANNq6F=pdWohTRYLqEkG3oy6VoWYJ=
>> >> c4Q...@ma...>
>> >> Content-Type: text/plain; charset="iso-8859-1"
>> >>
>> >> >From discussions with others at SciPy, we found ourselves disagreeing
>> on
>> >> what default we would want. We also weren't sure exactly which params
>> were
>> >> the ones that people tended to change. We have zero data on this. This
>> >> site
>> >> is intended to help start that data collection process.
>> >>
>> >> We can certainly improve this site to collect other kinds of info, but
>> >> this
>> >> is just a start. One could also view this as a launching point for
>> >> teaching
>> >> how to use rcParams (sorry David, i kinda like that name) in mpl. You
>> all
>> >> know I never let a good teaching moment go to waste!
>> >>
>> >> As for linking from matplotlib.org, I am ambivalent. It is a bit
>> >> gimmicky,
>> >> and I do worry about being counterproductive to efforts in SciPy to be
>> >> more
>> >> inclusive of women (given the rather anti-feministic undertones of the
>> >> site
>> >> we are parodying). Of course, that could just be me being overly
>> cautious.
>> >>
>> >> Cheers!
>> >> Ben Root
>> >> On Jul 20, 2013 2:20 PM, "Eric Firing" <ef...@ha...> wrote:
>>
>> >>
>> >> > On 2013/07/20 4:18 AM, David P. Sanders wrote:
>> >> > > Hi,
>> >> > >
>> >> > > Probably many of you know about "Plot or Not", a site where we
>> vote on
>> >> > > the same plot presented in different ways, to get feedback about
>> >> better
>> >> > > matplotlibrc params:
>> >> > >
>> >> > > http://warm-escarpment-9042.herokuapp.com/
>> >> > >
>> >> > > It seems to me an absolutely fantastic idea! I think many people do
>> >> not
>> >> > > realise how fantastic the plots can look with some of this modern
>> >> > > styling. (Styling was mentioned several times at SciPy.)
>> >> > >
>> >> > > Would it be possible to put a link to this site on the matplotlib
>> web
>> >> > > page and encourage people to use it?
>> >> >
>> >> > David,
>> >> >
>> >> > Interesting, but I'm not sure this is a good approach.  I really
>> don't
>> >> > see the point of the voting.  What I think would be more useful
>> would be
>> >> > a set of matplotlibrc files with examples of their effect on at
>> least a
>> >> > few plot types.
>>
>> >> >
>> >> > >
>> >> > > Definitely time to update the defaults!!
>> >> >
>> >> > Or maybe include a representative set of rcParams combinations to
>> make
>> >> > it easier for people to choose a design that suits their purpose.
>>  This
>> >> > could be part of a toolkit.
>> >> >
>> >> > Eric
>>
>> >> >
>> >> > >
>> >> > > Best wishes,
>> >> > > David.
>> >> > >
>> >> > > --
>> >> > > Dr. David P. Sanders
>> >> > >
>> >> > > Profesor Titular "A" / Associate Professor
>> >> > > Departamento de F?sica, Facultad de Ciencias
>> >> > > Universidad Nacional Aut?noma de M?xico (UNAM)
>> >> > >
>> >> > > dps...@ci... <mailto:dps...@ci...>
>> >> > > http://sistemas.fciencias.unam.mx/~dsanders
>> >> > > <http://sistemas.fciencias.unam.mx/%7Edsanders>
>> >> > >
>> >> > > Cub?culo / office: #414, 4o. piso del Depto. de F?sica
>>
>> >> > > Tel.: +52 55 5622 4965
>> >> > >
>> >> > >
>> >> > >
>> >> >
>> >>
>> ------------------------------------------------------------------------------
>> >> > > See everything from the browser to the database with AppDynamics
>> >> > > Get end-to-end visibility with application monitoring from
>> AppDynamics
>> >> > > Isolate bottlenecks and diagnose root cause in seconds.
>> >> > > Start your free trial of AppDynamics Pro today!
>> >> > >
>> >> >
>> >>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> >> > >
>> >> > >
>> >> > >
>> >> > > _______________________________________________
>> >> > > Matplotlib-devel mailing list
>> >> > > Mat...@li...
>> >> > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> >> > >
>> >> >
>> >> >
>> >> >
>> >> >
>> >>
>> ------------------------------------------------------------------------------
>> >> > See everything from the browser to the database with AppDynamics
>> >> > Get end-to-end visibility with application monitoring from
>> AppDynamics
>> >> > Isolate bottlenecks and diagnose root cause in seconds.
>> >> > Start your free trial of AppDynamics Pro today!
>> >> >
>> >>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> >> > _______________________________________________
>> >> > Matplotlib-devel mailing list
>> >> > Mat...@li...
>> >> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> >> >
>> >> -------------- next part --------------
>> >> An HTML attachment was scrubbed...
>> >>
>> >> ------------------------------
>> >>
>> >> Message: 4
>> >> Date: Sat, 20 Jul 2013 15:03:20 -0400
>> >> From: Benjamin Root <ben...@ou...>
>> >> Subject: Re: [matplotlib-devel] How to use STIX fonts in matplotlib
>> >>         plots?
>> >> To: "David P. Sanders" <dps...@ci...>
>> >> Cc: matplotlib development list
>> >>         <mat...@li...>
>> >> Message-ID:
>> >>         <CANNq6Fm0Oz=
>> >> 3uk...@ma...>
>> >> Content-Type: text/plain; charset="iso-8859-1"
>> >>
>> >> David,
>> >>
>> >> IIRC, we were just starting to investigate how to produce retina
>> graphics.
>> >> Perhaps you might be able to help Mike D and Michael de Hoon with there
>> >> efforts because very few of us have retina displays.
>> >>
>> >> Cheers!
>> >> Ben Root
>> >> On Jul 20, 2013 10:43 AM, "David P. Sanders" <
>> dps...@ci...>
>> >> wrote:
>> >>
>> >> > I find the default font used in matplotlib horrible. We should be
>> able
>> >> to
>> >> > do much better these days.
>> >> >
>> >> > One very interesting option, at least for standard (paper)
>> publishing,
>> >> is
>> >> > the STIX fonts, which is a Times-like font set promoted by several
>> >> > publishers.
>> >> >
>> >> > There are various options in matplotlib, such as
>> >> > matplotlib.rcParams["mathtext.fontset"], which allow the option
>> "stix",
>> >> > but I have not been able to get it to work. Can anybody please help
>> me
>> >> with
>> >> > this -- what is required?
>> >> >
>> >> > I have the STIX otf or ttf installed on my Mac, but I don't seem to
>> >> manage
>> >> > to get the LaTeX versions installed -- installing LaTeX fonts is *so*
>> >> > disgusting (is there some helper script for that?).
>> >> >
>> >> > Thanks and best wishes,
>>
>> >> > David.
>> >> >
>> >> > --
>> >> > Dr. David P. Sanders
>> >> >
>> >> > Profesor Titular "A" / Associate Professor
>> >> > Departamento de F?sica, Facultad de Ciencias
>> >> > Universidad Nacional Aut?noma de M?xico (UNAM)
>> >> >
>> >> > dps...@ci...
>> >> > http://sistemas.fciencias.unam.mx/~dsanders
>> >> >
>> >> > Cub?culo / office: #414, 4o. piso del Depto. de F?sica
>>
>> >> >
>> >> > Tel.: +52 55 5622 4965
>> >> >
>> >> >
>> >> >
>> >>
>> ------------------------------------------------------------------------------
>> >> > See everything from the browser to the database with AppDynamics
>> >> > Get end-to-end visibility with application monitoring from
>> AppDynamics
>> >> > Isolate bottlenecks and diagnose root cause in seconds.
>> >> > Start your free trial of AppDynamics Pro today!
>> >> >
>> >>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> >> > _______________________________________________
>> >> > Matplotlib-devel mailing list
>> >> > Mat...@li...
>> >> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> >> >
>> >> >
>> >> -------------- next part --------------
>> >> An HTML attachment was scrubbed...
>> >>
>> >> ------------------------------
>> >>
>> >>
>> >>
>> ------------------------------------------------------------------------------
>> >> See everything from the browser to the database with AppDynamics
>> >> Get end-to-end visibility with application monitoring from AppDynamics
>> >> Isolate bottlenecks and diagnose root cause in seconds.
>> >> Start your free trial of AppDynamics Pro today!
>> >>
>> >>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> >>
>> >> ------------------------------
>> >>
>> >> _______________________________________________
>> >> Matplotlib-devel mailing list
>> >> Mat...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> >>
>> >>
>> >> End of Matplotlib-devel Digest, Vol 86, Issue 17
>> >> ************************************************
>> >>
>> >
>> >
>> >
>> > --
>> > ************************************
>> > Chris Beaumont
>> > Graduate Student
>> > Institute for Astronomy
>> > University of Hawaii at Manoa
>> > 2680 Woodlawn Drive
>> > Honolulu, HI 96822
>> > www.ifa.hawaii.edu/~beaumont
>> > ************************************
>> >
>> >
>> >
>> > --
>> > ************************************
>> > Chris Beaumont
>> > Graduate Student
>> > Institute for Astronomy
>> > University of Hawaii at Manoa
>> > 2680 Woodlawn Drive
>> > Honolulu, HI 96822
>> > www.ifa.hawaii.edu/~beaumont
>> > ************************************
>> >
>>
>>
>>
>> --
>>
>> Adrian M. Price-Whelan ~ Columbia University ~ http://adrian.pw
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>>
>> ------------------------------
>>
>>
>> ------------------------------------------------------------------------------
>> See everything from the browser to the database with AppDynamics
>> Get end-to-end visibility with application monitoring from AppDynamics
>> Isolate bottlenecks and diagnose root cause in seconds.
>> Start your free trial of AppDynamics Pro today!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>>
>> ------------------------------
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>> End of Matplotlib-devel Digest, Vol 86, Issue 19
>> ************************************************
>>
>
>
>
> --
> Dr. David P. Sanders
>
> Profesor Titular "A" / Associate Professor
> Departamento de Física, Facultad de Ciencias
> Universidad Nacional Autónoma de México (UNAM)
>
> dps...@ci...
> http://sistemas.fciencias.unam.mx/~dsanders
>
> Cubículo / office: #414, 4o. piso del Depto. de Física
>
> Tel.: +52 55 5622 4965
>



-- 
Dr. David P. Sanders

Profesor Titular "A" / Associate Professor
Departamento de Física, Facultad de Ciencias
Universidad Nacional Autónoma de México (UNAM)

dps...@ci...
http://sistemas.fciencias.unam.mx/~dsanders

Cubículo / office: #414, 4o. piso del Depto. de Física

Tel.: +52 55 5622 4965

Re: [matplotlib-devel] Plot or Not: voting to create better matplotlibrc

[Adrian Price-W. <adr...@gm...>]

Hi,

Definitely don't link from matplotlib. This was a fun hack put together to
get people talking about re-styling -- success!

I have to echo Chris' disappointment about the discussion of defaults in
MPL. While there are certainly many subjective elements of style and
design, there are also a number of rules that the default settings violate
(as Chris mentions below). The way I interpret the push-back to replacing
the defaults is: "there are too many better alternatives that we will never
agree upon, so let's just keep what's there." To 0th order, just pick one!
Fixing the few things that Chris mentions below will go a long way to
modernizing the MPL feel and experience. There many other things I would
like to change about the defaults, but maybe the right thing to do is just
issue a pull request so we can discuss on there?

As a longer term idea, I propose:
- normalize what can and can't be modified with an rc file -- right now,
it's kind of all over the place

then:
- each plot in the matplotlib gallery should have a drop-down menu with
~3-5 style options
- these options can be named or whatever, but should be complete
matplotlibrc files that can either be a) shipped with matplotlib, or b)
very easily downloaded and installed (think:
 matplotlib.rc_install('name-of-style'))
- on each gallery entry page, selecting an option from the drop-down should
show the same plot made with the specified rc style

I'm happy to help implement this stuff, but I think this would be a
tremendous resource to the community.

And if you decide to reject everything from this email, *please* at least
change the default colormap :) #downwithJet

- Adrian

From: Chris Beaumont <bea...@ha...>
> Date: Sat, Jul 20, 2013 at 5:47 PM
> Subject: Re: Plot or Not: voting to create better matplotlibrc
> To: mat...@li...
>
>
> Hi,
>
> I thought I'd chime in on this discussion -- Adrian Price-Whelan and I put
> together plotornot during the SciPy sprints.
>
> I wouldn't advocate for linking to plotornot from matplotlib -- the idea
> is semi tongue-in-cheek, and meant to gauge to what extent there is
> consensus about plot styles. It's not set up to teach about rcParams, nor
> does it systematically explore all possible styles. The votes (>10K, last I
> checked) are saved, and eventually Adrian or I will look over the feedback
> and report back to you all. I haven't had time for that yet. I hope the
> name didn't *actually* offend anyone.
>
> At the risk of sounding unappreciative of MPL (which I love, and rely upon
> daily), I must admit I was disheartened after hearing the MPL devs at SciPy
> discuss styles and defaults. I understand that you don't want to change the
> default styles without a clearly better alternative. I also understand
> that, to some extent, style preferences are subjective. However, there
> seemed to be quite a bit of resistance to the idea that MPL defaults should
> change *at all.*
>
> Even if you ignore the subjective component of this (which I think is a
> mistake, since in my experience there is broad consensus that projects like
> ggplot2, d3, tableau, and spotfire do a "better" job than MPL at styling),
> there are some well-established visual principles that matplotlib violates.
> Some of my biggest pet peeves are:
>
> 1) The default 'axes.color_cycle' values should be equally visible, with
> similar luminance values. The current defaults (bgrcmyk) do not have this
> property -- c and y are harder to see, and thus carry less visual emphasis.
> A color table like the "Dark2" color brewer table (
> http://learnr.files.wordpress.com/2009/04/colours-dark2.png,
> colorbrewer2.org) is more uniform, and carefully designed for visibility
> and contrast. 'rgbcmyk' is clearly an arbitrary choice -- why not use a
> smarter default?
>
> 2) The default 'jet' colormap for images has a lot of poor properties
> (which is even mentioned on the MPL docs at
> http://matplotlib.org/api/pyplot_summary.html#id1). The brain is bad at
> ordering changes in hue (which is bigger -- purple or yellow?), and better
> at ordering changes in intensity or saturation. A colleague of mine
> designed a visualization tool for doctors, and found that the rainbow color
> table had a dramatic negative effect on the effectiveness of the tool (you
> can watch her TED talk about this at
> https://www.youtube.com/watch?v=kU7veyGGps4&t=440s). The jet default is
> especially frustrating, since it *cannot* be modified via rcParams
>
> 3) Some of the defaults violate Tufte principles like minimizing "chart
> junk." For example, the 'stepfilled' mode for hist is probably better than
> the default, which draws vertical lines between every bin. Those lines make
> the histogram noisier -- do they convey any extra information? Again, this
> can't be tweaked via rcParams.
>
> Sorry for being long-winded -- I just want to make the case that this is
> an important (and not *entirely* subjective) issue. If nothing else, it
> would be great to see some clear statement about where the MPL devs stand
> on this issue -- what criteria must be met to consider a change to the
> defaults? My apologies if such a document already exists somewhere!
>
> Cheers,
> Chris Beaumont
>
>
>
>
>
> On Sat, Jul 20, 2013 at 3:03 PM, <
> mat...@li...> wrote:
>
>> Send Matplotlib-devel mailing list submissions to
>>         mat...@li...
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> or, via email, send a message with subject or body 'help' to
>>         mat...@li...
>>
>> You can reach the person managing the list at
>>         mat...@li...
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Matplotlib-devel digest..."
>>
>>
>> Today's Topics:
>>
>>    1. Re: Plot or Not: voting to create better  matplotlibrc
>>       (Eric Firing)
>>    2. Re: How to use STIX fonts in matplotlib plots? (Eric Firing)
>>    3. Re: Plot or Not: voting to create better  matplotlibrc
>>       (Benjamin Root)
>>    4. Re: How to use STIX fonts in matplotlib plots? (Benjamin Root)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Sat, 20 Jul 2013 08:20:11 -1000
>> From: Eric Firing <ef...@ha...>
>> Subject: Re: [matplotlib-devel] Plot or Not: voting to create better
>>         matplotlibrc
>> To: mat...@li...
>> Message-ID: <51E...@ha...>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> On 2013/07/20 4:18 AM, David P. Sanders wrote:
>> > Hi,
>> >
>> > Probably many of you know about "Plot or Not", a site where we vote on
>> > the same plot presented in different ways, to get feedback about better
>> > matplotlibrc params:
>> >
>> > http://warm-escarpment-9042.herokuapp.com/
>> >
>> > It seems to me an absolutely fantastic idea! I think many people do not
>> > realise how fantastic the plots can look with some of this modern
>> > styling. (Styling was mentioned several times at SciPy.)
>> >
>> > Would it be possible to put a link to this site on the matplotlib web
>> > page and encourage people to use it?
>>
>> David,
>>
>> Interesting, but I'm not sure this is a good approach.  I really don't
>> see the point of the voting.  What I think would be more useful would be
>> a set of matplotlibrc files with examples of their effect on at least a
>> few plot types.
>>
>> >
>> > Definitely time to update the defaults!!
>>
>> Or maybe include a representative set of rcParams combinations to make
>> it easier for people to choose a design that suits their purpose.  This
>> could be part of a toolkit.
>>
>> Eric
>>
>> >
>> > Best wishes,
>> > David.
>> >
>> > --
>> > Dr. David P. Sanders
>> >
>> > Profesor Titular "A" / Associate Professor
>> > Departamento de F?sica, Facultad de Ciencias
>> > Universidad Nacional Aut?noma de M?xico (UNAM)
>> >
>> > dps...@ci... <mailto:dps...@ci...>
>> > http://sistemas.fciencias.unam.mx/~dsanders
>> > <http://sistemas.fciencias.unam.mx/%7Edsanders>
>> >
>> > Cub?culo / office: #414, 4o. piso del Depto. de F?sica
>> > Tel.: +52 55 5622 4965
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > See everything from the browser to the database with AppDynamics
>> > Get end-to-end visibility with application monitoring from AppDynamics
>> > Isolate bottlenecks and diagnose root cause in seconds.
>> > Start your free trial of AppDynamics Pro today!
>> >
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> >
>> >
>> >
>> > _______________________________________________
>> > Matplotlib-devel mailing list
>> > Mat...@li...
>> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> >
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Sat, 20 Jul 2013 08:55:37 -1000
>> From: Eric Firing <ef...@ha...>
>> Subject: Re: [matplotlib-devel] How to use STIX fonts in matplotlib
>>         plots?
>> To: mat...@li...
>> Message-ID: <51E...@ha...>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> On 2013/07/20 4:41 AM, David P. Sanders wrote:
>> > I find the default font used in matplotlib horrible. We should be able
>> > to do much better these days.
>>
>> Which font is being used as default on your installation?  And what are
>> the characteristics that earn the rating of "horrible"?
>>
>> Eric
>>
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Sat, 20 Jul 2013 14:58:12 -0400
>> From: Benjamin Root <ben...@ou...>
>> Subject: Re: [matplotlib-devel] Plot or Not: voting to create better
>>         matplotlibrc
>> To: Eric Firing <ef...@ha...>
>> Cc: matplotlib development list
>>         <mat...@li...>
>> Message-ID:
>>         <CANNq6F=pdWohTRYLqEkG3oy6VoWYJ=
>> c4Q...@ma...>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> >From discussions with others at SciPy, we found ourselves disagreeing on
>> what default we would want. We also weren't sure exactly which params were
>> the ones that people tended to change. We have zero data on this. This
>> site
>> is intended to help start that data collection process.
>>
>> We can certainly improve this site to collect other kinds of info, but
>> this
>> is just a start. One could also view this as a launching point for
>> teaching
>> how to use rcParams (sorry David, i kinda like that name) in mpl. You all
>> know I never let a good teaching moment go to waste!
>>
>> As for linking from matplotlib.org, I am ambivalent. It is a bit
>> gimmicky,
>> and I do worry about being counterproductive to efforts in SciPy to be
>> more
>> inclusive of women (given the rather anti-feministic undertones of the
>> site
>> we are parodying). Of course, that could just be me being overly cautious.
>>
>> Cheers!
>> Ben Root
>> On Jul 20, 2013 2:20 PM, "Eric Firing" <ef...@ha...> wrote:
>>
>> > On 2013/07/20 4:18 AM, David P. Sanders wrote:
>> > > Hi,
>> > >
>> > > Probably many of you know about "Plot or Not", a site where we vote on
>> > > the same plot presented in different ways, to get feedback about
>> better
>> > > matplotlibrc params:
>> > >
>> > > http://warm-escarpment-9042.herokuapp.com/
>> > >
>> > > It seems to me an absolutely fantastic idea! I think many people do
>> not
>> > > realise how fantastic the plots can look with some of this modern
>> > > styling. (Styling was mentioned several times at SciPy.)
>> > >
>> > > Would it be possible to put a link to this site on the matplotlib web
>> > > page and encourage people to use it?
>> >
>> > David,
>> >
>> > Interesting, but I'm not sure this is a good approach.  I really don't
>> > see the point of the voting.  What I think would be more useful would be
>> > a set of matplotlibrc files with examples of their effect on at least a
>> > few plot types.
>> >
>> > >
>> > > Definitely time to update the defaults!!
>> >
>> > Or maybe include a representative set of rcParams combinations to make
>> > it easier for people to choose a design that suits their purpose.  This
>> > could be part of a toolkit.
>> >
>> > Eric
>> >
>> > >
>> > > Best wishes,
>> > > David.
>> > >
>> > > --
>> > > Dr. David P. Sanders
>> > >
>> > > Profesor Titular "A" / Associate Professor
>> > > Departamento de F?sica, Facultad de Ciencias
>> > > Universidad Nacional Aut?noma de M?xico (UNAM)
>> > >
>> > > dps...@ci... <mailto:dps...@ci...>
>> > > http://sistemas.fciencias.unam.mx/~dsanders
>> > > <http://sistemas.fciencias.unam.mx/%7Edsanders>
>> > >
>> > > Cub?culo / office: #414, 4o. piso del Depto. de F?sica
>> > > Tel.: +52 55 5622 4965
>> > >
>> > >
>> > >
>> >
>> ------------------------------------------------------------------------------
>> > > See everything from the browser to the database with AppDynamics
>> > > Get end-to-end visibility with application monitoring from AppDynamics
>> > > Isolate bottlenecks and diagnose root cause in seconds.
>> > > Start your free trial of AppDynamics Pro today!
>> > >
>> >
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> > >
>> > >
>> > >
>> > > _______________________________________________
>> > > Matplotlib-devel mailing list
>> > > Mat...@li...
>> > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> > >
>> >
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > See everything from the browser to the database with AppDynamics
>> > Get end-to-end visibility with application monitoring from AppDynamics
>> > Isolate bottlenecks and diagnose root cause in seconds.
>> > Start your free trial of AppDynamics Pro today!
>> >
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> > _______________________________________________
>> > Matplotlib-devel mailing list
>> > Mat...@li...
>> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Sat, 20 Jul 2013 15:03:20 -0400
>> From: Benjamin Root <ben...@ou...>
>> Subject: Re: [matplotlib-devel] How to use STIX fonts in matplotlib
>>         plots?
>> To: "David P. Sanders" <dps...@ci...>
>> Cc: matplotlib development list
>>         <mat...@li...>
>> Message-ID:
>>         <CANNq6Fm0Oz=
>> 3uk...@ma...>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> David,
>>
>> IIRC, we were just starting to investigate how to produce retina graphics.
>> Perhaps you might be able to help Mike D and Michael de Hoon with there
>> efforts because very few of us have retina displays.
>>
>> Cheers!
>> Ben Root
>> On Jul 20, 2013 10:43 AM, "David P. Sanders" <dps...@ci...>
>> wrote:
>>
>> > I find the default font used in matplotlib horrible. We should be able
>> to
>> > do much better these days.
>> >
>> > One very interesting option, at least for standard (paper) publishing,
>> is
>> > the STIX fonts, which is a Times-like font set promoted by several
>> > publishers.
>> >
>> > There are various options in matplotlib, such as
>> > matplotlib.rcParams["mathtext.fontset"], which allow the option "stix",
>> > but I have not been able to get it to work. Can anybody please help me
>> with
>> > this -- what is required?
>> >
>> > I have the STIX otf or ttf installed on my Mac, but I don't seem to
>> manage
>> > to get the LaTeX versions installed -- installing LaTeX fonts is *so*
>> > disgusting (is there some helper script for that?).
>> >
>> > Thanks and best wishes,
>> > David.
>> >
>> > --
>> > Dr. David P. Sanders
>> >
>> > Profesor Titular "A" / Associate Professor
>> > Departamento de F?sica, Facultad de Ciencias
>> > Universidad Nacional Aut?noma de M?xico (UNAM)
>> >
>> > dps...@ci...
>> > http://sistemas.fciencias.unam.mx/~dsanders
>> >
>> > Cub?culo / office: #414, 4o. piso del Depto. de F?sica
>> >
>> > Tel.: +52 55 5622 4965
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > See everything from the browser to the database with AppDynamics
>> > Get end-to-end visibility with application monitoring from AppDynamics
>> > Isolate bottlenecks and diagnose root cause in seconds.
>> > Start your free trial of AppDynamics Pro today!
>> >
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> > _______________________________________________
>> > Matplotlib-devel mailing list
>> > Mat...@li...
>> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> >
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>>
>> ------------------------------
>>
>>
>> ------------------------------------------------------------------------------
>> See everything from the browser to the database with AppDynamics
>> Get end-to-end visibility with application monitoring from AppDynamics
>> Isolate bottlenecks and diagnose root cause in seconds.
>> Start your free trial of AppDynamics Pro today!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>>
>> ------------------------------
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>> End of Matplotlib-devel Digest, Vol 86, Issue 17
>> ************************************************
>>
>
>
>
> --
> ************************************
> Chris Beaumont
> Graduate Student
> Institute for Astronomy
> University of Hawaii at Manoa
> 2680 Woodlawn Drive
> Honolulu, HI 96822
> www.ifa.hawaii.edu/~beaumont
> ************************************
>
>
>
> --
> ************************************
> Chris Beaumont
> Graduate Student
> Institute for Astronomy
> University of Hawaii at Manoa
> 2680 Woodlawn Drive
> Honolulu, HI 96822
> www.ifa.hawaii.edu/~beaumont
> ************************************
>



-- 

Adrian M. Price-Whelan ~ Columbia University ~ http://adrian.pw

Re: [matplotlib-devel] Plot or Not: voting to create better matplotlibrc

[Eric F. <ef...@ha...>]

On 2013/07/20 11:47 AM, Chris Beaumont wrote:
> Hi,
>
> I thought I'd chime in on this discussion -- Adrian Price-Whelan and I
> put together plotornot during the SciPy sprints.
>
> I wouldn't advocate for linking to plotornot from matplotlib -- the idea
> is semi tongue-in-cheek, and meant to gauge to what extent there is
> consensus about plot styles. It's not set up to teach about rcParams,
> nor does it systematically explore all possible styles. The votes (>10K,
> last I checked) are saved, and eventually Adrian or I will look over the
> feedback and report back to you all. I haven't had time for that yet. I
> hope the name didn't *actually* offend anyone.
>
> At the risk of sounding unappreciative of MPL (which I love, and rely
> upon daily), I must admit I was disheartened after hearing the MPL devs
> at SciPy discuss styles and defaults. I understand that you don't want
> to change the default styles without a clearly better alternative. I
> also understand that, to some extent, style preferences are subjective.
> However, there seemed to be quite a bit of resistance to the idea that
> MPL defaults should change *at all.*
>
> Even if you ignore the subjective component of this (which I think is a
> mistake, since in my experience there is broad consensus that projects
> like ggplot2, d3, tableau, and spotfire do a "better" job than MPL at
> styling), there are some well-established visual principles that
> matplotlib violates. Some of my biggest pet peeves are:
>
> 1) The default 'axes.color_cycle' values should be equally visible, with
> similar luminance values. The current defaults (bgrcmyk) do not have
> this property -- c and y are harder to see, and thus carry less visual
> emphasis. A color table like the "Dark2" color brewer table
> (http://learnr.files.wordpress.com/2009/04/colours-dark2.png,
> colorbrewer2.org <http://colorbrewer2.org>) is more uniform, and
> carefully designed for visibility and contrast. 'rgbcmyk' is clearly an
> arbitrary choice -- why not use a smarter default?
>
> 2) The default 'jet' colormap for images has a lot of poor properties
> (which is even mentioned on the MPL docs at
> http://matplotlib.org/api/pyplot_summary.html#id1). The brain is bad at
> ordering changes in hue (which is bigger -- purple or yellow?), and
> better at ordering changes in intensity or saturation. A colleague of
> mine designed a visualization tool for doctors, and found that the
> rainbow color table had a dramatic negative effect on the effectiveness
> of the tool (you can watch her TED talk about this at
> https://www.youtube.com/watch?v=kU7veyGGps4&t=440s). The jet default is
> especially frustrating, since it *cannot* be modified via rcParams
>
> 3) Some of the defaults violate Tufte principles like minimizing "chart
> junk." For example, the 'stepfilled' mode for hist is probably better
> than the default, which draws vertical lines between every bin. Those
> lines make the histogram noisier -- do they convey any extra
> information? Again, this can't be tweaked via rcParams.
>
> Sorry for being long-winded -- I just want to make the case that this is
> an important (and not *entirely* subjective) issue. If nothing else, it
> would be great to see some clear statement about where the MPL devs
> stand on this issue -- what criteria must be met to consider a change to
> the defaults? My apologies if such a document already exists somewhere!
>
> Cheers,
> Chris Beaumont

Chris,

I appreciate the ideas, and I agree entirely that improvements are in 
order, so it is just a question of exactly what and how, not whether 
there should be changes.  (For example, the default line color set often 
irritates me, too, because blue and green look rather similar, 
particularly in comparison to red, which visually overwhelms the others.)

A problem with simply changing the defaults to some sort of consensus or 
majority opinion as to what is better is that inevitably there will be 
users who will be distressed when they upgrade and suddenly find that 
all their plots--perhaps generated automatically by their cron jobs or 
web apps--look very different, and perhaps don't even work well with the 
new defaults.  Therefore we have to be somewhat conservative, and the 
tendency is to minimize changes that are not essential.  I think that a 
change in the defaults will need to be staged in such a fashion that it 
will be as easy as possible for users to retain the old defaults if they 
prefer them.  That leads to the idea that something like a style toolkit 
or cookbook, or set of examples included with mpl, might be helpful. 
There is never going to be one good style for all; it would be good to 
have examples of how to tailor things for the screen, or for paper, or 
for presentations, or for publications (some of which still favor black 
and white).

The mpl examples (gallery) can be the first target for improvement; 
based on some experience and input, an actual change in the defaults 
might be announced and scheduled for some future release, with assurance 
that a matplotlibrc file for the old defaults will remain available for 
some interval.

Eric

Re: [matplotlib-devel] Plot or Not: voting to create better matplotlibrc

[Tony Yu <ts...@gm...>]

On Sat, Jul 20, 2013 at 4:47 PM, Chris Beaumont <bea...@ha...> wrote:

> Hi,
>
> I thought I'd chime in on this discussion -- Adrian Price-Whelan and I put
> together plotornot during the SciPy sprints.
>
> I wouldn't advocate for linking to plotornot from matplotlib -- the idea
> is semi tongue-in-cheek, and meant to gauge to what extent there is
> consensus about plot styles. It's not set up to teach about rcParams, nor
> does it systematically explore all possible styles. The votes (>10K, last I
> checked) are saved, and eventually Adrian or I will look over the feedback
> and report back to you all. I haven't had time for that yet. I hope the
> name didn't *actually* offend anyone.
>
> At the risk of sounding unappreciative of MPL (which I love, and rely upon
> daily), I must admit I was disheartened after hearing the MPL devs at SciPy
> discuss styles and defaults. I understand that you don't want to change the
> default styles without a clearly better alternative. I also understand
> that, to some extent, style preferences are subjective. However, there
> seemed to be quite a bit of resistance to the idea that MPL defaults should
> change *at all.*
>
> Even if you ignore the subjective component of this (which I think is a
> mistake, since in my experience there is broad consensus that projects like
> ggplot2, d3, tableau, and spotfire do a "better" job than MPL at styling),
> there are some well-established visual principles that matplotlib violates.
> Some of my biggest pet peeves are:
>
> 1) The default 'axes.color_cycle' values should be equally visible, with
> similar luminance values. The current defaults (bgrcmyk) do not have this
> property -- c and y are harder to see, and thus carry less visual emphasis.
> A color table like the "Dark2" color brewer table (
> http://learnr.files.wordpress.com/2009/04/colours-dark2.png,
> colorbrewer2.org) is more uniform, and carefully designed for visibility
> and contrast. 'rgbcmyk' is clearly an arbitrary choice -- why not use a
> smarter default?
>
> 2) The default 'jet' colormap for images has a lot of poor properties
> (which is even mentioned on the MPL docs at
> http://matplotlib.org/api/pyplot_summary.html#id1). The brain is bad at
> ordering changes in hue (which is bigger -- purple or yellow?), and better
> at ordering changes in intensity or saturation. A colleague of mine
> designed a visualization tool for doctors, and found that the rainbow color
> table had a dramatic negative effect on the effectiveness of the tool (you
> can watch her TED talk about this at
> https://www.youtube.com/watch?v=kU7veyGGps4&t=440s). The jet default is
> especially frustrating, since it *cannot* be modified via rcParams
>

Jet is terrible for so many reasons, but it can be modified (unless I
misunderstand):

image.cmap : gray

I'm all for changing the current defaults.

Cheers,
-Tony

Re: [matplotlib-devel] Plot or Not: voting to create better matplotlibrc

[Michael D. <md...@st...>]

Chris,

Thanks for outlining some of the issues with the defaults.  I agree 
wholeheartedly and also agree that most of these are simple objective 
improvements, and have nothing to do with wishy-washy things like 
"aesthetics".

My objections to changing the defaults have nothing to do with the fact 
that it would be hard to find subjective improvements -- I agree a lot 
can be done that would be easy to get consensus on. Eric said it better 
than I could:

    inevitably there will be users who will be distressed when they
    upgrade and suddenly find that all their plots--perhaps generated
    automatically by their cron jobs or web apps--look very different,
    and perhaps don't even work well with the new defaults.


This is why I suggested that the best way forward is to implement some 
sort of easy styling functionality (like what Tony Yu has submitted in 
#2236, though I haven't had a chance to look at it yet), and make it 
explicit for the user to select a new style. This could be either by 
adding a new line to the top of the plotting script, or adding a single 
switch in the global matplotlibrc file.  But there needs to be an 
explicit turning on of this.  To the extent that some things can't be 
changed with rcParams, we can address those on a case-by-case basis.

Another thing that we could do would be to borrow from the "from 
__future__ import" concept in Python.  Then users could say:

    style('future')

at the top of their script and see what it will look like in the default 
styling of the next version of matplotlib -- keeping the old defaults as 
default.

Mike

On 07/20/2013 05:47 PM, Chris Beaumont wrote:
> Hi,
>
> I thought I'd chime in on this discussion -- Adrian Price-Whelan and I 
> put together plotornot during the SciPy sprints.
>
> I wouldn't advocate for linking to plotornot from matplotlib -- the 
> idea is semi tongue-in-cheek, and meant to gauge to what extent there 
> is consensus about plot styles. It's not set up to teach about 
> rcParams, nor does it systematically explore all possible styles. The 
> votes (>10K, last I checked) are saved, and eventually Adrian or I 
> will look over the feedback and report back to you all. I haven't had 
> time for that yet. I hope the name didn't *actually* offend anyone.
>
> At the risk of sounding unappreciative of MPL (which I love, and rely 
> upon daily), I must admit I was disheartened after hearing the MPL 
> devs at SciPy discuss styles and defaults. I understand that you don't 
> want to change the default styles without a clearly better 
> alternative. I also understand that, to some extent, style preferences 
> are subjective. However, there seemed to be quite a bit of resistance 
> to the idea that MPL defaults should change *at all.*
>
> Even if you ignore the subjective component of this (which I think is 
> a mistake, since in my experience there is broad consensus that 
> projects like ggplot2, d3, tableau, and spotfire do a "better" job 
> than MPL at styling), there are some well-established visual 
> principles that matplotlib violates. Some of my biggest pet peeves are:
>
> 1) The default 'axes.color_cycle' values should be equally visible, 
> with similar luminance values. The current defaults (bgrcmyk) do not 
> have this property -- c and y are harder to see, and thus carry less 
> visual emphasis. A color table like the "Dark2" color brewer table 
> (http://learnr.files.wordpress.com/2009/04/colours-dark2.png, 
> colorbrewer2.org <http://colorbrewer2.org>) is more uniform, and 
> carefully designed for visibility and contrast. 'rgbcmyk' is clearly 
> an arbitrary choice -- why not use a smarter default?
>
> 2) The default 'jet' colormap for images has a lot of poor properties 
> (which is even mentioned on the MPL docs at 
> http://matplotlib.org/api/pyplot_summary.html#id1). The brain is bad 
> at ordering changes in hue (which is bigger -- purple or yellow?), and 
> better at ordering changes in intensity or saturation. A colleague of 
> mine designed a visualization tool for doctors, and found that the 
> rainbow color table had a dramatic negative effect on the 
> effectiveness of the tool (you can watch her TED talk about this at 
> https://www.youtube.com/watch?v=kU7veyGGps4&t=440s). The jet default 
> is especially frustrating, since it *cannot* be modified via rcParams
>
> 3) Some of the defaults violate Tufte principles like minimizing 
> "chart junk." For example, the 'stepfilled' mode for hist is probably 
> better than the default, which draws vertical lines between every bin. 
> Those lines make the histogram noisier -- do they convey any extra 
> information? Again, this can't be tweaked via rcParams.
>
> Sorry for being long-winded -- I just want to make the case that this 
> is an important (and not *entirely* subjective) issue. If nothing 
> else, it would be great to see some clear statement about where the 
> MPL devs stand on this issue -- what criteria must be met to consider 
> a change to the defaults? My apologies if such a document already 
> exists somewhere!
>
> Cheers,
> Chris Beaumont
>
>
>
>
>
> On Sat, Jul 20, 2013 at 3:03 PM, 
> <mat...@li... 
> <mailto:mat...@li...>> wrote:
>
>     Send Matplotlib-devel mailing list submissions to
>     mat...@li...
>     <mailto:mat...@li...>
>
>     To subscribe or unsubscribe via the World Wide Web, visit
>     https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>     or, via email, send a message with subject or body 'help' to
>     mat...@li...
>     <mailto:mat...@li...>
>
>     You can reach the person managing the list at
>     mat...@li...
>     <mailto:mat...@li...>
>
>     When replying, please edit your Subject line so it is more specific
>     than "Re: Contents of Matplotlib-devel digest..."
>
>
>     Today's Topics:
>
>        1. Re: Plot or Not: voting to create better  matplotlibrc
>           (Eric Firing)
>        2. Re: How to use STIX fonts in matplotlib plots? (Eric Firing)
>        3. Re: Plot or Not: voting to create better  matplotlibrc
>           (Benjamin Root)
>        4. Re: How to use STIX fonts in matplotlib plots? (Benjamin Root)
>
>
>     ----------------------------------------------------------------------
>
>     Message: 1
>     Date: Sat, 20 Jul 2013 08:20:11 -1000
>     From: Eric Firing <ef...@ha... <mailto:ef...@ha...>>
>     Subject: Re: [matplotlib-devel] Plot or Not: voting to create better
>             matplotlibrc
>     To: mat...@li...
>     <mailto:mat...@li...>
>     Message-ID: <51E...@ha...
>     <mailto:51E...@ha...>>
>     Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>     On 2013/07/20 4:18 AM, David P. Sanders wrote:
>     > Hi,
>     >
>     > Probably many of you know about "Plot or Not", a site where we
>     vote on
>     > the same plot presented in different ways, to get feedback about
>     better
>     > matplotlibrc params:
>     >
>     > http://warm-escarpment-9042.herokuapp.com/
>     >
>     > It seems to me an absolutely fantastic idea! I think many people
>     do not
>     > realise how fantastic the plots can look with some of this modern
>     > styling. (Styling was mentioned several times at SciPy.)
>     >
>     > Would it be possible to put a link to this site on the
>     matplotlib web
>     > page and encourage people to use it?
>
>     David,
>
>     Interesting, but I'm not sure this is a good approach.  I really don't
>     see the point of the voting.  What I think would be more useful
>     would be
>     a set of matplotlibrc files with examples of their effect on at
>     least a
>     few plot types.
>
>     >
>     > Definitely time to update the defaults!!
>
>     Or maybe include a representative set of rcParams combinations to make
>     it easier for people to choose a design that suits their purpose.
>      This
>     could be part of a toolkit.
>
>     Eric
>
>     >
>     > Best wishes,
>     > David.
>     >
>     > --
>     > Dr. David P. Sanders
>     >
>     > Profesor Titular "A" / Associate Professor
>     > Departamento de F?sica, Facultad de Ciencias
>     > Universidad Nacional Aut?noma de M?xico (UNAM)
>     >
>     > dps...@ci... <mailto:dps...@ci...>
>     <mailto:dps...@ci...
>     <mailto:dps...@ci...>>
>     > http://sistemas.fciencias.unam.mx/~dsanders
>     <http://sistemas.fciencias.unam.mx/%7Edsanders>
>     > <http://sistemas.fciencias.unam.mx/%7Edsanders>
>     >
>     > Cub?culo / office: #414, 4o. piso del Depto. de F?sica
>     > Tel.: +52 55 5622 4965 <tel:%2B52%2055%205622%204965>
>     >
>     >
>     >
>     ------------------------------------------------------------------------------
>     > See everything from the browser to the database with AppDynamics
>     > Get end-to-end visibility with application monitoring from
>     AppDynamics
>     > Isolate bottlenecks and diagnose root cause in seconds.
>     > Start your free trial of AppDynamics Pro today!
>     >
>     http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>     >
>     >
>     >
>     > _______________________________________________
>     > Matplotlib-devel mailing list
>     > Mat...@li...
>     <mailto:Mat...@li...>
>     > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>     >
>
>
>
>
>     ------------------------------
>
>     Message: 2
>     Date: Sat, 20 Jul 2013 08:55:37 -1000
>     From: Eric Firing <ef...@ha... <mailto:ef...@ha...>>
>     Subject: Re: [matplotlib-devel] How to use STIX fonts in matplotlib
>             plots?
>     To: mat...@li...
>     <mailto:mat...@li...>
>     Message-ID: <51E...@ha...
>     <mailto:51E...@ha...>>
>     Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>     On 2013/07/20 4:41 AM, David P. Sanders wrote:
>     > I find the default font used in matplotlib horrible. We should
>     be able
>     > to do much better these days.
>
>     Which font is being used as default on your installation?  And
>     what are
>     the characteristics that earn the rating of "horrible"?
>
>     Eric
>
>
>
>     ------------------------------
>
>     Message: 3
>     Date: Sat, 20 Jul 2013 14:58:12 -0400
>     From: Benjamin Root <ben...@ou... <mailto:ben...@ou...>>
>     Subject: Re: [matplotlib-devel] Plot or Not: voting to create better
>             matplotlibrc
>     To: Eric Firing <ef...@ha... <mailto:ef...@ha...>>
>     Cc: matplotlib development list
>             <mat...@li...
>     <mailto:mat...@li...>>
>     Message-ID:
>            
>     <CANNq6F=pdWohTRYLqEkG3oy6VoWYJ=c4Q...@ma... <mailto:c4Q...@ma...>>
>     Content-Type: text/plain; charset="iso-8859-1"
>
>     >From discussions with others at SciPy, we found ourselves
>     disagreeing on
>     what default we would want. We also weren't sure exactly which
>     params were
>     the ones that people tended to change. We have zero data on this.
>     This site
>     is intended to help start that data collection process.
>
>     We can certainly improve this site to collect other kinds of info,
>     but this
>     is just a start. One could also view this as a launching point for
>     teaching
>     how to use rcParams (sorry David, i kinda like that name) in mpl.
>     You all
>     know I never let a good teaching moment go to waste!
>
>     As for linking from matplotlib.org <http://matplotlib.org>, I am
>     ambivalent. It is a bit gimmicky,
>     and I do worry about being counterproductive to efforts in SciPy
>     to be more
>     inclusive of women (given the rather anti-feministic undertones of
>     the site
>     we are parodying). Of course, that could just be me being overly
>     cautious.
>
>     Cheers!
>     Ben Root
>     On Jul 20, 2013 2:20 PM, "Eric Firing" <ef...@ha...
>     <mailto:ef...@ha...>> wrote:
>
>     > On 2013/07/20 4:18 AM, David P. Sanders wrote:
>     > > Hi,
>     > >
>     > > Probably many of you know about "Plot or Not", a site where we
>     vote on
>     > > the same plot presented in different ways, to get feedback
>     about better
>     > > matplotlibrc params:
>     > >
>     > > http://warm-escarpment-9042.herokuapp.com/
>     > >
>     > > It seems to me an absolutely fantastic idea! I think many
>     people do not
>     > > realise how fantastic the plots can look with some of this modern
>     > > styling. (Styling was mentioned several times at SciPy.)
>     > >
>     > > Would it be possible to put a link to this site on the
>     matplotlib web
>     > > page and encourage people to use it?
>     >
>     > David,
>     >
>     > Interesting, but I'm not sure this is a good approach.  I really
>     don't
>     > see the point of the voting.  What I think would be more useful
>     would be
>     > a set of matplotlibrc files with examples of their effect on at
>     least a
>     > few plot types.
>     >
>     > >
>     > > Definitely time to update the defaults!!
>     >
>     > Or maybe include a representative set of rcParams combinations
>     to make
>     > it easier for people to choose a design that suits their
>     purpose.  This
>     > could be part of a toolkit.
>     >
>     > Eric
>     >
>     > >
>     > > Best wishes,
>     > > David.
>     > >
>     > > --
>     > > Dr. David P. Sanders
>     > >
>     > > Profesor Titular "A" / Associate Professor
>     > > Departamento de F?sica, Facultad de Ciencias
>     > > Universidad Nacional Aut?noma de M?xico (UNAM)
>     > >
>     > > dps...@ci... <mailto:dps...@ci...>
>     <mailto:dps...@ci...
>     <mailto:dps...@ci...>>
>     > > http://sistemas.fciencias.unam.mx/~dsanders
>     <http://sistemas.fciencias.unam.mx/%7Edsanders>
>     > > <http://sistemas.fciencias.unam.mx/%7Edsanders>
>     > >
>     > > Cub?culo / office: #414, 4o. piso del Depto. de F?sica
>     > > Tel.: +52 55 5622 4965 <tel:%2B52%2055%205622%204965>
>     > >
>     > >
>     > >
>     >
>     ------------------------------------------------------------------------------
>     > > See everything from the browser to the database with AppDynamics
>     > > Get end-to-end visibility with application monitoring from
>     AppDynamics
>     > > Isolate bottlenecks and diagnose root cause in seconds.
>     > > Start your free trial of AppDynamics Pro today!
>     > >
>     >
>     http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>     > >
>     > >
>     > >
>     > > _______________________________________________
>     > > Matplotlib-devel mailing list
>     > > Mat...@li...
>     <mailto:Mat...@li...>
>     > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>     > >
>     >
>     >
>     >
>     >
>     ------------------------------------------------------------------------------
>     > See everything from the browser to the database with AppDynamics
>     > Get end-to-end visibility with application monitoring from
>     AppDynamics
>     > Isolate bottlenecks and diagnose root cause in seconds.
>     > Start your free trial of AppDynamics Pro today!
>     >
>     http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>     > _______________________________________________
>     > Matplotlib-devel mailing list
>     > Mat...@li...
>     <mailto:Mat...@li...>
>     > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>     >
>     -------------- next part --------------
>     An HTML attachment was scrubbed...
>
>     ------------------------------
>
>     Message: 4
>     Date: Sat, 20 Jul 2013 15:03:20 -0400
>     From: Benjamin Root <ben...@ou... <mailto:ben...@ou...>>
>     Subject: Re: [matplotlib-devel] How to use STIX fonts in matplotlib
>             plots?
>     To: "David P. Sanders" <dps...@ci...
>     <mailto:dps...@ci...>>
>     Cc: matplotlib development list
>             <mat...@li...
>     <mailto:mat...@li...>>
>     Message-ID:
>            
>     <CANNq6Fm0Oz=3uk...@ma... <mailto:3uk...@ma...>>
>     Content-Type: text/plain; charset="iso-8859-1"
>
>     David,
>
>     IIRC, we were just starting to investigate how to produce retina
>     graphics.
>     Perhaps you might be able to help Mike D and Michael de Hoon with
>     there
>     efforts because very few of us have retina displays.
>
>     Cheers!
>     Ben Root
>     On Jul 20, 2013 10:43 AM, "David P. Sanders"
>     <dps...@ci... <mailto:dps...@ci...>>
>     wrote:
>
>     > I find the default font used in matplotlib horrible. We should
>     be able to
>     > do much better these days.
>     >
>     > One very interesting option, at least for standard (paper)
>     publishing, is
>     > the STIX fonts, which is a Times-like font set promoted by several
>     > publishers.
>     >
>     > There are various options in matplotlib, such as
>     > matplotlib.rcParams["mathtext.fontset"], which allow the option
>     "stix",
>     > but I have not been able to get it to work. Can anybody please
>     help me with
>     > this -- what is required?
>     >
>     > I have the STIX otf or ttf installed on my Mac, but I don't seem
>     to manage
>     > to get the LaTeX versions installed -- installing LaTeX fonts is
>     *so*
>     > disgusting (is there some helper script for that?).
>     >
>     > Thanks and best wishes,
>     > David.
>     >
>     > --
>     > Dr. David P. Sanders
>     >
>     > Profesor Titular "A" / Associate Professor
>     > Departamento de F?sica, Facultad de Ciencias
>     > Universidad Nacional Aut?noma de M?xico (UNAM)
>     >
>     > dps...@ci... <mailto:dps...@ci...>
>     > http://sistemas.fciencias.unam.mx/~dsanders
>     <http://sistemas.fciencias.unam.mx/%7Edsanders>
>     >
>     > Cub?culo / office: #414, 4o. piso del Depto. de F?sica
>     >
>     > Tel.: +52 55 5622 4965 <tel:%2B52%2055%205622%204965>
>     >
>     >
>     >
>     ------------------------------------------------------------------------------
>     > See everything from the browser to the database with AppDynamics
>     > Get end-to-end visibility with application monitoring from
>     AppDynamics
>     > Isolate bottlenecks and diagnose root cause in seconds.
>     > Start your free trial of AppDynamics Pro today!
>     >
>     http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>     > _______________________________________________
>     > Matplotlib-devel mailing list
>     > Mat...@li...
>     <mailto:Mat...@li...>
>     > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>     >
>     >
>     -------------- next part --------------
>     An HTML attachment was scrubbed...
>
>     ------------------------------
>
>     ------------------------------------------------------------------------------
>     See everything from the browser to the database with AppDynamics
>     Get end-to-end visibility with application monitoring from AppDynamics
>     Isolate bottlenecks and diagnose root cause in seconds.
>     Start your free trial of AppDynamics Pro today!
>     http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>
>     ------------------------------
>
>     _______________________________________________
>     Matplotlib-devel mailing list
>     Mat...@li...
>     <mailto:Mat...@li...>
>     https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>     End of Matplotlib-devel Digest, Vol 86, Issue 17
>     ************************************************
>
>
>
>
> -- 
> ************************************
> Chris Beaumont
> Graduate Student
> Institute for Astronomy
> University of Hawaii at Manoa
> 2680 Woodlawn Drive
> Honolulu, HI 96822
> www.ifa.hawaii.edu/~beaumont <http://www.ifa.hawaii.edu/%7Ebeaumont>
> ************************************
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Plot or Not: voting to create better matplotlibrc

[Nathaniel S. <nj...@po...>]

On Mon, Jul 22, 2013 at 2:55 PM, Michael Droettboom <md...@st...> wrote:
> This is why I suggested that the best way forward is to implement some sort
> of easy styling functionality (like what Tony Yu has submitted in #2236,
> though I haven't had a chance to look at it yet), and make it explicit for
> the user to select a new style.  This could be either by adding a new line
> to the top of the plotting script, or adding a single switch in the global
> matplotlibrc file.  But there needs to be an explicit turning on of this.

Are you saying that the defaults can't change (i.e., any changes must
be opt-in), or just that there needs to be some transition period
before the defaults can change and a simple way to opt out afterwards?
I agree with the latter :-).

I have mixed feelings about a full "styling system" though, since, how
many coherent "styles" for plots are there? If we provide a menu of
plot styles right in the main documentation then it seems like it
would just end up being an excuse for people to procrastinate playing
with the different settings, and increase the number of manuscripts I
read that have baroque and poorly chosen colormaps, plots that use the
"ggplot as drawn by xkcd" style, etc. And what value would it really
add? IMO we have a responsibility to nudge users towards making good
plots, and that means having good defaults, and perhaps also means
encouraging people to use them instead of just picking things that
optimize some vague aesthetic judgement at 2am before the submission
deadline...

How about
  mpl.approximately_emulate(<version number>)
which sets the defaults to whatever version of matplotlib is named?
That could be used a-priori by people who want to future-proof their
scripts, is very easy to add after the fact if you upgrade matplotlib
and discover some plot of yours has been broken, and also encompasses
the "future" functionality (you could ask your current matplotlib to
emulate the next version, if it knows how).

The advantage of a limited API that just takes a version number is not
just that it's simpler on the backend (no need for a system to name
and discover styles, etc. etc.), but it can also easily encapsulate
knowledge like "the defaults were the same from 0.99 through 1.2, so
if anything in that range is requested use *this* file, but then in
1.3...". This means that if a user knows that their plot worked on 1.1
but broke on 1.4, they don't have to care -- they can just say
  mpl.approximately_emulate("1.1")
instead of having to somehow figure out that the right call is:
  mpl.style("0.99-through-1.2")

-n

Re: [matplotlib-devel] Plot or Not: voting to create better matplotlibrc

[Michael D. <md...@st...>]

On 07/22/2013 10:42 AM, Nathaniel Smith wrote:
> On Mon, Jul 22, 2013 at 2:55 PM, Michael Droettboom <md...@st...> wrote:
>> This is why I suggested that the best way forward is to implement some sort
>> of easy styling functionality (like what Tony Yu has submitted in #2236,
>> though I haven't had a chance to look at it yet), and make it explicit for
>> the user to select a new style.  This could be either by adding a new line
>> to the top of the plotting script, or adding a single switch in the global
>> matplotlibrc file.  But there needs to be an explicit turning on of this.
> Are you saying that the defaults can't change (i.e., any changes must
> be opt-in), or just that there needs to be some transition period
> before the defaults can change and a simple way to opt out afterwards?
> I agree with the latter :-).

I'm saying that there needs to be a transition period, and the start of 
that transition would be to require an explicit opt-in of the new defaults.

>
> I have mixed feelings about a full "styling system" though, since, how
> many coherent "styles" for plots are there? If we provide a menu of
> plot styles right in the main documentation then it seems like it
> would just end up being an excuse for people to procrastinate playing
> with the different settings, and increase the number of manuscripts I
> read that have baroque and poorly chosen colormaps, plots that use the
> "ggplot as drawn by xkcd" style, etc. And what value would it really
> add? IMO we have a responsibility to nudge users towards making good
> plots, and that means having good defaults, and perhaps also means
> encouraging people to use them instead of just picking things that
> optimize some vague aesthetic judgement at 2am before the submission
> deadline...
>
> How about
>    mpl.approximately_emulate(<version number>)
> which sets the defaults to whatever version of matplotlib is named?
> That could be used a-priori by people who want to future-proof their
> scripts, is very easy to add after the fact if you upgrade matplotlib
> and discover some plot of yours has been broken, and also encompasses
> the "future" functionality (you could ask your current matplotlib to
> emulate the next version, if it knows how).
>
> The advantage of a limited API that just takes a version number is not
> just that it's simpler on the backend (no need for a system to name
> and discover styles, etc. etc.), but it can also easily encapsulate
> knowledge like "the defaults were the same from 0.99 through 1.2, so
> if anything in that range is requested use *this* file, but then in
> 1.3...". This means that if a user knows that their plot worked on 1.1
> but broke on 1.4, they don't have to care -- they can just say
>    mpl.approximately_emulate("1.1")
> instead of having to somehow figure out that the right call is:
>    mpl.style("0.99-through-1.2")
>
I like this version idea.  (Not sure about the name 
"approximately_emulate", but that's a detail...)  Other tools (sphinx, 
for example) have a way of declaring what version was used when 
something was created.  If the user says:

matplotlib.styling_required('1.2')

then, if we're on 1.3, we do our best to load the styling defaults from 
1.2, and display a warning to the effect "this plot was written for 
matplotlib 1.2, we're running 1.3, so we're entering 1.2 compatibility 
mode, but some things still may be broken.  See the changes 
documentation".  (Again, we can work on the exact wording later).

I think this is a nice approach.  I still think the ability to load 
arbitrary styles from files, online etc. is required, though. There's 
really two issues to resolve here: one is to make sharing of styles 
easier (to have an institutional or publication style, for example), the 
other is to transitition to better defaults with as little breakage and 
pain as possible.  I think we need to do both.

Mike

Re: [matplotlib-devel] Plot or Not: voting to create better matplotlibrc

[Chris B. <bea...@ha...>]

I had the same question about opt-out vs opt-in. Personally, I vote for
opt-out. I would like to see each release of MPL have an associated style
(which may be the same as the last release, but maybe not). With Tony's
style PR, users that need constant styles would either put
`style.use('1.3')` in their script, or `style: 1.3` in an rcParams file.
This would then freeze the style FOR-EV-ER (sandlot voice). However, the
default would be `style: latest`, so that the default user benefits from
the community's effort into making the best possible set of defaults. Is
that sufficiently pain-free for people who want future proofing? Or do you
think styles must be opt-in (which, effectively, means that defaults cannot
change).

I'm not sure if I understand what you're getting at re:
approximately_emulate. I'm in favor of two modes for style loading -- some
kind of lazy version that only touches the options explicitly addressed in
the file, and an explicit version that defaults all other options to
something. Thus, explicit loading would guarantee that a style never
changes.

chris

Re: [matplotlib-devel] Plot or Not: voting to create better matplotlibrc

[Michael D. <md...@st...>]

On 07/22/2013 11:34 AM, Chris Beaumont wrote:
> I had the same question about opt-out vs opt-in. Personally, I vote 
> for opt-out. I would like to see each release of MPL have an 
> associated style (which may be the same as the last release, but maybe 
> not). With Tony's style PR, users that need constant styles would 
> either put `style.use('1.3')` in their script, or `style: 1.3` in an 
> rcParams file. This would then freeze the style FOR-EV-ER (sandlot 
> voice). However, the default would be `style: latest`, so that the 
> default user benefits from the community's effort into making the best 
> possible set of defaults. Is that sufficiently pain-free for people 
> who want future proofing? Or do you think styles must be opt-in 
> (which, effectively, means that defaults cannot change).

In my experience, the vast majority of users don't read changelog notes, 
so we can't expect people to opt out of something that will change 
and/or break their existing plots.  This is particularly a problem where 
matplotlib is upgraded by a sysadmin or distribution (about 58% percent 
of users, by our survey), because it doesn't even get upgraded on the 
user's timetable, necessarily.  So I think any changes to the defaults 
have to be opt-in.  However, we do have a policy of breaking things 
after a release cycle of deprecation warnings.  So we can change the 
defaults in 1.5 after a round of warnings about them in 1.4 (if an 
explicit style is not set).

>
> I'm not sure if I understand what you're getting at re: 
> approximately_emulate.

I took Nathaniel's suggestion to just mean that default style should be 
selectable by a version number, so the user doesn't have to keep track 
of the mapping between a style set and a version of matplotlib.

> I'm in favor of two modes for style loading -- some kind of lazy 
> version that only touches the options explicitly addressed in the 
> file, and an explicit version that defaults all other options to 
> something. Thus, explicit loading would guarantee that a style never 
> changes.
>
Yes -- I agree there, too.  "set_style" vs. "update_style" perhaps? 
("update" used for its similarity to dict.update?)

Mike