QuoteOriginally posted by: CuchulainnQuoteOriginally posted by: outrunCuch, Polter,For tensor layouts, I'm thinking of translating the row/col major concept to either traversal by coordinates left to right, or right to left, -no permutations-.Have you used (semi) banded tensorts? What is the non-zero structure, any proposals other than full dense? Symmetric? What sort of symmetric?No. Dense is fine. Have you looked at multi_array?Cuch, you've mentioned the tridiagonal matrices (v. relevant for numerical PDE solution methods), should we have an interface accounting for this sparse structure?

QuoteOriginally posted by: PolterQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: outrunCuch, Polter,For tensor layouts, I'm thinking of translating the row/col major concept to either traversal by coordinates left to right, or right to left, -no permutations-.Have you used (semi) banded tensorts? What is the non-zero structure, any proposals other than full dense? Symmetric? What sort of symmetric?No. Dense is fine. Have you looked at multi_array?Cuch, you've mentioned the tridiagonal matrices (v. relevant for numerical PDE solution methods), should we have an interface accounting for this sparse structure?Yes. They are used in ADI, Splitting, Crank Nicolson (in some cases 3 vertices internally works in combination with Thomas' algo).

multi_array has dense structure only AFAIK.

QuoteOriginally posted by: outrunAnother design choice would be that if we use a vector to store our matrix elements, then we assume that the memory doesn't gets resized or moved. The same restrictions that iterators have. If we *do* want to resize the underlying vector, then we need to rebind our interface (update the pointer to begin of memory. This will be hidden for matrices that have ther own iternal storage, bur not for these bound interfaces, not for iterators in general. Is that smart to do?I think numerical analysis applications can live well without having to resize the matrix.

QuoteOriginally posted by: outrun I was thinkin to support compile time NxM and see if we can get a little extra performance, but that's for version 2.QuoteOriginally posted by: Cuchulainn I think numerical analysis applications can live well without having to resize the matrix.outrun -- an excellent idea, and what Cuch notes is very valid; at the same time we also might want to keep in mind that there are trade-offs involved here and the fixed-sized objects are not always superior choice even assuming that we know N & M at compile time -- here's an example of what I mean and the choices made regarding the above-mentioned trade-offs in case of Eigen:Fixed vs. Dynamic sizehttp://eigen.tuxfamily.org/dox-devel/TutorialMatrixClass.html#TutorialMatrixFixedVsDynamic"When should one use fixed sizes (e.g. Matrix4f), and when should one prefer dynamic sizes (e.g. MatrixXf)? The simple answer is: use fixed sizes for very small sizes where you can, and use dynamic sizes for larger sizes or where you have to. For small sizes, especially for sizes smaller than (roughly) 16, using fixed sizes is hugely beneficial to performance, as it allows Eigen to avoid dynamic memory allocation and to unroll loops. Internally, a fixed-size Eigen matrix is just a plain static array [...]The limitation of using fixed sizes, of course, is that this is only possible when you know the sizes at compile time. Also, for large enough sizes, say for sizes greater than (roughly) 32, the performance benefit of using fixed sizes becomes negligible. Worse, trying to create a very large matrix using fixed sizes could result in a stack overflow, since Eigen will try to allocate the array as a static array, which by default goes on the stack. Finally, depending on circumstances, Eigen can also be more aggressive trying to vectorize (use SIMD instructions) when dynamic sizes are used, see Vectorization."Consequently, the support for "fixed-size vectorizable Eigen objects" doesn't extend beyond a certain size threshold for a reason:http://eigen.tuxfamily.org/dox-devel/To ... mlThoughts?

Ah, something like Eigen::Map -- http://eigen.tuxfamily.org/dox-devel/cl ... _1Map.html (not responsible for managing memory (which is given) but only mapping ("binding"?) it to an interface consistent with the remaining Eigen linear algebra API) -- ?

Yes! I think this is a very useful and important functionality. I've used this for an interface simplification (and poor man's move semantics) where I had a bunch of (large, containing financial time-series data) Eigen::Vectors that needed to be passed through an API that wanted _one_ array, block of data -- now, constructing std::vector of Eigen::Vectors would involve copying (with no C++11 move semantics being implemented for the objects involved) and possibly kill the performance and/or the application (annoyingly, memory is finite...), but std::vector of Eigen::Maps (with each Eigen::Map associated to an Eigen::Vector) turned out to be the way to go -- both fast and simple on the code & interface (as well as hardware) requirements.