Getting the new version of SciPy from CVS I was happy to see the inclusion 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 finite 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 doesn't 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 interpolation 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.
Thoughts?
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 we 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 week)
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 :-) ). -Travis
I'm no splines expert, but I'd hope there was a way to factor out the splines code so that we only have one set of spline code to maintain. The smaller SciPy's code base the better. If different disciplines use splines in different ways, then they can put a different interface over the top of the splines module. If the disciplines use splines in ways that requires different underlying code, or if different implementations of splines are faster/better for different problem sets, then multiple libraries *might* be a good idea. It have to be a lot faster (2x) or a lot better to make the larger code base worth while though. eric ----- Original Message ----- From: "Travis Oliphant" <oliphant@ee.byu.edu> To: <scipy-dev@scipy.org> Sent: Thursday, August 02, 2001 5:55 PM Subject: [SciPy-dev] Spline module
Getting the new version of SciPy from CVS I was happy to see the inclusion 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 finite 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 doesn't 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 interpolation 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.
Thoughts?
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 we 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 week)
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 :-) ).
-Travis
_______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.net http://www.scipy.net/mailman/listinfo/scipy-dev
participants (2)
-
eric jones -
Travis Oliphant