The need for a unified numerical array object (was: [Numpy-discussion] Numeric3)

Jochen Küpper jochen at
Sat Feb 5 04:15:46 EST 2005

Travis Oliphant <oliphant at> writes:

> I'm more interested now in uniting a fractured community (or at
> least making interoperability easier).


although I am a bit too busy these days I wanna add my 1.5ct:

Few years ago I had the hope I could do (almost) all my calculations
in python, maybe writing a few limited extension modules in C. 

That hope is cured for now. Generally, all the necessary pieces are
there, but they are scattered over many packages: Numeric/Numarray,
scipy, pygsl, plus stuff like pyQt/pyGTK/wxWindows/... But getting
everything up and running for myself and colleagues is just to
demanding, esp. if system administrators are busy as well and
reluctant to mess up their system or work schedule.

Therefore I do almost all calculations in C++ right now. Compilers are
there, BLAS, LAPACK and even GSL are typically provided already,
otherwise admins do not hesitate much to install the latest binary
packages, which are available. It takes me a little longer to develop
code, but I know I can run it on any system I find and I easily save
the time their.

I still do small stuff in Python and use Numarray for it, but
everything that requires anything else I simply write in C++.

What I would love to see is a twofold system for numerics in Python:

An arrayobject plus simple ufuncs like min/max/sin/exp/... in the
Python core.

A "single" scientific Python project that provides multiple packages
using that arrayobject. There should be packages, for example, with
  a) Python+C only to provide basic linear algebra, FFT, ... with
     everything included (no external dependencies)
  b) FFTW, GSL, ... wrappers that still are only Python + C, but
     require external libraries to be installed.
  c) An "expert" package which wraps the most advanced libraries for
     each field, i.e. LAPACK. Here is should be possible to install
     each wrapper separately.

If would be nice if the subset a) of b) would use an identical
interface as a), similar for c) <- b).

Moreover I would see it advantageous to have three independent
packages here, so I could tell a sysadmin: "Please install
SciencePython_simple" or "Please install SciencePython_wrappers"
instead of "Please install SciencePython with options a, b, c".
Somehow these sys-mins feel that is easier.

Anyway, I appreciate all of yours work and I do understand that first
of all you have to solve your own problems. However, if this scattered
community manages to unify and simplify (lower entrance barriers)
their approach to Scientific calculations with Python, that will allow
it to grow much further than ever possible with the current situation,
that somehow limits itself to double experts: scientists with *good*
computer science knowledge or vice versa.

Time will tell, but I wish you all the luck you need! For me new
projects will come up constantly, maybe even a larger one will be in
Python again sometime.

Einigkeit und Recht und Freiheit      
    Liberté, Égalité, Fraternité                GnuPG key: CC1B0B4D
        (Part 3 you find in my messages before fall 2003.)

More information about the NumPy-Discussion mailing list