Boost logo

Boost :

Subject: Re: [boost] (Boost) QVM update
From: Nathan Crookston (nathan.crookston_at_[hidden])
Date: 2013-01-09 01:00:20


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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk