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

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

On Wed, Jul 7, 2010 at 9:56 AM, Christoph Hertzberg
<chtz@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> 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).
> For ordanary matrices there is a Eigen::DontAlign option, which I haven't
> found for Quaternions. And currently I don't see a very lot of gain in
> vectorization of Quaternions, especially (quaternion * vector3) is not
> vectorized, and (quaternion * quaternion) only for float (at least in
> Eigen2).

With Eigen3 you can map unaligned data as a Quaternion, but that's
less convenient. So you would like a DontAlign option, e.g.:

Quaternion<double,DontAlign>

Then we should also add such an option to Translation and Transform.

Why not.

> 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).

yes, that's not very nice. The only advantage of our current approach
is that keep the number of type instantiation to a minimum. The user
can still manually enforce constness by declaring the Map object
const:

const double* data= ...;
const Map<MatrixXf&> map(data,....);

But, sure, this is far to be satisfactory, for many reasons.

This issue also exists with named Block objects:

foo(const MatrixXf& m) {
  Block<MatrixXf> bl(mat,0,0,,4,4);
  bl.setZero();
}

API-wise, what about const qualifying the matrix type to enforce constness:

// here data can be a double* or a const double*
Map<const MatrixXf> mat(data,...);

// here data must be a double*
Map<MatrixXf> mat(data,...);

and we would do the same for Block. (Block and Map are based on the
same implementation).

Again the drawback is that we are artificially increasing the number
of types, and consequently compilation time and binary sizes....


> 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.
> 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)

Indeed, we had to introduce a separated ei_matrix_storage class for
that precise purpose. Actually, we did not thought that, e.g.,
sizeof(Map<Matrix4f>) would matter... but again, why not :)

gael

>
> 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
> ----------------------------------------------
>
>
>