[Matrix-SIG] An Experiment in code-cleanup.
Mon, 7 Feb 2000 18:08:43 -0600 (CST)
I wanted to let users of the community know (so they can help if they
want, or offer criticism or comments) that over the next several
months I will be experimenting with a branch of the main Numerical source
tree and endeavoring to "clean-up" the code for Numerical Python. I have
in mind a few (in my opinion minor) alterations to the current code-base
which necessitates a branch.
Guido has made some good suggestions for improving the code base, and both
David Ascher and Paul Dubois have expressed concerns over the current
state of the source code and given suggestions as to how to improve it.
That said, I should emphasize that my work is not authorized,
or endorsed, by any of the people mentioned above. It is simply my little
My intent is not to re-create Numerical Python --- I like most of the
current functionality --- but to merely, clean-up the code, comment it,
and change the underlying structure just a bit and add some features I
want. One goal I have is to create something that can go into Python
1.7 at some future point, so this incarnation of Numerical Python may not
be completely C-source compatible with current Numerical Python (but it
will be close). This means C-extensions that access the underlying
structure of the current arrayobject may need some alterations to use this
experimental branch if it every becomes useful.
I don't know how long this will take me. I'm not promising anything. The
purpose of this announcement is just to invite interested parties into the
These are the (somewhat negotiable) directions I will be pursuing.
1) Still written in C but heavily (in my opinion) commented.
2) Addition of bit-types and unsigned integer types.
3) Facility for memory-mapped dataspace in arrays.
4) Slices become copies with the addition of methods for current strict
5) Handling of sliceobjects which consist of sequences of indices (so that
setting and getting elements of arrays using their index is possible).
6) Rank-0 arrays will not be autoconverted to Python scalars, but will
still behave as Python scalars whenever Python allows general scalar-like
objects in it's operations. Methods will allow the
user-controlled conversion to the Python scalars.
7) Addition of attributes so that different users can configure aspects of
the math behavior, to their hearts content.
If their is anyone interested in helping in this "unofficial branch
work" let me know and we'll see about setting up someplace to work. Be
warned, however, that I like actual code or code-templates more than just
great ideas (truly great ideas are never turned away however ;-) )
If something I do benefits the current NumPy source in a non-invasive,
backwards compatible way, I will try to place it in the current CVS tree,
but that won't be a priority, as my time does have limitations, and I'm
scratching my own itch at this point.