Re: [boost] [gsoc18][ublas] Proposal to add advanced matrix operations

pon., 22 sty 2018 o 11:16 użytkownik Hans Dembinski via Boost < boost@lists.boost.org> napisał:

Hi David, Rajaditya, Artyom, Shikhar,

...

On 21. Jan 2018, at 13:00, David Bellot via Boost wrote:

I used the library in projects and it is very convenient. You just write your expressions as you would on paper and let Eigen generate the fastest possible code out of that. I only dislike that Eigen does not play well with "auto" since C++11, because they use the assignment to a matrix or vector to trigger the evaluation of the expression template.

As far as I know, direct usage of auto is not possible in any Expression Templates library since the assigment triggers an evaluation, as you already noticed. It's a minor inconviencen since it requires from the you user to know if final type of an expression should be a matrix or a vector. It might be a larger problem in a library which provides specialized types for matrices of different shapes, such as: symmetric, upper/lower triangular, diagonal. Such types are benefitial since it helps the library to find a more optimized kernel, e.g. use trmm instead of gemm for a matrix-matrix product if one of operands is lower/upper triangular. Then, the return type of an expression depends on types of input matrices and the actual computation and one should not expect from the user to be able to guess it correctly. As far as I know, only Blaze implements specialized types called adaptors (Eigen has views but their applicability is rather limited). Fortunately, there should be an easy solution available in each library. Each ET library should have a return type implemented in each expression node. Then, it is possible to implement a simple evaluate function: template<typename Expr> typename Expr::expression_type evaluate(Expr && expr) { return typename Expr::expression_type(expr); } It should always enforce the evaluation of an expression and one can safely return an expression from a function without knowing the actual type. Best regards, Marcin

I haven't done it myself, but Eigen seems to have a good strategy for adding new features, too. People can start to develop their stuff in an "unsupported" subdirectory, which is not meant for production, but the code is nevertheless distributed with Eigen. This helps to exposes the experimental code to more adventurous users. Eventually, a project that passed the test of time can move from "unsupported" to the main library.

Best regards, Hans

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