[Numpy-discussion] About NumPy description

[Francesc Altet]

A Dimecres 04 Abril 2007 04:13, Steven H. Rogers escrigué:
> How about:
> """
> NumPy extends Python with a multi-dimensional array type (class) and
> related mathematical functions.  This provides the Python user with
> useful abstractions for managing and computing with multi-dimensional
> bulk data.  This provides a strong foundation for for such domains as
> statistics, image and signal processing, finance, and general systems
> modeling.  Easy integration with ctypes and Fortran allow efficient
> leveraging of high performance C and Fortran code.
> """

Yeah. That's better because it stresses both parts, the data containers and 
the mathematical functionality. However, I think that the word 
multi-dimensional (which is cited twice) may mislead some potential users 
that might be more interested in the heterogeneous type support for use in 
the database field.

At any rate, it's very difficult to expose all the nice things that is 
offering NumPy to the Python users in just a few lines.  Because of this, 
perhaps it is worth to expand these possibilities in the home page of NumPy 
(numpy.scipy.org). BTW, I see this better explained now:

"""
Besides it's obvious scientific uses, NumPy can also be used as an efficient 
multi-dimensional container of generic data. Arbitrary data-types can be 
defined. This allows NumPy to seamlessly and speedily integrate with a 
wide-variety of databases.
"""

Perhaps Travis has modifyied this recently? In that case, I find the above 
paragraph quite informative for the database field.

Lately, I tend to think (as someone has already suggested here) that NumPy is 
embracing many different fields at once and that a split in a couple of 
packages could adapt better to the users need.  IMO, a core with the 
containers and very few functions on top of them (sorting, lookup, 
selection,...), and another layer on top of the core with more mathematical 
(random, linalg, FFT...) functionality would make more sense than the  
current organisation (all in one single package).

Of course, such a split could introduce more difficulties to manage (more 
SVNs, more distribution lists, more releases, more binary packages and so on 
and so forth), but also could lead to a small core that do few things but 
very well done (and hence, easy to integrate in many different projects) and 
the next layer that do many more things but that would be used by a more 
specific user base (more scientific/technical biased). Incidentally, at the 
top of this stack of layers should be scipy, of course.

Finally, I suppose that the NumPy core  that I'm referring to would somehow 
overlap with the PEP for the new buffer interface that Travis is lately 
pushing forward (and that is meant to be integrated with Python 3000), 
although as I see the things, adding basic functionality to this buffer (like 
as I already said, fast sorting, lookup, data selection...) and packaging 
this in a single, compact package could be a really great contribution to the 
Python community in general.

Just some thoughts,

-- 
>0,0<   Francesc Altet     http://www.carabos.com/
V   V   Cárabos Coop. V.   Enjoy Data
 "-"