[SciPy-dev] Re: Numeric 3 status

[Travis Oliphant]

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