Re: [eigen] Issues regarding Quaternion-alignment and const Maps

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

2010/7/7 Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx>:
> Hi,
>
> first of all great work, everyone!
>
> I have two issues with Eigen2, which I'm not sure Eigen3 has solved/will
> solve (I did look at the new source, but might have overlooked something)..
>
> First, I guess there is no (easy) possibility to have an not-aligned
> quaternion (without disabling alignment globally).

Eigen3 adds support for Map<Quaternion> with aligned and unaligned
flavors. Default is non-aligned. So, although I admit it's not the
simplest possible API, you can do this:

float data[4]; // not aligned

QuaternionMapf quat(data);

See Eigen/src/Geometry/Quaternion.h for more typedefs and to see how it works.

> For ordanary matrices there is a Eigen::DontAlign option, which I haven't
> found for Quaternions.

Indeed, we don't have it for Quaternions. Actually they don't have any
Options field.

My ideal solution, and something we need to do anyway to bring xpr
templates to quaternions, is a general QuaternionWrapper class taking
any expression (so you could wrap e.g. a DontAlign vector). Most of
the work is already done thanks to the QuaternionBase class. It's just
out of laziness we haven't done this yet.

> And currently I don't see a very lot of gain in
> vectorization of Quaternions, especially (quaternion * vector3) is not
> vectorized,

That's something we should do! The copy of the vector3 into an aligned
vector4 should have a quite small cost, should be worth it.

> and (quaternion * quaternion) only for float (at least in
> Eigen2).

That's still the case. SSE wouldn't bring a very big benefit for
doubles here, I'm afraid.


> The second issue is a bit more complicated:
> Eigen::Map severely violates const-correctness. I.e., it is possible to
> create a non-const Map from a (const double*).
> If you still accept API-changes, I would suggest having a Map and a ConstMap
> (similar to iterators in STL).

Ah yes, you are totally right, we must fix that. Will edit the
TODO-for-3.0 asap with that.

Not fully clear to me what the right approach is though, this needs
some thought.

> Ok, and actually a third very minor issue regarding Maps:
> Maps of fixed sizes should boil down to a single pointer, but they don't due
> to the ei_variable_if_dynamic-object, which is not allowed to have size 0,
> even if it contains no members.

This isn't a very big issue as Map objects are typically optimized
away by the compiler, so they have zero cost whatsoever. The only way
this can fail to happen is if you are storing a named Map object...
The only case that worries me is if people start having such data
members in their own structures, then it's indeed very stupid that Map
is bloated with these empty objects.

> One possible solution (without to much code-rewriting) would be to combine
> the sizes and the m_data pointer to a single object, providing
> getter-functions for rows and cols, and some template-specializations if
> sizes are Dynamic (similar to how ei_matrix_storage is implemented)

No need for template specializations, we can rely on the EBCO here.
Empty *base classes* really count as zero size. I'm going to do this.

Thanks for the useful report.
Benoit

>
> Best regards,
> Christoph
>
> --
> ----------------------------------------------
> Dipl.-Inf. Christoph Hertzberg
> Cartesium 0.051
> Universität Bremen
> Enrique-Schmidt-Straße 5
> 28359 Bremen
>
> Tel: (+49) 421-218-64252
> ----------------------------------------------
>
>
>