Is there a reason for frequent use of unsigned integer literals in Blaze?

[Paul Jurczak]

In my search for a modern C++ multidimensional array library, frequent use of unsigned integer literals and variables in Blaze seemed a bit quirky, e.g. StaticMatrix<int,3UL,2UL,columnMajor> B{ { 3, -1 }, { 0, 2 }, { -1, 0 } };` when StaticMatrix<int, 3, 2, columnMajor> B{{3, -1}, {0, 2}, {-1, 0}};` works just fine. My first thought was that it is mandatory, which would be a minor argument against adopting Blaze.

Seeing unsigned int in declarations and loop examples reminds me of Bjarne Stroustrup’s paper “Don’t add to the signed/unsigned mess” (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1491r0.pdf). Is there a particular reason for this choice?

[Klaus Iglberger]

Hi Paul!

Thanks for taking the time to creating this issue. You are the first person to “complain” about using the correct type of literal in the usage of our types. Blaze follows the conventions of the standard library (see for instance std::array), but also tries to provide a correct and comprehensible documentation. You are correct that it is absolutely sufficient to use an int to specify the extents of a StaticMatrix, but from our point of view the documentation should reflect the actual type, which in this case is a size_t.

I hope that you consider this as a minor detail in comparison to the big advantages that Blaze would provide to you. These include an impressive performance (especially for tiny and small vectors and matrices; see our Benchmark section), parallel execution, and an amazing extensibility and customizability (see for instance the Customization pages in the wiki and in particular the map() functions).

I hope that this answers the question,

Best regards,

Klaus!

[Paul Jurczak]

Hi Klaus,

Thank you for the detailed response. You are right, this is a minor stylistic issue forced upon us by some early C++ language design decisions. I will code a bit with Blaze to find how it fits in my problem domain. So far, it looks great!

Regards,

Paul