[SciPy-dev] Spline module
oliphant at ee.byu.edu
Thu Aug 2 16:55:24 CDT 2001
> Getting the new version of SciPy from CVS I was happy to see the
> of splines support. However, it is split between interpolate and
> signal. I
> personally would prefer a separate splines module. Some of us use splines
> for neither of the above. I've been using B-splines as a basis for a
> element method. The SLATEC library on Netlib has an set of excellent
> spline codes based upon de Boor's code. The only problem is that it
> support 2-D.
I'm not necessarily opposed to a separate splines module. But, splines do
get used in a number of different ways --- and the algorithms used in each
domain do tend to differ.
Perhaps your spline code would be better in a finite-element package,
rather than a spline module.
> I've written a set of F90 wrappers around the code to support some stuff
> in 2-D and provide a more object-oriented api, but I don't need
> so, I've been ignoring that part. I've been planning a port to Python
> and I'd
> be happy to help in the development of the splines part of scipy.
Love to have more help with scipy...
> I just noticed this addition too. Travis Oliphant is the man to talk to
> about this. I doubt he
> has thought to hard about its location in scipy and will be open to
> suggestion. Also,
> the SLATEC slant sounds promising. Can you work on it as a side project and
> can integrate it into SciPy later. Right now we need to work the existing
> kinks out
> of the code and get a binary release out the door. (It should been out last
> One thing though -- no F90 code. Sorry, but its harder to wrap in Python
> and there aren't
> any OS compilers around that handle it yet (give th gnu folks another few
> years though...)
> F77 code is acceptable, but we smile bigger when handed C/C++ and Python.
> Then again, Travis O. might not smile at all if its C++...
I don't mind f77 code (but then again I haven't dealt with the Windows
headaches as much as eric :-) ).
More information about the Scipy-dev