Re: [matplotlib-devel] Passing errorbar width arguments to bar/barh ?

[John Hunter]

On Tue, Jun 1, 2010 at 6:17 PM, Fernando Perez  wrote:
> Hi all,
>
> I just spent some time digging through the matplotlib code, and I see
> that the errorbar line width argument isn't passed through to the
> underlying call.  In axis.bar, we have this code:
>
>        if xerr is not None or yerr is not None:
>            if orientation == 'vertical':
>                # using list comps rather than arrays to preserve unit info
>                x = [l+0.5*w for l, w in zip(left, width)]
>                y = [b+h for b,h in zip(bottom, height)]
>
>            elif orientation == 'horizontal':
>                # using list comps rather than arrays to preserve unit info
>                x = [l+w for l,w in zip(left, width)]
>                y = [b+0.5*h for b,h in zip(bottom, height)]
>
>            self.errorbar(
>                x, y,
>                yerr=yerr, xerr=xerr,
>                fmt=None, ecolor=ecolor, capsize=capsize)
>
> while errorbar has this signature:
>
>    def errorbar(self, x, y, yerr=None, xerr=None,
>                 fmt='-', ecolor=None, elinewidth=None, capsize=3,
>                 barsabove=False, lolims=False, uplims=False,
>                 xlolims=False, xuplims=False, **kwargs):
>
> For a poster, we wanted thicker errorbars drawn and had to resort to:
>
> plt.rcParams['lines.markeredgewidth'] = 2
> plt.rcParams['lines.linewidth'] = 2
>
> and reverting back to normal width after making the errorbar calls.
> Should I file a ticket about this, or are such fine-tuning tasks
> considered as fair game for rcParams manipulations?
>
> I'm happy to file the ticket, I just don't want to create unnecessary
> noise if the rcparams is meant to be 'the way' to do it.

While this is certainly a bug that needs to be fixed (and Eric is
right that these functions are heavily overworked and hairy), there is
a better workaround than the one you tried.  From the errorbar
docstring:



Return value is a length 3 tuple.  The first element is the
:class:`~matplotlib.lines.Line2D` instance for the *y* symbol
lines.  The second element is a list of error bar cap lines,
the third element is a list of
:class:`~matplotlib.collections.LineCollection` instances for
the horizontal and vertical error ranges.

So you can call the appropriate methods on the return objects.  Eg

  ylines, caplines, vlines = ax.errorbar(...)

if you want to set the vertical line thickness, it is a LineCollection
instance so you can call

  vlines.set_linewidth(2.0)

Since it is a Collection instance, you can also vary the vertical
linewidths by passing in a sequuence of linewidths.

Hope this helps,
JDH

--

___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Passing errorbar width arguments to bar/barh ?

[John Hunter]

On Wed, Jun 2, 2010 at 8:01 AM, John Hunter  wrote:

> While this is certainly a bug that needs to be fixed (and Eric is
> right that these functions are heavily overworked and hairy), there is
> a better workaround than the one you tried.  From the errorbar
> docstring:

Ignore me :-)  I had a temporary mental failure and see that this
won't help you since you are calling "bar" and when bar is called with
the xerr/yerr args the errorbar return values aren't passed back up.
 And my solution wasn't correct anyhow, since the third argument
returned from errorbar is a *list* of LineCollection instances, not a
LineCollection instance.  Shutting up

JDH

--

___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Some keys generate tracebacks in the GTK backend

[Tony S Yu]

On Jun 1, 2010, at 8:59 AM, João Luís Silva wrote:

> Hi,
> 
> Pressing tab, the "Windows" key or the right click key (and maybe 
> others) on a plot with the GTKAgg or GTK backend causes the following 
> traceback:
> 
> Traceback (most recent call last):

[snip]

>   File "/usr/lib/python2.5/site-packages/matplotlib/backend_bases.py", 
> line 2079, in key_press
> if event.key in fullscreen_keys:
> TypeError: 'in ' requires string as left operand
> 
> This happens because in these cases the key is None. The WXAgg backend 
> doesn't have this bug (I haven't tested qt nor tk backends).


This is similar to an issue I had. I posted a patch for my error, but it was 
specific to Qt4 and required all keys to be manually added to the class 
definition. I suggested a more robust solution: returning early in 
backend_bases when the key is None. That suggestion kind of died after Darren 
Dale solicited responses from other devs.

If it helps at all, I've attached a very simple patch. The early return at the 
top of the patch is the important part. The change near the bottom is added 
because we've already checked for None (i.e. purely cosmetic).

-Tony


Index: lib/matplotlib/backend_bases.py
===
--- lib/matplotlib/backend_bases.py (revision 8366)
+++ lib/matplotlib/backend_bases.py (working copy)
@@ -2062,6 +2062,8 @@
 #self.destroy() # how cruel to have to destroy oneself!
 #return
 
+if event.key is None:
+return
 # Load key-mappings from your matplotlibrc file.
 fullscreen_keys = rcParams['keymap.fullscreen']
 home_keys = rcParams['keymap.home']
@@ -2128,8 +2130,7 @@
 ax.set_xscale('log')
 ax.figure.canvas.draw()
 
-elif event.key is not None and \
- (event.key.isdigit() and event.key!='0') or event.key in all:
+elif (event.key.isdigit() and event.key!='0') or event.key in all:
 # keys in list 'all' enables all axes (default key 'a'),
 # otherwise if key is a number only enable this particular axes
 # if it was the axes, where the event was raised

--

___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Some keys generate tracebacks in the GTK backend

[John Hunter]

On Wed, Jun 2, 2010 at 8:28 AM, Tony S Yu  wrote:
>
> On Jun 1, 2010, at 8:59 AM, João Luís Silva wrote:
>
> Hi,
>
> Pressing tab, the "Windows" key or the right click key (and maybe
> others) on a plot with the GTKAgg or GTK backend causes the following
> traceback:

Thanks Tony, committed to svn r8367

JDH

--

___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Passing errorbar width arguments to bar/barh ?

[Benjamin Root]

I am curious as to why bar() should even be acting like errorbar().  As a
user, I would expect bar() to do bar graphs and errorbar() to do error bar
graphs.  Is there some sort of use-case that I am missing where it makes
sense to generate errorbars from a bar() function?

Ben Root

On Wed, Jun 2, 2010 at 8:06 AM, John Hunter  wrote:

> On Wed, Jun 2, 2010 at 8:01 AM, John Hunter  wrote:
>
> > While this is certainly a bug that needs to be fixed (and Eric is
> > right that these functions are heavily overworked and hairy), there is
> > a better workaround than the one you tried.  From the errorbar
> > docstring:
>
> Ignore me :-)  I had a temporary mental failure and see that this
> won't help you since you are calling "bar" and when bar is called with
> the xerr/yerr args the errorbar return values aren't passed back up.
>  And my solution wasn't correct anyhow, since the third argument
> returned from errorbar is a *list* of LineCollection instances, not a
> LineCollection instance.  Shutting up
>
> JDH
>
>
> --
>
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--

___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Fwd: [Matplotlib-users] [mplot3d] change axis background color

[Benjamin Root]

This is from the matplotlib-users list.  A user noticed that he can not
change the background color of a 3d plot with arguments to .savefig().  Is
this a bug or is it intentional?

Thanks,
Ben Root

-- Forwarded message --
From: Denis Laxalde 
Date: Wed, Jun 2, 2010 at 9:42 AM
Subject: Re: [Matplotlib-users] [mplot3d] change axis background color
To: matplotlib-us...@lists.sourceforge.net


This is set in axis3d module (class Axis), by _AXINFO.
So far, I haven't found a way to modify colors/transparency but to edit
the latter file. Is this hard-coded or is there a way to modify this a
posteriori ?

Cheers,

   Denis

Le 02-06-2010, Benjamin Root  a
écrit :
> Huh, how about that?  I never noticed that before.  I wonder if that
> is a bug or if it is intentional?
>
> Ben Root
>
> On Tue, Jun 1, 2010 at 5:28 PM, Denis Laxalde
>  wrote:
>
>> Hi Ben,
>>
>> Thanks for your answer.  Actually, options for savefig seem to only
>> operate on 2D axes whereas I'm trying to change the color of 3D axes
>> (x,y,z) which, by default, have a grid with a gray background.  I
>> manage to remove the grid lines but not the background color.  (My
>> initial question was not very clear perhaps...)
>>
>>Denis
>>
>>
>> Le mardi 01 juin 2010 =E0 16:57 -0500, Benjamin Root a =E9crit :
>> > Denis,
>> >
>> > There are probably other ways, but the one that I know off the top
>> > of m=
> y
>> > head is done at the savefig() function.  If you want to remove the
>> > background entirely, you can specify the keyword argument
>> transparent=3DTrue.
>> > You can change the color using the facecolor keyword argument.  You
>> > can specify any color in that argument like you would elsewhere in
>> matplotlib.
>> >
>> > Ben Root
>> >
>> > On Tue, Jun 1, 2010 at 4:42 PM, Denis Laxalde
>> > 
>> wrote:
>> >
>> > > Hi,
>> > >
>> > > Is there a way to change (and maybe remove) the background color
>> > > (gra=
> y
>> > > by default) of axis in mplot3d graphics ?
>> > >
>> > > Thanks,
>> > >
>> > >  Denis
>> > >
>>


--

___
Matplotlib-users mailing list
matplotlib-us...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
--

___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Passing errorbar width arguments to bar/barh ?

[John Hunter]

On Wed, Jun 2, 2010 at 9:48 AM, Benjamin Root  wrote:
> I am curious as to why bar() should even be acting like errorbar().  As a
> user, I would expect bar() to do bar graphs and errorbar() to do error bar
> graphs.  Is there some sort of use-case that I am missing where it makes
> sense to generate errorbars from a bar() function?

Some of this stuff is just really old (circa 2003).  When you have
just a few users and someone sends you a patch, you tend to accept it
:-)

First we had bar, then we had errorbar, and someone wanted the
convenience of easily adding errorbars to bar plots.  Over time, these
conveniences have grown into a fairly complex interface (xerr, yerr,
asymmetric errors).  So it has grown more organically than by design
and some rationalization and normalization of functionality would be a
good thing.  We have to balance that with the downsides of code
breakage, however.

JDH

--

___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Fwd: [Matplotlib-users] [mplot3d] change axis background color

[Jae-Joon Lee]

On Wed, Jun 2, 2010 at 10:51 AM, Benjamin Root  wrote:
> This is from the matplotlib-users list.  A user noticed that he can not
> change the background color of a 3d plot with arguments to .savefig().  Is
> this a bug or is it intentional?
>
> Thanks,
> Ben Root

I think it is just that they are implemented differently. The
background of axes3d is not actually a figure background but an axes
patch. If you want, you can make the patch invisible. This will show
the default gray background of the figure. Also, the options like
transparent=True will work.

ax.patch.set_visible(False)

Regards,

-JJ

--

___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Bug rasterized image in pcolor and pcolormesh

[Eric Firing]

On 06/01/2010 05:21 PM, Benjamin Root wrote:
> I have finally managed to test against TkAgg, and the faint white lines
> do not appear to occur.  So, as far as I can tell (no clue about Macs),
> the GTKCairo, pdf and svg backends have this display bug.  Shall I file
> a bug report for this and another for the misaligned title?

Yes.  Please include the simplest scripts you can devise that generate 
and illustrate the problems.  In the pcolormesh case, this means keeping 
the plot (and the data being plotted) as simple as possible.  If the 
problem can be illustrated with only two color regions, for example, 
that is ideal.

Eric

>
> Ben Root
>
> On Tue, Jun 1, 2010 at 1:07 PM, Benjamin Root  > wrote:
>
> Correction -- the problem with pcolormesh and the faint white lines
> are occurring for pdf and svg files, *not* eps files as I originally
> stated.  I am also checking a number of display backends and found
> that the problem occurs for GTKCairo.  I am sure it also happens for
> TkAgg, but I can not confirm that right now.  I am unable to test
> the Mac backends, though.
>
> On a side note, when testing the backends, I noticed that GTKCairo
> was *slow* for displaying the figures.  Also, the GTK backend
> produced misaligned titles.  I can start a new thread about the
> misaligned titles, if someone wishes.
>
> Ben Root
>
>
> On Tue, Jun 1, 2010 at 11:05 AM, Benjamin Root  > wrote:
>
>
>
> On Tue, Jun 1, 2010 at 9:39 AM, Ryan May  > wrote:
>
> On Mon, May 31, 2010 at 11:28 AM, Benjamin Root
> mailto:ben.r...@ou.edu>> wrote:
>  > Markus,
>  >
>  > That is good to know that it has been fixed.  As for the
> difference in
>  > pcolor and pcolormesh, I think it has to do with the fact
> that pcolormesh is
>  > composed of many lines while pcolor is composed of many
> polygons.  It is
>  > probably more efficient to rasterize polygons than lines.
>
> To be blunt, this makes no sense whatsoever.  First,
> pcolormesh and
> pcolor differ in that it pcolor uses a generic
> PolyCollection to draw
> the quads, while pcolormesh uses a quadmesh object, which
> can be more
> efficient at the cost of generality, as it only needs to
> render a set
> of identical quads. Second, if you're talking rasterized
> drawing, in
> the end what gets written to a file is a 2D array of RGBA
> values.  It
> doesn't matter what you use to produce the results:
> identical image on
> the screen -> identical array in file.  It's possible that
> there are
> slight differences that you can't really see that produce
> different
> arrays, but that won't cause a factor of 8 difference in
> size. My
> guess is that pcolormesh isn't rasterizing properly.
>
> Indeed, you are right that lines aren't drawn.  I have looked
> back at the images produced by my test script that I posted to
> this thread and I see where I got confused.  The pcolormesh
> result in pdf and eps files have very faint white blocks around
> each quad.  At high enough data resolution, the color part of
> the quads look like lines while the white lines look like dots.
> This happens regardless of using rasterized=True or not, and I
> don't think it is visible in png files (although I am testing
> some very high resolution png files to verify).
>
> Ben Root
>
>
>
>
>
> --
>
>
>
>
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


--

___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Upcoming Debian stable release and matplotlib new release(s)

[Tom Holroyd (NIH/NIMH) [E]]

John Hunter wrote:
> 
> https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-0.99.3

I'm running Fedora 13, and it mostly works but the config output says that
Tkinter isn't there, but it is. It finds Qt4 OK, but seems to have trouble
finding tkinter and agg. I just did the yum install for these things, it's
only with matplotlib that I have a devel version. What is it looking for and
where do I look to see?

-- 
Dr. Tom
---
I would dance and be merry,
Life would be a ding-a-derry,
If I only had a brain.
-- The Scarecrow

--

___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Upcoming Debian stable release and matplotlib new release(s)

[John Hunter]

On Wed, Jun 2, 2010 at 12:34 PM, Tom Holroyd (NIH/NIMH) [E]
 wrote:
>
>
> John Hunter wrote:
>>
>> https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-0.99.3
>
> I'm running Fedora 13, and it mostly works but the config output says that
> Tkinter isn't there, but it is. It finds Qt4 OK, but seems to have trouble
> finding tkinter and agg. I just did the yum install for these things, it's
> only with matplotlib that I have a devel version. What is it looking for and
> where do I look to see?

Make sure you have the tk-devel and tcl-devel packages installed.
Also, try editing setup.cfg

  > cp setup.cfg.template setup.cfg

and set

  tkagg = True

to force a tkagg build (rather than an autobuild).

Do a clean rebuild (rm -rf build) and post the results of the
build/compile if you have problems.

JDH

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Passing errorbar width arguments to bar/barh ?

[Eric Firing]

On 06/01/2010 03:33 PM, Fernando Perez wrote:
> On Tue, Jun 1, 2010 at 4:35 PM, Eric Firing  wrote:
>> it seems to me that the solution is for
>> bar to take a kwarg, say "errorkw", which is a dict that will be passed
>> to errorbar via **errorkw, and that can have any valid errorbar kwargs
>> in it.  There is some precedent for this sort of thing, and I find it a
>> useful way of keeping kwargs from getting out of control when one is
>> making complicated compound plots.
>
> That would be my suggessted approach as well, I've used it elsewhere.
>
>> If there is no objection, I will do it.
>
> Fabulous, many thanks!

Done in svn 8369.  Its usage is illustrated in barchart_demo.py. 
Partially following your lead with subplots, I spelled it error_kw.

Eric

>
> Cheers,
>
> f
>
> --
>
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Passing errorbar width arguments to bar/barh ?

[Benjamin Root]

On Wed, Jun 2, 2010 at 10:26 AM, John Hunter  wrote:

> On Wed, Jun 2, 2010 at 9:48 AM, Benjamin Root  wrote:
> > I am curious as to why bar() should even be acting like errorbar().  As a
> > user, I would expect bar() to do bar graphs and errorbar() to do error
> bar
> > graphs.  Is there some sort of use-case that I am missing where it makes
> > sense to generate errorbars from a bar() function?
>
> Some of this stuff is just really old (circa 2003).  When you have
> just a few users and someone sends you a patch, you tend to accept it
> :-)
>
> First we had bar, then we had errorbar, and someone wanted the
> convenience of easily adding errorbars to bar plots.  Over time, these
> conveniences have grown into a fairly complex interface (xerr, yerr,
> asymmetric errors).  So it has grown more organically than by design
> and some rationalization and normalization of functionality would be a
> good thing.  We have to balance that with the downsides of code
> breakage, however.
>
> I kinda figured something like that was the case.  I am just cautious about
additional "organic" development of these functions.  I have encountered
some functions where it was a bug that the function did not pass on the
kwargs, and others where it wasn't a bug.  Does the approach of using a
separate dict called error_kw fit in with some sort of overall design/best
practices or might there be a better way to approach this.

I merely ask because I am quite new here and I am curious about what style
we want for our code.  Maybe we should consider some sort of special
universal (for matplotlib) module that does special handling of kwargs?  I
am just throwing out some thoughts.

Ben Root
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Bug rasterized image in pcolor and pcolormesh

[Benjamin Root]

On Wed, Jun 2, 2010 at 11:41 AM, Eric Firing  wrote:

> On 06/01/2010 05:21 PM, Benjamin Root wrote:
> > I have finally managed to test against TkAgg, and the faint white lines
> > do not appear to occur.  So, as far as I can tell (no clue about Macs),
> > the GTKCairo, pdf and svg backends have this display bug.  Shall I file
> > a bug report for this and another for the misaligned title?
>
> Yes.  Please include the simplest scripts you can devise that generate
> and illustrate the problems.  In the pcolormesh case, this means keeping
> the plot (and the data being plotted) as simple as possible.  If the
> problem can be illustrated with only two color regions, for example,
> that is ideal.
>
> Eric, I have attached scripts to both bug reports.  I have noticed that the
svn repo still does not have rasterization decorators for some of the
collections (e.g., PolyCollection, EllipseCollection, CircleCollection if I
remember correctly).  Don't know what are supposed to be the final list of
Collection that are eligible for that decorator, but it is incomplete at
this point in the trunk.

Ben Root


> Eric
>
> >
> > Ben Root
> >
> > On Tue, Jun 1, 2010 at 1:07 PM, Benjamin Root  > > wrote:
> >
> > Correction -- the problem with pcolormesh and the faint white lines
> > are occurring for pdf and svg files, *not* eps files as I originally
> > stated.  I am also checking a number of display backends and found
> > that the problem occurs for GTKCairo.  I am sure it also happens for
> > TkAgg, but I can not confirm that right now.  I am unable to test
> > the Mac backends, though.
> >
> > On a side note, when testing the backends, I noticed that GTKCairo
> > was *slow* for displaying the figures.  Also, the GTK backend
> > produced misaligned titles.  I can start a new thread about the
> > misaligned titles, if someone wishes.
> >
> > Ben Root
> >
> >
> > On Tue, Jun 1, 2010 at 11:05 AM, Benjamin Root  > > wrote:
> >
> >
> >
> > On Tue, Jun 1, 2010 at 9:39 AM, Ryan May  > > wrote:
> >
> > On Mon, May 31, 2010 at 11:28 AM, Benjamin Root
> > mailto:ben.r...@ou.edu>> wrote:
> >  > Markus,
> >  >
> >  > That is good to know that it has been fixed.  As for the
> > difference in
> >  > pcolor and pcolormesh, I think it has to do with the fact
> > that pcolormesh is
> >  > composed of many lines while pcolor is composed of many
> > polygons.  It is
> >  > probably more efficient to rasterize polygons than lines.
> >
> > To be blunt, this makes no sense whatsoever.  First,
> > pcolormesh and
> > pcolor differ in that it pcolor uses a generic
> > PolyCollection to draw
> > the quads, while pcolormesh uses a quadmesh object, which
> > can be more
> > efficient at the cost of generality, as it only needs to
> > render a set
> > of identical quads. Second, if you're talking rasterized
> > drawing, in
> > the end what gets written to a file is a 2D array of RGBA
> > values.  It
> > doesn't matter what you use to produce the results:
> > identical image on
> > the screen -> identical array in file.  It's possible that
> > there are
> > slight differences that you can't really see that produce
> > different
> > arrays, but that won't cause a factor of 8 difference in
> > size. My
> > guess is that pcolormesh isn't rasterizing properly.
> >
> > Indeed, you are right that lines aren't drawn.  I have looked
> > back at the images produced by my test script that I posted to
> > this thread and I see where I got confused.  The pcolormesh
> > result in pdf and eps files have very faint white blocks around
> > each quad.  At high enough data resolution, the color part of
> > the quads look like lines while the white lines look like dots.
> > This happens regardless of using rasterized=True or not, and I
> > don't think it is visible in png files (although I am testing
> > some very high resolution png files to verify).
> >
> > Ben Root
> >
> >
> >
> >
> >
> >
> --
> >
> >
> >
> >
> > ___
> > Matplotlib-devel mailing list
> > Matplotlib-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
> --
>
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.source

Re: [matplotlib-devel] Passing errorbar width arguments to bar/barh ?

[Eric Firing]

On 06/02/2010 01:20 PM, Benjamin Root wrote:
>
>
> On Wed, Jun 2, 2010 at 10:26 AM, John Hunter  > wrote:
>
> On Wed, Jun 2, 2010 at 9:48 AM, Benjamin Root  > wrote:
>  > I am curious as to why bar() should even be acting like
> errorbar().  As a
>  > user, I would expect bar() to do bar graphs and errorbar() to do
> error bar
>  > graphs.  Is there some sort of use-case that I am missing where
> it makes
>  > sense to generate errorbars from a bar() function?

See barchart_demo.py.  I don't use barcharts myself, but I can imagine 
that if I did, I might want errorbars on them.

>
> Some of this stuff is just really old (circa 2003).  When you have
> just a few users and someone sends you a patch, you tend to accept it
> :-)
>
> First we had bar, then we had errorbar, and someone wanted the
> convenience of easily adding errorbars to bar plots.  Over time, these
> conveniences have grown into a fairly complex interface (xerr, yerr,
> asymmetric errors).  So it has grown more organically than by design
> and some rationalization and normalization of functionality would be a
> good thing.  We have to balance that with the downsides of code
> breakage, however.
>
> I kinda figured something like that was the case.  I am just cautious
> about additional "organic" development of these functions.  I have
> encountered some functions where it was a bug that the function did not
> pass on the kwargs, and others where it wasn't a bug.  Does the approach
> of using a separate dict called error_kw fit in with some sort of
> overall design/best practices or might there be a better way to approach
> this.

It is precedented--see the relatively new subplots command, and 
Axes.text, which has had a fontdict kwarg for a long time.

I don't know of a better way of handling this sort of thing.  Perhaps it 
could be used more frequently and consistently within mpl.

Organic growth, with its faults and its advantages, is inherent in 
projects like mpl--and even in commercial products like Matlab.

mpl has only a little bit of written coding guidance.  See 
http://matplotlib.sourceforge.net/devel/coding_guide.html, most of which 
is not actually about coding.

>
> I merely ask because I am quite new here and I am curious about what
> style we want for our code.  Maybe we should consider some sort of
> special universal (for matplotlib) module that does special handling of
> kwargs?  I am just throwing out some thoughts.

You are welcome to propose something, but to have a chance of adoption 
it will need to be something that, for the most part, doesn't break 
users' code.

Eric

>
> Ben Root

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel