[SciPy-dev] Generic polynomials class (was Re: Volunteer for Scipy Project)

Fernando Perez fperez.net at gmail.com
Thu Oct 15 18:35:23 EDT 2009


Hi all,

On Wed, Oct 14, 2009 at 8:08 AM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
> One reason for the low level functions is that they are short and can be
> easily converted to cython functions or be library functions written in
> fortran or whatever. The z series could be done that way, but at the cython
> level they could probably be dispensed with and the underlying Cheybyshev
> series used instead, that's one reason they are private functions. What they
> brought to the python case was some vectorization of the algorithms. Another
> way to look at them is as symbolic Fourier transforms.

I don't know if this will genuinely add anything to this (very
interesting discussion), but Ariel, Mike and I thought a lot about
fairly similar problems in the nitime package, and went for an
approach with:

- a purely functional library (even if the functions end up having
long signatures and don't cache things they could),

- very simple data cointainers whose design evolves very conservatively

- analysis objects that expose a nice, high-level interface and manage
the containers and library functions.  These are what users should use
90% of the time, but if we get their design wrong, little is lost
because most of the complexities are in the functional library.

This is all summarized in our preprint for the scipy proceedings
(currently under review):

http://fperez.org/papers/nitime09_ro-tr-pe.pdf

and the nitime docs can be found here:

http://nipy.sourceforge.net/nitime/

while the master branch lives at github:

http://github.com/fperez/nitime


So far we're quite happy with this approach, and I hope this example
may be of some use to you guys as you sort out the poly design.  BTW,
I'm very excited to see this coming along, many thanks to Anne and
Chuck for so much hard work!

Cheers,

f



More information about the SciPy-Dev mailing list