On Thu, Jun 25, 2015 at 9:35 PM, Michael Marcin
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