I just committed some changes to fix the scipy core patch. The
problem was that Daishi apparently had the full scipy installed, so
many of the imports that worked in his tests did not work for scipy
core.
Most things seem to be working, but there is a problem in the
colormapping code in colors.py. The index into the LUT, which should
be an integer array, is coming out as a float array for scipy core.
I'm not sure why. Perry wrote this section of the code so he has a
better understanding of it than I do (around line 240 in colors.py),
this line is failing
#print 'types', typecode(self._lut), typecode(xa), xa.shape
rgba = take(self._lut, xa)
There may be other problems, but this is the only one I know of
currently.
A number of the symbols in numerix.mlab that Daishi originally defined
were from various scipy (non-core) proper modules and I could not find
these in the core. Will scipy core not be providing the equivalent of
MLab.py? There are a few of these functions used in matplotlib, and I
just redefined them manually for now in numerix.mlab. Eg, mean, std,
hanning, and a few more. Others, like cov, I buried the import into
the function that needs them, eg in matplotlib.mlab in the
detrend_linear function. If these aren't going to be in the core,
what do people suggest we do for numerix.mlab.
If anyone has any suggestions for help on the colormap LUT problem
referenced above, that would be great.
Thanks,
JDH
John,
It looks like you are referring to bugs in the Colormap.__call__ method that were introduced when I added support for masked values out-of-bounds values. I have committed a change that fixes the bugs I could find there (as tested with examples/image_masked.py), so that the colormap call produces exactly the same output with scipy as with Numeric or numarray--the same rgba values. Unfortunately, although that demo now runs with all three, it produces different plots. It appears that somewhere else in the code--I'm pretty sure it is not within colors.py--the floating point rgba values are getting rounded or, more likely, truncated, when using scipy.
Eric
John Hunter wrote:
···
I just committed some changes to fix the scipy core patch. The
problem was that Daishi apparently had the full scipy installed, so
many of the imports that worked in his tests did not work for scipy
core.
Most things seem to be working, but there is a problem in the
colormapping code in colors.py. The index into the LUT, which should
be an integer array, is coming out as a float array for scipy core.
I'm not sure why. Perry wrote this section of the code so he has a
better understanding of it than I do (around line 240 in colors.py),
this line is failing
#print 'types', typecode(self._lut), typecode(xa), xa.shape
rgba = take(self._lut, xa)
There may be other problems, but this is the only one I know of
currently.
A number of the symbols in numerix.mlab that Daishi originally defined
were from various scipy (non-core) proper modules and I could not find
these in the core. Will scipy core not be providing the equivalent of
MLab.py? There are a few of these functions used in matplotlib, and I
just redefined them manually for now in numerix.mlab. Eg, mean, std,
hanning, and a few more. Others, like cov, I buried the import into
the function that needs them, eg in matplotlib.mlab in the
detrend_linear function. If these aren't going to be in the core,
what do people suggest we do for numerix.mlab.
If anyone has any suggestions for help on the colormap LUT problem
referenced above, that would be great.
Thanks,
JDH
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options