[Numpy-discussion] About NumPy description
Francesc Altet
faltet@carabos....
Wed Apr 4 14:01:19 CDT 2007
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
"-"
More information about the Numpy-discussion
mailing list