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

[Peter Verveer]

On Feb 5, 2005, at 1:15 PM, Jochen Küpper wrote:

> Travis Oliphant <oliphant at ee.byu.edu> writes:
>
>> I'm more interested now in uniting a fractured community (or at
>> least making interoperability easier).
> 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.

Yes, I am starting to think that this approach is the only one that 
would cure the split we currently have between Numarray and 
Numeric/SciPy. Provide this, and make sure that Numarray/SciPy can use 
its Python/C API's and we can take it from there.

> 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)

That will be needed and should be easy to provide.  Basically these 
exist already.

>   b) FFTW, GSL, ... wrappers that still are only Python + C, but
>      require external libraries to be installed.

Don't forget that these packages tend to be using the GPL license. That 
should be fine, but means that such a package needs to be GPL-ed and 
separate from the rest.

>   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.

Agreed they should be independent and I dont see why this could not be 
the case.

I would add another requirement to such packages: good documentation.

> 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.

I can only agree with all what you wrote. My experience with Python has 
been the other way around: I have been leaving C/C++ behind for Python. 
But at the same time I have found myself limiting my code to a small 
sub-set of all the good stuff that is out there (basically I only use 
Numarray). I would like to see that change and what you outlined above 
seems to me the best way to go forward.

Peter