John,
Thanks for the clarification---and for responding so close to
the holiday!
It seems like matplotlib should track released scipy rather than scipy
svn, but I can see arguments for both sides (matplotlib cvs perhaps
should track scipy svn, but then we can't do a release until scipy
does...).
I understand the issue, and it does seem to me you should track
the release.
I know there has been some recent discussion and work on the scipy dev
list about a new package loading scheme, but am not sure what the
current status is (still in flux, finished).
At least part of it was given up on, and I believe Pearu and Travis
checked in those changes a few days ago. It does sound like it's
time for a new release, provided the scheme has settled.
For others trying to use things as they are now, the following quick
fix gets most things to work: Just change __init__.py in
site-packages/matplotlib/numerix/fft from:
elif which[0] == "scipy":
from scipy.basic.fft import *
to:
elif which[0] == "scipy":
# from scipy.basic.fft import *
from scipy.basic.fftpack import *
Do it in site-packages and not in the distribution, so your
distribution stays in sync with its CVS version. (I'm not
sure if this matters.)
I don't know if this does all that is required for pylab's fft
stuff (I only use it for plotting), but it does get *most*
examples to plot (I tried a random assortment of them).
However, a few examples do have problems, some trivial, others
perhaps not so. Some examples:
% pythonw specgram_demo.py
Traceback (most recent call last):
File "specgram_demo.py", line 24, in ?
Pxx, freqs, bins, im = specgram(x, NFFT=NFFT, Fs=Fs, noverlap=900)
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/pylab.py", line
2206, in specgram
ret = gca().specgram(*args, **kwargs)
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/axes.py", line 3379,
in specgram
window, noverlap)
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/mlab.py", line 1120,
in specgram
if x.typecode()==Complex: numFreqs = NFFT
AttributeError: 'scipy.ndarray' object has no attribute 'typecode'
scipy_core has changed how typecodes are handled so I suspect this
is an inconsistency that will survive revisions. I don't know what
else in mpl it may affect.
% pythonw boxplot_demo.py
Traceback (most recent call last):
File "boxplot_demo.py", line 17, in ?
boxplot(data)
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/pylab.py", line
1745, in boxplot
ret = gca().boxplot(*args, **kwargs)
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/matplotlib/axes.py", line 1061,
in boxplot
widths = distance * min(0.15, 0.5/distance)
ZeroDivisionError: float division
I don't know what's behind this.
% pythonw anim.py
The animated plot appears to work fine---what I could see of it!
Its window can't be brought to the front, and won't respond to
clicks on the close button. I believe this has always happened
and is unrelated to scipy; it's an OS X GUI issue (I'm using TkAgg).
%pythonw dannys_example.py
This failed for me because it is written to explicitly
use Numeric. A simple change at the top to
"import matplotlib.numerix as Numeric" has it plot fine with scipy.
Someone should check it with numarray and if it survives, make
the change.
Many other examples worked just fine, with images, contour plots,
histograms, TeX labels, axis tricks, interactivity, etc.. So perhaps
the only scipy_core changes that are significant for mpl are the fft
module move and the typecode change.
-Tom
···
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/