[eigen] Spline revival

[Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>]

Hi,

due to a recent request, I revisited my spline fork and adapted code
from it to the most recent Eigen version. Because the maintenance of
this quite old fork is a bit ugly, I switched to patch queues. The
most recent patch file, which was build against today's tip should be
working fine. If I am not wrong, it can be imported by running

$> hg import splines.patch

from the console.

The patch provides a simple Spline class and an interpolating spline
fitting in the unsupported module. The Spline class is templated over
the float type, the dimension and the degree. As for matrices, the
degree can be chosed dynamically, when it is set to Eigen::Dynamic at
compile time. The benefit is that with a small and fixed degree which
is known at compile time, the Spline class needs almost no heap
allocations.

After running CMake there are some simple unit tests available in
<build_dir>/unsupported/test/. So far I only tested VC10, x64. There
are most likely some "typename" keywords missing as VC10 never
complains and I tend to forget to specify them. :)

There are some design questions which are still open:

1) Should the global functions below go into a separate namespace as
e.g. Eigen::Splines or do we keep a single namespace?
  Eigen::KnotAveraging
  Eigen::ChordLengths

2) Is there a better solution for the static Spline member functions
Spline::Span and Spline::BasisFunctions? Do they need to be static?
IIRC, the reason for them being static is that
a) they need to be used when there is not yet a Spline object
available (see e.g. SplineFitting<SplineType>::Interpolate)
b) they can benefit (in particular Spline::BasisFunctions) from
knowing about the underlying Spline's compile time degree

Any comments are welcome and I hope to be able to merge this soon with
the master branch.

Regards,
Hauke

Attachment: splines.patch
Description: Binary data