Re: [matplotlib-devel] [Matplotlib-users] can't get started
John Hunter wrote: >>"Charlie" == Charlie Moad <[EMAIL PROTECTED]> writes: > > > Charlie> On 6/2/06, David S. <[EMAIL PROTECTED]> wrote: > >> I have just installed numpy-0.9.8, scipy-0.4.9, and > >> matplotlib-0.87.2 on a Windows machine with Python 2.4.2. > > Charlie> matplotlib-0.87.2 requires numpy-0.9.6. You will get an > Charlie> error otherwise. > > > This is starting to bite enough people that we should consider rolling > out a release. We had hope to get the 3d stuff working before the > next release, but having a version up there that doesn't work with the > latest numpy is a more pressing problem to me. Does this seem like a > good idea to you Charlie? Are there other features or fixes that > other developers would like to get in first? John, I agree that it is time for a new release. The changes I have been making involving not rendering things with alpha == 0 or linewidth == 0 are certainly not complete, but I don't think this is a showstopper. Anything using agg should be OK, postscript is OK, svg is OK with linewidth == 0, which I think is what matters most immediately--some things rely on this. Help from other developers will be needed for other backends. A new quiver could come before or after a release. I have not committed anything yet. I would like to be able to start doing so fairly soon, but in a way that does not cause trouble with a release. (At present, I am calling the new version quiver2 so that I can work with the pylab interface without clobbering the original version. The API will differ from that of the original, so maybe both should be present, with different names, for a while.) It would help to know when the actual production of the release is likely to occur, of course. Eric ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] contour demo
John Hunter wrote: > In the last figure 4 of contour_demo.py, the positioning of the > vertical colorbar looks too low. I would expect it to align roughly > with the vertical extent of the image axes. Is this intentional, > configurable, or a bug? > I committed a change to the demo that repositions the colorbar. Eric ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] new Quiver progress
Robert Hetland wrote:
Let me know if you would like to do a quick alpha test before you
commit. I'll help to put it through the paces..
-Rob.
Rob,
Thanks. Attached are a diff against svn and a test script to get you
started. If you apply the diff as a patch, you should be able to call
quiver2 from the pylab interface. Docstrings are provided. I made no
attempt to copy the kwarg part of the API from the old quiver; this one
is just too different. Most of the arg part of the API is the same,
except that the optional third or fifth argument is a mappable array
instead of a scale; I made the scale a kwarg, and it operates completely
differently from the one in the old quiver--but for good reason, I think.
The key idea for the scale is that the "units" kwarg establishes a unit
of measure ("arrow unit") for the arrows, and the scale gives the U,V
data units per arrow unit. For example, if units="inches" and you have
a 1 m/s velocity vector, then setting scale=2 will mean 2 m/s per inch,
and the vector will be half an inch (assuming the figure dpi value is
correct), regardless of how you change the window size or zoom. If
units="x", and your x-axis goes from 0 to 50 km, then you might set
scale=1/5.0 so that 1 m/s corresponds to 5 km along the x-axis; if you
zoom in, the vector will grow. If units="width" (present default, though
maybe not a good one), then the unit is the width of the plot, so you
might make scale=50, so that 1 m/s makes an arrow 1/50th the width of
the plot. Change the window width, and the arrow length changes along
with it. Zoom, and it does not change, however. In all cases, the
arrow direction remains constant, regardless of window or view limit
manipulations. (This is all because of John's transform magic--it is a
little hard to understand at first, but it certainly provides wonderful
functionality.)
There is a simple auto-scaling algorithm, so one does not have to
specify the scale kwarg initially.
Once quiver.py is in place, I will add related functionality such as
ellipses, so you can plot mean velocities and standard error ellipses,
for example.
One thing I have not looked into yet is what it will take to do all this
correctly with polar axes and with basemap, which I will need.
Eric
Index: lib/matplotlib/quiver.py
===
--- lib/matplotlib/quiver.py (revision 0)
+++ lib/matplotlib/quiver.py (revision 0)
@@ -0,0 +1,285 @@
+'''
+Support for plotting fields of arrows.
+
+Presently this contains a single class, Quiver, but it
+might make sense to consolidate other arrow plotting here.
+
+This will also become a home for things such as standard
+deviation ellipses, which can and will be derived very easily from
+the Quiver code.
+'''
+
+
+_quiver_doc = '''
+Plot a 2-D field of arrows.
+
+Function signatures:
+
+quiver(U, V, *kw)
+quiver(U, V, C, *kw)
+quiver(X, Y, U, V, *kw)
+quiver(X, Y, U, V, C, *kw)
+
+Arguments:
+
+X, Y give the x and y coordinates of the arrow origins
+U, V give the x and y components of the arrow vectors
+C is an optional array used to map colors to the arrows
+
+All arguments may be 1-D or 2-D arrays or sequences.
+If X and Y are absent, they will be generated as a uniform grid.
+If U and V are 2-D arrays but X and Y are 1-D, and if
+len(X) and len(Y) match the column and row dimensions
+of U, then X and Y will be expanded with meshgrid.
+
+Keyword arguments (default given first):
+
+ * units = 'width' | 'height' | 'dots' | 'inches' | 'x' | 'y'
+arrow units; the arrow dimensions *except for length*
+are in multiples of this unit.
+ * scale = None | float
+data units per arrow unit, e.g. m/s per plot width;
+a smaller scale parameter makes the arrow longer.
+
+Arrow dimensions and scales can be in any of several units:
+
+'width' or 'height': the width or height of the axes
+'dots' or 'inches': pixels or inches, based on the figure dpi
+'x' or 'y': X or Y data units
+
+In all cases the arrow aspect ratio is 1, so that if U==V the angle
+of the arrow on the plot is 45 degrees CCW from the X-axis.
+
+The arrows scale differently depending on the units, however.
+For 'x' or 'y', the arrows get larger as one zooms in; for other
+units, the arrow size is independent of the zoom state. For
+'width or 'height', the arrow size increases with the width and
+height of the axes, respectively, when the the window is resized;
+for 'dots' or 'inches', resizing does not change the arrows.
+
+
+ * width = 0.005shaft width in arrow units; default depends on
+choice of units, above, but is equivalent to
+0.005 times the width of the plot.
+ * headwidth = 3head width as multiple of shaft width
+ * headlength = 5 head length as multiple of shaft width
+ *
[matplotlib-devel] FAQ error
1. All the set calls should be setp calls So: set(gca(), 'xticks', [1,2,3,4]) should be: from pylab import * setp(gca(), 'xticks', [1,2,3,4]) 2. Question: "Can I just generate images without having a window popup?" HTML markup is bad, so I get this in my browser href=backends.html#Cairo>Cairo Here goes the patch (first one ever :)) --- faq.html.template 2006-06-05 01:33:45.53125 +0200 +++ faq.html.template.new 2006-06-05 01:37:15.203125000 +0200 @@ -747,7 +747,7 @@ 'Can I just generate images without having a window popup?', """ The easiest way to do this is use an image backend, either Agg, href=backends.html#Cairo>Cairo, Agg, Cairo, GD or Paint if you want to generate PNG images, eg, for use in a web page, or PS if you want publication quality, scalable images. All of these @@ -858,7 +858,7 @@ locs, labels = xticks() -set(labels, fontsize=8) +setp(labels, fontsize=8) You can also set the default ticklabel size in your from pylab import * plot([1,2,3,4], [1,4,9,16]) -set(gca(), 'xticks', [1,2,3,4]) -labels = set(gca(), 'xticklabels', +setp(gca(), 'xticks', [1,2,3,4]) +labels = setp(gca(), 'xticklabels', ['Frogs', 'Hogs', 'Bogs', 'Slogs']) -set(labels, 'rotation', 'vertical') +setp(labels, 'rotation', 'vertical') show() """), ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] contour demo
John Hunter wrote: > In the last figure 4 of contour_demo.py, the positioning of the > vertical colorbar looks too low. I would expect it to align roughly > with the vertical extent of the image axes. Is this intentional, > configurable, or a bug? I would call it a design deficiency. In mpl as in matlab, automatic colorbar positioning is done in a very simple way: an existing axes is shrunken and a colorbar is added using liberated space, and positioned relative to the shrunken axes. When a colorbar is added, the same thing happens, and the first colorbar is not repositioned to take into account the new size and position of the master axes. The key point is that the positioning is done once for each colorbar--it is static. The nicest way to fix this might require something that I think you have deliberately and wisely left out of mpl so far: a layout engine, like the Tk packer etc. Simpler methods might be devised. I am not inclined to spend time on this right now, however, because (1) the problem only arises when using two colorbars, which is probably not a very common use case, and (2) it is easily fixed by manually repositioning the colorbars, so it is not a problem for publication-quality plots. Also (3) getting the aspect-ratio handling working has been enough of a struggle that I am reluctant to risk destabilizing it right now (under the optimistic assumption that it actually is stable now), and (4) I think there are much more important things that need work. Maybe what I should do is add the manual positioning to the demo so the plot looks nice, and serves as an example of how to do the positioning. > > Also, in many of the contour examples, the text labels overlap the > contour lines, especially when the text labels are large. Should we > revisit the code which removes line segments that overlap the text > code to see if we can improve this a bit? To do this well might require quite a different strategy than the present one; the segment removal might need to be done at drawing time, so that it could adapt to the scale of the plot when it is drawn. The problem is that the lines scale with the figure size but the labels don't. So one might need a "LabelledLineCollection" artist instead of using separate LineCollection and Text artists. Eric ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] new Quiver progress
Gary, Thanks for the prompt test and report. I agree that the ability to put a dot at locations where arrows are below a threshold would be good. I will add it. I think it should be similar to a circle marker that scales with the arrow width, and has a diameter that is a fraction of that width. I also observed the stroking problem with small arrows and finite linewidth. I haven't checked into it, but I am wondering whether the problem is in the specification of the line join type. Eric Gary Ruben wrote: > Hi Eric, > > Having entered the build-from-source world with the latest ubuntu, I > applied your patch and tried it out with the example code I sent you > using a call similar to > > quiver2(x,y,u,v,units='x',width=0.5,headwidth=3,headlength=3,headaxislength=2) > > > > This works very nicely for my purposes - perfectly in fact. > Many thanks for your work on this. > The only thing I think might be nice to add is some sort of minsize > parameter so that you could get a pixel or something marking the > existence of a data value for a grid point or a tiny arrowhead, sort of > like the current svn quiver behaves, but size settable. I tried adding > linewidths=(1,) to see if this would work. It sort of works, but looks > pretty ugly and I think confirms my suspicion that the problems I had > seen in my attempts were due to line stroking. > > Thanks and good work! > > Gary ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] new Quiver progress
This is good news Eric and sounds like the desired behaviour. Thanks for letting me know. I was intending to try to work it out this weekend but have spent my time instead learning to build numpy/scipy/matplotlib from source - a worthwhile exercise. I don't think JDH/Charlie should wait for new quiver plots before doing another release. On the scaled down arrows, do you see strange artifacts when viewing at certain magnifications? JDH thought this might be due to subpixel rendering problems, although I wasn't sure that was the reason. I look forward to seeing how the transform stuff works. I found it all a bit unfathomable. thanks, Gary Eric Firing wrote: > Jordan, Gary, > > I have been working on another implementation of quiver functionality. It is > not ready to commit yet, but I think I have the transforms worked out > reasonably well. The arrows never get distorted, and their orientation is > preserved as the axes are manipulated. Length can be preserved or not, > depending on the units one chooses. Below a threshold, the whole arrow is > scaled down as its length is reduced; above that threshold, only the length > changes. I am subclassing PolyCollection, so there is full flexibility in > rendering with or without an edge. > > I expect I will be ready to commit something within a week. > > Eric ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] can't get started
On 6/4/06, Eric Firing <[EMAIL PROTECTED]> wrote: > John Hunter wrote: > >>"Charlie" == Charlie Moad <[EMAIL PROTECTED]> writes: > > > > > > Charlie> On 6/2/06, David S. <[EMAIL PROTECTED]> wrote: > > >> I have just installed numpy-0.9.8, scipy-0.4.9, and > > >> matplotlib-0.87.2 on a Windows machine with Python 2.4.2. > > > > Charlie> matplotlib-0.87.2 requires numpy-0.9.6. You will get an > > Charlie> error otherwise. > > > > > > This is starting to bite enough people that we should consider rolling > > out a release. We had hope to get the 3d stuff working before the > > next release, but having a version up there that doesn't work with the > > latest numpy is a more pressing problem to me. Does this seem like a > > good idea to you Charlie? Are there other features or fixes that > > other developers would like to get in first? > > John, > > I agree that it is time for a new release. > > The changes I have been making involving not rendering things with alpha > == 0 or linewidth == 0 are certainly not complete, but I don't think > this is a showstopper. Anything using agg should be OK, postscript is > OK, svg is OK with linewidth == 0, which I think is what matters most > immediately--some things rely on this. Help from other developers will > be needed for other backends. > > A new quiver could come before or after a release. I have not committed > anything yet. I would like to be able to start doing so fairly soon, but > in a way that does not cause trouble with a release. (At present, I am > calling the new version quiver2 so that I can work with the pylab > interface without clobbering the original version. The API will differ > from that of the original, so maybe both should be present, with > different names, for a while.) It would help to know when the actual > production of the release is likely to occur, of course. Sounds like we could push 0.87.3 tomorrow or Tuesday. I personally think the new quiver should be held off until 0.88 and it should replace the old one if it is truly better. - Charlie ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] new Quiver progress
Hi Eric, Having entered the build-from-source world with the latest ubuntu, I applied your patch and tried it out with the example code I sent you using a call similar to quiver2(x,y,u,v,units='x',width=0.5,headwidth=3,headlength=3,headaxislength=2) This works very nicely for my purposes - perfectly in fact. Many thanks for your work on this. The only thing I think might be nice to add is some sort of minsize parameter so that you could get a pixel or something marking the existence of a data value for a grid point or a tiny arrowhead, sort of like the current svn quiver behaves, but size settable. I tried adding linewidths=(1,) to see if this would work. It sort of works, but looks pretty ugly and I think confirms my suspicion that the problems I had seen in my attempts were due to line stroking. Thanks and good work! Gary ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] new Quiver progress
Eric Firing wrote: > Gary, > > Thanks for the prompt test and report. > > I agree that the ability to put a dot at locations where arrows are > below a threshold would be good. I will add it. I think it should be > similar to a circle marker that scales with the arrow width, and has a > diameter that is a fraction of that width. That sounds like a good idea. > I also observed the stroking problem with small arrows and finite > linewidth. I haven't checked into it, but I am wondering whether the > problem is in the specification of the line join type. I suspect you're right about the join type. When I was building arrows out of LineCollections I had my suspicions that this was the problem. I didn't look into what control Agg gives you over this - there may not be an appropriate join type which always looks good. regards, Gary ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] can't get started
> "Charlie" == Charlie Moad <[EMAIL PROTECTED]> writes: Charlie> Sounds like we could push 0.87.3 tomorrow or Tuesday. I Charlie> personally think the new quiver should be held off until Charlie> 0.88 and it should replace the old one if it is truly Charlie> better. OK, let's hold for Tues to give other devs a chance to jump in if they have anything tomorrow. JDH ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
