[SciPy-dev] Spline module

[eric jones]

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 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
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 at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev