matplotlib-devel Mailing List for matplotlib (Page 469)

>>>>> "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

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?

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?

JFH

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

Eric Firing wrote:
> Jeff,
>
> Thanks for the report.  I have committed a bugfix combined with a speedup: the check for gray will not occur if the image is cached.
>
> Eric
>
>   

Thanks Eric - that works fine.

-Jeff

-- 
Jeffrey S. Whitaker         Phone : (303)497-6313
NOAA/OAR/CDC  R/PSD1        FAX   : (303)497-6449
325 Broadway                Boulder, CO, USA 80305-3328

Jeff,

Thanks for the report.  I have committed a bugfix combined with a speedup: the check for gray will not occur if the image is cached.

Eric

----- Original Message -----
From: Jeff Whitaker <js...@fa...>
Date: Friday, June 2, 2006 1:07 pm
Subject: [matplotlib-devel] RGBA in imshow
To: matplotlib development list <mat...@li...>

> Hi all:
> 
> It looks like one can no longer plot an array of RGBA values in 
> imshow - 
> I suspect this is a consequence of the recent changes to the way 
> colors 
> are handled.  For example
> 
> from pylab import *
> # make a random rgba matrix
> rgba = ones((64,64,4),'f')
> for k in range(3):
>   rgba[:,:,k] = rand(64,64).astype('f')
> imshow(rgba)
> show()
> 
> works in 0.87.2, but fails with
> 
> Traceback (most recent call last):
>  File "/Users/jsw/lib/python/matplotlib/backends/backend_gtk.py", 
> line 
> 283, in expose_event
>    self._render_figure(self._pixmap, w, h)
>  File 
> "/Users/jsw/lib/python/matplotlib/backends/backend_gtkagg.py", 
> line 72, in _render_figure
>    FigureCanvasAgg.draw(self)
>  File "/Users/jsw/lib/python/matplotlib/backends/backend_agg.py", 
> line 
> 389, in draw
>    self.figure.draw(renderer)
>  File "/Users/jsw/lib/python/matplotlib/figure.py", line 531, in draw
>    for a in self.axes: a.draw(renderer)
>  File "/Users/jsw/lib/python/matplotlib/axes.py", line 991, in draw
>    im.draw(renderer)
>  File "/Users/jsw/lib/python/matplotlib/image.py", line 184, in draw
>    im = self.make_image()
>  File "/Users/jsw/lib/python/matplotlib/image.py", line 130, in 
> make_image    im.is_grayscale = (self.cmap.is_gray() and
>  File "/Users/jsw/lib/python/matplotlib/colors.py", line 634, in 
> is_gray    return (alltrue(self._lut[:,0] == self._lut[:,1])
> 
> with the latest svn.
> 
> This patch to image.py seems to fix it, but I'm not sure it's the 
> right 
> solution
> 
> --- /Users/jsw/lib/python/matplotlib/image.py.orig      2006-06-02 
> 17:04:52.000000000 -0600
> +++ /Users/jsw/lib/python/matplotlib/image.py   2006-06-02 
> 17:05:24.000000000 -0600
> @@ -127,8 +127,10 @@
>             im.flipud_in()
> 
>         im.set_bg( *bg)
> -        im.is_grayscale = (self.cmap.is_gray() and
> -                           len(self._A.shape) == 2)
> +        if len(self._A.shape) == 2:
> +            im.is_grayscale = self.cmap.is_gray()
> +        else:
> +            im.is_grayscale = False
> 
>         im.set_interpolation(self._interpd[self._interpolation])
> 
> 
> -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
> 
> 
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

Hi all:

It looks like one can no longer plot an array of RGBA values in imshow - 
I suspect this is a consequence of the recent changes to the way colors 
are handled.  For example

from pylab import *
# make a random rgba matrix
rgba = ones((64,64,4),'f')
for k in range(3):
   rgba[:,:,k] = rand(64,64).astype('f')
imshow(rgba)
show()

works in 0.87.2, but fails with

Traceback (most recent call last):
  File "/Users/jsw/lib/python/matplotlib/backends/backend_gtk.py", line 
283, in expose_event
    self._render_figure(self._pixmap, w, h)
  File "/Users/jsw/lib/python/matplotlib/backends/backend_gtkagg.py", 
line 72, in _render_figure
    FigureCanvasAgg.draw(self)
  File "/Users/jsw/lib/python/matplotlib/backends/backend_agg.py", line 
389, in draw
    self.figure.draw(renderer)
  File "/Users/jsw/lib/python/matplotlib/figure.py", line 531, in draw
    for a in self.axes: a.draw(renderer)
  File "/Users/jsw/lib/python/matplotlib/axes.py", line 991, in draw
    im.draw(renderer)
  File "/Users/jsw/lib/python/matplotlib/image.py", line 184, in draw
    im = self.make_image()
  File "/Users/jsw/lib/python/matplotlib/image.py", line 130, in make_image
    im.is_grayscale = (self.cmap.is_gray() and
  File "/Users/jsw/lib/python/matplotlib/colors.py", line 634, in is_gray
    return (alltrue(self._lut[:,0] == self._lut[:,1])

with the latest svn.

This patch to image.py seems to fix it, but I'm not sure it's the right 
solution

--- /Users/jsw/lib/python/matplotlib/image.py.orig      2006-06-02 
17:04:52.000000000 -0600
+++ /Users/jsw/lib/python/matplotlib/image.py   2006-06-02 
17:05:24.000000000 -0600
@@ -127,8 +127,10 @@
             im.flipud_in()
 
         im.set_bg( *bg)
-        im.is_grayscale = (self.cmap.is_gray() and
-                           len(self._A.shape) == 2)
+        if len(self._A.shape) == 2:
+            im.is_grayscale = self.cmap.is_gray()
+        else:
+            im.is_grayscale = False
 
         im.set_interpolation(self._interpd[self._interpolation])


-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

Hi Jim,

Would you send me your files? I'm interested in using Qt4 myself.

Thanks,
Darren

On Wednesday 31 May 2006 11:51, James Amundson wrote:
> Hello,
>
> I have ported the existing Qt(3) backend to Qt4. Qt4 is a substantial
> change from Qt3; the Python bindings for Qt have also changed
> substantially. Since the two versions of Qt are likely to coexist for at
> least a while, I think it makes sense to have a separate Qt4 backend.
>
> How do I go about contributing my Qt4 backend? I have three files:
> backend_qt4.py, backend_qt4agg.py  and embedding in qt4.py.
>
> Best,
> Jim Amundson
>
>
>
> -------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

-- 
Darren S. Dale, Ph.D.
Cornell High Energy Synchrotron Source
Cornell University
200L Wilson Lab
Rt. 366 & Pine Tree Road
Ithaca, NY 14853

dd...@co...
office: (607) 255-9894
fax: (607) 255-9001

Hello,

I have ported the existing Qt(3) backend to Qt4. Qt4 is a substantial
change from Qt3; the Python bindings for Qt have also changed
substantially. Since the two versions of Qt are likely to coexist for at
least a while, I think it makes sense to have a separate Qt4 backend.

How do I go about contributing my Qt4 backend? I have three files:
backend_qt4.py, backend_qt4agg.py  and embedding in qt4.py.

Best,
Jim Amundson

Hi everyone,

Here is a script that creates a graph with a y-axis break. I went with a 
suggestion from Darren to use two axes and draw a break symbol in between 
them. The advantage of two axes is that you can pan them independently (plus 
it's probably easier). It shows roughly what I think it should look like, but 
I still have to improve a few things. So I have a few questions:

- how can I hide the y-ticks in the middle of the graph (so hide only the 
ticks on the top y-axis of the lower axes while leaving the ones at the 
bottom there?

- Can I somehow use a transAxes transform so the axis break symbol (now 
implemented as a LineCollection) stays in the same position when panning? Is 
a LineCollection the best choice? I tried with a Patch class, the problem is 
that the verts of this symbol are not connected.

> >>>>> "Ralf" == Ralf Gommers <r.g...@uc...> writes:
>
>     Ralf> Hi everyone, Guess no-one has a trick yet to put in an axis
>     Ralf> break. My question is now, should this not be on the goals
>     Ralf> list at least?
>
>     Ralf> If the developers think it is a good idea to implement this,
>     Ralf> I would like to have a go at it. As I'm not all that
>     Ralf> familiar with the matplotlib internals it would be great if
>     Ralf> someone has any ideas on how to go about it.
>
> This is not possible and is not easy.  Currently, we don't even have
> independent control of the lines that surround the white axes box (the
> left and right y-axis lines and the upper and lower x-axis lines.  It
> is a long-standing wish to be able to control these independently of
> the axes box, and this would be a good place for you to start.  See
> axis.py and axes.py.
>
> JDH

Thanks,
Ralf

Jordan,

I committed the quiver patch with a slight modification, no functional change.

Eric

----- Original Message -----
From: Jordan Dawe <jdawe@u.washington.edu>
Date: Tuesday, May 30, 2006 12:39 pm
Subject: [matplotlib-devel] Quiver Patch
To: matplotlib development list <mat...@li...>

> 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
> 

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 <jdawe@u.washington.edu>
Date: Tuesday, May 30, 2006 12:39 pm
Subject: [matplotlib-devel] Quiver Patch
To: matplotlib development list <mat...@li...>

> 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
> 

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

John Hunter wrote:
> Hope this helps,
> JDH
>   

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

Jordan

>>>>> "Jordan" == Jordan Dawe <jdawe@u.washington.edu> writes:
    Jordan> Cool, that makes sense.  Another question: what plot types
    Jordan> generate 10000 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