matplotlib-devel Mailing List for matplotlib (Page 4)

John Hunter wrote:
> Jordan> I think what we need is to set the coordinate transform to
> Jordan> be in and absolute, instead of relative, coordinate
> Jordan> system,
> This is probably what you want to do. You want to define your arrow
> in something like points, then do a rotation, and then apply one of
> the transformation offsets to place your arrow at an x,y location.
This sounds a lot like what a I did a while ago (following suggested 
code form JDH), and posted here. My intent is to clean it up so that it 
can get included in MPL, but I haven't had the chance. Meanwhile, here 
it is again. Use it as you will.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
 		
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

>>>>> "Jordan" == Jordan Dawe <jdawe@u.washington.edu> writes:
 Jordan> Here's a reference talking about the different coordinate
 Jordan> systems accessible in matplotlib:
 Jordan> http://www.scipy.org/Cookbook/Matplotlib/Transformations
 Jordan> I think what we need is to set the coordinate transform to
 Jordan> be in and absolute, instead of relative, coordinate
 Jordan> system, or to build one ourselves. But I don't know
 Jordan> enough about matplotlib's internals to know if this is
 Jordan> right. Comments?
This is probably what you want to do. You want to define your arrow
in something like points, then do a rotation, and then apply one of
the transformation offsets to place your arrow at an x,y location.
Note there is a bug in some version of matplotlib in the affine code
which is fixes in SVN -- this arrow should have it's base at 0.5, 0.5
and be pointing NW and measure 2 inches from base to tip. The arrow
size is independent of zoom and figure window size, which may or may
not be desirable....
from matplotlib.transforms import Affine, Value, zero
from matplotlib.patches import Polygon
from pylab import figure, show, nx
fig = figure()
ax = fig.add_subplot(111, xlim=(0,1), ylim=(0,1), autoscale_on=False)
sx = 144/72.*fig.dpi.get() # 2 inches
sy = 144/72.*fig.dpi.get()
theta = 45*nx.pi/180.
# arrow drawn in pixels
trans = Affine(
 Value(sx*nx.cos(theta)),
 Value(sx*nx.sin(theta)),
 Value(-sy*nx.sin(theta)),
 Value(sy*nx.cos(theta)),
 zero(),
 zero())
verts = [
 (-0.05,0.75),
 (0, 1.),
 (0.05,0.75),
 (0.05,0),
 (-0.05,0),
 ]
# offset in data coords
trans.set_offset((0.5, 0.5), ax.transData)
poly = Polygon(verts, transform=trans)
ax.add_patch(poly)
show()

Gary Ruben wrote:
> Hi Jordan,
> When I zoom, if the x and y zooms are not locked you will still get 
> the problem you mention with my modified arrows. They're still just 
> patches locked to the current x and y coordinates.
> I've attached my modified Arrow() in case you want to look at it. It 
> requires a change to quiver in axes.py too to add the arrowstyle 
> parameter and pass it through but you can just ignore that stuff and 
> remove the arrowstyle references if you want to try it out. The 
> changes just keep the arrow head length fixed and adjust the length of 
> the arrow shaft until it gets so short that it becomes necessary to 
> start scaling down the width in proportion with the length (I'm not 
> sure if that makes sense).
> Gary
That makes a lot of sense. I've just been changing this line:
 arrow[:,1] *= width
to
 arrow[:,1] *= L*width
but this, of course, ends up with some weird looking arrows at the ends 
of the data range
The main problem with quiver as it currently exists is that, if say you 
plot:
quiver(ones([1,2]),ones([1,2]))
You end up with arrows that are twice as tall as they are wide, instead 
of 45 degree arrows. This is definitely a bug, not a feature.
Here's a reference talking about the different coordinate systems 
accessible in matplotlib:
http://www.scipy.org/Cookbook/Matplotlib/Transformations
I think what we need is to set the coordinate transform to be in and 
absolute, instead of relative, coordinate system, or to build one 
ourselves. But I don't know enough about matplotlib's internals to know 
if this is right. Comments?
Jordan

Hi Jordan,
When I zoom, if the x and y zooms are not locked you will still get the 
problem you mention with my modified arrows. They're still just patches 
locked to the current x and y coordinates.
I've attached my modified Arrow() in case you want to look at it. It 
requires a change to quiver in axes.py too to add the arrowstyle 
parameter and pass it through but you can just ignore that stuff and 
remove the arrowstyle references if you want to try it out. The changes 
just keep the arrow head length fixed and adjust the length of the arrow 
shaft until it gets so short that it becomes necessary to start scaling 
down the width in proportion with the length (I'm not sure if that makes 
sense).
Gary
Jordan Dawe wrote:
<snip>
> Wow, serendipitously I'm working on exactly the same thing at the 
> moment. Question: when you zoom, do you ensure that the x-direction in 
> your window is the same length as the y-direction? My current theory on 
> this is the distorted arrows are the result of quiver measuring 
> everything in the x-y space of the plot, instead of in absolute terms. 
> Setting axis('equal') or axis('scaled') seems to improve the arrow 
> appearance...
> 
> Jordan

Hi John,
I'll have a look at this over the weekend.
 From the link and example you provided I'm not yet sure that subpixel 
rendering is the problem, but it could well be - What I'm getting is the 
vertices displaced away from the expected position by quite a way, but 
I'll see if the patch you made is at the Python level, in which case I 
can try it easily, or if at the C level, it may be time to try my Ubuntu 
installation out and finally learn to build from source.
thanks,
Gary

>>>>> "Gary" == Gary Ruben <gr...@bi...> writes:
 Gary> I've been rewriting the Arrow class in patches.py to improve
 Gary> the look of quiver plots and am getting generally good
 Gary> results. The problems with current quiver plots are that
 Gary> arrows representing very small values are scaled along their
 Gary> length but not in width and also that arrowheads are not of
 Gary> a constant size. I have addressed both of these problems and
 Gary> getting results much more like Matlab quiver plots
 Gary> now. However, now that I am scaling arrow patches down to
 Gary> very small sizes, I see weird shaped arrows at some zoom
 Gary> levels but when I zoom in close enough to see the shape
 Gary> properly they look nicely formed. Is there a known problem,
 Gary> perhaps with Agg doing some fancy truncation in order to
 Gary> achieve good speed, where patches are distorted if their
 Gary> vertices are very close together at a particular
 Gary> magnification? I can provide code and graphic examples if it
 Gary> would help.
My guess is that this has something to do with subpixel rendering, and
it has cropped up in a number of circumstances. Unfortunately, I
don't know of an easy answer. If you tell agg to draw a line from 0,0
to 1,1, the line will look different than a line from .5,.5 to 1.5,1.5
See
http://antigrain.com/tips/line_alignment/line_alignment.agdoc.html#PAGE_LINE_ALIGNMENT
One way to confirm that this is your problem is to turn antialiasing
off
 patch.set_antialiased(False)
but I just noticed that the agg draw_polygon method does not respect
the aa setting, so I just committed changes to svn to fix this. Do
you have access to svn?
With svn in the example below, the green polygon should look more
jaggy than the yellow one. My guess is that this weirdness for small
arrows will go away with antialiasing off, but then you will have
crappy, aliased arrows. Not sure what the right answer is...
from matplotlib.patches import RegularPolygon
from pylab import figure, show
p1 = RegularPolygon((1,1), 5, antialiased=True, facecolor='yellow', linewidth=5)
p2 = RegularPolygon((0,0), 5, antialiased=False, facecolor='green', linewidth=5, alpha=0.5)
fig = figure()
ax = fig.add_subplot(111, xlim=(-6,6), ylim=(-6,6), autoscale_on=False)
ax.add_patch(p1)
ax.add_patch(p2)
show()
JDH

Gary Ruben wrote:
> I've been rewriting the Arrow class in patches.py to improve the look 
> of quiver plots and am getting generally good results. The problems 
> with current quiver plots are that arrows representing very small 
> values are scaled along their length but not in width and also that 
> arrowheads are not of a constant size. I have addressed both of these 
> problems and getting results much more like Matlab quiver plots now. 
> However, now that I am scaling arrow patches down to very small sizes, 
> I see weird shaped arrows at some zoom levels but when I zoom in close 
> enough to see the shape properly they look nicely formed. Is there a 
> known problem, perhaps with Agg doing some fancy truncation in order 
> to achieve good speed, where patches are distorted if their vertices 
> are very close together at a particular magnification? I can provide 
> code and graphic examples if it would help.
Wow, serendipitously I'm working on exactly the same thing at the 
moment. Question: when you zoom, do you ensure that the x-direction in 
your window is the same length as the y-direction? My current theory on 
this is the distorted arrows are the result of quiver measuring 
everything in the x-y space of the plot, instead of in absolute terms. 
Setting axis('equal') or axis('scaled') seems to improve the arrow 
appearance...
Jordan

I've been rewriting the Arrow class in patches.py to improve the look of 
quiver plots and am getting generally good results. The problems with 
current quiver plots are that arrows representing very small values are 
scaled along their length but not in width and also that arrowheads are 
not of a constant size. I have addressed both of these problems and 
getting results much more like Matlab quiver plots now. However, now 
that I am scaling arrow patches down to very small sizes, I see weird 
shaped arrows at some zoom levels but when I zoom in close enough to see 
the shape properly they look nicely formed. Is there a known problem, 
perhaps with Agg doing some fancy truncation in order to achieve good 
speed, where patches are distorted if their vertices are very close 
together at a particular magnification? I can provide code and graphic 
examples if it would help.
Gary R.

Robert Hetland wrote:
> 
> On May 15, 2006, at 2:32 PM, Eric Firing wrote:
> 
>> there is a lengthy chunk of docstring explaining that if you expect 
>> x,y to be row,column, you are wrong!
>>
> 
> I think that most people who have used matlab, netcdf, etc. expect 
> things to be 'backwards,' like C instead 'forwards' like fortran. I 
> always use a convention like var[time, z, y, x] which seems to work 
> nicely with things like sum and mean (which operate on the first axis by 
> default for time integrals and averages), with broadcast arrays (for 
> multiplying by dx and dy, which for me are typically only functions of x 
> and y), and, of course, with pcolor!
> 
> Should this way of thinking be put into an example? Into the MPL 
> documentation? Or, just let people figure it out naturally?
Rob,
Sounds to me like something you might want to put on one of the wikis.
I have tended not to think of the x,y order in terms of storage order; I 
just naturally think of coordinates as x,y,z, and indices as i,j,k, and 
so it seems natural for x to correspond to i, etc. This is math 
notation, not computer science. I suspect this is the same thing that 
trips up other people encountering the x-is-column-number convention in 
pcolor, hence the need for documentation, and possibly a friendly option 
for specifying the intended order. I also suspect that the reason 
Matlab uses its present convention has nothing to do with storage 
order--Matlab started out in Fortran, and uses Fortran conventions--but 
rather with the way a matrix is written, with the second index 
increasing across the page from left to right.
Eric

I'm trying to change the fontsize of a legend:
from pylab import *
plot([1,2],[1,2],[1,2],[2,3])
l=legend()
# this doesnt work:
l.fontsize=20
draw()
# I think this should change the fontsize of the 
# first legend entry, but it changes both of them:
t=l.get_texts()
t[0].set_fontsize(20)
Also, is it possible to modify the layout of the legend entries, like the 
spacing between them (l.pad only changes the space between the entries and 
the frame) and the orientation (horizontal instead of vertical, or perhaps a 
table layout)?
I'm using svn-2398.
Thanks,
Darren

On May 15, 2006, at 2:32 PM, Eric Firing wrote:
> there is a lengthy chunk of docstring explaining that if you expect 
> x,y to be row,column, you are wrong!
I think that most people who have used matlab, netcdf, etc. expect 
things to be 'backwards,' like C instead 'forwards' like fortran. I 
always use a convention like var[time, z, y, x] which seems to work 
nicely with things like sum and mean (which operate on the first axis 
by default for time integrals and averages), with broadcast arrays 
(for multiplying by dx and dy, which for me are typically only 
functions of x and y), and, of course, with pcolor!
Should this way of thinking be put into an example? Into the MPL 
documentation? Or, just let people figure it out naturally?
-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

Rob,
I agree, what you propose is logical and desirable. I think the 
implementation would be essentially a matter of using meshgrid 
internally when needed, or a piece of meshgrid for your single-vector 
case. I don't think there will be any more efficient way to do it at 
present. In the future, when we have only numpy to deal with, and when 
we are doing a grand unification of pcolor-like plotting methods, then 
perhaps things can be arranged so that even internally the x and y don't 
have to be expanded out.
In the meantime, I can try to make a simple version of this, while 
factoring common functionality out of pcolor and pcolormesh.
A related idea that I might want to try at the same time is a kwarg to 
control the orientation, so that x,y can correspond to row, column; as 
it is, there is a lengthy chunk of docstring explaining that if you 
expect x,y to be row,column, you are wrong!
John,
Can we simply remove pcolor_classic now? Or are there circumstances 
under which it is still needed?
Eric
Robert Hetland wrote:
> 
> 
> I would like to propose expanding the inputs of pcolor to take 
> vectors. Often, you have x and y independent (seperable), and you 
> don't want to go on constructing an x array of redundant values. 
> Actually, in NumPy it is not straightforward to do this with resize if 
> your variable is in the first dimension like time. This is because 
> NumPy makes heavy use of array broadcasting, so that you don't need to 
> drag around all that redundant data.
> 
> I realize that there is meshgrid, but I only use it for plotting 
> (because of array broadcasting), and only with two vectors (see the 
> second example below). I think MPL would benifit from following the 
> spirit of array broadcasting, and make it such that:
> 
> x = arange(10)
> y = arange(30)
> z = rand(30,10)
> pcolor (x, y, z)
> 
> will work as expected. Perhaps, we could require a NewAxis in the 
> right places, but it would also make sense without. We could also 
> consider the case of just one vector. Consider
> 
> x,y = meshgrid(arange(10), arange(30))
> y = y + random.normal(size=y.shape)
> z = random.random(y.shape)
> pcolor (x, y, z)
> # but x is still essentially just arange(10), so it would be nice if 
> this worked, too.
> pcolor(arange(10), y, z)
> 
> What do you all think?
> 
> -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
> 

I would like to propose expanding the inputs of pcolor to take 
vectors. Often, you have x and y independent (seperable), and you 
don't want to go on constructing an x array of redundant values. 
Actually, in NumPy it is not straightforward to do this with resize 
if your variable is in the first dimension like time. This is 
because NumPy makes heavy use of array broadcasting, so that you 
don't need to drag around all that redundant data.
I realize that there is meshgrid, but I only use it for plotting 
(because of array broadcasting), and only with two vectors (see the 
second example below). I think MPL would benifit from following the 
spirit of array broadcasting, and make it such that:
x = arange(10)
y = arange(30)
z = rand(30,10)
pcolor (x, y, z)
will work as expected. Perhaps, we could require a NewAxis in the 
right places, but it would also make sense without. We could also 
consider the case of just one vector. Consider
x,y = meshgrid(arange(10), arange(30))
y = y + random.normal(size=y.shape)
z = random.random(y.shape)
pcolor (x, y, z)
# but x is still essentially just arange(10), so it would be nice if 
this worked, too.
pcolor(arange(10), y, z)
What do you all think?
-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

Eric Firing wrote:
> Jeff,
>
>
>> Playing around with it a bit with I found that using a format string 
>> in the format keyword causes an exception:
> ...
>>
>> Changing 'FormatStringFormatter' to 'FormatStrFormatter' in 
>> colorbar.py seems to fix it.
>
> Fixed, thanks. I thought I had tested that, but...
>
>>
>> Also, the docs suggest that the ticks keyword can be a list, but if I 
>> use for example
>>
>> colorbar(ticks=[-1.0,0,1.0])
>>
>> I don't get what I expect. In fact, it seems to use the default tick 
>> locations no matter what assign to ticks (a list or a ticker object, 
>> such as MultipleLocator(4)). Am I mis-interpreting the docstrings?
>
> It was working as you expected for images but not for contours. Now 
> that is fixed also.
>
> Eric
Excellent, thanks Eric!
-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

Jeff,
> Playing around with it a bit with I found that using a format string in 
> the format keyword causes an exception:
...
> 
> Changing 'FormatStringFormatter' to 'FormatStrFormatter' in colorbar.py 
> seems to fix it.
Fixed, thanks. I thought I had tested that, but...
> 
> Also, the docs suggest that the ticks keyword can be a list, but if I 
> use for example
> 
> colorbar(ticks=[-1.0,0,1.0])
> 
> I don't get what I expect. In fact, it seems to use the default tick 
> locations no matter what assign to ticks (a list or a ticker object, 
> such as MultipleLocator(4)). Am I mis-interpreting the docstrings?
It was working as you expected for images but not for contours. Now 
that is fixed also.
Eric

Eric Firing wrote:
> I made a few modifications to the new colorbar, so part of my previous 
> message no longer applies. If the new colorbar finds kwargs from 
> colorbar_classic, it issues a warning and then proceeds to call 
> colorbar_classic. This should keep most old code working as before.
>
> Eric
>
Eric: Thanks for all your hard work! Looks like it should make 
colorbar much more flexible (and useful). 
Playing around with it a bit with I found that using a format string in 
the format keyword causes an exception:
Traceback (most recent call last):
 File "colorbar_test.py", line 10, in ?
 colorbar(format='%5.2f')
 File "/Users/jsw/lib/python/matplotlib/pylab.py", line 341, in colorbar
 ret = gcf().colorbar(mappable, cax = cax, **kw)
 File "/Users/jsw/lib/python/matplotlib/figure.py", line 676, in colorbar
 cb = cbar.Colorbar(cax, mappable, **kw)
 File "/Users/jsw/lib/python/matplotlib/colorbar.py", line 419, in __init__
 ColorbarBase.__init__(self, ax, **kw)
 File "/Users/jsw/lib/python/matplotlib/colorbar.py", line 125, in __init__
 self.formatter = ticker.FormatStringFormatter(format)
AttributeError: 'module' object has no attribute 'FormatStringFormatter
Changing 'FormatStringFormatter' to 'FormatStrFormatter' in colorbar.py 
seems to fix it.
Also, the docs suggest that the ticks keyword can be a list, but if I 
use for example
colorbar(ticks=[-1.0,0,1.0])
I don't get what I expect. In fact, it seems to use the default tick 
locations no matter what assign to ticks (a list or a ticker object, 
such as MultipleLocator(4)). Am I mis-interpreting the docstrings?
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/PSD1 FAX : (303)497-6449
325 Broadway Boulder, CO, USA 80305-3328

I made a few modifications to the new colorbar, so part of my previous 
message no longer applies. If the new colorbar finds kwargs from 
colorbar_classic, it issues a warning and then proceeds to call 
colorbar_classic. This should keep most old code working as before.
Eric

All,
I have committed a new set of colorbar code, mainly in its own file 
(colorbar.py), and renamed the originals to pylab.colorbar_classic and 
figure.colorbar_classic. All examples using colorbars that I could test 
have been modified if necessary, so that they work with the new version.
For a quick introduction, try contour_demo, contourf_demo, and image_masked.
The kwargs for the new version are quite different from the old, so this 
will cause breakage. There are several possible ways of dealing with 
this, including using rc to simply specify which version of the colorbar 
is used. I would prefer to avoid adding compatibility stuff directly to 
the new colorbar.
I think that the new colorbar has enough advantages over the old one to 
justify complete replacement as a goal.
Eric

Michael,
I think this is fixed as part of a large set of changes that I just 
committed to svn.
Eric
MICHAEL P MOSSEY wrote:
> The following script demonstrates a problem in autoscaling. Not all the data
> ends up in the window, when using set_aspect( aspect='equal',
> adjustable='datalim' ). This is using the cvs version as of a few weeks ago.
> 
> Note: This uses a closed polygon as data. The type of shape which triggers the
> bug is an asymmetical one (not symmetrical in x or y axes that is). Data which
> is symmetrical in x and y axes does not trigger the bug.
> 
> If you have questions, please copy me on reply, as I get the digest.
> 
> 
> import pylab
> 
> fig = pylab.figure( figsize = [ 8, 5 ] )
> axes = fig.add_axes( [ 0.1, 0.1, 0.8, 0.8 ] )
> axes.set_aspect( aspect='equal', adjustable='datalim' )
> 
> xs = [5.4, -6.3, -9.3, 0.5, 9.6, 5.4 ]
> ys = [8.4, 7.7, -3.6, -9.9, -2.5, 8.4 ]
> 
> axes.plot( xs, ys )
> 
> pylab.savefig( 'figure.png' )
> 
> 
> 
> 
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

I have confirmed the problem with current svn; I will work on it.
Eric
MICHAEL P MOSSEY wrote:
> The following script demonstrates a problem in autoscaling. Not all the data
> ends up in the window, when using set_aspect( aspect='equal',
> adjustable='datalim' ). This is using the cvs version as of a few weeks ago.
> 
> Note: This uses a closed polygon as data. The type of shape which triggers the
> bug is an asymmetical one (not symmetrical in x or y axes that is). Data which
> is symmetrical in x and y axes does not trigger the bug.
> 
> If you have questions, please copy me on reply, as I get the digest.
> 
> 
> import pylab
> 
> fig = pylab.figure( figsize = [ 8, 5 ] )
> axes = fig.add_axes( [ 0.1, 0.1, 0.8, 0.8 ] )
> axes.set_aspect( aspect='equal', adjustable='datalim' )
> 
> xs = [5.4, -6.3, -9.3, 0.5, 9.6, 5.4 ]
> ys = [8.4, 7.7, -3.6, -9.9, -2.5, 8.4 ]
> 
> axes.plot( xs, ys )
> 
> pylab.savefig( 'figure.png' )
> 
> 
> 
> 
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

The version I'm using is:
__version__ = '0.88'
__revision__ = '$Revision: 2251 $'
__date__ = '$Date: 2006年04月03日 07:57:51 -0700 (2006年4月03日) $'

The following script demonstrates a problem in autoscaling. Not all the data
ends up in the window, when using set_aspect( aspect='equal',
adjustable='datalim' ). This is using the cvs version as of a few weeks ago.
Note: This uses a closed polygon as data. The type of shape which triggers the
bug is an asymmetical one (not symmetrical in x or y axes that is). Data which
is symmetrical in x and y axes does not trigger the bug.
If you have questions, please copy me on reply, as I get the digest.
import pylab
fig = pylab.figure( figsize = [ 8, 5 ] )
axes = fig.add_axes( [ 0.1, 0.1, 0.8, 0.8 ] )
axes.set_aspect( aspect='equal', adjustable='datalim' )
xs = [5.4, -6.3, -9.3, 0.5, 9.6, 5.4 ]
ys = [8.4, 7.7, -3.6, -9.9, -2.5, 8.4 ]
axes.plot( xs, ys )
pylab.savefig( 'figure.png' )

Jeff Whitaker wrote:
> Jordan Dawe wrote:
>> Hi, I just wanted to thank the devs for all the work they've done. I 
>> just got my second journal article published, and all the figures 
>> were generated using matplotlib. I put a note in the 
>> acknowledgements to that effect, for some cheap advertising.
>>
>> Here's a link to the pdf if you're interested, but you (or your U) 
>> needs a Geophysical Research Letters subscription to access it.
>>
>> http://www.agu.org/journals/gl/gl0609/2006GL025784/2006GL025784.pdf
>>
>> Thanks again.
>>
>> Jordan
>>
> Thanks for that, Jordan. Nice job. I'm curious, did you use basemap 
> for the maps? 
> -Jeff
>
No, I just did a contourf of the model's 'land' field.
Jordan

Jordan Dawe wrote:
> Hi, I just wanted to thank the devs for all the work they've done. I 
> just got my second journal article published, and all the figures were 
> generated using matplotlib. I put a note in the acknowledgements to 
> that effect, for some cheap advertising.
>
> Here's a link to the pdf if you're interested, but you (or your U) 
> needs a Geophysical Research Letters subscription to access it.
>
> http://www.agu.org/journals/gl/gl0609/2006GL025784/2006GL025784.pdf
>
> Thanks again.
>
> Jordan
>
Thanks for that, Jordan. Nice job. I'm curious, did you use basemap for the maps? 
-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, I just wanted to thank the devs for all the work they've done. I 
just got my second journal article published, and all the figures were 
generated using matplotlib. I put a note in the acknowledgements to 
that effect, for some cheap advertising.
Here's a link to the pdf if you're interested, but you (or your U) needs 
a Geophysical Research Letters subscription to access it.
http://www.agu.org/journals/gl/gl0609/2006GL025784/2006GL025784.pdf
Thanks again.
Jordan