scipy support

Travis,

I think the big problem is in numerix, not scipy. The builtin min and scipy amin are getting confused, so that min is being called when amin should be; almost all the extra time is in calls to min and max.

I can't sort it out right now, but I may be able to get to it this evening--but maybe someone will beat me to it!

Once that numerix problem is fixed, I expect the timing difference between scipy and Numeric for the mpl demos will be small, and can be checked at leisure.

Eric

Travis Oliphant wrote:

ยทยทยท

Eric Firing wrote:

John,

Something must not have gotten rebuilt when it should have; removing build and doing a complete rebuilt (with and without VERBOSE) solved the problem. So, --scipy is now working with svn version of scipy and cvs version of matplotlib--at least for the few demos I have tested so far.

Speed is disappointing, though; contour_demo on my machine takes twice as long with scipy as with Numeric.

We'll start looking at speed issues more closely soon. There are several optimizations planned already, but it would be nice to get some real-world experience as to what is actually slow and what isn't. Some thing will always be slower, but I'd like to get rid of any obvious, and unnecesary slow-downs.

Good benchmark data is very helpful for this exercise. So, if you could determine exactly what operations are slower in contour demo that would be very helpful.
One issue is that backward-compatibility is achieved by going throw another layer of function calls. This will always introduce something of a slow-down. I will continue to work to make things as fast as they can be. There were a lot of new features added and there has been very-little time spent on optimization. -Travis.

Travis,

I was wrong--the problem (causing slow contour_demo with scipy) is that scipy is using min and max in ma.py where it should be using amin and amax. A diff against svn is attached.

Eric

ma_patch.diff (1.57 KB)