2015-05-05 14:56 GMT+02:00 Rob Stewart :

On May 4, 2015 3:06:31 PM EDT, Emil Dotchevski wrote:

...

Boost QVM defines a set of generic functions and operator overloads for working with quaternions, vectors and matrices of static size. The library also defines vector and matrix data types, however it allows users to introduce their own types by specializing the q_traits, v_traits and m_traits templates.

Online documentation and a link to download the source code under the Boost license is available at http://www.revergestudios.com/boost-qvm/.

I took a quick look at the docs and I have to ask, "Why?" Why would I want to use your library? There is no motivation section and nothing to explain it's value. You just assume everyone knows about its purpose and value.

I don't know anything about quarternions, for example. Does QVM relate to specific fields with which I'm not acquainted thereby making the library of no use to me? How are your vectors related to std::vector? How are your matrices related to those in uBLAS? Such are the questions you should address, don't you think?

I took a quick look as well. Besides the questions above, I wondered how to access vector elements, but "Accessing vector elements and swizzling" [1] doesn't help. It's an undocumented list of incomplete declarations. [1] http://www.revergestudios.com/boost-qvm/accessing_vector_elements_and_swizzl...

Boost QVM defines a set of generic functions and operator overloads for

...

working with quaternions, vectors and matrices of static size.

​I do agree with the previous comments, and I would like to add this question: how does it compare to ublas::fixed_vector and ublas::fixed_matrix in term of both usability and speed ? If it's really better than what we already have in ublas, why don't you try to propose a patch to improve ublas ? Best, David​

Joël Lamotte wrote:

While you're at it, comparison with some user well known libraries would be helpful (Eigen, CML, GLM, comes to mind) though not mandatory for inclusion in boost for me.

+1

On Thu, Jun 18, 2015 at 3:31 PM, Andrew Hundt wrote:

I agree with many of the previous comments on QVM, particularly the simple tutorial and starter definitions, as well as comparison to other tools. I could also *very much* use a way to implement generic algorithms that work for multiple linear algebra packages.

You're right on the money, the emphasis in QVM is not so much on the types that it provides, but on the ability to use QVM with types from other libraries, of which there are many. For example with QVM you can multiply a Maya MMatrix by an Unreal FMatrix and get a correct, type-safe result. In addition, it lets you easily define multiple types, e.g. a highly-optimized low level system may define its own, perhaps platform-specific matrix type, then use QVM to enable the full set of matrix operations for it.

Additionally, considering the described focus on realtime graphics and simulation I would be interested in functions for rigid body, affine, and dual quaternion transforms. To this end, eigen provides many of the essentials in their geometry module which could be used as a reference.

Yes, this does seem like a useful further development for QVM. Thanks! -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

2015-05-07 2:25 GMT+02:00 Emil Dotchevski :

Q: Why doesn't QVM use [] or () to access vector and matrix elements?

A: Because it's designed to work with user-defined types, and the C++ standard requires these operators to be members. Of course if a user-defined type defines operator[] or operator() they are available for use with other QVM functions, but the generic access defined by QVM uses operator% instead.

Emil, correct me if I'm wrong. For higher dimensions the user would be forced to use traits explicitly: qvm::v_traits::r<I>(vec); qvm::m_traits::r(mat); It'd also probably be possible to add a free function get, now or later if the users requested it: qvm::get<I>(vec); qvm::get(mat); There are std::get, boost::get and boost::geometry::get serving similar purpose so it should be intuitive. Regards, Adam

Emil Dotchevski wrote:

For example one of the 3D vector types I use looks like this: struct float3 { float x, y, z; }, so typically I access its elements as v.x, v.y and v.z

THAT is what I believe is needed in a "basic" matrix and vector library, plus operations on those types. Emil, can you include a collection of such types with the library? The scenario I'm thinking of is this: New employee: Phil, how do we do matrices for affine transforms? Me: Just #include this and use types called floatvec2 and floatmat2x2 and + and * just work. New employee: Wow, that's almost as easy as Java! Versus: New employee: Phil, how do we do matrices for affine transforms? Me: First, define your own structs. Then define partial specialisations of these two type traits templates. Now #include this, and + and * will just work. New employee: Poo, you lost me at "partial specialisation". I think it's quicker just to write my own matrix multiplication function. Cheers, Phil.

David Bellot wrote:

...

Me: Just #include this and use types called floatvec2 and floatmat2x2 and + and * just work.

​my cosmetic and artistic opinion about that: ​ ​with ublas, you can do that:​

​#include

// this is not needed but it's useful to have them ​#include ​#include

​int main() { fixed_matrix m1;

m1 <<= 1,2,3 4,5,6, 7,8,9;

cout << m1 << endl; }

And personally, I find fixed_matrix to be easier to remember and more explicit to use than floatvec2 or dblmat2x2 or whatever else. And I don't have to look into the doc, if I can't remember if the matrix name was DblMat2x2 or double_mat2_2... or Matrix2D ? (no, it's not the same library).

QVM defines ready-to-use types as well: http://www.revergestudios.com/boost-qvm/quaternion_vector_and_matrix_types_r... qvm::vec v; qvm::mat m; As for the <<= syntactic sugar, I'd rather consider adding a support for C++11 std::initializer_list and/or variadic templates (if they were supported by the compiler): m { 1,2,3 4,5,6 7,8,9 }; That said, the user could implement such type by himself. He could also adapt fixed_matrix to the QVM matrix Concept and be able to e.g. calculate the transformation matrix. Of course assuming that both libraries could work well with each other. Regards, Adam

On Thu, May 7, 2015 at 3:30 AM, Phil Endecott < spam_from_boost_dev@chezphil.org> wrote:

Emil Dotchevski wrote:

...

For example one of the 3D vector types I use looks like this: struct float3 { float x, y, z; }, so typically I access its elements as v.x, v.y and v.z

THAT is what I believe is needed in a "basic" matrix and vector library, plus operations on those types.

Emil, can you include a collection of such types with the library?

The library does define a basic (or default) vector type: http://www.revergestudios.com/boost-qvm/vec.html.

Me: First, define your own structs. Then define partial specialisations of these two type traits templates. Now #include this, and + and * will just work.

There are independent reasons why people may want to define their own vector types or may already have several different vector types on their hands. QVM can be used to make such types compatible with each other. In addition, QVM itself emits many different vector types, e.g. see http://www.revergestudios.com/boost-qvm/view_proxy.html. Emil

On Thu, Jun 25, 2015 at 9:35 PM, Michael Marcin wrote:

I love swizzling although I dislike this particular syntax.

See http://zajo.github.io/boost-qvm/operator_mod_rationale.html. Basically, I can't think of a better alternative.

I don't see any performance benchmarks which is a deal breaker for me.

To get maximum performance you have to lower the level of abstraction and you'll probably need a completely different API. For example transforming a buffer of 100,000 vectors can be an order of magnitude faster than transforming 100,000 individual vectors. That said, if you have some kind of benchmark I'd be happy to adapt it to QVM and publish the results.

I'm pretty happy with Eigen3, I don't see where QVM is providing enough value to make me consider switching.

The value is in the ability to adapt existing types (e.g. from a C library or from other C++ libraries like Eigen) but also QVM lets you write expressions like this: transp(delc<1>(delr<2>(m))) (The above gives you an rvalue that accesses the original matrix m with row 2 deleted, then column 1 of the result deleted, then the result of that transposed.) Such expressions work on 3rd party matrix types without creating any temporaries (so, theoretically without overhead). You can peek at the implementation of delr, delc and transp in https://github.com/zajo/boost-qvm/blob/master/libs/qvm/include/boost/qvm/map... .

Maybe its use as an interop library to stitch disparate libraries together is enough value to include it in boost. But in that case I think maybe a smaller addition to the Boost.Geometry library is more appropriate.

I do not think that there is any commonality between Geometry and QVM. Sure, QVM operations can be used with Geometry types but they can also be used with the types of any other library. -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

On Fri, Jun 26, 2015 at 12:57 AM, Sam Kellett wrote:

...

On Thu, Jun 25, 2015 at 9:35 PM, Michael Marcin wrote:

...

I love swizzling although I dislike this particular syntax.

See http://zajo.github.io/boost-qvm/operator_mod_rationale.html. Basically, I can't think of a better alternative.

What about

v['x'] *= 42; v['yxz'] = 42;

1) Character constants containing more than one character are implementation-defined (not portable). 2) The swizzling dispatch must be done at compile-time. You couldn't do this with an int argument to operator[]. 3) operator[] must be a member function, and QVM operations work on user-defined types. You can, of course, define operator[] in your own types in terms of operator% from QVM. So we're stuck with: v%X *= 42; v%YXZ *= 42; -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

On Fri, Jun 26, 2015 at 7:33 PM, Michael Marcin wrote:

On 6/26/2015 3:42 AM, Emil Dotchevski wrote:

...

1) Character constants containing more than one character are implementation-defined (not portable).

2) The swizzling dispatch must be done at compile-time. You couldn't do this with an int argument to operator[].

3) operator[] must be a member function, and QVM operations work on user-defined types. You can, of course, define operator[] in your own types in terms of operator% from QVM.

So we're stuck with:

v%X *= 42; v%YXZ *= 42;

I'm not a TMP wizard and I haven't looked at your implementation but what about something like.

(v,yz)

https://ideone.com/c4HR8G

This seems better than %, thanks. I need to think carefully if the , overload could somehow interfere with things like passing vectors to other functions. -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

On 6/26/2015 1:30 AM, Emil Dotchevski wrote:

...

Maybe its use as an interop library to stitch disparate libraries together is enough value to include it in boost. But in that case I think maybe a smaller addition to the Boost.Geometry library is more appropriate.

I do not think that there is any commonality between Geometry and QVM. Sure, QVM operations can be used with Geometry types but they can also be used with the types of any other library.

What I mean is Boost.Geometry already has adapters for point types among other things. You are providing adapters for matrix vector and quaternion types. http://www.boost.org/doc/libs/1_58_0/libs/geometry/doc/html/geometry/example... It seems like this aligns extremely closely with the adaption part of your library.

On Fri, Jun 26, 2015 at 11:22 PM, Emil Dotchevski wrote:

On Fri, Jun 26, 2015 at 7:33 PM, Michael Marcin wrote:

...

On 6/26/2015 1:30 AM, Emil Dotchevski wrote: What I mean is Boost.Geometry already has adapters for point types among other things. You are providing adapters for matrix vector and quaternion types.

http://www.boost.org/doc/libs/1_58_0/libs/geometry/doc/html/geometry/example...

...

It seems to me Geometry is about shapes and shape operations and iteration. QVM has nothing to do with shapes or iteration, but it defines a complete set of generic namespace-scope quaternion/matrix/vector operations, which Geometry doesn't. I also think that it shouldn't: if you want to use such operations with Geometry types just use the QVM adaptation machinery

I've always dreamt of boost.geometry supporting 3d, and qvm might be a way to accomplish that. However, it might make the most sense for boost.geometry 3d components to utilize qvm under the hood to implement 3d geometric functionality rather than make qvm part of boost.geometry. Perhaps others can imagine better ways to accomplish these goals. Cheers! Andrew Hundt

Hi, Andrew Hundt schreef op 2-7-2015 om 7:47:

On Fri, Jun 26, 2015 at 11:22 PM, Emil Dotchevski wrote:

...

On Fri, Jun 26, 2015 at 7:33 PM, Michael Marcin wrote:

...

On 6/26/2015 1:30 AM, Emil Dotchevski wrote: What I mean is Boost.Geometry already has adapters for point types among other things. You are providing adapters for matrix vector and quaternion types.

http://www.boost.org/doc/libs/1_58_0/libs/geometry/doc/html/geometry/example... It seems to me Geometry is about shapes and shape operations and iteration. QVM has nothing to do with shapes or iteration, but it defines a complete set of generic namespace-scope quaternion/matrix/vector operations, which Geometry doesn't. I also think that it shouldn't: if you want to use such operations with Geometry types just use the QVM adaptation machinery

I've always dreamt of boost.geometry supporting 3d, and qvm might be a way to accomplish that. However, it might make the most sense for boost.geometry 3d components to utilize qvm under the hood to implement 3d geometric functionality rather than make qvm part of boost.geometry. Perhaps others can imagine better ways to accomplish these goals.

This is indeed exactly what is wished. Boost.Geometry currently uses Boost.UBlas for some vector/matrix operations. But those operations are, actually already from the start, planned to once be replaced and extended, and QVM looks like a good candidate for that. Regards, Barend

On Mon, Aug 3, 2015 at 7:56 PM, Andrew Hundt wrote:

On Mon, May 4, 2015 at 3:06 PM, Emil Dotchevski wrote:

...

Boost QVM defines a set of generic functions and operator overloads for working with quaternions, vectors and matrices of static size. The library also defines vector and matrix data types, however it allows users to introduce their own types by specializing the q_traits, v_traits and m_traits templates.

Online documentation and a link to download the source code under the Boost license is available at http://www.revergestudios.com/boost-qvm/.

I would like to thank Adam Wulkiewicz for volunteering to be the review manager for QVM and for his valuable initial feedback.

Thanks, Emil Dotchevski

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

I was looking at qvm again and I came up with a few additional questions and thoughts:

Is it possible to specialize operations to use the underlying library's implementation at no (or minimal) performance cost? For example, if both matrices in a multiplication are eigen matrices, can the eigen * operator be used by the Boost.QVM function call internally?

There is no need to specialize anything, if your matrices define any operations they will be picked by overload resolution (including by internal QVM functions) since the overloads defined by QVM have a generic signature and any other overload is considered a better match.

- Are there STL iterator adaptors? (might have missed them)

QVM defines indexing through the ir and iw m_traits function templates, but if you use 2x2, 3x3 or 4x4 matrices QVM does not use indexing, all reads and writes are static. In principle iterators could, maybe should be defined.

- Could integration with the basic QVM types for some of the most popular libraries be included (uBLAS, eigen, armadillo, QMatrix, etc)?

Yes, that would be trivial.

- Have you considered Cube support? (see armadillo for example/explanation http://arma.sourceforge.net/)

Cubes are a useful alternative to something like a vector of 4x4 homogenous transforms, particularly when combined with 2d views of the 3d object, or when you have a number of different matrices with different underlying data and the same dimensions. For example 3 matrices that hold R,G,B values of an image, or a dense volumetric representation of the world.

No, I haven't. I'm not familiar with Cubes so it may or may not make sense to include with QVM.

- perhaps a scalar iterator in addition to views? Equivalent to the pixel iterator in gil

http://www.boost.org/doc/libs/1_58_0/libs/gil/doc/html/gildesignguide.html#P... views may simply be superior, however.

Do you mean similarly to the scalar cast QVM view, except that instead of type casting a (user-specified) function is called to convert the elements on request? That seems like a very good idea.

Examples that would be useful:

- Basic example that does something interesting, see boost.geometry's examples for ideas - Basic example converting between two different underlying library's types and performing an operation on them - One liner examples for each of the basic functions, see http://en.cppreference.com/w/cpp/algorithm/copy for an idea of what I mean - Tutorial on how to implement your own generic algorithm with the library with best practices, perhaps SVD - How to integrate an algorithm provided by a 3rd party library, such Eigen's SVD implementation http://eigen.tuxfamily.org/dox/group__SVD__Module.html - How to extend QVM with a new type, for example, dual quaternions or the various geometric types that exist in conformal geometric algebra, such as in versor http://versor.mat.ucsb.edu/#basics

Yes, the documentation does need more examples, thank you for the suggestions, though I'm a bit worried about adapting general algorithms since that steps into general linear algebra territory and I do think that the focus in QVM should remain on, well, Quaternions, Vectors and Matrices. :) That said, it does make sense to provide SVD algorithm in QVM; I'm sure there are a few others like that. Thank you for the feedback! -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode