The need for a unified numerical array object (was: [Numpy-discussion] Numeric3)
verveer at embl.de
Sat Feb 5 08:01:44 CST 2005
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
> 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
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.
More information about the Numpy-discussion