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