matplotlib-devel Mailing List for matplotlib

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