On Wed, Jul 2, 2014 at 4:45 PM, Adam Wulkiewicz wrote:

Hi Fabien,

2014-07-02 16:36 GMT+02:00 Fabien Picarougne < fabien.picarougne@univ-nantes.fr>:

...

Hi,

I have developed a generic matrix library with some specialization for 3D operations. I wondering if it would be of interest for me to submit it as a Boost library.

There are some differences compared to the current ublas/matrix class. The dimensions of this matrix are template parameters, this allows to make specializations for particular dimensions and efficiency in some combinations of parameters.

This library takes advantage of some C++11 elements and so requires a C++11 enabled compiler. I have tested it with gcc 4.8.2 and MSVC 2013.

It contains a generic global matrix class (CMat) which can be specialized in a number of matrix (square matrix, vectors, 4x4 matrix.) in order to use more efficient algorithms or adding particular methods. Because I use it in a 3D rendering engine, I have built a specific CMat4x4 class with standard 3D operators on matrix and vectors.

I have posted the current code here: https://bitbucket.org/fpicarougne/template-matrix-library

In order to use all the specializations, include "Matrix/CMat3D.hpp" and take a look to "Matrix.cpp" for an example of usage.

Your proposal is closer to the QVM library ( http://www.revergestudios.com/boost-qvm/) already proposed for inclusion into Boost than to uBlas. Have you checked it out? Your work could be a nice extension of this library. In particular, Matrix and Vector concepts from QVM could be used and specializations of algorithms optimized for some specific Matrices sizes dispatched in compile-time. Emil what do you think?

The QVM library is more generic. In my experience, while the interface of the operations of a vector/matrix library can be standardized, it is often impractical to standardize the vector and matrix types themselves, because different use cases demand different compromise between ease of use and performance. For example, 16 or 32-byte alignment may result in maximum speed but that isn't always the best option. That's why the emphasis in the QVM library is on the generic nature of the operations: they are independent of any types and can kick-in for any user-defined or third-party matrix/vector types (and of course types that QVM itself emits). This allows developers to define platform-, project- or even module-specific types and the full set of QVM operations become available automatically. Later, if necessary, profiler-guided optimizations can target only a critical subset of the types and the operations; e.g. one can overload to optimize only operator*, and only for some aligned_mat44 type (overload resolution will always prefer such user-defined overloads over the QVM overloads.) -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

Thank you for your very interesting remarks. I did not know the QVM library and I have spent a little time to understand it. Initially, Traits was in my future plans, but the work that has been done on QVM is more developed that what was in my mind. But, in my understanding, there are some differences in our two approaches. I understand the intent of QVM and I agree with that. In my case, the main objective was to factor methods (to avoid writing the same thing twice) and to do a maximum of calculations during compile time. It explains the global usage of CRTP in my classes. I think there is another difference in the design of both library in the usage of specialization. In what I understand, QVM uses enable_if pattern to achieve this specialization, and I use template specialization. I see here some advantages of both approaches: you can group different specializations in a single class in QVM (and not in my library) and you group specializations for a particular type in my library (I guess it can also be done in a way in QVM). But I cannot honestly say here what paradigm is the best... Regards, Fabien -----Message d'origine----- De : Boost [mailto:boost-bounces@lists.boost.org] De la part de Adam Wulkiewicz Envoyé : jeudi 3 juillet 2014 14:35 À : boost@lists.boost.org Objet : Re: [boost] Interest in a new generic matrix library with specific 3D operations? Emil Dotchevski wrote:

The QVM library is more generic.

In my experience, while the interface of the operations of a vector/matrix library can be standardized, it is often impractical to standardize the vector and matrix types themselves, because different use cases demand different compromise between ease of use and performance. For example, 16 or 32-byte alignment may result in maximum speed but that isn't always the best option.

That's why the emphasis in the QVM library is on the generic nature of the operations: they are independent of any types and can kick-in for any user-defined or third-party matrix/vector types (and of course types that QVM itself emits).

This allows developers to define platform-, project- or even module-specific types and the full set of QVM operations become available automatically. Later, if necessary, profiler-guided optimizations can target only a critical subset of the types and the operations; e.g. one can overload to optimize only operator*, and only for some aligned_mat44 type (overload resolution will always prefer such user-defined overloads over the QVM overloads.)

Yes, the QVM design is more generic. This is why I proposed to use the concepts from this library in the implementation of the algorithms. To be more precise, I thought about domain-specific algorithms. In this case from computer graphics but tools for other domains like robotics or physics could be implemented as well, e.g.: - functions for handling view and perspective (implemented by Fabien as SetOrtho(), SetFrustum(), SetLookAt(), etc.), - some generic Rotation concept allowing to represent it (in 3D) as axis-angle, matrix3x3 or quaternion, which could just be simply applied to e.g. a Vector in a unified way, - the conversions between various representations, - similar thing with Orientation - rotation + translation (e.g. matrix3x4 or quaternion and a vector), - similar thing with Transformation - the above + scale (e.g. matrix4x4 or quaternion and some vectors), - differential operators like gradient, divergence, etc. and probably a VectorField concept, - most certainly many more... Of course we should debate if and where such domain-specific algorithms could be put. But this is also true for QVM I guess. A little off-topic... Would it be difficult to extend QVM to use e.g. Boost.SIMD in the future? E.g. provide additional traits defining the alignment of the data and use vectorization accordingly? Regards, Adam _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost