matplotlib-devel Mailing List for matplotlib (Page 3)

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

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