[SciPy-dev] Re: Numeric 3 status
oliphant at ee.byu.edu
Thu May 19 15:42:46 CDT 2005
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...
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
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.
More information about the Scipy-dev