matplotlib-devel Mailing List for matplotlib

Robert,
Thanks for the feedback. Comments are below. I think I addressed some 
items over the weekend, so the version in svn should work better than 
the one you tested, assuming you tested the original one I sent out as a 
diff.
Robert Hetland wrote:
> 
> Eric-
> 
> I had a chance to play around with the new quiver this morning. Here 
> are some thoughts:
> 
> 1. I read that somebody thought it was a bit slow, but this is not my 
> experience. I tried to quiver my model data (128x128 with masking), 
> and it rendered in a few seconds. I tried to look at images with more 
> arrows, but I could not actually see the arrows with so many points. 
> In my experience you can't put more than about O(100000) (i.e., about 
> 100x100) arrows on a figure and have it make any sense anyways.
> 
> 2. It seems to handle masking fine. I gave it masked arrays and 
> arrays with nans (it complained a bit about the masked array, but 
> rendered anyways). This is key for me.
> 
Interesting. I did nothing to explicitly deal with masked arrays or 
nans, so how well this works may be backend-dependent and/or platform 
dependent. If this turns out to be a problem, I can put in more 
explicit handling of masks and nans, but it is likely to add overhead.
Question: should handling of masks apply to all input arrays, or is it 
enough to have it apply to U, V, and C? It doesn't matter so much for 
Quiver, but it is one of the differences between pcolor and 
pcolormesh--support of masked X, Y complicates the former and might be 
hard to add to the latter. I hope it is unnecessary.
> 3. It handles colors nicely, but there is no apparent way to set the 
> color limits. Perhaps adding vmin and vmax as kwargs (matching pcolor) 
> would make some sense.
This brings up a more general design question: when should functionality 
like this be added via kwargs versus other mechanisms? It would be nice 
to have more uniformity among classes and functions, so that the general 
strategy could be documented once for a whole bunch of functions, 
instead of being repeated, with variations, for each. This would go 
along with better factoring out of chunks of functionality. In the 
absence of a big push, all this is going to have to happen piecemeal if 
at all, and complicated by the demands of backwards compatibility.
Returning to the specific question, however, I left vmin and vmax out to 
keep things simple, with the idea that there are other standard ways of 
setting them: via an explicit norm kwarg, via the clim method of any 
scalar mappable (which the Quiver is, since it inherits from 
PolyCollection), and via the pylab clim command. If there is a 
consensus that scalar mappables should uniformly support the vmin and 
vmax kwargs directly, then I don't mind adding that. I can see the 
argument for uniformity, given that this is common among scalar 
mappables. Probably it could be factored out by inclusion in 
ScalarMappable.__init__.
> 
> 4. I *really* like how the arrows get gray (and don't try to render at 
> a whole pixel) when they get small. I agree with the other person that 
> it might be nice to have a small dot to indicate zero velocity. No 
> dot should be rendered *ever* for values masked or NaNed, however.
> 
The graying is a function of the backend--specifically, whether 
rendering is antialiased.
The optional dot (actually a hexagon) for arrows below a threshold size 
is in svn, one of the changes I made over the weekend.
> 5. It's a bit of a pain to find values of scale and width that work 
> well, and quiver doesn't seem to make very good choices by default. I 
> don't think this is a big deal, but rather simply the price of the 
> added functionality. Making some more intelligent default choices 
> might not be a bad idea, though. In particular, smaller arrows when 
> there are more arrows to be rendered would be a good place to start.
> 
I changed the autoscaling so that both the length scale and the shaft 
width (and therefore the head size, which scales with shaft width) vary 
with the square root of the number of arrows, but with limits to prevent 
arrows from getting too large and fat or too small and thin. So I think 
you will find the svn version much improved in this regard.
> Some ideas for future work:
> 
> 1. I'm pretty happy with the polygons, but it would be nice to have 
> line collections instead. This would also facilitate my next idea:
> 
Not "line collections instead", but "in addition": the functionality and 
appearance are very different with polygons than with lines. I think I 
can add a line alternative with only a little extra code, but I won't 
even look at it again until this weekend, at the very earliest.
> 2. I would love to have a 'curly vector' tool. However, I'm not sure 
> how much to put into the curly_quiver package, and how much work must 
> be done by the user. I think that at a minimum, it would be nice to 
> give curly lines (i.e., an additional dimension to u and v)that have 
> arrows on the end of them, and leave it to the user to define what 
> those lines are somehow. If these lines could change color along their 
> track, then it would be the best thing ever made!
You can make curly lines with mapped colors using a LineCollection 
(recent change: it now inherits from ScalarMappable). Curly_quiver 
sounds like quite a different animal, though, and potentially much more 
difficult to do well; I don't think there would be much overlap with the 
present code in quiver, or with the code even after I add the line version.
Eric

With the latest svn matplotlib and numpy 0.9.8 I'm now getting:
Python 2.4.3 (#1, Mar 30 2006, 13:31:07)
[GCC 4.0.1 (Apple Computer, Inc. build 5247)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> import pylab
Traceback (most recent call last):
 File "<stdin>", line 1, in ?
 File "/Users/jsw/lib/python/pylab.py", line 1, in ?
 from matplotlib.pylab import *
 File "/Users/jsw/lib/python/matplotlib/pylab.py", line 196, in ?
 import cm
 File "/Users/jsw/lib/python/matplotlib/cm.py", line 5, in ?
 import colors
 File "/Users/jsw/lib/python/matplotlib/colors.py", line 33, in ?
 from numerix import array, arange, take, put, Float, Int, where, \
 File "/Users/jsw/lib/python/matplotlib/numerix/__init__.py", line 66, in ?
 import numpy.oldnumeric as numpy
ImportError: No module named oldnumeric
With numpy 0.9.8 I can do
from numpy.core import oldnumeric
but not
from numpy import oldnumeric.
I suppose this is a consequence of Travis's numerix commits yesterday - 
is the latest numpy svn now required?
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

On Tue, Jun 13, 2006 at 09:21:44AM -0500, John Hunter wrote:
> I'm not at all opposed to making a helper function like scatter to plot
> parametric lines with colormaps, but I don't think "plot" is the right
> vehicle, since it returns a Line2d, not a LineCollection, and since it
> is already heavily overloaded. parplot? =20
 I think having a helper function is a good idea. Not only does it
help the newcomer, but it also allows the oldtimer to write shorter and
more readable code.
 I find that "parplot" is not a great name for such a function, but I
cannot think of a better one. Maybe the list will have better ideas.
 Ga=EBl

Eric-
I had a chance to play around with the new quiver this morning. Here 
are some thoughts:
1. I read that somebody thought it was a bit slow, but this is not my 
experience. I tried to quiver my model data (128x128 with masking), 
and it rendered in a few seconds. I tried to look at images with 
more arrows, but I could not actually see the arrows with so many 
points. In my experience you can't put more than about O(100000) 
(i.e., about 100x100) arrows on a figure and have it make any sense 
anyways.
2. It seems to handle masking fine. I gave it masked arrays and 
arrays with nans (it complained a bit about the masked array, but 
rendered anyways). This is key for me.
3. It handles colors nicely, but there is no apparent way to set the 
color limits. Perhaps adding vmin and vmax as kwargs (matching 
pcolor) would make some sense.
4. I *really* like how the arrows get gray (and don't try to render 
at a whole pixel) when they get small. I agree with the other person 
that it might be nice to have a small dot to indicate zero 
velocity. No dot should be rendered *ever* for values masked or 
NaNed, however.
5. It's a bit of a pain to find values of scale and width that work 
well, and quiver doesn't seem to make very good choices by default. 
I don't think this is a big deal, but rather simply the price of the 
added functionality. Making some more intelligent default choices 
might not be a bad idea, though. In particular, smaller arrows when 
there are more arrows to be rendered would be a good place to start.
Some ideas for future work:
1. I'm pretty happy with the polygons, but it would be nice to have 
line collections instead. This would also facilitate my next idea:
2. I would love to have a 'curly vector' tool. However, I'm not sure 
how much to put into the curly_quiver package, and how much work must 
be done by the user. I think that at a minimum, it would be nice to 
give curly lines (i.e., an additional dimension to u and v)that have 
arrows on the end of them, and leave it to the user to define what 
those lines are somehow. If these lines could change color along 
their track, then it would be the best thing ever made!
-Rob.
-----
Rob Hetland, Assistant Professor
Dept of Oceanography, Texas A&M University
p: 979-458-0096, f: 979-845-6331
e: he...@ta..., w: http://pong.tamu.edu

>>>>> "Ga=EBl" =3D=3D Ga=EBl Varoquaux <gae...@no...> wr=
ites:
 Ga=EBl> 	Hi, It would be a nice feature for the plot command to
 Ga=EBl> accept a list of rgb colors of the same length than the data
 Ga=EBl> vectors to be plotted, in order to generate plots alike the
 Ga=EBl> one on the wiki
 Ga=EBl> "http://scipy.org/Cookbook/Matplotlib/MulticoloredLine".
Eric recently updated LineCollection to inherit from ScalarMappable
(in mpl 0.87.3) which means you can pass it a colormap instance.
Perhaps we should update the wiki example to reflect this. I'm not at
all opposed to making a helper function like scatter to plot
parametric lines with colormaps, but I don't think "plot" is the right
vehicle, since it returns a Line2d, not a LineCollection, and since it
is already heavily overloaded. parplot? =20
JDH

	Hi,
 It would be a nice feature for the plot command to accept a list of
rgb colors of the same length than the data vectors to be plotted, in
order to generate plots alike the one on the wiki
"http://scipy.org/Cookbook/Matplotlib/MulticoloredLine".
	Regards,
 Ga=EBl