[boost] (Boost) QVM update

[Emil Dotchevski]

Boost QVM has been updated. Note, this library has not been reviewed
yet and it is not part of Boost.

Boost QVM provides a set of generic functions for working with
quaternions, and vector and matrix types of static size. All
operations use a type-traits system, which enables types from other
vector/matrix libraries to be integrated in a common type-safe
interface.

The current source code and documentation is available at
http://www.revergestudios.com/boost-qvm. It contains minor bug fixes,
and the following new features:

- view proxies that negate matrix rows and columns (negr/negc)

- view proxies that swap two rows or columns in a matrix (swapr/swapc)

- functions for indexing at run-time of any vector or matrix object of
arbitrary size.

Comments and bug reports are appreciated.

Thanks!
Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Nathan Crookston]

Hi Emil,

Emil Dotchevski wrote:

> Boost QVM has been updated. Note, this library has not been reviewed
> yet and it is not part of Boost.
>

> Comments and bug reports are appreciated.
>

I've been looking forward to this library. I often need something like
this in my work (mixture of graphics programming, image processing, and
geospatial applications). I wasn't happy with what ublas offered in the
static-sized 3-8 dimensions, so I rolled my own -- I'd be much happier to
have something like this, though.

The documentation seem especially complete. A few questions and comments
that occurred to me as I was reading through (and occasionally glancing at
the code):

* I'm sure [qvms]_traits is used all over the place, but I'd still rather
see scalar_traits, vector_traits, etc., especially as those may be
specialized by the user.

* I thought s_traits was hard to find in the 'Generic programming
utilities' section. Should it be in the 'Type traits' section instead?

* It looks like matrix types (probably vectors and quaternions too) must be
default constructible (for both make and the template conversion operator
of mat), though I didn't see that particular requirement noted -- am I
mistaken?

* The SFINAE page seems to reference itself:

sfinae
The boost::qvm::sfinae namespace contains only function names that use
SFINAE <circular link>. The boost::qvm namespace contains all Boost QVM
type and function names.

I would have expected it to link to an explanation of sfinae -- not
necessarily part of QVM's docs.

* inverse: I was surprised to see that you're inverting using the matrix
of cofactors. For my personal education, why do you use that method -- is
it more stable or efficient than others? A home-rolled implementation I
did something like the following:

//Solving Ax = b
matrix<float> A;
vector<float> b;
inverse_matrix<float> inverse_m = invert(m);//actually perform lu
decomposition
vector<float> x = inverse_m * b;//actually back-substitutes from lu matrix.

In that case, I knew that I'd only ever multiply by a vector -- which
allowed me to use a method which is at least as efficient as matrix
inversion and more numerically stable. I'm not sure if an inverse_matrix
type would allow something like:

matrix<float> A = ...;
inverse_matrix<float> B = ...;
auto C = A * B;
auto D = B * A;
to be computed as efficiently as if B were really just a matrix type. I
could look that up tomorrow, when I have a reference on the material. If
it is, I think it would be interesting to have inverse return a view_proxy.

* I haven't looked, but I assume QVM is targeting cases where both matrices
fit into cache? Meaning, it doesn't worry about things like cache blocking?

* I think the swizzling code is interesting. The Accessing * Elements
pages aren't too informative, though. It would help me if those pages, in
the 'See also:' section, were to link to examples of their usage.

* Further on swizzling -- when I'm dealing with OpenGL texture coordinates,
the canonical names for them are s, t, r and q. Is there an interface
whereby I could allow writing something like this?

TexCoord tc1(1, 2, 0, .5);
TexCoord tc2 = tc1 % TSRQ;

I don't know that I'll ever need such a thing -- this is mostly out of
curiosity.

I haven't had a chance to try QVM out -- I'd like to work up examples with
e.g., std::array<float,4>, then something with boost::units types as the
scalar types. In fact, working with the latter would be a killer feature
from this library for me. I'll let you know what I find.

Thanks again for making this library available!

Nate

[Shakti Misra]

Hi Emil,
I also am waiting to try it out. My environment doesn't allow me to use
boost completely.
I may be getting little greedy, but any chance of using vectorization? :)
~Thanks
Shakti

[Emil Dotchevski]

On Tue, Jan 8, 2013 at 10:00 PM, Nathan Crookston
<nathan.c...@gmail.com> wrote:

> * I'm sure [qvms]_traits is used all over the place, but I'd still rather
> see scalar_traits, vector_traits, etc., especially as those may be
> specialized by the user.

They used to be called vector_traits, etc, but I think that the
shorter names are more practical, given that even user-defined
specializations appear in namespace qvm. I'll make sure s_traits gets
the proper exposure in the documentation though.

> * It looks like matrix types (probably vectors and quaternions too) must be
> default constructible (for both make and the template conversion operator
> of mat), though I didn't see that particular requirement noted -- am I
> mistaken?

Yes, some functions do require that types are default-constructable,
though make<> could be specialized. I should mention this in the
documentation.

> * inverse: I was surprised to see that you're inverting using the matrix
> of cofactors. For my personal education, why do you use that method -- is
> it more stable or efficient than others?

This just is the way I've been inverting matrices and it has worked
for my needs. :) That said, I'm not against adding support for
alternative implementations, even if they put additional requirements
on the input matrix.

Do note however, that I've implemented inversion and all other
algorithms in meta-code that is able to output specific code for any
size matrices. See (boost)/libs/qvm/gen/gen.cpp (which was used to
generate the files in (boost)/qvm/gen.)

> * I haven't looked, but I assume QVM is targeting cases where both matrices
> fit into cache? Meaning, it doesn't worry about things like cache blocking?

I've been careful to avoid language-level inefficiencies (like
temporary objects, etc.), but I haven't been too concerned with low
level optimizations. I'm not against optimizing further (again, the
code generator may be useful for that.)

> * Further on swizzling -- when I'm dealing with OpenGL texture coordinates,
> the canonical names for them are s, t, r and q. Is there an interface
> whereby I could allow writing something like this?

There is also RGBA for color vectors. Maybe it makes sense to add more
swizzlers, that isn't very difficult because (you guessed it) there is
a code generator for that too.

> I haven't had a chance to try QVM out -- I'd like to work up examples with
> e.g., std::array<float,4>, then something with boost::units types as the
> scalar types. In fact, working with the latter would be a killer feature
> from this library for me. I'll let you know what I find.

Yes, that would be interesting. So far I've hooked up DirectX and
OpenGL matrices and vectors, and types from 3rd-party code I've used,
so I know that v_traits/m_traits/q_traits work well. I haven't had a
need to hook up a custom scalar type yet. Practically speaking, we
don't know if s_traits is designed correctly until I or someone else
does that.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode

[Emil Dotchevski]

On Wed, Jan 9, 2013 at 5:22 AM, Shakti Misra
<shakti.mi...@gmail.com> wrote:
> I may be getting little greedy, but any chance of using vectorization? :)

If you mean vectorization to support efficient processing of large
arrays of matrices or vectors, I think that's outside of the scope of
this library.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode