[Numpy-discussion] Trying out Numeric3
oliphant at ee.byu.edu
Thu Mar 24 16:09:08 EST 2005
Michiel Jan Laurens de Hoon wrote:
> Arnd's comment raises the question of how to try out or contribute to
> Numeric3 if the code base is changing from day to day. It may be a
> good idea to set up some division of labor, so we can contribute to
> Numeric3 without getting in each other's way. For example, I'd be
> interested in working on setup.py and putting different parts of
> Numeric3/scipy_base together.
Well, CVS, makes that somewhat easy if we just commit changes
regularly, and update regularly.
But, I understand that people may want to know what kinds of things they
could work on right now. I'm working on finishing adding methods.
I'd like to create the new core distribution on an SVN server.
Enthought is willing to host the SVN server as far as I know. SVN is
easy to use and is supposed to be easier to manage than CVS.
- the PEP for the __index__ method added to Python needs to be
written and the code implemented --- this is not that hard for the
budding Python contributor
- the PEP for a good "buffer" object (this has been called by others
a "byte" array which might be a good name. Essentially, it needs to be
a light-weight object around a chunk of memory -- i.e. a way to allocate
memory through Python. We would like to standardize on a set of meta
information that could be used to "understand" this memory as a numeric
array. Then, other objects which used this buffer as a memory block
would just have to expose the meta information in order to make seamless
the transfer of data from one application to another. We need to be
vocal about the value of the buffer object. This PEP is one way to do
that. There are some people who think buffer objects were a "bad
idea." This is primarily because of a fatal flaw in some objects that
both expose a memory pointer through the buffer protocol AND allow the
object's memory to be reallocated (using realloc) --- Numeric does not
do this. This problem could actually be easily fixed by a good
Python memory allocator that returns a simple memory object. If people
who wanted memory went through it's C-API (instead of using malloc and
realloc), much of the problems would be alleviated. This is what the
new "byte" object should be. I think it also wise to expect the "byte"
object to have an attribute called "meta" that would just be a
dictionary of "other information" you might want to pass to something
using the buffer protocol.
- a record array class. This should be adapted from the numarray
record array class and probably inherit from the ndarray type.
- ufunc modifications. This is where I'm headed after the array
methods task is done. If people have ideas about how ufuncs should be
handled, now is the time to voice them. If somebody could help me here,
it would be great. But, in a couple of days, I will be spending the
next chunck of my (spare) time on ufunc modifications.
More information about the NumPy-Discussion