matplotlib-devel Mailing List for matplotlib

On Tue, Nov 25, 2008 at 1:31 PM, Michael Droettboom <md...@st...> wrote:
> The trunk has effectively the same fix already in that additional code you
> point out. Its purpose is to make sure the zoom happens only once for each
> grouping. It could probably be done better, but it does work.
OK, thanks for the explanation. I've purged the invalid merge from the trunk.
JDH

The change doesn't apply to the trunk. The shared axes logic is 
completely different now. Whereas before there was a unidirectional 
link from one axes to another, and a concept of "master" and "slave" 
axes, the new version avoids that complication by using the "Grouper" class.
The bug fix was required on the branch because the zoom rectangle was 
getting "doubly applied", once for each axis which caused (in effect) 
for the zoom to go too far. The fix was simply to ignore one of the 
axes, in this case the "master" axes.
The trunk has effectively the same fix already in that additional code 
you point out. Its purpose is to make sure the zoom happens only once 
for each grouping. It could probably be done better, but it does work.
So the software engineering lesson here, is I should have remembered to 
merge my own change on the branch -- I would have known right away it 
didn't apply. (Actually, that's probably why I didn't merge it, but of 
course, you still have to let SVN know you don't want to merge the 
change somehow...)
Mike
John Hunter wrote:
> On Tue, Nov 25, 2008 at 12:28 PM, John Hunter <jd...@gm...> wrote:
> 
>> On Tue, Nov 25, 2008 at 12:16 PM, John Hunter <jd...@gm...> wrote:
>> 
>>> pan/zoom appears to be broken in the sharex axis demo. If you do a
>>> zoom to rect on ax2 or ax3 in
>>> examples/pylab_examples/shared_axis_demo.py the event seems to be
>>> swallowed, though a zoom in ax1 is respected.
>>> 
>> The problem appears to be in the backend_bases
>> NavigationToolbar2.release_zoom method. I have updated svn r6447 with
>>
>> # JDH: I don't know why this is here but I expect to be
>> # able to zoomo on any axis that is shared. This was
>> # breaking zoom-to-rect on shared_axis_demo if the zoom
>> # happened in ax2 or ax3 so i am replacing the continue
>> # with a pass until this is sorted out
>> if a._sharex or a._sharey:
>> #continue
>> pass
>>
>> If anyone knows why the continue was/should be there, speak up!
>> 
>
> OK, I think I see where this came in. I did an svnmerge the other day
> from the branch, and merged in Michael's change:
>
> r6365 | mdboom | 2008年11月05日 09:15:28 -0600 (2008年11月05日) | 1 line
>
> Fix bug in zoom rectangle with twin axes
>
> Michael, perhaps you can comment on this bugfix on the branch, and
> whether this change or something like it should be in the trunk? I
> see the trunk has some additional logic that the branch does not have:
>
> # detect twinx,y axes and avoid double zooming
> twinx, twiny = False, False
> if last_a:
> for la in last_a:
> if a.get_shared_x_axes().joined(a,la): twinx=True
> if a.get_shared_y_axes().joined(a,la): twiny=True
>
>
> JDH
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

I'm so sorry Erik. I missed your last email.
I just submitted your patch with a slight modification.
As far as I know, matplotlib still supports python 2.4, and
Conditional Expressions are introduced in 2.5.
Regards,
-JJ
On Tue, Nov 11, 2008 at 9:22 PM, Erik Tollerud <eri...@gm...> wrote:
> Patch against today's svn is attached. Sorry for the long delay...
>
> Right now, "scatterpoints" is just set to 3 in Legend.__init__, but
> presumably that should be an rcParam...
>
> On Fri, Oct 31, 2008 at 2:42 AM, Jae-Joon Lee <lee...@gm...> wrote:
>> Sorry Erik.
>> Can you make a new patch against the current SVN?
>> Some of the patch was applied (but without scatterpoints option) in the SVN.
>> Thanks,
>>
>> -JJ
>>
>>
>>
>>
>> On Thu, Oct 30, 2008 at 1:58 PM, Erik Tollerud <eri...@gm...> wrote:
>>> No more thoughts on this? Or was some version of the patch committed?
>>>
>>> On Mon, Oct 20, 2008 at 12:16 PM, Erik Tollerud <eri...@gm...> wrote:
>>>> Actually, looking more closely, there is one thing that's still
>>>> bothering me: as it is now, it's impossible to have, say, 2 points
>>>> for plotted values, and 3 points for scatter plots on the same legend
>>>> (you have to give a numpoints=# command that's shared by everything in
>>>> the legend, if I'm understanding it). It'd be nice to have a
>>>> property, say, "scatterpoints" (and presumably then an associated
>>>> rcParam "legend.scatterpoints" ) that sets the number of points to use
>>>> for scatter plots. That way, I can make plots just like in the
>>>> original form, but it can also be the same number for both if so
>>>> desired. I've attached a patch based on the last one that does this,
>>>> although it probably needs to be changed to allow for an rcParam
>>>> 'legend.scatterplot' (I don't really know the procedure for adding a
>>>> new rcParam).
>>>>
>>>> On Mon, Oct 20, 2008 at 3:22 AM, Erik Tollerud <eri...@gm...> wrote:
>>>>> The current patch looks good to me... it satisfies all the use cases I
>>>>> had in mind, and I can't think of much else that would be wanted.
>>>>> Thanks!
>>>>>
>>>>> I also very much like the idea of the "sizebar," although that's
>>>>> probably a substantially larger job to implement. I may look into it
>>>>> though, time permitting...
>>>>>
>>>>> On Sat, Oct 18, 2008 at 7:04 PM, Jae-Joon Lee <lee...@gm...> wrote:
>>>>>>> To help clarify the original purpose of "update_from": I wrote this
>>>>>>> method when writing the original legend implementation so the legend
>>>>>>> proxy objects could easily copy their style attributes from the
>>>>>>> underlying objects they were a proxy for (so not every property is
>>>>>>> copied, eg the xdata for line objects is not copied). So the
>>>>>>> operating question should be: what properties do I need to copy to
>>>>>>> make the legend representation of the object. While you are in
>>>>>>> there, perhaps you could clarify this in the docstrings of the
>>>>>>> update_from method.
>>>>>>
>>>>>> Thanks for clarifying this, John.
>>>>>>
>>>>>> Manuel,
>>>>>> The patch looks good to me. We may submit the patch (I hope Erik is
>>>>>> okay with the current patch) and it would be great if you handle the
>>>>>> submission.
>>>>>>
>>>>>> -JJ
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Oct 17, 2008 at 9:45 PM, Manuel Metz <mm...@as...> wrote:
>>>>>>> Jae-Joon Lee wrote:
>>>>>>>> Thanks Manuel.
>>>>>>>>
>>>>>>>> Yes, we need rotation value and etc, but my point is, do we need to
>>>>>>>> update it within the update_from() method? Although my preference is
>>>>>>>> not to do it, it may not matter much as far as we state what this
>>>>>>>> method does clearly in the doc.
>>>>>>>
>>>>>>> Okay, it's probably better to create the object correctly (numsides ...)
>>>>>>> instead of copying the properties (see also JDHs mail !)
>>>>>>>
>>>>>>>> And, in your patch, I don't think updating the numsides value has any
>>>>>>>> effect as it does not recreate the paths.
>>>>>>>>
>>>>>>>> I'm attaching the revised patch. In this patch, update_from() only
>>>>>>>> update gc-related properties. And numsides, size, and rotations are
>>>>>>>> given during the object creation time.
>>>>>>>
>>>>>>> Yes, this looks better. But creating handle_sizes is a little bit too
>>>>>>> much effort. This is done internally. It will do passing a sizes list,
>>>>>>> that may or may not be shorter/longer than numpoints (see revised patch).
>>>>>>>
>>>>>>> I also changed the way the yoffsets are updated in _update_positions().
>>>>>>>
>>>>>>> One additional thing I have in mind (for a later time) is a "sizesbar"
>>>>>>> similar to a colorbar where you can read off values corresponding to
>>>>>>> marker sizes...
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Manuel
>>>>>>>
>>>>>>>> Erik,
>>>>>>>> I see your points. My main concern is that the yoffsets makes the
>>>>>>>> results a bit funny when numpoints is 2. The attached patch has a
>>>>>>>> varying sizes of [0.5*(max+min), max, min]. The yoffsets are only
>>>>>>>> introduced when numpints > 2 and you can also provide it as an
>>>>>>>> optional argument.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> -JJ
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Oct 16, 2008 at 8:43 PM, Manuel Metz <mm...@as...> wrote:
>>>>>>>>> Manuel Metz wrote:
>>>>>>>>>> Jae-Joon Lee wrote:
>>>>>>>>>>> Hi Manuel,
>>>>>>>>>>>
>>>>>>>>>>> I think it is a good to introduce the update_from method in Collections.
>>>>>>>>>>> But, I'm not sure if it is a good idea to also update sizes, paths and
>>>>>>>>>>> rotation (in RegularPolyCoolection). My impression is that update_from
>>>>>>>>>>> method is to update gc related attributes. For comparison,
>>>>>>>>>>> Patch.update_from() does not update the path.
>>>>>>>>>> That's exactly the point why I wasn't fully happy with the patch. The
>>>>>>>>>> path is generated by the _path_generator, so instead of copying the path
>>>>>>>>>> it seems to be better to create an instance of the corresponding class
>>>>>>>>>> (e.g. the StarPolygonCollection class, as suggested before).
>>>>>>>>>>
>>>>>>>>>> One should update the rotation attribute (!!); it's only one number. A
>>>>>>>>>> '+' marker, for example, has rotation = 0, whereas a 'x' marker has
>>>>>>>>>> rotation=pi/4. That's the only difference between those two !
>>>>>>>>>>
>>>>>>>>>>> Also, is it okay to update properties without checking its length?. It
>>>>>>>>>>> does not seem to cause any problems though.
>>>>>>>>>> It's in principal not a problem to copy the sizes attribute without
>>>>>>>>>> checking the length. If it's shorter the the number of items the sizes
>>>>>>>>>> are repeated; if it's longer it gets truncated.
>>>>>>>>>>
>>>>>>>>>> mm
>>>>>>>>>>
>>>>>>>>>>> I guess It would better to use xdata_markers than xdata in the
>>>>>>>>>>> get_handle() method. The difference is when numpoints==1. Using xdata
>>>>>>>>>>> gives two marker points.
>>>>>>>>>>>
>>>>>>>>>>> I was actually about to to commit my patch. I'll try to account your
>>>>>>>>>>> changes and post my version of patch later today.
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>>
>>>>>>>>>>> -JJ
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Oct 15, 2008 at 4:07 PM, Manuel Metz <mm...@as...> wrote:
>>>>>>>>>>>> hmm
>>>>>>>>>>>>
>>>>>>>>>>>> -------- Original Message --------
>>>>>>>>>>>> Jae-Joon Lee wrote:
>>>>>>>>>>>>>> - the parameter numpoints should be used (it's ignored right now)
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks Manuel. I guess we can simply reuse xdata_marker for this purpose.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> - Some private variables are accessed and a new RegularPolycollection is
>>>>>>>>>>>>>> created (does this work eg. with a StarPolygonCollection? I haven't
>>>>>>>>>>>>>> checked, but I don't think so !). Instead of creating a new
>>>>>>>>>>>>>> RegularPolyCollection it might be more useful to make a copy of the
>>>>>>>>>>>>>> existing object... I was thinking about a update_from() method for the
>>>>>>>>>>>>>> Collection class(es) similar to update_from() for lines.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> By changing "RegularPolyCoolection" to "type(handles)", it works for
>>>>>>>>>>>>> StarPolygonCollection.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In Erik's current implementation, the markers in the legend have
>>>>>>>>>>>>> varying colors, sizes, and y offsets.
>>>>>>>>>>>>> The color variation seems fine. But do we need to vary the sizes and
>>>>>>>>>>>>> y-offsets? My inclination is to use a fixed size (median?) and a fixed
>>>>>>>>>>>>> y offset. How does Erik and others think?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>> -JJ
>>>>>>>>>>>> Attached is my current version of the patch. I've moved all of the
>>>>>>>>>>>> properties-copying stuff to collections, which makes the changes
>>>>>>>>>>>> legend.py more clearer (but I'm not fully happy with the patch and
>>>>>>>>>>>> haven't commit anything yet)
>>>>>>>>>>>>
>>>>>>>>>>>> mm
>>>>>>>>>>>>
>>>>>>>>> Hi Jae-Joon,
>>>>>>>>> so here is my revised version of the patch. What do you think ?
>>>>>>>>>
>>>>>>>>> Manuel
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -------------------------------------------------------------------------
>>>>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>>>>>>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>>>>>>> Grand prize is a trip for two to an Open Source event anywhere in the world
>>>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>>>>> _______________________________________________
>>>>>>> Matplotlib-devel mailing list
>>>>>>> Mat...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> -------------------------------------------------------------------------
>>>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>>>>>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>>>>>> Grand prize is a trip for two to an Open Source event anywhere in the world
>>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>>>> _______________________________________________
>>>>>> Matplotlib-devel mailing list
>>>>>> Mat...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Erik Tollerud
>>>> Graduate Student
>>>> Center For Cosmology
>>>> Department of Physics and Astronomy
>>>> 2142 Frederick Reines Hall
>>>> University of California, Irvine
>>>> Office Phone: (949)824-2587
>>>> Cell: (651)307-9409
>>>> eto...@uc...
>>>>
>>>
>>>
>>>
>>> --
>>> Erik Tollerud
>>> Graduate Student
>>> Center For Cosmology
>>> Department of Physics and Astronomy
>>> 2142 Frederick Reines Hall
>>> University of California, Irvine
>>> Office Phone: (949)824-2587
>>> Cell: (651)307-9409
>>> eto...@uc...
>>>
>>
>
>
>
> --
> Erik Tollerud
> Graduate Student
> Center For Cosmology
> Department of Physics and Astronomy
> 2142 Frederick Reines Hall
> University of California, Irvine
> Office Phone: (949)824-2587
> Cell: (651)307-9409
> eto...@uc...
>

On Tue, Nov 25, 2008 at 12:28 PM, John Hunter <jd...@gm...> wrote:
> On Tue, Nov 25, 2008 at 12:16 PM, John Hunter <jd...@gm...> wrote:
>> pan/zoom appears to be broken in the sharex axis demo. If you do a
>> zoom to rect on ax2 or ax3 in
>> examples/pylab_examples/shared_axis_demo.py the event seems to be
>> swallowed, though a zoom in ax1 is respected.
>
> The problem appears to be in the backend_bases
> NavigationToolbar2.release_zoom method. I have updated svn r6447 with
>
> # JDH: I don't know why this is here but I expect to be
> # able to zoomo on any axis that is shared. This was
> # breaking zoom-to-rect on shared_axis_demo if the zoom
> # happened in ax2 or ax3 so i am replacing the continue
> # with a pass until this is sorted out
> if a._sharex or a._sharey:
> #continue
> pass
>
> If anyone knows why the continue was/should be there, speak up!
OK, I think I see where this came in. I did an svnmerge the other day
from the branch, and merged in Michael's change:
 r6365 | mdboom | 2008年11月05日 09:15:28 -0600 (2008年11月05日) | 1 line
 Fix bug in zoom rectangle with twin axes
Michael, perhaps you can comment on this bugfix on the branch, and
whether this change or something like it should be in the trunk? I
see the trunk has some additional logic that the branch does not have:
 # detect twinx,y axes and avoid double zooming
 twinx, twiny = False, False
 if last_a:
 for la in last_a:
 if a.get_shared_x_axes().joined(a,la): twinx=True
 if a.get_shared_y_axes().joined(a,la): twiny=True
JDH

On Tue, Nov 25, 2008 at 12:16 PM, John Hunter <jd...@gm...> wrote:
> pan/zoom appears to be broken in the sharex axis demo. If you do a
> zoom to rect on ax2 or ax3 in
> examples/pylab_examples/shared_axis_demo.py the event seems to be
> swallowed, though a zoom in ax1 is respected.
The problem appears to be in the backend_bases
NavigationToolbar2.release_zoom method. I have updated svn r6447 with
 # JDH: I don't know why this is here but I expect to be
 # able to zoomo on any axis that is shared. This was
 # breaking zoom-to-rect on shared_axis_demo if the zoom
 # happened in ax2 or ax3 so i am replacing the continue
 # with a pass until this is sorted out
 if a._sharex or a._sharey:
 #continue
 pass
If anyone knows why the continue was/should be there, speak up!
JDH

pan/zoom appears to be broken in the sharex axis demo. If you do a
zoom to rect on ax2 or ax3 in
examples/pylab_examples/shared_axis_demo.py the event seems to be
swallowed, though a zoom in ax1 is respected.
I know Eric was recently working on autoscale support for sharex axes
 r6315 | efiring | 2008年10月23日 19:08:58 -0500 (2008年10月23日) | 2 lines
 Support autoscaling with shared axes
And perhaps the current bug is related to the problem Michael
wrote about earlier in the thread: "shared axes" bug in matplotlib
0.98
 Back when the 0.98 transformations were being written, John and I
 had a long discussion about whether data limits should be Bbox-like
 or pair-of-intervals-like, and we ultimately decided to leave things
 as-is to avoid creating too much newness at once. IMHO, however,
 the real problem is that the shared axes mechanism doesn't know
 whether the limits are changing because of autoscaling (in which
 case the limits should be unioned together), or panning/zooming, in
 which case the limits need to be replaced. The second problem is
 probably necessary to fix whether we use Bboxes or not.
JDH

Hey John and the rest of the MPL gang:
I've made the changes you suggested, but the problem is looking to be
deeper than it seemed. I'm also moving this conversation to
matplotlib-devel, since that's probably the more appropriate place for
it.
This updated patch allows for the creation of colormaps with various
alphas, but there is likely more work to be done so that mpl can
consistently make use of it (because it seems like all built-in cmaps
are RGB, not RGBA).
In trying to come up with an example that exercises the new
capabilities, I found out that methods like scatter and countourf modify
the colormap you give them and reset all of the alpha values to 1.
I think this is because inside collections, we pass self._alpha, which
is the Artist._alpha, and 1.0 by default, when making calls such
as:
 _colors.colorConverter.to_rgba_array(c, self._alpha)
...Thus resetting all of alpha values.
I was able to get around this by allowing collections to take on an
alpha value of None, and then passing alpha=None to scatter and
countourf, for example. There are probably other places where such a
change should be done, unless someone has a better idea for how do do
this. I updated examples/pylab/plot_scatter.py to show off the new
capability.
Another thing that I was unable to get around is that if you now make a
plot using the same colormap but omit the alpha=None parameter, or set
it to something other than None, it will reset the alpha values on the
previous plot:
 figure(2)
 c = scatter(theta, r, c=colors, s=area,cmap=myColormap,alpha=None)
will do the right thing, but calling scatter without alpha=None
 figure(3)
 d = scatter(theta, r, c=colors, s=area,cmap=myColormap)
or
 d = scatter(theta, r, c=colors, s=area,cmap=myColormap, alpha=.5)
will reset all of the alpha values in myColormap to 1 or .5.
You can do c.cmap._init() to reset its original alpha values, and if you
force a redraw on figure(2) (by panning or zooming on it, for example),
it will look right again. However, if you go and fiddle with figure(3)
(pan/zoom), and come back to figure(2), panning or zooming will
cause all of the alpha values will be reset again.
I'm not sure if it would be worth it to make a copy of the colormap to
prevent this from happening. Anyone have thoughts on this?
(the full example of this is commented with FIXME: in polar_scatter.py)
best,
 Paul Ivanov
John Hunter, on 2008年11月23日 07:36, wrote:
> On Sun, Nov 23, 2008 at 2:01 AM, Paul Ivanov <piv...@gm...> wrote:
>> I took a stab at it, how does this look?
>>
>> I also took the liberty of adding alpha to LinearSegmentedColormap and
>> updated its docstring changing two somewhat ambiguous uses of the word
>> 'entry' with 'key' and 'value'.
> 
> Hey Paul,
> 
> Thanks for taking this on. I haven't tested this but I read the patch
> and have some inline comments below. Some additional comments:
> 
> * the patch should include a section in the CHANGELOG and
> API_CHANGES letting people know what is different.
> 
> * you should run examples/tests/backend_driver.py and make sure all
> the examples still run, checking the output of some of the mappable
> types (images, scaltter, pcolor...)
> 
> * it would be nice to have an example in the examples dir which
> exercises the new capabilities.
> 
> See also, in case you haven't,
> http://matplotlib.sourceforge.net/devel/coding_guide.html, which
> covers some of this in more detail.
> 
> Thanks again! Comments below:
> 
> Index: lib/matplotlib/colors.py
> ===================================================================
> --- lib/matplotlib/colors.py	(revision 6431)
> +++ lib/matplotlib/colors.py	(working copy)
> @@ -452,7 +452,7 @@
> self._isinit = False
> 
> 
> - def __call__(self, X, alpha=1.0, bytes=False):
> + def __call__(self, X, alpha=None, bytes=False):
> """
> *X* is either a scalar or an array (of any dimension).
> If scalar, a tuple of rgba values is returned, otherwise
> @@ -466,9 +466,10 @@
> """
> You need to document what alpha can be here: what does None mean, can
> it be an array, scalar, etc...
> 
> if not self._isinit: self._init()
> - alpha = min(alpha, 1.0) # alpha must be between 0 and 1
> - alpha = max(alpha, 0.0)
> - self._lut[:-3, -1] = alpha
> + if alpha:
> 
> I prefer to explicitly use "if alpha is None", since there are other
> things that would test False (0, [], '') that you probably don't mean.
> 
> + alpha = min(alpha, 1.0) # alpha must be between 0 and 1
> + alpha = max(alpha, 0.0)
> 
> You should be able to use np.clip(alpha, 0, 1) here, but we should
> consider instead raising for illegal alpha values since this will be
> more helpful to the user. I realize some of this is inherited code
> from before your changes, but we can improve it while making this
> patch.
> 
> + self._lut[:-3, -1] = alpha
> mask_bad = None
> if not cbook.iterable(X):
> vtype = 'scalar'
> @@ -558,9 +559,10 @@
> def __init__(self, name, segmentdata, N=256):
> """Create color map from linear mapping segments
> 
> - segmentdata argument is a dictionary with a red, green and blue
> - entries. Each entry should be a list of *x*, *y0*, *y1* tuples,
> - forming rows in a table.
> + segmentdata argument is a dictionary with red, green and blue
> + keys. An optional alpha key is also supported. Each value
> + should be a list of *x*, *y0*, *y1* tuples, forming rows in a
> + table.
> 
> Example: suppose you want red to increase from 0 to 1 over
> the bottom half, green to do the same over the middle half,
> @@ -606,6 +608,8 @@
> self._lut[:-3, 0] = makeMappingArray(self.N,
> self._segmentdata['red'])
> self._lut[:-3, 1] = makeMappingArray(self.N,
> self._segmentdata['green'])
> self._lut[:-3, 2] = makeMappingArray(self.N,
> self._segmentdata['blue'])
> + if self._segmentdata.has_key('alpha'):
> + self._lut[:-3, 3] = makeMappingArray(self.N,
> self._segmentdata['blue'])
> 
> Is this what you meant? I think you would use 'alpha' rather than
> 'blue' here, no?
> 
> self._isinit = True
> self._set_extremes()
> 
> @@ -664,11 +668,10 @@
> 
> 
> def _init(self):
> - rgb = np.array([colorConverter.to_rgb(c)
> + rgba = np.array([colorConverter.to_rgba(c)
> for c in self.colors], np.float)
> self._lut = np.zeros((self.N + 3, 4), np.float)
> - self._lut[:-3, :-1] = rgb
> - self._lut[:-3, -1] = 1
> + self._lut[:-3] = rgba
> self._isinit = True
> self._set_extremes()