Rick Muller wrote:
The conversion turned out to be easy. I wrote an interface routine called NumWrap that has a flag (use_numpy) that determines whether to import from Numeric or numpy. I then modified my code to import everything from NumWrap. So far very easy.
Good news. Conversion from Numeric should be really easy and conversion from numarray only a little-bit harder.
I have a test-suite that exercises many different parts of my code. I ran the test suite using Numeric and it took 351 sec. I then ran using numpy and it took 615 sec!! Almost twice as long. (I should point out that the very good news was that the test suite ran the first time I tried it with the numpy routines without any errors!)
Probably scalar math again. I'm working on that right now, so hopefully it will be faster in the next release of numpy.
I started digging into the differences using the python profiler, and was surprised what turned up. The big difference turned out to be routines that were taking various mathematical functions (pow, exp, even simple scalar multiplication) of array elements.
This routine:
def vwn_xx(x,b,c): return x*x+b*x+c
which is called on many elements of a very large grid, went from taking 17 sec in the test suite to taking 68 sec in the test suite. Another routine that took a log() and a pow() of grid elements, went from 15 sec to 100 sec.
I looked through Travis' new documentation. I first tried the .toscalar() function, as follows: rho = 0.5*dens[i].toscalar()
Sorry, you may have an older version. The new spelling is .item() ;-) -Travis