Eric Jonas wrote:

...

I forgot to let you know in my previous email, that I would be very, very pleased to receive help on scipy.base. There is a great deal of opportunity for people to get involved and assist with the formation of a solid scipy.base. I listed a few areas in my previous email, but I'm sure I forgot some things.

Well, I have an undergraduate working with me with some decent C and python experience and an interest in numerical computing; we've downloaded the latest from the SF CVS Numeric3 module and are going to start looking over things; are there any mailing lists or other recommended sources of information? As the person in charge of all of this, is there some area you'd prefer for us to get started on ? We'd love to help you get this all working this summer...

Fantastic, Spring term started, and my time for Numeric3 dried up considerably. Fortunately, there is not that much left to do algorithmically but what is left is somewhat difficult. Three things remain for the ufuncs: 1) altered coercion rules to treat scalars differently --- should not be difficult to code (in fact mostly done already SEE scipy.alter_numeric) 2) change the reduce (accumulate), and reduceat functions to handle misaligned and byteswapped data using array iterators and buffers when necessary (i.e. adapt what has been done for general ufuncs to these methods). This is the hard part. I pretty much know how to do it, but it takes a big chunk of time and thought process on my part and I have not been able to get to it for the past month. At the same time, I would like to alter these ufunc methods so that you can specify the argument type they "reduce into" i.e. you should be able to specify that a reduce on a Int8 array returns an output in an Int32 array. 3) add the error handling functionality of numarray. Ufuncs that cause errors will flip the IEEE hardware flag. This needs to be checked if that is the specified error handling mode. This shouldn't take too long. So, #2 is the hard part and is what has me stopped (I know it will take me several hours to days to code it correctly --- and I've not been able to set aside that time). After these three things are accomplished, then what remains is on the critical path is: Updating the scipy numerix module to use scipy.base by default, making sure that scipy.base can ship by itself and have the same basic modules that Numeric provides and a clean path to upgrading to full ATLAS-based linear algebra and/or improved FFT performance. Realistically, this all may not be finished until the scipy conference in September. I'd like it to be done earlier than that of course. The reality is that there are very few actually willing to work on the code base and a great many that will actually want to use it. Those with the C-skill necessary to help (or willing and able to learn some C) are apparently few in number. Any help you provide will be appreciated. You are welcome to tackle anything you think would be useful. -Travis