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