Patch: set capsize of errorbar via matplotlibrc

Development matplotlib-devel
1

Hi fellow developers,

I am using matplotlib in particle physics where we generally do not plot the little end caps of error bars. They add no information, but they make the plot harder to read, especially if it is a busy plot.

In physics, we follow the general aesthetic rule to maximise the "data to ink ratio", which means that the information should be presented with a minimum of optical gimmicks.

So, I end up calling errorbar everytime with capsize=0. I argue that having end caps or not is a global style option, and therefore it makes sense to put this into matplotlibrc.

I prepared a patch in order to do that and would like you to include it into the distribution.

Please tell me what you think of it.

0001-get-capsize-via-configuration-entry-lines.capsize.patch (4.05 KB)

2

Dear developers,

I submitted a patch a few weeks ago that I think would be useful to have in the matplotlib, but I didn't get any response. I use the library extensively for science work and would like to be able to contribute to this great project.

Since I didn't get any responses, I would like to know what you want me to do in order to get my ideas into the project. I cannot commit much time, but I am sure I will find little neat pieces to add every now and then.

Please allow me to participate.

0001-get-capsize-via-configuration-entry-lines.capsize.patch (4.05 KB)

···

-------- Original Message --------
Subject: Patch: set capsize of errorbar via matplotlibrc
Date: Thu, 09 Aug 2012 14:10:27 +0200
From: Hans Dembinski <hans.dembinski@...1073...>
To: matplotlib-devel@lists.sourceforge.net

Hi fellow developers,

I am using matplotlib in particle physics where we generally do not plot
the little end caps of error bars. They add no information, but they
make the plot harder to read, especially if it is a busy plot.

In physics, we follow the general aesthetic rule to maximise the "data
to ink ratio", which means that the information should be presented with
a minimum of optical gimmicks.

So, I end up calling errorbar everytime with capsize=0. I argue that
having end caps or not is a global style option, and therefore it makes
sense to put this into matplotlibrc.

I prepared a patch in order to do that and would like you to include it
into the distribution.

Please tell me what you think of it.

3

Dear developers,

I submitted a patch a few weeks ago that I think would be useful to have
in the matplotlib, but I didn't get any response. I use the library
extensively for science work and would like to be able to contribute to
this great project.

Good!

Since I didn't get any responses, I would like to know what you want me
to do in order to get my ideas into the project. I cannot commit much
time, but I am sure I will find little neat pieces to add every now and
then.

Submitting patches as github pull requests is strongly preferred. See http://matplotlib.sourceforge.net/devel/index.html.

In the svn days, most devel discussions of proposed changes occurred on this mailing list, but now attention is much more on github PRs and less on the mailing list.

Please allow me to participate.

We welcome you--but sometimes we are simply overwhelmed and/or unorganized, and consequently unresponsive. There is a random aspect to it!

Regarding your patch: this sounds like it might be a good idea, but I don't think the rc param should be called lines.capsize because it is not a general line property, but something specific to errorbars. "lines.*cap*" refer to completely unrelated general line properties.

It would be good to get some thoughts from others as to whether to an "errorbar" or similar category should be added to rcParams, with your suggestion as the first entry in that category. Maybe we need some policy guideline as to what should go in rcParams and what should not.

Eric

···

On 2012/08/29 11:57 PM, Hans Dembinski wrote:

-------- Original Message --------
Subject: Patch: set capsize of errorbar via matplotlibrc
Date: Thu, 09 Aug 2012 14:10:27 +0200
From: Hans Dembinski <hans.dembinski@...1073...>
To: matplotlib-devel@lists.sourceforge.net

Hi fellow developers,

I am using matplotlib in particle physics where we generally do not plot
the little end caps of error bars. They add no information, but they
make the plot harder to read, especially if it is a busy plot.

In physics, we follow the general aesthetic rule to maximise the "data
to ink ratio", which means that the information should be presented with
a minimum of optical gimmicks.

So, I end up calling errorbar everytime with capsize=0. I argue that
having end caps or not is a global style option, and therefore it makes
sense to put this into matplotlibrc.

I prepared a patch in order to do that and would like you to include it
into the distribution.

Please tell me what you think of it.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

4

Sorry for the lack of a response. We have been absolutely swamped with the push for v1.2.0, and your email must have gotten lost in the pile. Note, repinging us as you have done is the absolutely correct thing to do.

Looking over your patch, the goal is sound, but the name of the rcparam you choose would likely cause confusion. “line.capsize” and “line.capstyle”, for instance, are referring to two completely different things that just happens to have the same name “cap”. There are a lot of kwargs in axes.py that have yet to be included into the rcparams, and we really need to push to do this, but in a sensible and structured manner.

Anybody have thoughts on updating the naming scheme of the rc-params?

Ben Root

···

On Thu, Aug 30, 2012 at 5:57 AM, Hans Dembinski <hans.dembinski@…1073…> wrote:

Dear developers,

I submitted a patch a few weeks ago that I think would be useful to have in the matplotlib, but I didn’t get any response. I use the library extensively for science work and would like to be able to contribute to this great project.

Since I didn’t get any responses, I would like to know what you want me to do in order to get my ideas into the project. I cannot commit much time, but I am sure I will find little neat pieces to add every now and then.

Please allow me to participate.

5

: ) Thanks for the response.

Submitting patches as github pull requests is strongly preferred. See
http://matplotlib.sourceforge.net/devel/index.html.

In the svn days, most devel discussions of proposed changes occurred on
this mailing list, but now attention is much more on github PRs and less
on the mailing list.

Okay, I will try that then!

Please allow me to participate.

We welcome you--but sometimes we are simply overwhelmed and/or
unorganized, and consequently unresponsive. There is a random aspect to it!

I can deal with randomness, in fact, the field of statistics is one of my special interests : D

Regarding your patch: this sounds like it might be a good idea, but I
don't think the rc param should be called lines.capsize because it is
not a general line property, but something specific to errorbars.
"lines.*cap*" refer to completely unrelated general line properties.

It would be good to get some thoughts from others as to whether to an
"errorbar" or similar category should be added to rcParams, with your
suggestion as the first entry in that category. Maybe we need some
policy guideline as to what should go in rcParams and what should not.

You are right, I also thought about that. My first idea was to add an errorbar.* category, but then I saw that also the bar plots (axes.bar(...), axes.barh(...)) use caps. What I am trying to say is that it is not only used by axes.errorbar(...). That's why I put into the lines.* category, but that's certainly open for discussion.

Having a policy on what to put into rcParams sounds useful.

Best regards,
Hans

···

On 08/30/2012 08:41 PM, Eric Firing wrote: