[Numpy-discussion] Trying out Numeric3

[Travis Oliphant]

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.

Current needs:

   - 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. 


-Travis