[Numpy-discussion] Numpy Benchmarking

[Robert Kern]

joris at ster.kuleuven.ac.be wrote:
> Hi,
> 
>  [TO]: NumPy uses Numeric's old wrapper to lapack algorithms. 
>  [TO]: 
>  [TO]: SciPy uses it's own f2py-generated wrapper (it doesn't rely on the
>  [TO]: NumPy wrapper).
>  [TO]: 
>  [TO]: The numpy.dual library exists so you can use the SciPy calls if the 
>  [TO]: person has SciPy installed or the NumPy ones otherwise.  It exists 
>  [TO]: precisely for the purpose of seamlessly taking advantage of 
>  [TO]: algorithms/interfaces that exist in NumPy but  are improved in SciPy.
> 
> This strikes me as a little bit odd. Why not just provide the best-performing 
> function to both SciPy and NumPy? Would NumPy be more difficult to install
> if the SciPy algorithm for inv() was incorporated?

That's certainly the case for the FFT algorithms. Scipy wraps more (and more 
complicated) FFT libraries that are faster than FFTPACK.

Most of the linalg functionality should probably be wrapping the same routines 
if an optimized LAPACK is available. However, changing the routine used in numpy 
in the absence of an optimized LAPACK would require reconstructing the f2c'ed 
lapack_lite library that we include with the numpy source. That hasn't been 
touched in so long that I would hesitate to do so. If you are willing to do the 
work and the testing to ensure that it still works everywhere, we'd probably 
accept the change.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco