matplotlib-devel Mailing List for matplotlib (Page 4)

I have another Gallery example that I'd like to post if anyone finds it
worthy. It is just a polished version of the scatter_hist example at
http://matplotlib.sourceforge.net/examples/pylab_examples/scatter_hist.html

See the most recent graphic on this thread:
http://old.nabble.com/How-to-overlay-an-image-on-a-multi-plot--td28111498.html

I have contributed a few gallery examples in the past

http://matplotlib.sourceforge.net/examples/api/radar_chart.html
http://matplotlib.sourceforge.net/examples/pylab_examples/barchart_demo2.html
http://matplotlib.sourceforge.net/examples/pylab_examples/boxplot_demo2.html

and I am just trying to (slowly) help with getting publication quality
graphics into the gallery, a la R's gallery at
http://addictedtor.free.fr/graphiques/thumbs.php (matplotlib looks soooo
much better).

By "publication quality" I just mean graphics that have legends, axes
labels, specified axes ranges etc, so that in one example people see a lot
of the functionality they'll likely use a lot.

If anyone is interested, I can take my code and generalize it with fake data
and axes labels, add some comments, etc.

Cheers,

Josh

-----
Josh Hemann
Statistical Advisor 
http://www.vni.com/ Visual Numerics 
jhemann at vni dizzot com 

-- 
View this message in context: http://old.nabble.com/Another-Gallery-example--tp28145163p28145163.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Hi Gökhan,

I've uploaded the latest version for review at the sourceforge tracker :
https://sourceforge.net/tracker/?func=detail&aid=2981606&group_id=80706&atid=560722

Please report any remaining bugs.


On Sat, Apr 3, 2010 at 6:23 AM, Gökhan Sever <gok...@gm...> wrote:
> Hi Peter,
>
> Your previous addition looks fine here. Keep pinging probably someone should
> commit your additions.
>
> I would like to see your further editions. Maybe you can use google-code or
> somewhere to host the code and continue making additions there. Once some
> important steps are completed changes can integrated into matplotlib back.
>
> --
> Gökhan

Eric Firing wrote:
> Jeff Klukas wrote:
>> Alright, I have attached a top-level diff that contains the changes to
>> axes.py that allow sending multiple colors to the 'color' argument in
>> Axes.hist.
>>
>> Below is a short examples that passes lists to 'colors' and 'labels'.
> 
> Jeff,
> 
> Thanks.  I find that both hist and the patch need some additional 
> reworking, which I will try to get done this weekend.

Done in commits ending with 8220.  Illustrated in 
examples/pylab_examples/histogram_demo_extended.py.

Thanks for your work on this.

(There is probably quite a bit more cleanup and refactoring that could 
be done.  Much of the plotting capability of hist could be factored out 
for other uses, for example.)

Eric

> 
> Eric
> 
>> Cheers,
>> Jeff
>>
>> || Jeff Klukas, Research Assistant, Physics
>> || University of Wisconsin -- Madison
>> || jeff.klukas@gmail | jeffyklukas@aim | jeffklukas@skype
>> || http://www.hep.wisc.edu/~jklukas/
>>
>> ----------------------------------
>> import pylab as P
>>
>> mu, sigma = 200, 25
>> x0 = mu + sigma*P.randn(10000)
>> x1 = mu + sigma*P.randn(7000)
>> x2 = mu + sigma*P.randn(3000)
>>
>> P.figure()
>>
>> colors = ['crimson', 'burlywood', 'chartreuse']
>> labels = ['Crimson', 'Burlywood', 'Chartreuse']
>> n, bins, patches = P.hist([x0,x1,x2], 10, histtype='bar',
>>                           color=colors, label=labels)
>>
>> P.legend()
>> P.show()
>> ---------------------------------
>>
>>
>>
>> On Wed, Mar 31, 2010 at 1:27 PM, Eric Firing <ef...@ha...> wrote:
>>> Jeff Klukas wrote:
>>>> When plotting multiple data with one Axes.hist call, the method's
>>>> interface allows you to specify a list of labels to the 'label' kwarg
>>>> to distinguish between the datasets.  To get different colors,
>>>> however, you cannot give a list of colors to 'color'; instead, you
>>>> have to leave out the 'color' kwarg and change the color cycle.
>>>>
>>>> Is there any reason why the color kwarg can't work like label?  I
>>>> spent an hour or two trying to debug a script before I realized that
>>>> 'color' wasn't being interpreted as I expected.  I realize that there
>>>> is some ambiguity since a color argument can be an rgb or rgba
>>>> sequence.  My proposal would be that 'color' would be interpreted as a
>>>> list of distinct colors only when multiple datasets are given as input
>>>> and len(color) equals the number of datasets.
>>>>
>>>> I find it hard to imagine a case where you would want to set all
>>>> datasets to be the same color, so I don't think the ambiguity would be
>>>> a major issue.  I would be happy to write and submit an implementation
>>>> if others think this is a reasonable idea.
>>> Sounds good to me.  I agree that it makes no sense to have to set the color
>>> cycle for hist (although using the color cycle as a default is reasonable),
>>> and I think it is just an artifact of the way hist has evolved.
>>>
>>> Eric
>>>
>>>> Cheers,
>>>> Jeff
>>>>
>>>> || Jeff Klukas, Research Assistant, Physics
>>>> || University of Wisconsin -- Madison
>>>> || jeff.klukas@gmail | jeffyklukas@aim | jeffklukas@skype
>>>> || http://www.hep.wisc.edu/~jklukas/
>>>>

On Fri, Apr 2, 2010 at 1:25 PM, Peter Butterworth <bu...@gm...> wrote:

> Any feedback on the submitted patch ?
>
>
> I've now added the possibility to switch autoscale off.
>
> On Sun, Mar 28, 2010 at 9:26 PM, Peter Butterworth <bu...@gm...>
> wrote:
> > please find attached the 2 patched files and the diff vs trunk.
>

Hi Peter,

Your previous addition looks fine here. Keep pinging probably someone should
commit your additions.

I would like to see your further editions. Maybe you can use google-code or
somewhere to host the code and continue making additions there. Once some
important steps are completed changes can integrated into matplotlib back.

-- 
Gökhan

Jeff Klukas wrote:
> Alright, I have attached a top-level diff that contains the changes to
> axes.py that allow sending multiple colors to the 'color' argument in
> Axes.hist.
> 
> Below is a short examples that passes lists to 'colors' and 'labels'.

Jeff,

Thanks.  I find that both hist and the patch need some additional 
reworking, which I will try to get done this weekend.

Eric

> 
> Cheers,
> Jeff
> 
> || Jeff Klukas, Research Assistant, Physics
> || University of Wisconsin -- Madison
> || jeff.klukas@gmail | jeffyklukas@aim | jeffklukas@skype
> || http://www.hep.wisc.edu/~jklukas/
> 
> ----------------------------------
> import pylab as P
> 
> mu, sigma = 200, 25
> x0 = mu + sigma*P.randn(10000)
> x1 = mu + sigma*P.randn(7000)
> x2 = mu + sigma*P.randn(3000)
> 
> P.figure()
> 
> colors = ['crimson', 'burlywood', 'chartreuse']
> labels = ['Crimson', 'Burlywood', 'Chartreuse']
> n, bins, patches = P.hist([x0,x1,x2], 10, histtype='bar',
>                           color=colors, label=labels)
> 
> P.legend()
> P.show()
> ---------------------------------
> 
> 
> 
> On Wed, Mar 31, 2010 at 1:27 PM, Eric Firing <ef...@ha...> wrote:
>> Jeff Klukas wrote:
>>> When plotting multiple data with one Axes.hist call, the method's
>>> interface allows you to specify a list of labels to the 'label' kwarg
>>> to distinguish between the datasets.  To get different colors,
>>> however, you cannot give a list of colors to 'color'; instead, you
>>> have to leave out the 'color' kwarg and change the color cycle.
>>>
>>> Is there any reason why the color kwarg can't work like label?  I
>>> spent an hour or two trying to debug a script before I realized that
>>> 'color' wasn't being interpreted as I expected.  I realize that there
>>> is some ambiguity since a color argument can be an rgb or rgba
>>> sequence.  My proposal would be that 'color' would be interpreted as a
>>> list of distinct colors only when multiple datasets are given as input
>>> and len(color) equals the number of datasets.
>>>
>>> I find it hard to imagine a case where you would want to set all
>>> datasets to be the same color, so I don't think the ambiguity would be
>>> a major issue.  I would be happy to write and submit an implementation
>>> if others think this is a reasonable idea.
>> Sounds good to me.  I agree that it makes no sense to have to set the color
>> cycle for hist (although using the color cycle as a default is reasonable),
>> and I think it is just an artifact of the way hist has evolved.
>>
>> Eric
>>
>>> Cheers,
>>> Jeff
>>>
>>> || Jeff Klukas, Research Assistant, Physics
>>> || University of Wisconsin -- Madison
>>> || jeff.klukas@gmail | jeffyklukas@aim | jeffklukas@skype
>>> || http://www.hep.wisc.edu/~jklukas/
>>>

Any feedback on the submitted patch ?


I've now added the possibility to switch autoscale off.

On Sun, Mar 28, 2010 at 9:26 PM, Peter Butterworth <bu...@gm...> wrote:
> please find attached the 2 patched files and the diff vs trunk.

Ryan May wrote:
> On Fri, Apr 2, 2010 at 11:42 AM, Eric Firing <ef...@ha...> wrote:
>> Ryan May wrote:
>>> On Fri, Apr 2, 2010 at 1:23 AM, Eric Firing <ef...@ha...> wrote:
>>>>> On Fri, Mar 26, 2010 at 12:13 PM, Ryan May <rm...@gm...> wrote:
>>>>>> I just hit a problem with using quiver with Basemap when when
>>>>>> angles='xy'.  Because Basemap's x,y units are in meters, you end up
>>>>>> with angles that are quantized due to floating point truncation
>>>>>> (30000. + 0.001*u = 30000.).  Changing to angles='uv' fixes the
>>>>>> problem, but it probably should be automatically scaled, as noted in
>>>>>> the comments:
>>>>>>
>>>>>>      elif self.angles == 'xy' or self.scale_units == 'xy':
>>>>>>          # We could refine this by calculating eps based on
>>>>>>          # the magnitude of U, V relative to that of X, Y,
>>>>>>          # to ensure we are always making small shifts in X, Y.
>>>>>>
>>>>>> I managed to fix the problem locally by setting:
>>>>>>
>>>>>>          angles, lengths = self._angles_lengths(U, V, eps=0.0001 *
>>>>>> self.XY.max())
>>>>>>
>>>> I don't think this will work in all cases.  For example, there could be a
>>>> single arrow at (0,0).
>>> Good point.
>>>
>>>> Instead of self.XY.max(), how about abs(self.ax.dataLim.width)?
>>> Wouldn't this have problems if we zoom in sufficiently that the width
>>> is much less than magnitude of the values? Not exactly sure what data
>>> set would sensibly yield this, so I'm not sure if we should worry
>>> about it.
>>>
>>> If we do care, we could just put a minimum bound on eps:
>>>
>>> eps=max(1e-8, 0.0001 * self.XY.max())
>> I don't like taking the max of a potentially large array every time; and one
>> needs max absolute value in any case.  I think the following is better:
>>
>> eps = np.abs(self.ax.dataLim.extents).max() * 0.001
> 
> I hadn't thought about performance.  I think that's more important
> than any worries about bounds being disproportionately smaller. I'll
> check this in.

Sorry for the piecemeal approach in thinking about this--but now I 
realize that to do this right, as indicated by the comment in the 
original code, we need to take the magnitude of U and V into account. 
The maximum magnitude could be calculated once in set_UVC and then saved 
so that it does not have to be recalculated every time it is used in 
make_verts.

Maybe I am still missing some simpler way to handle this well.

Eric

> 
> Ryan
> 

On Fri, Apr 2, 2010 at 11:42 AM, Eric Firing <ef...@ha...> wrote:
> Ryan May wrote:
>>
>> On Fri, Apr 2, 2010 at 1:23 AM, Eric Firing <ef...@ha...> wrote:
>>>>
>>>> On Fri, Mar 26, 2010 at 12:13 PM, Ryan May <rm...@gm...> wrote:
>>>>>
>>>>> I just hit a problem with using quiver with Basemap when when
>>>>> angles='xy'.  Because Basemap's x,y units are in meters, you end up
>>>>> with angles that are quantized due to floating point truncation
>>>>> (30000. + 0.001*u = 30000.).  Changing to angles='uv' fixes the
>>>>> problem, but it probably should be automatically scaled, as noted in
>>>>> the comments:
>>>>>
>>>>>      elif self.angles == 'xy' or self.scale_units == 'xy':
>>>>>          # We could refine this by calculating eps based on
>>>>>          # the magnitude of U, V relative to that of X, Y,
>>>>>          # to ensure we are always making small shifts in X, Y.
>>>>>
>>>>> I managed to fix the problem locally by setting:
>>>>>
>>>>>          angles, lengths = self._angles_lengths(U, V, eps=0.0001 *
>>>>> self.XY.max())
>>>>>
>>> I don't think this will work in all cases.  For example, there could be a
>>> single arrow at (0,0).
>>
>> Good point.
>>
>>> Instead of self.XY.max(), how about abs(self.ax.dataLim.width)?
>>
>> Wouldn't this have problems if we zoom in sufficiently that the width
>> is much less than magnitude of the values? Not exactly sure what data
>> set would sensibly yield this, so I'm not sure if we should worry
>> about it.
>>
>> If we do care, we could just put a minimum bound on eps:
>>
>> eps=max(1e-8, 0.0001 * self.XY.max())
>
> I don't like taking the max of a potentially large array every time; and one
> needs max absolute value in any case.  I think the following is better:
>
> eps = np.abs(self.ax.dataLim.extents).max() * 0.001

I hadn't thought about performance.  I think that's more important
than any worries about bounds being disproportionately smaller. I'll
check this in.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Ryan May wrote:
> On Fri, Apr 2, 2010 at 1:23 AM, Eric Firing <ef...@ha...> wrote:
>>> On Fri, Mar 26, 2010 at 12:13 PM, Ryan May <rm...@gm...> wrote:
>>>> I just hit a problem with using quiver with Basemap when when
>>>> angles='xy'.  Because Basemap's x,y units are in meters, you end up
>>>> with angles that are quantized due to floating point truncation
>>>> (30000. + 0.001*u = 30000.).  Changing to angles='uv' fixes the
>>>> problem, but it probably should be automatically scaled, as noted in
>>>> the comments:
>>>>
>>>>       elif self.angles == 'xy' or self.scale_units == 'xy':
>>>>           # We could refine this by calculating eps based on
>>>>           # the magnitude of U, V relative to that of X, Y,
>>>>           # to ensure we are always making small shifts in X, Y.
>>>>
>>>> I managed to fix the problem locally by setting:
>>>>
>>>>           angles, lengths = self._angles_lengths(U, V, eps=0.0001 *
>>>> self.XY.max())
>>>>
>> I don't think this will work in all cases.  For example, there could be a
>> single arrow at (0,0).
> 
> Good point.
> 
>> Instead of self.XY.max(), how about abs(self.ax.dataLim.width)?
> 
> Wouldn't this have problems if we zoom in sufficiently that the width
> is much less than magnitude of the values? Not exactly sure what data
> set would sensibly yield this, so I'm not sure if we should worry
> about it.
> 
> If we do care, we could just put a minimum bound on eps:
> 
> eps=max(1e-8, 0.0001 * self.XY.max())

I don't like taking the max of a potentially large array every time; and 
one needs max absolute value in any case.  I think the following is better:

eps = np.abs(self.ax.dataLim.extents).max() * 0.001

Eric


> 
> Ryan
> 

On Fri, Apr 2, 2010 at 1:23 AM, Eric Firing <ef...@ha...> wrote:
>> On Fri, Mar 26, 2010 at 12:13 PM, Ryan May <rm...@gm...> wrote:
>>> I just hit a problem with using quiver with Basemap when when
>>> angles='xy'.  Because Basemap's x,y units are in meters, you end up
>>> with angles that are quantized due to floating point truncation
>>> (30000. + 0.001*u = 30000.).  Changing to angles='uv' fixes the
>>> problem, but it probably should be automatically scaled, as noted in
>>> the comments:
>>>
>>>       elif self.angles == 'xy' or self.scale_units == 'xy':
>>>           # We could refine this by calculating eps based on
>>>           # the magnitude of U, V relative to that of X, Y,
>>>           # to ensure we are always making small shifts in X, Y.
>>>
>>> I managed to fix the problem locally by setting:
>>>
>>>           angles, lengths = self._angles_lengths(U, V, eps=0.0001 *
>>> self.XY.max())
>>>
>
> I don't think this will work in all cases.  For example, there could be a
> single arrow at (0,0).

Good point.

> Instead of self.XY.max(), how about abs(self.ax.dataLim.width)?

Wouldn't this have problems if we zoom in sufficiently that the width
is much less than magnitude of the values? Not exactly sure what data
set would sensibly yield this, so I'm not sure if we should worry
about it.

If we do care, we could just put a minimum bound on eps:

eps=max(1e-8, 0.0001 * self.XY.max())

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Ryan May wrote:
> Ping.  Not sure if you missed it first time around or are just that busy.
> 

I looked, but decided I needed to look again, and then lost it in the 
stack.  See below.

> Ryan
> 
> On Fri, Mar 26, 2010 at 12:13 PM, Ryan May <rm...@gm...> wrote:
>> Eric,
>>
>> I just hit a problem with using quiver with Basemap when when
>> angles='xy'.  Because Basemap's x,y units are in meters, you end up
>> with angles that are quantized due to floating point truncation
>> (30000. + 0.001*u = 30000.).  Changing to angles='uv' fixes the
>> problem, but it probably should be automatically scaled, as noted in
>> the comments:
>>
>>        elif self.angles == 'xy' or self.scale_units == 'xy':
>>            # We could refine this by calculating eps based on
>>            # the magnitude of U, V relative to that of X, Y,
>>            # to ensure we are always making small shifts in X, Y.
>>
>> I managed to fix the problem locally by setting:
>>
>>            angles, lengths = self._angles_lengths(U, V, eps=0.0001 *
>> self.XY.max())
>>

I don't think this will work in all cases.  For example, there could be 
a single arrow at (0,0).

Instead of self.XY.max(), how about abs(self.ax.dataLim.width)?

Eric


>> but I'm not sure if you would want a different fix. If you're happy
>> with this fix, I'll go ahead an check in.
> 
> Ryan
> 

Hi,

A "quick afternoon hack" developed into what seems to me to be a
useful and simple framework for doing animations in matplotlib,
utilizing the timed idle event in GTK (currently). It also supports
writing out a movie file using ffmpeg.  Particular issues:

1) Supporting backends other than gtk. I'm not sure how to mimic the
behavior of gobject.idle_add() with Qt and Wx. Also, I'm not sure if
code to mimic this belongs with the animation class or should be kept
with the backend to allow use elsewhere.

2) The FuncAnimation class is written to allow an easy way to make a
more "procedural" animation, such as one that displays data while
reading from a live source, or draws a line repeatedly adding the
points.  My question is whether the interface makes sense or if it's
even worthwhile since it's just saving a couple lines of code that
would be necessary to just to a straightforward Animation subclass.

The code still needs quite a bit of clean up and thought to make sure
that the classes are broken up into the proper parts, as well as
documentation, but I wanted to see if this seems like a good way to go
to add easy animation support to matplotlib.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Ping.  Not sure if you missed it first time around or are just that busy.

Ryan

On Fri, Mar 26, 2010 at 12:13 PM, Ryan May <rm...@gm...> wrote:
> Eric,
>
> I just hit a problem with using quiver with Basemap when when
> angles='xy'.  Because Basemap's x,y units are in meters, you end up
> with angles that are quantized due to floating point truncation
> (30000. + 0.001*u = 30000.).  Changing to angles='uv' fixes the
> problem, but it probably should be automatically scaled, as noted in
> the comments:
>
>        elif self.angles == 'xy' or self.scale_units == 'xy':
>            # We could refine this by calculating eps based on
>            # the magnitude of U, V relative to that of X, Y,
>            # to ensure we are always making small shifts in X, Y.
>
> I managed to fix the problem locally by setting:
>
>            angles, lengths = self._angles_lengths(U, V, eps=0.0001 *
> self.XY.max())
>
> but I'm not sure if you would want a different fix. If you're happy
> with this fix, I'll go ahead an check in.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Alright, I have attached a top-level diff that contains the changes to
axes.py that allow sending multiple colors to the 'color' argument in
Axes.hist.

Below is a short examples that passes lists to 'colors' and 'labels'.

Cheers,
Jeff

|| Jeff Klukas, Research Assistant, Physics
|| University of Wisconsin -- Madison
|| jeff.klukas@gmail | jeffyklukas@aim | jeffklukas@skype
|| http://www.hep.wisc.edu/~jklukas/

----------------------------------
import pylab as P

mu, sigma = 200, 25
x0 = mu + sigma*P.randn(10000)
x1 = mu + sigma*P.randn(7000)
x2 = mu + sigma*P.randn(3000)

P.figure()

colors = ['crimson', 'burlywood', 'chartreuse']
labels = ['Crimson', 'Burlywood', 'Chartreuse']
n, bins, patches = P.hist([x0,x1,x2], 10, histtype='bar',
                          color=colors, label=labels)

P.legend()
P.show()
---------------------------------



On Wed, Mar 31, 2010 at 1:27 PM, Eric Firing <ef...@ha...> wrote:
> Jeff Klukas wrote:
>>
>> When plotting multiple data with one Axes.hist call, the method's
>> interface allows you to specify a list of labels to the 'label' kwarg
>> to distinguish between the datasets.  To get different colors,
>> however, you cannot give a list of colors to 'color'; instead, you
>> have to leave out the 'color' kwarg and change the color cycle.
>>
>> Is there any reason why the color kwarg can't work like label?  I
>> spent an hour or two trying to debug a script before I realized that
>> 'color' wasn't being interpreted as I expected.  I realize that there
>> is some ambiguity since a color argument can be an rgb or rgba
>> sequence.  My proposal would be that 'color' would be interpreted as a
>> list of distinct colors only when multiple datasets are given as input
>> and len(color) equals the number of datasets.
>>
>> I find it hard to imagine a case where you would want to set all
>> datasets to be the same color, so I don't think the ambiguity would be
>> a major issue.  I would be happy to write and submit an implementation
>> if others think this is a reasonable idea.
>
> Sounds good to me.  I agree that it makes no sense to have to set the color
> cycle for hist (although using the color cycle as a default is reasonable),
> and I think it is just an artifact of the way hist has evolved.
>
> Eric
>
>>
>> Cheers,
>> Jeff
>>
>> || Jeff Klukas, Research Assistant, Physics
>> || University of Wisconsin -- Madison
>> || jeff.klukas@gmail | jeffyklukas@aim | jeffklukas@skype
>> || http://www.hep.wisc.edu/~jklukas/
>>
>