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

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

oops, I didn't see  there was a thread already...

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