date:20060530

> "Jordan" == Jordan Dawe <[EMAIL PROTECTED]> writes:

Jordan> Ok, I have some questions about what the protocol for
Jordan> patch submission should be, in terms of 'completeness' of
Jordan> the patch.

Jordan> I have a patch for the quiver function that is half
Jordan> done... it has converted the arrows from patches to
Jordan> linecollections, and it will accept arbitrary X and Y
Jordan> coordinates for the arrow positions, as suggested by Rob.
Jordan> Unfortunetly, none of the color functionality is working.
Jordan> Partly this is because the color functionality of
Jordan> LineCollection is different from PolyCollection (which
Jordan> quiver originally used) and partly because I don't
Jordan> understand how matplotlib sets colors at all.  Should I
Jordan> submit this half finished patch so that others can have a
Jordan> chance to improve the color function?  Or should I not
Jordan> submit until I figure out how color works and fix the
Jordan> thing?

I don't recommend submitting patches that don't work.  Rather, post
code samples here with questions in the areas you need help.

Jordan> Furthermore, can LineCollection actually do all the things
Jordan> that quiver's old color commands demand of it?  I don't
Jordan> see a place to set a colormap for a LineCollection, but as
Jordan> I said, I don't understand it very well.

You can create a line collection that is color mappable by deriving
from LineCollection and ScalarMappable.  It will take a little more
work to fully integrate it into the colormappable framework, eg so
colorbars and interactive changing of colormaps works as expected, but
this may be enough to speed you along

This is a good example of how you can extend and specialize the
existing classes if they don't behave like you want them to.


from matplotlib.colors import normalize
from matplotlib.cm import ScalarMappable, jet
from matplotlib.collections import LineCollection

from pylab import figure, show, nx
class LineCollectionSM(LineCollection, ScalarMappable):
def __init__(self,
 segments,
 x,
 norm,
 cmap, 
 # and the other args for LineCollection
 ):
LineCollection.__init__(self, segments)
ScalarMappable.__init__(self, norm, cmap)
self.set_array(x)

def draw(self, renderer):
self._colors = self.to_rgba(self.get_array())
LineCollection.draw(self, renderer)


def random_segment():
x1, y1, x2, y2 = nx.mlab.rand(4)
return (x1, y1), (x2, y2)
segments = [random_segment() for i in range(50)]
x = nx.mlab.rand(50)
col = LineCollectionSM(segments, x, normalize(), jet)
fig = figure()
ax = fig.add_subplot(111, xlim=(0,1), ylim=(0,1), autoscale_on=False)
ax.add_collection(col)
show()


---
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Re: collection initializer color handling vs quiver

2006-05-30 Thread Gary Ruben


Hi Jordan,

Thanks for your heads-up. I actually left this and went back to using 
polygon patches for the arrows, mainly because I thought I'd have more 
control over the size without having to do any fancy line collection 
stuff. Re. your change, the call to the LineCollection__init__ function 
in axes.py just needs an extra set of []'s around the list comprehension 
and all is OK, but your solution could work too.
I do intend to look again at the transform stuff to try to get arrows 
transforming properly - just very busy at the moment, but then I usually am.


Gary R.

I've found one problem with your Arrow LineCollection; it's not actually 
a line collection.  It's one line, so some of the LineCollection 
functions fail on it.  You need to break up the arrow into segments, 
like this:


'barbed': array([ [ [0.,0.], [L,0.] ],
 [ [L,0.], [L-S,S/3] ],
 [ [L,0.], [L-S,-S/3] ] ]

Except just doing this will break the matrixmultiply.  Just a heads-up.

Jordan





---
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] win32api MFC backend

2006-05-30 Thread cyril . giraudon

Hello,

No no, it's not a joke, :-).

I was thinking about using matplotlib within a pythonic mozilla plugin
(xulrunner application more precisely).

Using the general and neutral plugin from mozcmgui, I 've succeeded in insert a
GTK Agg canvas in a web page on Linux. It works quite fine, it handles events...

I'd like to do the same thing on win32, several possiblities :
- Trying to use gtkAgg, not easy to "branch" a gtk window to an MFC hnwd;
- Trying to use tkAgg, I think it's possible because a tcl/tk plugin exists for
Windows, but another toolkit is needed (tkinter);
- Trying to use a native "MFCAgg" directly. I'm going to try to "plug" a
win32api windows within a native C++ handle, I wish it's posible.

Why does an MFC(Agg) backend not already exist ? Is it not possible ? Some
licence problems ? Philosophical issues ? Is there any plan to write this some
day ?

Would it be difficult to add such a bachend ?
Furthermore, wouldn't it give a partial answer to interactive session issues
with pythonwin, scite (MFC based IDE) ?

Thanks a lot,

Cyril.


---
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid7521&bid$8729&dat1642
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Quiver



> 
> You can create a line collection that is color mappable by deriving
> from LineCollection and ScalarMappable.  It will take a little more
> work to fully integrate it into the colormappable framework, eg so
> colorbars and interactive changing of colormaps works as expected, but
> this may be enough to speed you along

John,

Is there any reason not to simply make LineCollection inherit from 
ScalarMappable the same way that PatchCollection does? I don't see any real 
disadvantage or backwards incompatibility, and I think it would be useful and 
add consistency.  I can do it today, barring unforseen problems with related 
changes I am making.

Eric 


---
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Quiver


Jordan,

Are you sure you want to use a LineCollection for this?  If you do, someone is 
sure to say, "But I want red arrows with black borders..."  

My impression from the earlier posts on this topic was that part of the trouble 
was an attempt to be too clever and too automatic; this was interfering with 
getting the transforms right so that the arrows would look right, like text, 
regardless of how the axes are stretched or squished.  Maybe the LineCollection 
makes this easier, but I am reasonably sure it can be done cleanly and well 
with PolyCollections also.  (I am biased toward the PolyCollection approach 
because it is closer to the m_vec.m functionality I added to Rich Pawlowicz's 
m_map; I will need something like this for basemap if it does not already 
exist.)

Eric


- Original Message -
From: Jordan Dawe <[EMAIL PROTECTED]>
Date: Monday, May 29, 2006 7:18 pm
Subject: [matplotlib-devel] Quiver
To: matplotlib development list 

> Ok, I have some questions about what the protocol for patch 
> submission 
> should be, in terms of 'completeness' of the patch.
> 
> I have a patch for the quiver function that is half done... it has 
> converted the arrows from patches to linecollections, and it will 
> accept 
> arbitrary X and Y coordinates for the arrow positions, as suggested 
> by 
> Rob.  Unfortunetly, none of the color functionality is working.  
> Partly 
> this is because the color functionality of LineCollection is 
> different 
> from PolyCollection (which quiver originally used) and partly 
> because I 
> don't understand how matplotlib sets colors at all.  Should I 
> submit 
> this half finished patch so that others can have a chance to 
> improve the 
> color function?  Or should I not submit until I figure out how 
> color 
> works and fix the thing?
> 
> Furthermore, can LineCollection actually do all the things that 
> quiver's 
> old color commands demand of it?  I don't see a place to set a 
> colormap 
> for a LineCollection, but as I said, I don't understand it very well.
> 
> Jordan
> 
> 
> ---
> All the advantages of Linux Managed Hosting--Without the Cost and 
> Risk!Fully trained technicians. The highest number of Red Hat 
> certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-
> us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 


---
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Quiver

> "Eric" == Eric Firing <[EMAIL PROTECTED]> writes:

Eric> Is there any reason not to simply make LineCollection
Eric> inherit from ScalarMappable the same way that
Eric> PatchCollection does? I don't see any real disadvantage or
Eric> backwards incompatibility, and I think it would be useful
Eric> and add consistency.  I can do it today, barring unforseen
Eric> problems with related changes I am making.

I think this looks like a good idea too.

JDH



---
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Quiver

Eric Firing wrote:

Jordan,

Are you sure you want to use a LineCollection for this? If you do, someone is sure to say, "But I want red arrows with black borders..."

My impression from the earlier posts on this topic was that part of the trouble
was an attempt to be too clever and too automatic; this was interfering with
getting the transforms right so that the arrows would look right, like text,
regardless of how the axes are stretched or squished. Maybe the LineCollection
makes this easier, but I am reasonably sure it can be done cleanly and well
with PolyCollections also. (I am biased toward the PolyCollection approach
because it is closer to the m_vec.m functionality I added to Rich Pawlowicz's
m_map; I will need something like this for basemap if it does not already
exist.)

Eric

No, I am not sure we want to use LineCollection. I am using it because
it is harder to see the distortions introduced by data coordinates when
lines are used instead of polygons. I don't understand the transforms
and I feel I have zero chance of getting a good looking plot in a
reasonable length of time working with polygons. So I've been going the
LineCollection way for two reasons: one, Gary's post with his line arrow
seemed to indicate he was working in that direction as well (although it
appears I was hasty to assume that, judging by his follow-up post), and
two, because I figured I could get something going quickly and then
build on it. So really, this isn't a transform issue anymore, because
I've abandoned that idea as beyond my abilities.

If you all feel that turning quiver into line objects isn't a good idea,
then there's not really much work I can do on it; the polygons work as
well as they are going to as-is.

Also, a question: why use collection objects? The implimentation
doesn't strike me as being much faster rendering wise, but maybe I'm
wrong. Is it just so all the objects can be manipulated all at once by
changing the state of the collection? Also, is there any particular
reason the collections only accept verts or segments, instead of being
able to just send it a patch or line object and have the collection
object extract the relevant data?

Jordan

---
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Quiver

> "Jordan" == Jordan Dawe <[EMAIL PROTECTED]> writes:

Jordan> Also, a question: why use collection objects?  The
Jordan> implimentation doesn't strike me as being much faster
Jordan> rendering wise, but maybe I'm wrong.  Is it just so all
Jordan> the objects can be manipulated all at once by changing the
Jordan> state of the collection?  

collections aren't as fast as they can be, mainly because they use
sequences of python objects rather than numeric arrays, so all the
object coercion still has to be done.  Their primary efficiency is the
avoidance of repeated object creation and their attendant function
calls and setting the graphics contect.

Eg, if you create 1 Line2D objects, you will pay for 1 object
creations, 1 separate transformations, 1 calls to the renderer
draw function, and 1 settings of the gc state.

With a collection, you have a lot less overhead, but they are still
too slow for some purposes.

Jordan> Also, is there any particular
Jordan> reason the collections only accept verts or segments,
Jordan> instead of being able to just send it a patch or line
Jordan> object and have the collection object extract the relevant
Jordan> data?

Currently the collections are designed to be flexible (eg, each polygon can
have separate color and width properties) and reasonably fast.  They
are not particularly easy to use, so some helper functionality would
be useful.

JDH


---
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Quiver




Jordan> Also, a question: why use collection objects?  The
Jordan> implimentation doesn't strike me as being much faster
Jordan> rendering wise, but maybe I'm wrong.  Is it just so all
Jordan> the objects can be manipulated all at once by changing the
Jordan> state of the collection?  


collections aren't as fast as they can be, mainly because they use
sequences of python objects rather than numeric arrays, so all the
object coercion still has to be done.  Their primary efficiency is the
avoidance of repeated object creation and their attendant function
calls and setting the graphics contect.

Eg, if you create 1 Line2D objects, you will pay for 1 object
creations, 1 separate transformations, 1 calls to the renderer
draw function, and 1 settings of the gc state.
  
Cool, that makes sense.  Another question: what plot types generate 
1 Line2D objects?  I can see quiver doing something like that if one 
plots an 100x100 grid, but it seems to me the resulting arrows would be 
totally unreadable.


I hope I'm not coming across as snotty here.  I really love matplotlib, 
it's all I use nowadays, and quite an amazing piece of code.  I want to 
find someplace where I can start adding functionality, but the backend 
is really confusing me.  I guess I'm trying to figure out what bits of 
the code are design decisions and what bits are there because they 
worked, but aren't necessarily the best solution.

Jordan> Also, is there any particular
Jordan> reason the collections only accept verts or segments,
Jordan> instead of being able to just send it a patch or line
Jordan> object and have the collection object extract the relevant
Jordan> data?

Currently the collections are designed to be flexible (eg, each polygon can
have separate color and width properties) and reasonably fast.  They
are not particularly easy to use, so some helper functionality would
be useful.
  
Cool, so I take this to mean it would be helpful to add some code to the 
__init__() funcs of the collection objects so they can accept objects as 
well as vertex data?  Cause I think I could do that.


So, are the basic drawing primitives in matplotlib Line2D, 
LineCollection, Patch, and PolyCollection, with QuadMesh a special case 
so that pcolor renders fast?


Jordan


---
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Quiver

> "Jordan" == Jordan Dawe <[EMAIL PROTECTED]> writes:
Jordan> Cool, that makes sense.  Another question: what plot types
Jordan> generate 1 Line2D objects?  I can see quiver doing
Jordan> something like that if one plots an 100x100 grid, but it
Jordan> seems to me the resulting arrows would be totally
Jordan> unreadable.

some contours may generate this many line objects.  scatters and
pcolors can generate tens of thousands of polygons or more...  Never
underestimate the power of the user to throw more stuff into a plot
than previously thought impossible.

Jordan> Cool, so I take this to mean it would be helpful to add
Jordan> some code to the __init__() funcs of the collection
Jordan> objects so they can accept objects as well as vertex data?
Jordan> Cause I think I could do that.

My weak preference is to have higher level functions that create the
collection objects (think Axes.scatter, Axes.pcolor or many of the
functions in the finance module) rather than overloading the
constructor, which might get confusing.  A Collection is at the level
of Line2D -- most users don't create them directly, and helper
functions should make them easy to use.

Jordan> So, are the basic drawing primitives in matplotlib Line2D,
Jordan> LineCollection, Patch, and PolyCollection, with QuadMesh a
Jordan> special case so that pcolor renders fast?


The base types are Text, Line2D, Patch, Image and Collection.  Some of
these are specialized, eg TextWithDash inherits from Text, Polygon and
Rectangle inherit from Patch, LineCollection inherits from Collection
and so on.  There are several types of Images. There is an artist
hierarchy diagram in the PDF user's guide which is fairly
comprehensive but not entirely up-to-date, eg QuadMesh is not there.

Regarding the design question.  I think there is near uniform
consensus that the transforms are kludgy and hard to work with, but as
Andrew has pointed out, it would be a lot of work to replace them with
something more intuitive since they pervade the code; "open heart
surgery on matplotlib", I think he called it.  It would have been a good
summer-of-code project.  I think it is a reasonably hard problem  --
how to support affines plus general non-linear transformations and
have your transformations efficiently updated in the presence of
window resizes and the like.  Certainly not a very hard problem --
lots of people have solved it -- but nontrivial.  Typically one ends
up special casing the common transformations, so polar plots are
supported with custom axes.  One could make a generic axes object that
drew good tick lines and labels in the presence of arbitrary nonlinear
transformations on non-separable axes, but it would take some smarts.
One of the things that makes transformations hard to do well is that
beyond the pure math of affines and functions on those affines, which
is pretty easy, you have to make the results play nicely in the
presence of axes graphs that have tick labels on them in nice places
and user's who want to pan and zoom.  What should zoom-to-rect do on a
polar axes?  

I regard the collections as a bit kludgy too -- I had a few specific
use cases I was targeting, basically a few plots types where lots of
objects were being creates: scatters, pcolors, financial candlestick
plots, and tried to find some common denominators.  Collections were
the first attempt at solving this problem, and I think I traded too
much flexibility for a somewhat non-intuitive interface and subpar
performance.  There is yet room to either refactor the existing
collections or design new ones to solve specific problems better
(think QuadMesh).  Whatever their current short-comings, I still think
back fondly to the bad-old-days, when the pcolor_demo advised you to
"go get a cup of coffee" while you waited for it to render.  And it
really took that long.

The Axis code needs some improvement, because the notion of each Axes
having a single x-axis and y-axis is fairly limiting, and the ticking
is too slow.  Separate objects for each tick line and label slow things
down a lot.  

The Axes code does too much -- handling almost all of the object
creation and the objects these methods return are too primitive (eg
plot, scatter and pcolor are axes methods that return graphics
primitives like Line2D).  There is some consensus that we should have
high level plot objects (FunctionItem, ScatterItem, XYPlotItem) which
are created separately from an Axes and contain their primitive
graphics objects.  This is closer to the gnuplot model.

Many of the other objects seem to be holding up fairly well and handle
common and unusual cases fairly elegantly -- the FigureCanvas, Figure,
Line2D, Patch, Text and matplotlib Events seem to work pretty well.

Hope this helps,
JDH


---
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red

Re: [matplotlib-devel] Quiver


John Hunter wrote:

Hope this helps,
JDH
  


Sweet, that helps a lot.  Thank you very much.

Jordan


---
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Quiver Patch

Ok, here's something of a weird patch, because I don't know how to use 
subversion properly.  It has changes to axes.py which update quiver so 
that it accepts arbitrary X,Y data; it doesn't demand the data be on a 
grid anymore.


The other changes are to collections.py; I updated LineCollection so it 
inherits from ScalarMappable.  I did this just by copying what looked 
like the relevant code from PatchCollection and then I tested it with my 
LineCollection based version of quiver.  I think I got it right, but I 
don't really know what I'm doing here so someone should check it over.


Jordan
Index: lib/matplotlib/axes.py
===
--- lib/matplotlib/axes.py  (revision 2421)
+++ lib/matplotlib/axes.py  (working copy)
@@ -3206,16 +3206,16 @@
 QUIVER( U, V )
 QUIVER( X, Y, U, V, S)
 QUIVER( U, V, S )
-QUIVER( ..., color=None, width=1.0, cmap=None,norm=None )
+QUIVER( ..., color=None, width=1.0, cmap=None, norm=None )
 
 Make a vector plot (U, V) with arrows on a grid (X, Y)
 
-The optional arguments color and width are used to specify the color 
and width
-of the arrow. color can be an array of colors in which case the arrows 
can be
-colored according to another dataset.
+If X and Y are not specified, U and V must be 2D arrays.  Equally 
spaced
+X and Y grids are then generated using the meshgrid command.
 
-If cmap is specified and color is 'length', the colormap is
-used to give a color according to the vector's length.
+color can be a color value or an array of colors, so that the arrows 
can be
+colored according to another dataset.  If cmap is specified and color 
is 'length',
+the colormap is used to give a color according to the vector's length.
 
 If color is a scalar field, the colormap is used to map the scalar to 
a color
 If a colormap is specified and color is an array of color triplets, 
then the
@@ -3263,10 +3263,15 @@
 assert X.shape == Y.shape
 assert U.shape == X.shape
 
+U = ravel(U)
+V = ravel(V)
+X = ravel(X)
+Y = ravel(Y)
+
 arrows = []
 N = sqrt( U**2+V**2 )
 if do_scale:
-Nmax = maximum.reduce(maximum.reduce(N)) or 1 # account for div by 
zero
+Nmax = maximum.reduce(N) or 1 # account for div by zero
 U = U*(S/Nmax)
 V = V*(S/Nmax)
 N = N*Nmax
@@ -3281,7 +3286,6 @@
 shading = kwargs.get('shading', 'faceted')
 
 C = None
-I,J = U.shape
 if color == 'length' or color is True:
 if color is True:
 warnings.warn('''Use "color='length'",
@@ -3290,12 +3294,15 @@
 elif color is None:
 color = (0,0,0,1)
 else:
-clr = asarray(color)
+clr = ravel(asarray(color))
 if clr.shape == U.shape:
 C = clr
 
-arrows = [ Arrow(X[i,j],Y[i,j],U[i,j],V[i,j],0.1*S ).get_verts()
-   for i in xrange(I) for j in xrange(J) ]
+I = U.shape[0]
+arrows = []
+for i in xrange(I):
+arrows.append( FancyArrow(X[i],Y[i],U[i],V[i],0.1*S ).get_verts() )
+
 collection = PolyCollection(
 arrows,
 edgecolors = 'None',
@@ -3311,6 +3318,7 @@
 else:
 collection.set_facecolor(color)
 self.add_collection( collection )
+
 lims = asarray(arrows)
 _max = maximum.reduce( maximum.reduce( lims ))
 _min = minimum.reduce( minimum.reduce( lims ))
Index: lib/matplotlib/collections.py
===
--- lib/matplotlib/collections.py   (revision 2421)
+++ lib/matplotlib/collections.py   (working copy)
@@ -367,7 +367,7 @@
 raise NotImplementedError('Vertices in data coordinates are 
calculated\n'
 + 'only with offsets and only if _transOffset == dataTrans.')
 
-class LineCollection(Collection):
+class LineCollection(Collection, ScalarMappable):
 """
 All parameters must be sequences.  The property of the ith line
 segment is the prop[i % len(props)], ie the properties cycle if
@@ -381,6 +381,8 @@
  linestyle = 'solid',
  offsets = None,
  transOffset = None,#identity_transform(),
+ norm = None,  # optional for ScalarMappable
+ cmap = None,  # ditto
  ):
 """
 segments is a sequence of ( line0, line1, line2), where
@@ -412,6 +414,7 @@
 """
 
 Collection.__init__(self)
+ScalarMappable.__init__(self, norm, cmap)
 
 if linewidths is None   :
 linewidths   = (rcParams['lines.linewidth'], )
@@ -419,7 +422,7 @@
 if colors is None   :
 colors   = (rcParams['lines

Re: [matplotlib-devel] Quiver Patch

Jordan,

Sorry for the duplication, but I made and committed a similar LineCollection 
change before seeing your message.  It is almost identical to yours.

I will check your Quiver change and commit it if it looks OK.

Thanks.

Eric

- Original Message -
From: Jordan Dawe <[EMAIL PROTECTED]>
Date: Tuesday, May 30, 2006 12:39 pm
Subject: [matplotlib-devel] Quiver Patch
To: matplotlib development list 

> Ok, here's something of a weird patch, because I don't know how to 
> use 
> subversion properly.  It has changes to axes.py which update quiver 
> so 
> that it accepts arbitrary X,Y data; it doesn't demand the data be 
> on a 
> grid anymore.
> 
> The other changes are to collections.py; I updated LineCollection 
> so it 
> inherits from ScalarMappable.  I did this just by copying what 
> looked 
> like the relevant code from PatchCollection and then I tested it 
> with my 
> LineCollection based version of quiver.  I think I got it right, 
> but I 
> don't really know what I'm doing here so someone should check it over.
> 
> Jordan
> 


---
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Quiver Patch