matplotlib-users Mailing List for matplotlib

On Wed, Jul 11, 2012 at 08:33:21PM -0400, Tony Yu wrote:
> On Wed, Jul 11, 2012 at 2:28 PM, Benjamin Root <ben...@ou...> wrote:
> 
> >
> >
> > On Wed, Jul 11, 2012 at 11:23 AM, John Hunter <jd...@gm...> wrote:
> >
> >>
> >>
> >> On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall <
> >> dam...@gm...> wrote:
> >>>
> >>> Well, as Ben said, that error fill plot is neato! It doesn't look too
> >>> complicated, either. I'd be more than happy to port it over later today
> >>> when I get bored of typing up my thesis. It'll probably only take me
> >>> about 30 minutes.
> >>>
> >>> If nobody is opposed to this idea, I'll go ahead and submit a PR this
> >>> evening (British Summer (hah!) Time).
> >>>
> >>
> >>
> >> While it is a nice graph, I am not sure that the use case is common
> >> enough to justify a new plotting method. One can get the same result with:
> >>
> >>
> >> In [68]: x = np.linspace(0, 2 * np.pi)
> >>
> >> In [69]: y_sin = np.sin(x)
> >>
> >> In [70]: err = np.concatenate([y_sin + 0.2, y_sin[::-1] - 0.2])
> >>
> >> In [71]: plot(x, y_sin)
> >> Out[71]: [<matplotlib.lines.Line2D object at 0x96959ec>]
> >>
> >> In [72]: fill_between(np.concatenate([x, x[::-1]]), err,
> >> facecolor='red', alpha=0.5)
> >> Out[72]: <matplotlib.collections.PolyCollection object at 0x962758c>
> >>
> >> Admittedly the [::-1] thing is a bit counter-intuitive, but rather than
> >> adding a new plotting method, perhaps we would be better off with a helper
> >> method to create the xs and ys for fill_between
> >>
> >> xs, ys = mlab.pad_line(x, y, 0.2)
> >> fill_between(xs, ys)
> >>
> >> JDH
> >>
> >
> >
> > I could definitely agree with a pad_line() function. We might want to
> > revisit the issue of how much visibility the mlab module should get in the
> > documentation (it currently doesn't get much at all). My whole take on
> > mlab was that it was a left-over from the days of working around issues in
> > NumPy and SciPy and that it was being slowly phased out. As for other
> > possible locations, cbook feels like it is more for the devs than for the
> > users, and adding it to pyplot would render the whole purpose of creating
> > this function as opposed to errorfill moot.
> >
> > As an additional point about such a pad_line function, it should probably
> > be nice to mirror the errorbar() functionality to allow not only a constant
> > error, but also a N, Nx1, or 2xN array of +/- error. (note that errorbar()
> > for the 2xN array case does -row1 and +row2).
> >
> 
> Damon: it sounds like you're volunteering to submit a PR to add this
> function ;)
> 
> Here's the relevant bit (which should already handle the cases Ben mentions
> above):
> 
> 
> https://github.com/tonysyu/mpltools/blob/master/mpltools/special/errorfill.py#L54
> 
> It needs a docstring and a home (pyplot.py?). I kind of think `offset_line`
> is more explicit than `pad_line` (both of these are *much* better than my
> original `extrema_from_error_input`).
>
There was talk of this living in mlab or cbook. Is there a preference?
> Cheers,
> -Tony
> 
> 
> > Cheers!
> > Ben Root
> >
> >
-- 
Damon McDougall
http://damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

On Thu, Jul 12, 2012 at 1:58 PM, Daπid <dav...@gm...> wrote:
> I don't know if there is any reason for not having it, but as a
> workaround, you could use np.hist to get the data (syntax is the same
> as mpl.hist and returns the same numbers, but without drawing) and
> then renormalise and plot with mpl.bars.
>
> On Thu, Jul 12, 2012 at 4:42 PM, Alan G Isaac <ala...@gm...>
> wrote:
> > This is essentially a query about why certain histogram types
> > are not offered. I can see two possible answers: haven't gotten
> > to them, or, don't want to offer them (e.g., they're bad practice).
> >
> > I will choose Stata as a point of comparison.
> > http://www.stata.com/help.cgi?hist
> > The types are density, fraction, frequency, and percent.
> > Frequency corresponds of mpl's normed=False.
> > Density corresponds of mpl's normed=True.
> > Today I wanted the 'fraction' type, but mpl did not offer it.
> > (Note that because of other elements of the graph, hacks like
> > replacing the ticklabels won't work nicely.)
> >
> > If there is not sentiment against offering these types,
> > I suggest that the `normed` keyword accept strings,
> > including "fraction" and "percent", and that `hist`
> > be extended to produce these types.
> >
> > Cheers,
> > Alan Isaac
> >
>
Alan,
It is tricky to balance functionality, conciseness, and usability. It is
both a shortcoming and a strength that we strive to provide a no-frills
library that gives the user plenty of rope, while still trying to
anticipate most users' needs so that they can get stuff prototyped and
working. For most other plots, one would simply convert the data units
themselves prior to plotting. However, hist() is a different beast from
say, plot() or scatter(), because hist() inherently performs calculations
upon the input data and displays the results of those calculations.
Therefore, one can't simply perform a conversion on the data prior to
calling hist() like one would for other functions.
In that light, your idea makes a lot of sense and could essentially be
considered as a way to "pretty print" what the graph would normally look
like if normed=True. In other words, having normed='percent' would
essentially perform the calculations exactly as it would if normed=True,
but would multiply the y-coordinate system by 100. Is that what you are
looking for?
Cheers!
Ben Root

On 2012年07月12日 7:20 AM, Damon McDougall wrote:
> On Thu, Jul 12, 2012 at 10:42:59AM -0400, Alan G Isaac wrote:
>> This is essentially a query about why certain histogram types
>> are not offered. I can see two possible answers: haven't gotten
>> to them, or, don't want to offer them (e.g., they're bad practice).
>>
>> I will choose Stata as a point of comparison.
>> http://www.stata.com/help.cgi?hist
>> The types are density, fraction, frequency, and percent.
>> Frequency corresponds of mpl's normed=False.
>> Density corresponds of mpl's normed=True.
>> Today I wanted the 'fraction' type, but mpl did not offer it.
>> (Note that because of other elements of the graph, hacks like
>> replacing the ticklabels won't work nicely.)
>>
>> If there is not sentiment against offering these types,
>> I suggest that the `normed` keyword accept strings,
>> including "fraction" and "percent", and that `hist`
>> be extended to produce these types.
>>
>> Cheers,
>> Alan Isaac
>>
>> ------------------------------------------------------------------------------
>> 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-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
> +1. I think this adds more flexbility to the current histogram
> implementation.
>
> I wonder whether this would be worth a pull request?
>
Yes, please go ahead. The 'normed' Boolean is not a good design; 
accepting more descriptive strings would be an improvement.
Eric

I don't know if there is any reason for not having it, but as a
workaround, you could use np.hist to get the data (syntax is the same
as mpl.hist and returns the same numbers, but without drawing) and
then renormalise and plot with mpl.bars.
On Thu, Jul 12, 2012 at 4:42 PM, Alan G Isaac <ala...@gm...> wrote:
> This is essentially a query about why certain histogram types
> are not offered. I can see two possible answers: haven't gotten
> to them, or, don't want to offer them (e.g., they're bad practice).
>
> I will choose Stata as a point of comparison.
> http://www.stata.com/help.cgi?hist
> The types are density, fraction, frequency, and percent.
> Frequency corresponds of mpl's normed=False.
> Density corresponds of mpl's normed=True.
> Today I wanted the 'fraction' type, but mpl did not offer it.
> (Note that because of other elements of the graph, hacks like
> replacing the ticklabels won't work nicely.)
>
> If there is not sentiment against offering these types,
> I suggest that the `normed` keyword accept strings,
> including "fraction" and "percent", and that `hist`
> be extended to produce these types.
>
> Cheers,
> Alan Isaac
>
> ------------------------------------------------------------------------------
> 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-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

On Thu, Jul 12, 2012 at 10:42:59AM -0400, Alan G Isaac wrote:
> This is essentially a query about why certain histogram types
> are not offered. I can see two possible answers: haven't gotten
> to them, or, don't want to offer them (e.g., they're bad practice).
> 
> I will choose Stata as a point of comparison.
> http://www.stata.com/help.cgi?hist
> The types are density, fraction, frequency, and percent.
> Frequency corresponds of mpl's normed=False.
> Density corresponds of mpl's normed=True.
> Today I wanted the 'fraction' type, but mpl did not offer it.
> (Note that because of other elements of the graph, hacks like
> replacing the ticklabels won't work nicely.)
> 
> If there is not sentiment against offering these types,
> I suggest that the `normed` keyword accept strings,
> including "fraction" and "percent", and that `hist`
> be extended to produce these types.
> 
> Cheers,
> Alan Isaac
> 
> ------------------------------------------------------------------------------
> 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-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
+1. I think this adds more flexbility to the current histogram
implementation.
I wonder whether this would be worth a pull request?
-- 
Damon McDougall
http://damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

On Thu, Jul 12, 2012 at 03:53:28PM +0200, David Kremer wrote:
> Hello, I want to ask some questions about fonts in figures.
> 
> I think that the best figures are achieved when the font used is the 
> same as in the surrounding text in all the figure. This is the case when 
> I use the latex notation (between $$), but unfortunately the police used 
> for the axis is not the same (this is sans-serif font).
> 
> On the other hand, you could have a sans-serif font in your document, 
> and thus you would like your equations to be also sans-serif as far it 
> is possible.
> 
> The reason I write to this mailing is because I want to know if it 
> exists general recipes to have the same font in all the figure with 
> matplotlib.
> 
> The first thing I thought about as a general recipie is to use an 
> 'epslatex' output, which is then compiled with latex to give an eps or a 
> pdf file, but I am not sure if it is possible to achieve such a result.
> 
> If you have some idea about that, let me know.
> 
> Thanks,
> 
> David
> 
> ------------------------------------------------------------------------------
> 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-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Hi David,
Have you set usetex=True in your rcParams?
-- 
Damon McDougall
http://damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

This is essentially a query about why certain histogram types
are not offered. I can see two possible answers: haven't gotten
to them, or, don't want to offer them (e.g., they're bad practice).
I will choose Stata as a point of comparison.
http://www.stata.com/help.cgi?hist
The types are density, fraction, frequency, and percent.
Frequency corresponds of mpl's normed=False.
Density corresponds of mpl's normed=True.
Today I wanted the 'fraction' type, but mpl did not offer it.
(Note that because of other elements of the graph, hacks like
replacing the ticklabels won't work nicely.)
If there is not sentiment against offering these types,
I suggest that the `normed` keyword accept strings,
including "fraction" and "percent", and that `hist`
be extended to produce these types.
Cheers,
Alan Isaac

You can either send them the link to this discussion, or just the little
snippet concerning gcf() above; just taking care of that would be an
improvement.
On Thu, Jul 12, 2012 at 10:17 AM, Joshua Koehler <jjk...@gm...>wrote:
> That did the trick. I tried going through the source code but it just got
> too messy. How do I let the networkx developers know about this?
> On Jul 11, 2012, at 1:18 PM, Benjamin Root wrote:
>
>
>
> On Wed, Jul 11, 2012 at 12:45 PM, Joshua Koehler <jjk...@gm...>wrote:
>
>> Hi all,
>>
>> I am currently trying to have two panels each with their own figure
>> instance so they can have separate plots.
>>
>> I can successfully update a plot if there is only one panel. As soon as I
>> add a second panel, I get the following error when I try to update (replot)
>> a plot (Showing last message only):
>>
>> File
>> "/Library/Frameworks/Python.framework/Versions/7.3/lib/python2.7/site-packages/matplotlib/axes.py",
>> line 1374, in _sci
>> "Argument must be an image, collection, or ContourSet in this Axes")
>> ValueError: Argument must be an image, collection, or ContourSet in this
>> Axes
>>
>> I looked online first and one site suggested it was because I was using
>> matplotlib.Figure instead of pylab.Figure. I switched and the problem still
>> occurs. I was curious to see if this problem had to do with how I set up my
>> program, not with matplotlib, so I wrote a little test program. The exact
>> same problem occurs. I have attached the test program. To see that it does
>> work with just one panel comment out lines 39, 41, and 49. When put back
>> in, I get the above error message.
>>
>> Any suggestions as to how to fix this?
>>
>> Thanks!
>>
>> Josh
>>
>>
> Josh,
>
> Can you please post the entire traceback? My suspicion for what is
> happening is that both figures are sharing the same canvas, but I am not
> exactly sure. Anyway, when you perform a plot on one panel, you are
> calling "clear()" for that figure, which may be having side-effects for the
> other figure since it is attached to the same Wx object.
>
> Actually, looking over your code again, I see a few things that may or may
> not be part of the problem, but should be addressed, nevertheless. First,
> you are calling FigureCanvas and assigning it to self.canvas. This canvas
> is different from the canvas that the figure will actually use, so I am not
> sure if this is being done correctly. Second, your call to "plt.close()"
> assumes that the figure you want to close is the currently active figure.
> What you want to call is "plt.close(self.figure)" in order to make sure it
> closes the figure you intend to close.
>
> Ben Root
>
>
>
>
> ------------------------------------------------------------------------------
> 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-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
-- 
Daniel Hyams
dh...@gm...

That did the trick. I tried going through the source code but it just got too messy. How do I let the networkx developers know about this?
On Jul 11, 2012, at 1:18 PM, Benjamin Root wrote:
> 
> 
> On Wed, Jul 11, 2012 at 12:45 PM, Joshua Koehler <jjk...@gm...> wrote:
> Hi all,
> 
> I am currently trying to have two panels each with their own figure instance so they can have separate plots.
> 
> I can successfully update a plot if there is only one panel. As soon as I add a second panel, I get the following error when I try to update (replot) a plot (Showing last message only):
> 
> File "/Library/Frameworks/Python.framework/Versions/7.3/lib/python2.7/site-packages/matplotlib/axes.py", line 1374, in _sci
> "Argument must be an image, collection, or ContourSet in this Axes")
> ValueError: Argument must be an image, collection, or ContourSet in this Axes
> 
> I looked online first and one site suggested it was because I was using matplotlib.Figure instead of pylab.Figure. I switched and the problem still occurs. I was curious to see if this problem had to do with how I set up my program, not with matplotlib, so I wrote a little test program. The exact same problem occurs. I have attached the test program. To see that it does work with just one panel comment out lines 39, 41, and 49. When put back in, I get the above error message.
> 
> Any suggestions as to how to fix this?
> 
> Thanks!
> 
> Josh
> 
> 
> Josh,
> 
> Can you please post the entire traceback? My suspicion for what is happening is that both figures are sharing the same canvas, but I am not exactly sure. Anyway, when you perform a plot on one panel, you are calling "clear()" for that figure, which may be having side-effects for the other figure since it is attached to the same Wx object.
> 
> Actually, looking over your code again, I see a few things that may or may not be part of the problem, but should be addressed, nevertheless. First, you are calling FigureCanvas and assigning it to self.canvas. This canvas is different from the canvas that the figure will actually use, so I am not sure if this is being done correctly. Second, your call to "plt.close()" assumes that the figure you want to close is the currently active figure. What you want to call is "plt.close(self.figure)" in order to make sure it closes the figure you intend to close.
> 
> Ben Root

Hello, I want to ask some questions about fonts in figures.
I think that the best figures are achieved when the font used is the 
same as in the surrounding text in all the figure. This is the case when 
I use the latex notation (between $$), but unfortunately the police used 
for the axis is not the same (this is sans-serif font).
On the other hand, you could have a sans-serif font in your document, 
and thus you would like your equations to be also sans-serif as far it 
is possible.
The reason I write to this mailing is because I want to know if it 
exists general recipes to have the same font in all the figure with 
matplotlib.
The first thing I thought about as a general recipie is to use an 
'epslatex' output, which is then compiled with latex to give an eps or a 
pdf file, but I am not sure if it is possible to achieve such a result.
If you have some idea about that, let me know.
Thanks,
David

On Thu, Jul 12, 2012 at 09:41:32AM -0400, Tony Yu wrote:
> On Thu, Jul 12, 2012 at 9:28 AM, Damon McDougall
> <dam...@gm...>wrote:
> 
> > On Wed, Jul 11, 2012 at 08:33:21PM -0400, Tony Yu wrote:
> > > On Wed, Jul 11, 2012 at 2:28 PM, Benjamin Root <ben...@ou...> wrote:
> > >
> > > >
> > > >
> > > > On Wed, Jul 11, 2012 at 11:23 AM, John Hunter <jd...@gm...>
> > wrote:
> > > >
> > > >>
> > > >>
> > > >> On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall <
> > > >> dam...@gm...> wrote:
> > > >>>
> > > >>> Well, as Ben said, that error fill plot is neato! It doesn't look too
> > > >>> complicated, either. I'd be more than happy to port it over later
> > today
> > > >>> when I get bored of typing up my thesis. It'll probably only take me
> > > >>> about 30 minutes.
> > > >>>
> > > >>> If nobody is opposed to this idea, I'll go ahead and submit a PR this
> > > >>> evening (British Summer (hah!) Time).
> > > >>>
> > > >>
> > > >>
> > > >> While it is a nice graph, I am not sure that the use case is common
> > > >> enough to justify a new plotting method. One can get the same result
> > with:
> > > >>
> > > >>
> > > >> In [68]: x = np.linspace(0, 2 * np.pi)
> > > >>
> > > >> In [69]: y_sin = np.sin(x)
> > > >>
> > > >> In [70]: err = np.concatenate([y_sin + 0.2, y_sin[::-1] - 0.2])
> > > >>
> > > >> In [71]: plot(x, y_sin)
> > > >> Out[71]: [<matplotlib.lines.Line2D object at 0x96959ec>]
> > > >>
> > > >> In [72]: fill_between(np.concatenate([x, x[::-1]]), err,
> > > >> facecolor='red', alpha=0.5)
> > > >> Out[72]: <matplotlib.collections.PolyCollection object at 0x962758c>
> > > >>
> > > >> Admittedly the [::-1] thing is a bit counter-intuitive, but rather
> > than
> > > >> adding a new plotting method, perhaps we would be better off with a
> > helper
> > > >> method to create the xs and ys for fill_between
> > > >>
> > > >> xs, ys = mlab.pad_line(x, y, 0.2)
> > > >> fill_between(xs, ys)
> > > >>
> > > >> JDH
> > > >>
> > > >
> > > >
> > > > I could definitely agree with a pad_line() function. We might want to
> > > > revisit the issue of how much visibility the mlab module should get in
> > the
> > > > documentation (it currently doesn't get much at all). My whole take on
> > > > mlab was that it was a left-over from the days of working around
> > issues in
> > > > NumPy and SciPy and that it was being slowly phased out. As for other
> > > > possible locations, cbook feels like it is more for the devs than for
> > the
> > > > users, and adding it to pyplot would render the whole purpose of
> > creating
> > > > this function as opposed to errorfill moot.
> > > >
> > > > As an additional point about such a pad_line function, it should
> > probably
> > > > be nice to mirror the errorbar() functionality to allow not only a
> > constant
> > > > error, but also a N, Nx1, or 2xN array of +/- error. (note that
> > errorbar()
> > > > for the 2xN array case does -row1 and +row2).
> > > >
> > >
> > > Damon: it sounds like you're volunteering to submit a PR to add this
> > > function ;)
> > >
> > > Here's the relevant bit (which should already handle the cases Ben
> > mentions
> > > above):
> > >
> > >
> > >
> > https://github.com/tonysyu/mpltools/blob/master/mpltools/special/errorfill.py#L54
> > >
> > > It needs a docstring and a home (pyplot.py?). I kind of think
> > `offset_line`
> > > is more explicit than `pad_line` (both of these are *much* better than my
> > > original `extrema_from_error_input`).
> > >
> > > Cheers,
> > > -Tony
> > >
> > >
> > > > Cheers!
> > > > Ben Root
> > > >
> > > >
> >
> > Woohoo! Something other than my thesis to do! I have one question. It
> > looks like your function `extrema_from_error_input` just adds +/- an
> > error scalar (or array), but in the gallery it looks like the padding
> > is thinner in the areas of the `sin` function where the magnitude of the
> > gradient is larger. Is this the case, or am I missing something?
> >
> > --
> > Damon McDougall
> >
> 
> 
> Yep, that's the way it should look because it's adding the error just in
> the y-direction. To get a constant thickness, you'd have to add a constant
> orthogonal to the line's slope.
> 
> Good luck procrastinating on your thesis ;)
> -Tony
Aha, the answer was 'yes, I was missing something'! :)
Thanks.
-- 
Damon McDougall
http://damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

On Thu, Jul 12, 2012 at 9:28 AM, Damon McDougall
<dam...@gm...>wrote:
> On Wed, Jul 11, 2012 at 08:33:21PM -0400, Tony Yu wrote:
> > On Wed, Jul 11, 2012 at 2:28 PM, Benjamin Root <ben...@ou...> wrote:
> >
> > >
> > >
> > > On Wed, Jul 11, 2012 at 11:23 AM, John Hunter <jd...@gm...>
> wrote:
> > >
> > >>
> > >>
> > >> On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall <
> > >> dam...@gm...> wrote:
> > >>>
> > >>> Well, as Ben said, that error fill plot is neato! It doesn't look too
> > >>> complicated, either. I'd be more than happy to port it over later
> today
> > >>> when I get bored of typing up my thesis. It'll probably only take me
> > >>> about 30 minutes.
> > >>>
> > >>> If nobody is opposed to this idea, I'll go ahead and submit a PR this
> > >>> evening (British Summer (hah!) Time).
> > >>>
> > >>
> > >>
> > >> While it is a nice graph, I am not sure that the use case is common
> > >> enough to justify a new plotting method. One can get the same result
> with:
> > >>
> > >>
> > >> In [68]: x = np.linspace(0, 2 * np.pi)
> > >>
> > >> In [69]: y_sin = np.sin(x)
> > >>
> > >> In [70]: err = np.concatenate([y_sin + 0.2, y_sin[::-1] - 0.2])
> > >>
> > >> In [71]: plot(x, y_sin)
> > >> Out[71]: [<matplotlib.lines.Line2D object at 0x96959ec>]
> > >>
> > >> In [72]: fill_between(np.concatenate([x, x[::-1]]), err,
> > >> facecolor='red', alpha=0.5)
> > >> Out[72]: <matplotlib.collections.PolyCollection object at 0x962758c>
> > >>
> > >> Admittedly the [::-1] thing is a bit counter-intuitive, but rather
> than
> > >> adding a new plotting method, perhaps we would be better off with a
> helper
> > >> method to create the xs and ys for fill_between
> > >>
> > >> xs, ys = mlab.pad_line(x, y, 0.2)
> > >> fill_between(xs, ys)
> > >>
> > >> JDH
> > >>
> > >
> > >
> > > I could definitely agree with a pad_line() function. We might want to
> > > revisit the issue of how much visibility the mlab module should get in
> the
> > > documentation (it currently doesn't get much at all). My whole take on
> > > mlab was that it was a left-over from the days of working around
> issues in
> > > NumPy and SciPy and that it was being slowly phased out. As for other
> > > possible locations, cbook feels like it is more for the devs than for
> the
> > > users, and adding it to pyplot would render the whole purpose of
> creating
> > > this function as opposed to errorfill moot.
> > >
> > > As an additional point about such a pad_line function, it should
> probably
> > > be nice to mirror the errorbar() functionality to allow not only a
> constant
> > > error, but also a N, Nx1, or 2xN array of +/- error. (note that
> errorbar()
> > > for the 2xN array case does -row1 and +row2).
> > >
> >
> > Damon: it sounds like you're volunteering to submit a PR to add this
> > function ;)
> >
> > Here's the relevant bit (which should already handle the cases Ben
> mentions
> > above):
> >
> >
> >
> https://github.com/tonysyu/mpltools/blob/master/mpltools/special/errorfill.py#L54
> >
> > It needs a docstring and a home (pyplot.py?). I kind of think
> `offset_line`
> > is more explicit than `pad_line` (both of these are *much* better than my
> > original `extrema_from_error_input`).
> >
> > Cheers,
> > -Tony
> >
> >
> > > Cheers!
> > > Ben Root
> > >
> > >
>
> Woohoo! Something other than my thesis to do! I have one question. It
> looks like your function `extrema_from_error_input` just adds +/- an
> error scalar (or array), but in the gallery it looks like the padding
> is thinner in the areas of the `sin` function where the magnitude of the
> gradient is larger. Is this the case, or am I missing something?
>
> --
> Damon McDougall
>
Yep, that's the way it should look because it's adding the error just in
the y-direction. To get a constant thickness, you'd have to add a constant
orthogonal to the line's slope.
Good luck procrastinating on your thesis ;)
-Tony

On Wed, Jul 11, 2012 at 08:33:21PM -0400, Tony Yu wrote:
> On Wed, Jul 11, 2012 at 2:28 PM, Benjamin Root <ben...@ou...> wrote:
> 
> >
> >
> > On Wed, Jul 11, 2012 at 11:23 AM, John Hunter <jd...@gm...> wrote:
> >
> >>
> >>
> >> On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall <
> >> dam...@gm...> wrote:
> >>>
> >>> Well, as Ben said, that error fill plot is neato! It doesn't look too
> >>> complicated, either. I'd be more than happy to port it over later today
> >>> when I get bored of typing up my thesis. It'll probably only take me
> >>> about 30 minutes.
> >>>
> >>> If nobody is opposed to this idea, I'll go ahead and submit a PR this
> >>> evening (British Summer (hah!) Time).
> >>>
> >>
> >>
> >> While it is a nice graph, I am not sure that the use case is common
> >> enough to justify a new plotting method. One can get the same result with:
> >>
> >>
> >> In [68]: x = np.linspace(0, 2 * np.pi)
> >>
> >> In [69]: y_sin = np.sin(x)
> >>
> >> In [70]: err = np.concatenate([y_sin + 0.2, y_sin[::-1] - 0.2])
> >>
> >> In [71]: plot(x, y_sin)
> >> Out[71]: [<matplotlib.lines.Line2D object at 0x96959ec>]
> >>
> >> In [72]: fill_between(np.concatenate([x, x[::-1]]), err,
> >> facecolor='red', alpha=0.5)
> >> Out[72]: <matplotlib.collections.PolyCollection object at 0x962758c>
> >>
> >> Admittedly the [::-1] thing is a bit counter-intuitive, but rather than
> >> adding a new plotting method, perhaps we would be better off with a helper
> >> method to create the xs and ys for fill_between
> >>
> >> xs, ys = mlab.pad_line(x, y, 0.2)
> >> fill_between(xs, ys)
> >>
> >> JDH
> >>
> >
> >
> > I could definitely agree with a pad_line() function. We might want to
> > revisit the issue of how much visibility the mlab module should get in the
> > documentation (it currently doesn't get much at all). My whole take on
> > mlab was that it was a left-over from the days of working around issues in
> > NumPy and SciPy and that it was being slowly phased out. As for other
> > possible locations, cbook feels like it is more for the devs than for the
> > users, and adding it to pyplot would render the whole purpose of creating
> > this function as opposed to errorfill moot.
> >
> > As an additional point about such a pad_line function, it should probably
> > be nice to mirror the errorbar() functionality to allow not only a constant
> > error, but also a N, Nx1, or 2xN array of +/- error. (note that errorbar()
> > for the 2xN array case does -row1 and +row2).
> >
> 
> Damon: it sounds like you're volunteering to submit a PR to add this
> function ;)
> 
> Here's the relevant bit (which should already handle the cases Ben mentions
> above):
> 
> 
> https://github.com/tonysyu/mpltools/blob/master/mpltools/special/errorfill.py#L54
> 
> It needs a docstring and a home (pyplot.py?). I kind of think `offset_line`
> is more explicit than `pad_line` (both of these are *much* better than my
> original `extrema_from_error_input`).
> 
> Cheers,
> -Tony
> 
> 
> > Cheers!
> > Ben Root
> >
> >
Woohoo! Something other than my thesis to do! I have one question. It
looks like your function `extrema_from_error_input` just adds +/- an
error scalar (or array), but in the gallery it looks like the padding
is thinner in the areas of the `sin` function where the magnitude of the
gradient is larger. Is this the case, or am I missing something?
-- 
Damon McDougall
http://damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Hi
I've submitted a bug report "Issue *#1008"* on github (which I had trouble
finding).
Regards
Pål
On 11 July 2012 17:41, Benjamin Root <ben...@ou...> wrote:
>
>
> On Wed, Jul 11, 2012 at 10:41 AM, Pål Gunnar Ellingsen <pa...@gm...>wrote:
>
>> Hi
>>
>> I'm trying to save a animation, which I've generated using
>> animation.FuncAnimation.
>> The animation has it's background set by plt.rcParams['figure.facecolor']
>> = 'black'
>> Which works with plt.show(), though not with animation save.
>> I know that plt.save needs the argument facecolor to save a figure with a
>> given background, but the animations save does not like such an argument.
>> What am I doing wrong?
>>
>>
>> Kind regards
>>
>> Pål
>>
>>
> You aren't doing anything wrong. It is most likely an oversight on our
> part to not consider that use-case. Could you file a bug report about this?
>
> Cheers!
> Ben Root
>
>

http://horit.com/yuaoqlcns/405279.html 

On Wed, Jul 11, 2012 at 2:28 PM, Benjamin Root <ben...@ou...> wrote:
>
>
> On Wed, Jul 11, 2012 at 11:23 AM, John Hunter <jd...@gm...> wrote:
>
>>
>>
>> On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall <
>> dam...@gm...> wrote:
>>>
>>> Well, as Ben said, that error fill plot is neato! It doesn't look too
>>> complicated, either. I'd be more than happy to port it over later today
>>> when I get bored of typing up my thesis. It'll probably only take me
>>> about 30 minutes.
>>>
>>> If nobody is opposed to this idea, I'll go ahead and submit a PR this
>>> evening (British Summer (hah!) Time).
>>>
>>
>>
>> While it is a nice graph, I am not sure that the use case is common
>> enough to justify a new plotting method. One can get the same result with:
>>
>>
>> In [68]: x = np.linspace(0, 2 * np.pi)
>>
>> In [69]: y_sin = np.sin(x)
>>
>> In [70]: err = np.concatenate([y_sin + 0.2, y_sin[::-1] - 0.2])
>>
>> In [71]: plot(x, y_sin)
>> Out[71]: [<matplotlib.lines.Line2D object at 0x96959ec>]
>>
>> In [72]: fill_between(np.concatenate([x, x[::-1]]), err,
>> facecolor='red', alpha=0.5)
>> Out[72]: <matplotlib.collections.PolyCollection object at 0x962758c>
>>
>> Admittedly the [::-1] thing is a bit counter-intuitive, but rather than
>> adding a new plotting method, perhaps we would be better off with a helper
>> method to create the xs and ys for fill_between
>>
>> xs, ys = mlab.pad_line(x, y, 0.2)
>> fill_between(xs, ys)
>>
>> JDH
>>
>
>
> I could definitely agree with a pad_line() function. We might want to
> revisit the issue of how much visibility the mlab module should get in the
> documentation (it currently doesn't get much at all). My whole take on
> mlab was that it was a left-over from the days of working around issues in
> NumPy and SciPy and that it was being slowly phased out. As for other
> possible locations, cbook feels like it is more for the devs than for the
> users, and adding it to pyplot would render the whole purpose of creating
> this function as opposed to errorfill moot.
>
> As an additional point about such a pad_line function, it should probably
> be nice to mirror the errorbar() functionality to allow not only a constant
> error, but also a N, Nx1, or 2xN array of +/- error. (note that errorbar()
> for the 2xN array case does -row1 and +row2).
>
Damon: it sounds like you're volunteering to submit a PR to add this
function ;)
Here's the relevant bit (which should already handle the cases Ben mentions
above):
https://github.com/tonysyu/mpltools/blob/master/mpltools/special/errorfill.py#L54
It needs a docstring and a home (pyplot.py?). I kind of think `offset_line`
is more explicit than `pad_line` (both of these are *much* better than my
original `extrema_from_error_input`).
Cheers,
-Tony
> Cheers!
> Ben Root
>
>