matplotlib-devel Mailing List for matplotlib

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
 >> Hey someone said something nice about transforms!
 Eric> About time, isn't it!
 Eric> One thing I still don't understand: when is it necessary to
 Eric> bracket code with freeze/thaw?
It's never necessary, it's an optimization. Lots of objects share the
ax.transData transform. When it is called to transform, all the lazy
objects must be evaluated and lots of virtual function calls made. By
"freezing" the transform, it will evaluate the lazy objects and
compute and cache the components of the affine. Every freeze must be
paired with a thaw, and only when you know the window resize, figure
dpi, xlim settings, etc cannot occur in between the freeze and the
thaw. The call to thaw releases the cached values. It is only
helpful in a deeply nested call to draw with objects that share the
same transformation, eg in Axes.draw.
 Eric> If you want me to go ahead and commit, I am happy to do so.
It would help get more testers. I don't feel strongly either way
 Eric> it. We need to clean things up occasionally, and not keep
 Eric> accumulating alternative versions of things. In that vein,
 Eric> can we drop pcolor_classic before the next major release?
As far as I am concerned, yes, but I suggest posting to the users list
before dropping old functions to see how many people may still want
them around.
JDH

> Hey someone said something nice about transforms!
About time, isn't it!
One thing I still don't understand: when is it necessary to bracket code 
with freeze/thaw?
> 
> Eric, I haven't had a chance to try this code out but I did read
> through it and it looks very nice. A small comment: fig.dpi is
> already a Value, so I don't think you want
> 
> + elif self.units == 'inches':
> + dpi = ax.figure.dpi.get()
> + dx = T.Value(dpi)
> 
> because that is copy semantics and you probably want reference
> semantics
> 
> + elif self.units == 'inches':
> + dx = ax.figure.dpi
> 
> That way if someone changes the figure dpi. Or maybe I'm missing
> something and you really want copy.
You are right--the copy was a blatant bug, and I'm glad you caught it.
> 
> fig.dpi.set(72.)
> 
> all of your transforms are automagically updated.
> 
> Is there any reason not to commit this to svn? It seems to live in
> parallel with the existing quiver, so shouldn't cause anyone any
> grief.
> 
I was holding off so as not to confuse things by making a big change 
during a version release; Charlie indicated that this was his 
preference. Is the release packaging occurring today?
If you want me to go ahead and commit, I am happy to do so. The idea 
would be that quiver2 is an experimental version, subject to more 
changes (e.g., addition of dots when arrows get too small; maybe changes 
 in kwarg function and naming, if someone has better suggestions), but 
that it would replace the old quiver, perhaps at the next major release 
point. This is also Charlie's suggestion, and I agree with it. We need 
to clean things up occasionally, and not keep accumulating alternative 
versions of things. In that vein, can we drop pcolor_classic before the 
next major release?
Eric

>>>>> "John" == John Hunter <jdh...@ac...> writes:
>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
 Eric> arrow 1/50th the width of the plot. Change the window
 Eric> width, and the arrow length changes along with it. Zoom,
 Eric> and it does not change, however. In all cases, the arrow
 Eric> direction remains constant, regardless of window or view
 Eric> limit manipulations. (This is all because of John's
 Eric> transform magic--it is a little hard to understand at first,
 Eric> but it certainly provides wonderful functionality.)
 John> Hey someone said something nice about transforms!
 John> Eric, I haven't had a chance to try this code out but I did
 John> read through it and it looks very nice. A small comment:
 John> fig.dpi is already a Value, so I don't think you want
 John> + elif self.units == 'inches': + dpi = ax.figure.dpi.get() +
 John> dx = T.Value(dpi)
 John> because that is copy semantics and you probably want
 John> reference semantics
 John> + elif self.units == 'inches': + dx = ax.figure.dpi
 John> That way if someone changes the figure dpi. Or maybe I'm
 John> missing something and you really want copy.
 John> fig.dpi.set(72.)
 John> all of your transforms are automagically updated.
OK, let me try again. I added the "maybe I'm missing something"
sentence after reading through my post in the wrong place and it
totally garbled the meaning. What I meant to say was
A small comment: fig.dpi is already a Value, so I don't think you want
+ elif self.units == 'inches':
+ dpi = ax.figure.dpi.get()
+ dx = T.Value(dpi)
because that is copy semantics and you probably want reference
semantics
+ elif self.units == 'inches':
+ dx = ax.figure.dpi
That way if someone changes the figure dpi
 fig.dpi.set(72.)
all of your transforms are automagically updated. Or maybe I'm missing
something and you really want copy.
JDH

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
 Eric> arrow 1/50th the width of the plot. Change the window
 Eric> width, and the arrow length changes along with it. Zoom,
 Eric> and it does not change, however. In all cases, the arrow
 Eric> direction remains constant, regardless of window or view
 Eric> limit manipulations. (This is all because of John's
 Eric> transform magic--it is a little hard to understand at first,
 Eric> but it certainly provides wonderful functionality.)
Hey someone said something nice about transforms!
Eric, I haven't had a chance to try this code out but I did read
through it and it looks very nice. A small comment: fig.dpi is
already a Value, so I don't think you want
+ elif self.units == 'inches':
+ dpi = ax.figure.dpi.get()
+ dx = T.Value(dpi)
because that is copy semantics and you probably want reference
semantics
+ elif self.units == 'inches':
+ dx = ax.figure.dpi
That way if someone changes the figure dpi. Or maybe I'm missing
something and you really want copy.
 fig.dpi.set(72.)
all of your transforms are automagically updated.
Is there any reason not to commit this to svn? It seems to live in
parallel with the existing quiver, so shouldn't cause anyone any
grief.
JDH
JDH

>>>>> "Charlie" == Charlie Moad <cw...@gm...> 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

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

On 6/4/06, Eric Firing <ef...@ha...> wrote:
> John Hunter wrote:
> >>>>>>"Charlie" == Charlie Moad <cw...@gm...> writes:
> >
> >
> > Charlie> On 6/2/06, David S. <dav...@al...> 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

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

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

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

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

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.531250000 +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 <a
-href=backends.html#Agg>Agg</a>, href=backends.html#Cairo>Cairo</a>, <a
+href=backends.html#Agg>Agg</a>, <a href=backends.html#Cairo>Cairo</a>, <a
 href=backends.html#GD>GD</a> or <a href=backends.html#Paint>Paint</a>
 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 @@
 <pre>
 locs, labels = xticks()
-set(labels, fontsize=8)
+setp(labels, fontsize=8)
 </pre>
 You can also set the default ticklabel size in your <a
@@ -901,10 +901,10 @@
 <pre>
 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()
 </pre>
 """),

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

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

John Hunter wrote:
>>>>>>"Charlie" == Charlie Moad <cw...@gm...> writes:
> 
> 
> Charlie> On 6/2/06, David S. <dav...@al...> 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