Thu Feb 21 08:12:33 CST 2013
On 21/02/2013 14:50, Charles R Harris wrote:
> On Thu, Feb 21, 2013 at 3:33 AM, Pablo Winant <email@example.com
> <mailto:firstname.lastname@example.org>> wrote:
> It's good to see people working in that direction. I will be more than
> happy to participate if I can.
> As a user : I really wish I had a cubic spline interpolation with
> natural bounding conditions (which implies linear extrapolation). This
> is what is implemented in Matlab's griddedInterpolator and is missing
> from the existing options in scipy (right?). Being able to
> evaluate the
> derivatives is also a big advantage.
> As a developper : there is the Einspline library that has a
> straightforward implementation in C. In particular, the representation
> of spline objects (C structs) and the low-level API are very
> straightforward and may be a good of inspiration. The library is
> currently GPL, but the author told me it could be made BSD if some m4
> macros are removed.
> For what it's worth, I have made a simple Cython wrapper around
> some of
> its functions
> and was considering repackaging it. I had some other plans (like
> code for higher dimensions using some kind of templating, and updating
> SIMD evaluation). If there is a more elegant alternative, I would be
> happy to jump on the bandwagon.
> I agree completely about the remarks on the spline format: it
> should be
> left as simple as possible. Having it isomorphic to C structs
> would be a
> good thing too as it permits easy experiments with extensions (for
> instance PyCuda kernels)
> C structs tend to be non-portable, although we could work around that.
> Do you use PyCuda? Is it mostly float32?
I am experimenting with both float32/float64. Ideally, I would like to
focus on float64, but gpu devices that work well with that precision are
much more expensive.
Although, I have used PyCuda so far my concern is also valid with PyCuda
or any other SIMD framework. I think that performance is a very
important issue for that kind of computation, and I wonder how hard it
will be to write a GPU kernel using the objects you implement.
Ideally the spline data would be in a simple format that can be passed
to these kernels. I think C structs are supported by kernels (at least
cuda), but I don't know about other kinds of data. It may well be that
conversion is trivial.
Another example. The evaluation routine written in python could be
automatically compiled by, say, Numba. In the future, it will have
support for GPU computing so that would be an elegant way to compile an
efficient interpolation function, by adjusting the code only marginally.
Again, I guess it puts some restriction on the data type.
This may not be the primarly objective of your work (as scipy doesn't do
gpu computing), but when I hear that a clean complete rewrite is on its
way, it's tempting to think how the code could be made to work on these
usecases, with little effort.
> SciPy-Dev mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SciPy-Dev