[SciPy-dev] Spline module
eric at scipy.org
Thu Aug 2 21:36:09 CDT 2001
I'm no splines expert, but I'd hope there was a way to factor out the
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
splines in ways that requires different underlying code, or if different
implementations of splines are faster/better for different problem sets,
multiple libraries *might* be a good idea. It have to be a lot faster (2x)
lot better to make the larger code base worth while though.
----- Original Message -----
From: "Travis Oliphant" <oliphant at ee.byu.edu>
To: <scipy-dev at 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
> > 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
> > 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
> > we
> > can integrate it into SciPy later. Right now we need to work the
> > kinks out
> > of the code and get a binary release out the door. (It should been out
> > week)
> > One thing though -- no F90 code. Sorry, but its harder to wrap in
> > and there aren't
> > any OS compilers around that handle it yet (give th gnu folks another
> > years though...)
> > F77 code is acceptable, but we smile bigger when handed C/C++ and
> > 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 :-) ).
> Scipy-dev mailing list
> Scipy-dev at scipy.net
More information about the Scipy-dev