matplotlib-devel Mailing List for matplotlib (Page 468)

How about 'plots'?  (i.e., a bunch of plot commands)

Perhaps this could also be the function that loops through multiple =20
lines.  For example in matlab you can do

plot (x, y)
plot (x', y')

to plot out a grid -- the columns (or is it the rows..) are looped =20
through inside the plot command.  Is this the sort of thing you have =20
in mind for the new 'parplot' command?

-Rob

On Jun 14, 2006, at 1:06 AM, Ga=EBl Varoquaux wrote:

> On Tue, Jun 13, 2006 at 05:33:57PM +0200, Ga=EBl Varoquaux wrote:
>>     I find that "parplot" is not a great name for such a function, =20=

>> but I
>> cannot think of a better one. Maybe the list will have better ideas.
>
>     Talking to a friend we came up with a name like "pathcolor", or
> "pathplot".
>
> 	Ga=EBl
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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

On Tue, Jun 13, 2006 at 05:33:57PM +0200, Ga=EBl Varoquaux wrote:
>     I find that "parplot" is not a great name for such a function, but =
I
> cannot think of a better one. Maybe the list will have better ideas.

    Talking to a friend we came up with a name like "pathcolor", or
"pathplot".

	Ga=EBl

Robert,

Thanks for the feedback.  Comments are below.  I think I addressed some 
items over the weekend, so the version in svn should work better than 
the one you tested, assuming you tested the original one I sent out as a 
diff.

Robert Hetland wrote:
> 
> Eric-
> 
> I had a chance to play around with the new quiver this morning.  Here  
> are some thoughts:
> 
> 1. I read that somebody thought it was a bit slow, but this is not my  
> experience.  I tried to quiver my model data (128x128 with masking),  
> and it rendered in a few seconds.  I tried to look at images with  more 
> arrows, but I could not actually see the arrows with so many  points.  
> In my experience you can't put more than about O(100000)  (i.e., about 
> 100x100) arrows on a figure and have it make any sense  anyways.
> 
> 2.  It seems to handle masking fine.  I gave it masked arrays and  
> arrays with nans (it complained a bit about the masked array, but  
> rendered anyways).  This is key for me.
> 

Interesting.  I did nothing to explicitly deal with masked arrays or 
nans, so how well this works may be backend-dependent and/or platform 
dependent.  If this turns out to be a problem, I can put in more 
explicit handling of masks and nans, but it is likely to add overhead.

Question: should handling of masks apply to all input arrays, or is it 
enough to have it apply to U, V, and C?  It doesn't matter so much for 
Quiver, but it is one of the differences between pcolor and 
pcolormesh--support of masked X, Y complicates the former and might be 
hard to add to the latter.  I hope it is unnecessary.

> 3.  It handles colors nicely, but there is no apparent way to set the  
> color limits. Perhaps adding vmin and vmax as kwargs (matching  pcolor) 
> would make some sense.

This brings up a more general design question: when should functionality 
like this be added via kwargs versus other mechanisms?  It would be nice 
to have more uniformity among classes and functions, so that the general 
strategy could be documented once for a whole bunch of functions, 
instead of being repeated, with variations, for each.  This would go 
along with better factoring out of chunks of functionality.  In the 
absence of a big push, all this is going to have to happen piecemeal if 
at all, and complicated by the demands of backwards compatibility.

Returning to the specific question, however, I left vmin and vmax out to 
keep things simple, with the idea that there are other standard ways of 
setting them: via an explicit norm kwarg, via the clim  method of any 
scalar mappable (which the Quiver is, since it inherits from 
PolyCollection), and via the pylab clim command.  If there is a 
consensus that scalar mappables should uniformly support the vmin and 
vmax kwargs directly, then I don't mind adding that.  I can see the 
argument for uniformity, given that this is common among scalar 
mappables.  Probably it could be factored out by inclusion in 
ScalarMappable.__init__.


> 
> 4.  I *really* like how the arrows get gray (and don't try to render  at 
> a whole pixel) when they get small.  I agree with the other person  that 
> it might be nice to have a  small dot to indicate zero  velocity.  No 
> dot should be rendered *ever* for values masked or  NaNed, however.
> 

The graying is a function of the backend--specifically, whether 
rendering is antialiased.

The optional dot (actually a hexagon) for arrows below a threshold size 
is in svn, one of the changes I made over the weekend.

> 5. It's a bit of a pain to find values of scale and width that work  
> well, and quiver doesn't seem to make very good choices by default.   I 
> don't think this is a big deal, but rather simply the price of the  
> added functionality.  Making some more intelligent default choices  
> might not be a bad idea, though.  In particular, smaller arrows when  
> there are more arrows to be rendered would be a good place to start.
> 

I changed the autoscaling so that both the length scale and the shaft 
width (and therefore the head size, which scales with shaft width) vary 
with the square root of the number of arrows, but with limits to prevent 
arrows from getting too large and fat or too small and thin.  So I think 
you will find the svn version much improved in this regard.



> Some ideas for future work:
> 
> 1. I'm pretty happy with the polygons, but it would be nice to have  
> line collections instead.  This would also facilitate my next idea:
> 

Not "line collections instead", but "in addition": the functionality and 
appearance are very different with polygons than with lines.  I think I 
can add a line alternative with only a little extra code, but I won't 
even look at it again until this weekend, at the very earliest.

> 2. I would love to have a 'curly vector' tool.  However, I'm not sure  
> how much to put into the curly_quiver package, and how much work must  
> be done by the user.  I think that at a minimum, it would be nice to  
> give curly lines (i.e., an additional dimension to u and v)that have  
> arrows on the end of them, and leave it to the user to define what  
> those lines are somehow.  If these lines could change color along  their 
> track, then it would be the best thing ever made!

You can make curly lines with mapped colors using a LineCollection 
(recent change: it now inherits from ScalarMappable).  Curly_quiver 
sounds like quite a different animal, though, and potentially much more 
difficult to do well; I don't think there would be much overlap with the 
present code in quiver, or with the code even after I add the line version.

Eric

With the latest svn matplotlib and numpy 0.9.8 I'm now getting:

Python 2.4.3 (#1, Mar 30 2006, 13:31:07)
[GCC 4.0.1 (Apple Computer, Inc. build 5247)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> import pylab
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/Users/jsw/lib/python/pylab.py", line 1, in ?
    from matplotlib.pylab import *
  File "/Users/jsw/lib/python/matplotlib/pylab.py", line 196, in ?
    import cm
  File "/Users/jsw/lib/python/matplotlib/cm.py", line 5, in ?
    import colors
  File "/Users/jsw/lib/python/matplotlib/colors.py", line 33, in ?
    from numerix import array, arange, take, put, Float, Int, where, \
  File "/Users/jsw/lib/python/matplotlib/numerix/__init__.py", line 66, in ?
    import numpy.oldnumeric as numpy
ImportError: No module named oldnumeric

With numpy 0.9.8 I can do

from numpy.core import oldnumeric

but not

from numpy import oldnumeric.


I suppose this is a consequence of Travis's numerix commits yesterday - 
is the latest numpy svn now required?


-Jeff

-- 
Jeffrey S. Whitaker         Phone  : (303)497-6313
Meteorologist               FAX    : (303)497-6449
NOAA/OAR/PSD  R/PSD1        Email  : Jef...@no...
325 Broadway                Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg

On Tue, Jun 13, 2006 at 09:21:44AM -0500, John Hunter wrote:
> I'm not at all opposed to making a helper function like scatter to plot
> parametric lines with colormaps, but I don't think "plot" is the right
> vehicle, since it returns a Line2d, not a LineCollection, and since it
> is already heavily overloaded.  parplot? =20

    I think having a helper function is a good idea. Not only does it
help the newcomer, but it also allows the oldtimer to write shorter and
more readable code.

    I find that "parplot" is not a great name for such a function, but I
cannot think of a better one. Maybe the list will have better ideas.

    Ga=EBl

Eric-

I had a chance to play around with the new quiver this morning.  Here  
are some thoughts:

1. I read that somebody thought it was a bit slow, but this is not my  
experience.  I tried to quiver my model data (128x128 with masking),  
and it rendered in a few seconds.  I tried to look at images with  
more arrows, but I could not actually see the arrows with so many  
points.  In my experience you can't put more than about O(100000)  
(i.e., about 100x100) arrows on a figure and have it make any sense  
anyways.

2.  It seems to handle masking fine.  I gave it masked arrays and  
arrays with nans (it complained a bit about the masked array, but  
rendered anyways).  This is key for me.

3.  It handles colors nicely, but there is no apparent way to set the  
color limits. Perhaps adding vmin and vmax as kwargs (matching  
pcolor) would make some sense.

4.  I *really* like how the arrows get gray (and don't try to render  
at a whole pixel) when they get small.  I agree with the other person  
that it might be nice to have a  small dot to indicate zero  
velocity.  No dot should be rendered *ever* for values masked or  
NaNed, however.

5. It's a bit of a pain to find values of scale and width that work  
well, and quiver doesn't seem to make very good choices by default.   
I don't think this is a big deal, but rather simply the price of the  
added functionality.  Making some more intelligent default choices  
might not be a bad idea, though.  In particular, smaller arrows when  
there are more arrows to be rendered would be a good place to start.

Some ideas for future work:

1. I'm pretty happy with the polygons, but it would be nice to have  
line collections instead.  This would also facilitate my next idea:

2. I would love to have a 'curly vector' tool.  However, I'm not sure  
how much to put into the curly_quiver package, and how much work must  
be done by the user.  I think that at a minimum, it would be nice to  
give curly lines (i.e., an additional dimension to u and v)that have  
arrows on the end of them, and leave it to the user to define what  
those lines are somehow.  If these lines could change color along  
their track, then it would be the best thing ever made!

-Rob.

-----
Rob Hetland, Assistant Professor
Dept of Oceanography, Texas A&M University
p: 979-458-0096, f: 979-845-6331
e: he...@ta..., w: http://pong.tamu.edu

>>>>> "Ga=EBl" =3D=3D Ga=EBl Varoquaux <gae...@no...> wr=
ites:

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

Eric recently updated LineCollection to inherit from ScalarMappable
(in mpl 0.87.3) which means you can pass it a colormap instance.
Perhaps we should update the wiki example to reflect this.  I'm not at
all opposed to making a helper function like scatter to plot
parametric lines with colormaps, but I don't think "plot" is the right
vehicle, since it returns a Line2d, not a LineCollection, and since it
is already heavily overloaded.  parplot? =20

JDH

	Hi,

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

	Regards,

    Ga=EBl

Darren Dale wrote:

>On Monday 12 June 2006 11:02, Darren Dale wrote:
>  
>
>>I can confirm this, using mpl svn2473 and numpy svn2603.
>>
>>On Monday 12 June 2006 03:08, Nils Wagner wrote:
>>    
>>
>>>matplotlib data path
>>>/usr/lib64/python2.4/site-packages/matplotlib/mpl-data
>>>$HOME=/home/nwagner
>>>loaded rc file /home/nwagner/matplotlibrc
>>>matplotlib version 0.87.3
>>>verbose.level helpful
>>>interactive is False
>>>platform is linux2
>>>numerix numpy 0.9.9.2603
>>>Traceback (most recent call last):
>>>  File "cascade.py", line 3, in ?
>>>    from pylab import plot, show, xlim, ylim, subplot, xlabel, ylabel,
>>>title, legend,savefig,clf,scatter
>>>  File "/usr/lib64/python2.4/site-packages/pylab.py", line 1, in ?
>>>    from matplotlib.pylab import *
>>>  File "/usr/lib64/python2.4/site-packages/matplotlib/pylab.py", line
>>>198, in ?
>>>    import mlab  #so I can override hist, psd, etc...
>>>  File "/usr/lib64/python2.4/site-packages/matplotlib/mlab.py", line 74,
>>>in ?
>>>    from numerix.fft import fft, inverse_fft
>>>ImportError: cannot import name inverse_fft
>>>      
>>>
>
>It looks like NumPy renamed inverse_fft to ifft. Adding the following to the 
>numpy block in lib/matplotlib/numerix/fft/__init__.py lets me run pylab 
>again:
>
>    from numpy.dft import *
>    inverse_fft = ifft 
>  
>
The ifft name has been there for a while.  Recently though, I moved the 
old interface to numpy.dft.old (similar to what was done for linalg).   
This is in an effort to distinguish between backwards_compatible names 
and "currently used" names.

I've committed a change that imports all the old names to the numerix 
interface.  I didn't see any use besides inverse_fft, but I figure 
others who use the numerix interface may have been using more names so I 
imported all of them.

Sorry, I didn't catch this sooner.

-Travis

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:

    Eric> I don't understand how event handling works, so I am
    Eric> wondering: can we indeed be sure that window resize etc
    Eric> events are being blocked inside the freeze/thaw block in
    Eric> Axes.draw()?  Are they blocked inside the entire draw
    Eric> method?  What controls when a mouse event gets processed?

As far as I understand, GTK and other GUIs operate in a single thread,
which means all the events they generate will be handled sequentially
and not in parallel.  Thus we can be sure that a call to  draw will
complete before the next one is called.  But someone correct me if I'm
wrong...

What we try to avoid is having too many of these events pile up, so
for example if a draw operation is expensive, lots of them can be
queued and will be executing long after the resize is over.  To avoid
this, we use an idle draw handler in FigureCanvas.draw_idle.

JDH

John Hunter wrote:
>>>>>>"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. 

John,

I don't understand how event handling works, so I am wondering: can we 
indeed be sure that window resize etc events are being blocked inside 
the freeze/thaw block in Axes.draw()?  Are they blocked inside the 
entire draw method?  What controls when a mouse event gets processed?

Thanks.

Eric

Jeff,

I made minimal changes to my copy of basemap to support the new quiver 
and quiverkey, and to illustrate them in quiver_demo.py.  The older 
quiver is still accessible as quiver_classic. A diff against svn is 
attached.  (It includes do-nothing diffs caused by my editor's deletion 
of end-of-line whitespace when a file is saved.)  If you like, I can 
commit the changes.

There is still what I hope is a minor flaw: when the aspect ratio is 
controlled, as in basemap, it seems that the changes in rendered arrow 
width upon zooming are a bit jumpy, and the key arrow width can end up a 
bit different from the map arrow widths.  I don't think this affects the 
length, so the key is still valid (as far as I have been able to 
determine.)  I would like to improve this, but I don't think that use of 
the new quiver needs to wait for it.

Eric

On Monday 12 June 2006 11:02, Darren Dale wrote:
> I can confirm this, using mpl svn2473 and numpy svn2603.
>
> On Monday 12 June 2006 03:08, Nils Wagner wrote:
> > matplotlib data path
> > /usr/lib64/python2.4/site-packages/matplotlib/mpl-data
> > $HOME=/home/nwagner
> > loaded rc file /home/nwagner/matplotlibrc
> > matplotlib version 0.87.3
> > verbose.level helpful
> > interactive is False
> > platform is linux2
> > numerix numpy 0.9.9.2603
> > Traceback (most recent call last):
> >   File "cascade.py", line 3, in ?
> >     from pylab import plot, show, xlim, ylim, subplot, xlabel, ylabel,
> > title, legend,savefig,clf,scatter
> >   File "/usr/lib64/python2.4/site-packages/pylab.py", line 1, in ?
> >     from matplotlib.pylab import *
> >   File "/usr/lib64/python2.4/site-packages/matplotlib/pylab.py", line
> > 198, in ?
> >     import mlab  #so I can override hist, psd, etc...
> >   File "/usr/lib64/python2.4/site-packages/matplotlib/mlab.py", line 74,
> > in ?
> >     from numerix.fft import fft, inverse_fft
> > ImportError: cannot import name inverse_fft

It looks like NumPy renamed inverse_fft to ifft. Adding the following to the 
numpy block in lib/matplotlib/numerix/fft/__init__.py lets me run pylab 
again:

    from numpy.dft import *
    inverse_fft = ifft 

Should I commit this?

Darren

I can confirm this, using mpl svn2473 and numpy svn2603.

On Monday 12 June 2006 03:08, Nils Wagner wrote:
> matplotlib data path /usr/lib64/python2.4/site-packages/matplotlib/mpl-data
> $HOME=/home/nwagner
> loaded rc file /home/nwagner/matplotlibrc
> matplotlib version 0.87.3
> verbose.level helpful
> interactive is False
> platform is linux2
> numerix numpy 0.9.9.2603
> Traceback (most recent call last):
>   File "cascade.py", line 3, in ?
>     from pylab import plot, show, xlim, ylim, subplot, xlabel, ylabel,
> title, legend,savefig,clf,scatter
>   File "/usr/lib64/python2.4/site-packages/pylab.py", line 1, in ?
>     from matplotlib.pylab import *
>   File "/usr/lib64/python2.4/site-packages/matplotlib/pylab.py", line
> 198, in ?
>     import mlab  #so I can override hist, psd, etc...
>   File "/usr/lib64/python2.4/site-packages/matplotlib/mlab.py", line 74,
> in ?
>     from numerix.fft import fft, inverse_fft
> ImportError: cannot import name inverse_fft
>
>
>
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

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

Helge,

Helge Avlesen wrote:
> On 6/9/06, Eric Firing <ef...@ha...> wrote:
> 
>>Suggestions for improvements in the API or other aspects are welcome.
> 
> 
> Hi,
> an option for quiver to quickly draw thousands of simple monocolor
> arrows each constructed from e.g. 3 line segments would be useful for
> someone(like me) that uses matplotlib
> for browsing vector plots of large fields (e.g. 800x600). currently
> this is not practical
> with any of the quiver variants, as it takes minutes to render. I
> already use linecollections
> to draw high res coastlines, so a faster quiver should be feasible.

I have made some changes to facilitate this, but I have not tried to 
implement it yet.  It should be possible with only a little bit more 
code than is in quiver.py at present, but it may require figuring out a 
trick or two.  I don't want to work on it quite yet, but it does seem 
like a good idea--provided rendering LineCollections really is much 
faster than rendering PolyCollections.

> 
> another optimization could be perhaps be to arrange for numpy arrays
> to be passed directly to the drawing methods instead of the all the
> zipping and loops that currently are necessary?
> 

Quite some time ago I asked John about this, and the answer was that all 
this conversion overhead is probably not a large part of the total 
plotting time, so optimizing it may not be worth the trouble.  But I 
agree--it would seem much more natural to pass X and Y arrays around 
than to have to zip them into sequences of (x,y) tuples.

Eric

I added the ability to easily generate a key for quiver plots.  The 
function is called quiverkey(). It is illustrated in the revised 
examples/quiver_demo.py.  I also changed Axes.quiver and pylab.quiver to 
use quiver2 if possible--that is, if it seems consistent with the 
arguments that are supplied.  If not, quiver_classic is used.

Eric

On 6/9/06, Eric Firing <ef...@ha...> wrote:
> Suggestions for improvements in the API or other aspects are welcome.

Hi,
an option for quiver to quickly draw thousands of simple monocolor
arrows each constructed from e.g. 3 line segments would be useful for
someone(like me) that uses matplotlib
for browsing vector plots of large fields (e.g. 800x600). currently
this is not practical
with any of the quiver variants, as it takes minutes to render. I
already use linecollections
to draw high res coastlines, so a faster quiver should be feasible.

another optimization could be perhaps be to arrange for numpy arrays
to be passed directly to the drawing methods instead of the all the
zipping and loops that currently are necessary?

otherwise, quiver2 looks very good for final plots - good work!

Helge

They look great!  I would think a DeprecationWarning when you detect
the old usage would suffice for 1 major release cycle, hence all of
0.88.

Thanks,
     Charlie

On 6/9/06, Eric Firing <ef...@ha...> wrote:
> A reimplementation of the quiver command has been committed to svn.  It
> is temporarily accessible as "quiver2" so as not to interfere with the
> original quiver, and in examples there is a quiver2_demo.py.  The API
> differs from that of the original quiver.  See the docstring for
> details.  Since the earlier version that I sent out as a diff, I have
> removed the "C" kwarg (unnecessary, given the function signature) and
> added the "minlength" kwarg; if the rendered arrow is less than this
> length in units of the shaft width, then it is replaced with a hexagon
> of this diameter.  Also, the dpi bug that John found is fixed.
>
> Some time before the next release I would like to replace the present
> quiver with quiver2.  If necessary I can use the same trick as for
> colorbar, in which the default is the new version, but the presence of a
> kwarg exclusive to the old version triggers use of the old version with
> a deprecation warning.  I would like to be able to establish a schedule
> for actually removing such deprecated code, however.
>
> Suggestions for improvements in the API or other aspects are welcome.
>
> On my todo list are a "key" method to draw a labeled scale arrow, and an
> ellipse-drawing capability.
>
> The "scatter" command is quite similar and, like the proposed
> "ellipses", could take advantage of code presently in the Quiver class,
> so I will consider doing such a consolidation, using a base class or a
> mixin to factor out as much common functionality as possible.
>
> I have looked briefly at basemap.  It looks like quiver2 will fit in OK
> with small changes; a bit more work might be needed to support some of
> the scaling options in quiver2.  In any case, whenever quiver2 does
> replace quiver I want to make sure that basemap is ready so that the new
> quiver works well with it; for my own work, velocity vectors on maps are
> central.
>
> Eric
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

A reimplementation of the quiver command has been committed to svn.  It 
is temporarily accessible as "quiver2" so as not to interfere with the 
original quiver, and in examples there is a quiver2_demo.py.  The API 
differs from that of the original quiver.  See the docstring for 
details.  Since the earlier version that I sent out as a diff, I have 
removed the "C" kwarg (unnecessary, given the function signature) and 
added the "minlength" kwarg; if the rendered arrow is less than this 
length in units of the shaft width, then it is replaced with a hexagon 
of this diameter.  Also, the dpi bug that John found is fixed.

Some time before the next release I would like to replace the present 
quiver with quiver2.  If necessary I can use the same trick as for 
colorbar, in which the default is the new version, but the presence of a 
kwarg exclusive to the old version triggers use of the old version with 
a deprecation warning.  I would like to be able to establish a schedule 
for actually removing such deprecated code, however.

Suggestions for improvements in the API or other aspects are welcome.

On my todo list are a "key" method to draw a labeled scale arrow, and an 
ellipse-drawing capability.

The "scatter" command is quite similar and, like the proposed 
"ellipses", could take advantage of code presently in the Quiver class, 
so I will consider doing such a consolidation, using a base class or a 
mixin to factor out as much common functionality as possible.

I have looked briefly at basemap.  It looks like quiver2 will fit in OK 
with small changes; a bit more work might be needed to support some of 
the scaling options in quiver2.  In any case, whenever quiver2 does 
replace quiver I want to make sure that basemap is ready so that the new 
quiver works well with it; for my own work, velocity vectors on maps are 
central.

Eric

The main purpose of this release is to take advantage of the new aspect 
ratio handling in matplotlib 0.87.3.

Some new features have been added (new polar-centric convenience 
projections, sinusoidal projection, ability to plot land-sea masks, 
pcolormesh method), and numerous bugs were squashed.

Here is the full list of changes since 0.8.2:

           * updated for new matplotlib aspect ratio handling.
           Now maps will always have the correct aspect ratio.
           * if resolution keyword is set to None when Basemap
           instance is created, no boundary data sets are needed
           (methods to draw boundaries, like drawcoastlines, will
           raise an exception).
           * update to proj4 module - renamed pyproj to avoid
           conflicts with proj4 module from CDAT.
           * createfigure method deprecated, since maps
           will now automatically have the correct aspect ratio.
           * Added new projections Xpstere, Xplaea, Xpaeqd (where X
           can be n or s).  These are special-case, polar-centric
           versions of the stereographic, lambert azimuthal equal area
           and azimuthal equidistant projections that don't require
           you specify the lat/lon values of the lower-left and upper-right
           corners. 
           * fixed bugs in plot, scatter and mapboundary methods for
           miller, cylindrical and mercator projections.
           * 'crude' and 'low' resolution boundary datasets now installed
           by default.  basemap_data package now only needed for to get
           'intermediate' and 'high' resolution datasets.
           * moved all packages under single lib/ directory so
       setuptools' "develop" command works properly.
           * Added sinusoidal projection.
           * bilinear interpolation routines can return masked arrays with
           values outside range of data coordinates masked.
           * New examples (warpimage.py - warping an image to
           different map projections, polarmaps.py - simplified polar
           projections, garp.py - 'World According to Garp' maps).
           * pcolormesh method added.
           * drawlsmask method added for masking oceans and/or land areas.
           5 minute land-sea mask dataset added.


-Jeff

-- 
Jeffrey S. Whitaker         Phone  : (303)497-6313
Meteorologist               FAX    : (303)497-6449
NOAA/OAR/PSD  R/PSD1        Email  : Jef...@no...
325 Broadway                Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg

On 6/6/06, Charlie Moad <cw...@gm...> wrote:
> New compile to match numpy-0.9.8.
> win32-py2.4 coming tomorrow morning...
>
> http://cheeseshop.python.org/pypi/matplotlib/
> http://sourceforge.net/project/showfiles.php?group_id=80706
>
> ===============================================================
> 2006-06-06 Released 0.87.3 at revision 2432

And just to prove that ipython is wedded to mpl til death do us part:

http://scipy.net/pipermail/ipython-user/2006-June/001750.html

We put 0.7.2 of ipython out also yesterday, and it does include a
number of fixes to the threading support that pylab requires with the
WX, GTK or Qt backends.

Cheers,

f

ps - it seems the matplotlibrc file at:

http://matplotlib.sf.net/matplotlibrc

is a bit outdated:

In [1]: import matplotlib
/home/fperez/tmp/local/lib/python2.3/site-packages/matplotlib/__init__.py:947:
UserWarning: Bad val "free" on line #204
        "image.aspect : free              # free | preserve"
        in file "/home/fperez/.matplotlib/matplotlibrc"
        not a valid aspect specification

The one in the source distro is fine (I'm in the middle of updating,
so I noticed).

New compile to match numpy-0.9.8.
win32-py2.4 coming tomorrow morning...

http://cheeseshop.python.org/pypi/matplotlib/
http://sourceforge.net/project/showfiles.php?group_id=80706

===============================================================
2006-06-06 Released 0.87.3 at revision 2432

2006-05-30 More partial support for polygons with outline or fill,
           but not both.  Made LineCollection inherit from
           ScalarMappable. - EF

2006-05-29 Yet another revision of aspect-ratio handling. - EF

2006-05-27 Committed a patch to prevent stroking zero-width lines in
           the svg backend - DSD

2006-05-24 Fixed colorbar positioning bug identified by Helge
           Avlesen, and improved the algorithm; added a 'pad'
           kwarg to control the spacing between colorbar and
           parent axes. - EF

2006-05-23 Changed color handling so that collection initializers
           can take any mpl color arg or sequence of args; deprecated
           float as grayscale, replaced by string representation of
           float. - EF

2006-05-19 Fixed bug: plot failed if all points were masked - EF

2006-05-19 Added custom symbol option to scatter - JDH

2006-05-18 New example, multi_image.py; colorbar fixed to show
           offset text when the ScalarFormatter is used; FixedFormatter
           augmented to accept and display offset text. - EF

2006-05-14 New colorbar; old one is renamed to colorbar_classic.
           New colorbar code is in colorbar.py, with wrappers in
           figure.py and pylab.py.
           Fixed aspect-handling bug reported by Michael Mossey.
           Made backend_bases.draw_quad_mesh() run.- EF

2006-05-08 Changed handling of end ranges in contourf: replaced
           "clip-ends" kwarg with "extend".  See docstring for
           details. -EF

2006-05-08 Added axisbelow to rc - JDH

2006-05-08 If using PyGTK require version 2.2+ - SC

2006-04-19 Added compression support to PDF backend, controlled by
           new pdf.compression rc setting. - JKS

2006-04-19 Added Jouni's PDF backend

2006-04-18 Fixed a bug that caused agg to not render long lines

2006-04-16 Masked array support for pcolormesh; made pcolormesh support the
           same combinations of X,Y,C dimensions as pcolor does;
           improved (I hope) description of grid used in pcolor,
           pcolormesh. - EF

2006-04-14 Reorganized axes.py - EF

2006-04-13 Fixed a bug Ryan found using usetex with sans-serif fonts and
           exponential tick labels - DSD

2006-04-11 Refactored backend_ps and backend_agg to prevent module-level
           texmanager imports. Now these imports only occur if text.usetex
           rc setting is true - DSD

2006-04-10 Committed changes required for building mpl on win32
           platforms with visual studio.  This allows wxpython
           blitting for fast animations. - CM

2006-04-10 Fixed an off-by-one bug in Axes.change_geometry.

2006-04-10 Fixed bug in pie charts where wedge wouldn't have label in
           legend. Submitted by Simon Hildebrandt. - ADS

2006-05-06 Usetex makes temporary latex and dvi files in a temporary
           directory, rather than in the user's current working
           directory - DSD

2006-04-05 Apllied Ken's wx deprecation warning patch closing sf patch
           #1465371 - JDH

2006-04-05 Added support for the new API in the postscript backend.
           Allows values to be masked using nan's, and faster file
           creation - DSD

2006-04-05 Use python's subprocess module for usetex calls to
           external programs. subprocess catches when they exit
           abnormally so an error can be raised. - DSD

2006-04-03 Fixed the bug in which widgets would not respond to
           events.  This regressed the twinx functionality, so I
           also updated subplots_adjust to update axes that share
           an x or y with a subplot instance. - CM

2006-04-02 Moved PBox class to transforms and deleted pbox.py;
           made pylab axis command a thin wrapper for Axes.axis;
           more tweaks to aspect-ratio handling; fixed Axes.specgram
           to account for the new imshow default of unit aspect
           ratio; made contour set the Axes.dataLim. - EF

2006-03-31 Fixed the Qt "Underlying C/C++ object deleted" bug. - JRE

2006-03-31 Applied Vasily Sulatskov's Qt Navigation Toolbar enhancement. - JRE

2006-03-31 Ported Norbert's rewriting of Halldor's stineman_interp
           algorithm to make it numerix compatible and added code to
           matplotlib.mlab.  See examples/interp_demo.py - JDH

2006-03-30 Fixed a bug in aspect ratio handling; blocked potential
           crashes when panning with button 3; added axis('image')
           support. - EF

2006-03-28 More changes to aspect ratio handling; new PBox class
           in new file pbox.py to facilitate resizing and repositioning
           axes; made PolarAxes maintain unit aspect ratio. - EF

2006-03-23 Refactored TextWithDash class to inherit from, rather than
           delegate to, the Text class. Improves object inspection
           and closes bug # 1357969 - DSD

2006-03-22 Improved aspect ratio handling, including pylab interface.
           Interactive resizing, pan, zoom of images and plots
           (including panels with a shared axis) should work.
           Additions and possible refactoring are still likely. - EF

2006-03-21 Added another colorbrewer colormap (RdYlBu) - JSWHIT

2006-03-21 Fixed tickmarks for logscale plots over very large ranges.
           Closes bug # 1232920 - DSD

2006-03-21 Added Rob Knight's arrow code; see examples/arrow_demo.py - JDH

2006-03-20 Added support for masking values with nan's, using ADS's
           isnan module and the new API. Works for *Agg backends - DSD

2006-03-20 Added contour.negative_linestyle rcParam - ADS

2006-03-20 Added _isnan extension module to test for nan with Numeric
	   - ADS

2006-03-17 Added Paul and Alex's support for faceting with quadmesh
           in sf patch 1411223 - JDH

2006-03-17 Added Charle Twardy's pie patch to support colors=None.
           Closes sf patch 1387861 - JDH

2006-03-17 Applied sophana's patch to support overlapping axes with
           toolbar navigation by toggling activation with the 'a' key.
           Closes sf patch 1432252 - JDH

2006-03-17 Applied Aarre's linestyle patch for backend EMF; closes sf
           patch 1449279 - JDH

2006-03-17 Applied  Jordan Dawe's patch to support kwarg properties
           for grid lines in the grid command.  Closes sf patch
           1451661 - JDH

2006-03-17 Center postscript output on page when using usetex - DSD

2006-03-17 subprocess module built if Python <2.4 even if subprocess
           can be imported from an egg - ADS

2006-03-17 Added _subprocess.c from Python upstream and hopefully
           enabled building (without breaking) on Windows, although
           not tested. - ADS

2006-03-17 Updated subprocess.py to latest Python upstream and
           reverted name back to subprocess.py - ADS

2006-03-16 Added John Porter's 3D handling code

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