matplotlib-devel Mailing List for matplotlib

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