[eigen] Re: Spline revival

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]


Hi,

I applied the patch to the master branch and fixed the unit tests such
that they are now also compiling with gcc (tested on 4.3).

I will maintain the module and as I said before, any comments are welcome.

- Hauke

On Fri, Nov 25, 2011 at 3:09 PM, Hauke Heibel
<hauke.heibel@xxxxxxxxxxxxxx> wrote:
> 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



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/