Re: [eigen] Patch for quaternion normalization and cross product for Vector4f

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

2009/3/11 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
> actually I've already applied the quaternion product patch.

ok, wonderful.

>
> about vector3 ops using aligned vector4, currently I would say that's
> up to the user to correctly use vector4 to ensure the last coeff is
> zero when it really as to be 0 (dot/norm) and uses .start<3> when
> there is no alternative (minCoeff). Am I right if I say that in that
> context the only missing feature is a vectorized cross product ?

For purely vector ops, yes I think you're right.

Things get more complicated with 3x3 matrices. Here it seems that for
good performance with matrix products, what we need is to embed the
3x3 matrix as top-left corner in a 4x4 matrix with zeros outside. So
it is really getting complicated, and very wasteful of memory.
Probably a reason to not think of matrices for now.

> If
> so, then the easiest way is to add a cross3() function. Another option
> would be to check the MaxSizeAtCompileTime value to automatically
> vectorize:
> a.start<3>().cross(b.start<3>()), the problem is the return type which
> have to be a Vector4.

And, that API would be worse than a cross3() function.

> Another related thing: we already can do:
>
> typedef Matrix<float,3,1,0,4,1> AlignedVector3;
>
> so if we improve the vectorization to better take into account the
> Max{Row|Cols|Size}AtCompileTime values, then all coeff wise ops could
> be easily vectorized. Likewise, the cross product could automatically
> return an "AlignedVector3".

Interesting! But I think that getting something usable would require
to have constructors initializing with zeros outside of the useful
part. We could actually do that in the Matrix ctors in the case when
both SizeAtCompileTime and MaxSizeAtCompileTime are finite, and are
different; but not if this slows down compilation for everybody.

> The only problems I see are:
>  1 - the dot/norm stuff (we would need specialized versions of ei_predux)
>  2 - the evaluation to a temporary if the Max*AtCompileTime values are
> not taken into account (I don't remember how it behaves)

Yes they are taken into account, that's why the evaluation of a
dyn-size block in a fixed-size matrix won't cause a dynamic memory
allocation.

Cheers,
Benoit