Plot or Not: voting to create better matplotlibrc

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, matplotlib-devel-request@lists.sourceforge.net wrote:

Send Matplotlib-devel mailing list submissions to

    matplotlib-devel@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit

    [https://lists.sourceforge.net/lists/listinfo/matplotlib-devel](https://lists.sourceforge.net/lists/listinfo/matplotlib-devel)

or, via email, send a message with subject or body ‘help’ to

    matplotlib-devel-request@lists.sourceforge.net

You can reach the person managing the list at

    matplotlib-devel-owner@lists.sourceforge.net

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 <efiring@…930…>

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

    matplotlibrc

To: matplotlib-devel@lists.sourceforge.net

Message-ID: <51EAD4DB.5040906@…229…>

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)

dpsanders@…1147… mailto:dpsanders@...1147...

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

Matplotlib-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


Message: 2

Date: Sat, 20 Jul 2013 08:55:37 -1000

From: Eric Firing <efiring@…930…>

Subject: Re: [matplotlib-devel] How to use STIX fonts in matplotlib

    plots?

To: matplotlib-devel@lists.sourceforge.net

Message-ID: <51EADD29.6080601@…229…>

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.root@…745…53…>

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

    matplotlibrc

To: Eric Firing <efiring@…229…>

Cc: matplotlib development list

    <matplotlib-devel@lists.sourceforge.net>

Message-ID:

    <CANNq6F=pdWohTRYLqEkG3oy6VoWYJ=c4Qob7vJ5q-SrE7tcrqA@...150...>

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” <efiring@…229…> 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)

dpsanders@…1147… mailto:dpsanders@...1147...

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

Matplotlib-devel@lists.sourceforge.net

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

Matplotlib-devel@lists.sourceforge.net

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.root@…745…53…>

Subject: Re: [matplotlib-devel] How to use STIX fonts in matplotlib

    plots?

To: “David P. Sanders” <dpsanders@…1147…>

Cc: matplotlib development list

    <matplotlib-devel@lists.sourceforge.net>

Message-ID:

    <CANNq6Fm0Oz=3ukXYH4yFA0qbHi2j7-sjdhkCzyrkU-4ELRdyow@...1149.....>

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” <dpsanders@…1147…>

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)

dpsanders@…1147…

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

Matplotlib-devel@lists.sourceforge.net

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

Matplotlib-devel@lists.sourceforge.net

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,

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

···

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

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

···

On Sat, Jul 20, 2013 at 4:47 PM, Chris Beaumont <beaumont@...229...> 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

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, > <matplotlib-devel-request@lists.sourceforge.net > <mailto:matplotlib-devel-request@lists.sourceforge.net>> wrote:

    Send Matplotlib-devel mailing list submissions to
    matplotlib-devel@lists.sourceforge.net
    <mailto:matplotlib-devel@lists.sourceforge.net>

    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
    matplotlib-devel-request@lists.sourceforge.net
    <mailto:matplotlib-devel-request@lists.sourceforge.net>

    You can reach the person managing the list at
    matplotlib-devel-owner@lists.sourceforge.net
    <mailto:matplotlib-devel-owner@lists.sourceforge.net>

    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 <efiring@…229… <mailto:efiring@…229…>>
    Subject: Re: [matplotlib-devel] Plot or Not: voting to create better
            matplotlibrc
    To: matplotlib-devel@lists.sourceforge.net
    <mailto:matplotlib-devel@lists.sourceforge.net>
    Message-ID: <51EAD4DB.5040906@…229…
    <mailto:51EAD4DB.5040906@…229…>>
    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)
    >
    > dpsanders@…1147… <mailto:dpsanders@…1147…>
    <mailto:dpsanders@…1147…
    <mailto:dpsanders@…1147…>>
    > http://sistemas.fciencias.unam.mx/~dsanders
    <http://sistemas.fciencias.unam.mx/~dsanders>
    > <http://sistemas.fciencias.unam.mx/~dsanders>
    >
    > 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
    > Matplotlib-devel@lists.sourceforge.net
    <mailto:Matplotlib-devel@lists.sourceforge.net>
    > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
    >

    ------------------------------

    Message: 2
    Date: Sat, 20 Jul 2013 08:55:37 -1000
    From: Eric Firing <efiring@…229… <mailto:efiring@…229…>>
    Subject: Re: [matplotlib-devel] How to use STIX fonts in matplotlib
            plots?
    To: matplotlib-devel@lists.sourceforge.net
    <mailto:matplotlib-devel@lists.sourceforge.net>
    Message-ID: <51EADD29.6080601@…229…
    <mailto:51EADD29.6080601@…229…>>
    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.root@…553… <mailto:ben.root@…553…>>
    Subject: Re: [matplotlib-devel] Plot or Not: voting to create better
            matplotlibrc
    To: Eric Firing <efiring@…229… <mailto:efiring@…229…>>
    Cc: matplotlib development list
            <matplotlib-devel@lists.sourceforge.net
    <mailto:matplotlib-devel@lists.sourceforge.net>>
    Message-ID:
               <CANNq6F=pdWohTRYLqEkG3oy6VoWYJ=c4Qob7vJ5q-SrE7tcrqA@…150… <mailto:c4Qob7vJ5q-SrE7tcrqA@…150…>>
    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" <efiring@…229… > <mailto:efiring@…229…>> 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)
    > >
    > > dpsanders@…1147… <mailto:dpsanders@…1147…>
    <mailto:dpsanders@…1147…
    <mailto:dpsanders@…1147…>>
    > > http://sistemas.fciencias.unam.mx/~dsanders
    <http://sistemas.fciencias.unam.mx/~dsanders>
    > > <http://sistemas.fciencias.unam.mx/~dsanders>
    > >
    > > 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
    > > Matplotlib-devel@lists.sourceforge.net
    <mailto:Matplotlib-devel@lists.sourceforge.net>
    > > 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
    > Matplotlib-devel@lists.sourceforge.net
    <mailto:Matplotlib-devel@lists.sourceforge.net>
    > 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.root@…553… <mailto:ben.root@…553…>>
    Subject: Re: [matplotlib-devel] How to use STIX fonts in matplotlib
            plots?
    To: "David P. Sanders" <dpsanders@…1147…
    <mailto:dpsanders@…1147…>>
    Cc: matplotlib development list
            <matplotlib-devel@lists.sourceforge.net
    <mailto:matplotlib-devel@lists.sourceforge.net>>
    Message-ID:
               <CANNq6Fm0Oz=3ukXYH4yFA0qbHi2j7-sjdhkCzyrkU-4ELRdyow@…150… <mailto:3ukXYH4yFA0qbHi2j7-sjdhkCzyrkU-4ELRdyow@…150…>>
    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" > <dpsanders@…1147… <mailto:dpsanders@…1147…>> > 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)
    >
    > dpsanders@…1147… <mailto:dpsanders@…1147…>
    > http://sistemas.fciencias.unam.mx/~dsanders
    <http://sistemas.fciencias.unam.mx/~dsanders>
    >
    > 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
    > Matplotlib-devel@lists.sourceforge.net
    <mailto:Matplotlib-devel@lists.sourceforge.net>
    > 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
    Matplotlib-devel@lists.sourceforge.net
    <mailto:Matplotlib-devel@lists.sourceforge.net>
    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/~beaumont>
************************************

------------------------------------------------------------------------------
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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

···

On Mon, Jul 22, 2013 at 2:55 PM, Michael Droettboom <mdroe@...31...> 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.

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

···

On 07/22/2013 10:42 AM, Nathaniel Smith wrote:

On Mon, Jul 22, 2013 at 2:55 PM, Michael Droettboom <mdroe@...31...> 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).

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

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 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.
Yes – I agree there, too. “set_style” vs. “update_style” perhaps?
(“update” used for its similarity to dict.update?)
Mike

···

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).

        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.