# multi-dimensional arrays?

9 messages
Open this post in threaded view
|

## multi-dimensional arrays?

 Does glas intend to address multi-dimensional arrays? There seems to be a big disconnect between c++ libraries that support 1d and 2d arrays with various linear algebra support and libraries that support larger dimensionality (usually without any connection to linear algebra).   IMO, this is really unfortunate.  I think we really need either one library that supports both multidimensional arrays and linear algebra or 2 libraries that interoperate well. _______________________________________________ glas mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/glas
Open this post in threaded view
|

## Re: multi-dimensional arrays?

 On Thu, 14 Dec 2006, Neal Becker wrote: > Does glas intend to address multi-dimensional arrays? > > There seems to be a big disconnect between c++ libraries that support 1d and > 2d arrays with various linear algebra support and libraries that support > larger dimensionality (usually without any connection to linear algebra).   > IMO, this is really unfortunate.  I think we really need either one library > that supports both multidimensional arrays and linear algebra or 2 libraries > that interoperate well. The problem, as I see it, is that higher dimensional objects don't allow for the nice notation that vectors and matrices do.  Most tensor libraries I've seen use some sort of index notation, say a[i][j][k] = b[i][j] * c[k] + d[i][m] * e[k][l][m] But for ordinary matrices, this is quite cumbersome.  Is there a nice notation that unifies vectors/matrices with higher dimensional tensors? Hopefully it would not be too hard to have a tensor library where the special cases of 1- and 2-dimensional tensors satisfy the glas vector and matrix concepts though. Nested vectors and matrices are a different case, these should be supported.  Much of it comes naturally, unless you go out of the way to forbid constructing a matrix >.  But there does need to be some extra functionality, for example partial transpose A(i,j)(k,l) -> B(i,k)(j,l).  I don't think this affects the core library much (although I may be wrong) - as long as one keeps in mind that the nested operation might need to be specified eg, for a vector of vectors, you might want to construct the vector of 2-norms of the nested vectors, then construct the 1-norm of that vector, as one operation, say as a lambda expression norm_1(v, norm_2(_1)).  Or maybe norm_1(map(v, norm_2(_1))). Cheers, Ian _______________________________________________ glas mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/glas
Open this post in threaded view
|

## Re: multi-dimensional arrays?

 Hi all, I had to developp my own lib since I could not find any libs dealing with multi-dim vectors in the sense of Vector< Vector<..> >. Those vectors are use with corresponding Matrix < Matrix< .. > >. (block matrices). Such situations arise naturally when the underlying differential equations evolves in a space that is a tensorial product of sub-spaces. For example, de Boltzmann equation space is the phase space which can be seen as a tensorial product of real space and momemtum space. Another example is a Cartesian 2D space which can be seen as X \otimes Y. In this cases, there is no problem with natural notations since a matrix vector product A*X will leads to A(i,j)*X[j] which are again matrix vector products. I know that the GLAS project is still in a design stage but if some of you are interested : I made some interesting (at least for me) experiments on the subject of Expression Template efficiency in the case of large (out of cache) vectors (mono and multi-dim). In short my ET mecanism is specialized to use ATLAS in the case of 1D vectors. The result is that I can type X=a*Y+b*Z (in the multi-dim case) and I obtain results which are better that the corresponding low level loop coding (by +/- 40 %). I also compared these results with blitz and uBlas which (only) provides result as good as the low level loop codes. Regards Laurent _______________________________________________ glas mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/glas
Open this post in threaded view
|

## Re: multi-dimensional arrays?

 In reply to this post by Ian McCulloch Ian McCulloch wrote: >Hopefully it would not be too hard to have a tensor library where the >special cases of 1- and 2-dimensional tensors satisfy the glas vector and >matrix concepts though. > >Nested vectors and matrices are a different case, these should be >supported.  Much of it comes naturally, unless you go out of the way to >forbid constructing a matrix >.  But there does need to be some >extra functionality, for example partial transpose >A(i,j)(k,l) -> B(i,k)(j,l).  I don't think this affects the core library >much (although I may be wrong) >   > I think this is an important point. Toon and I have thought about this for a long time. We will certainly talk about this in detail. Providing the container matrix< matrix > is not hard. I recall that algorithms are application/interpretation dependent, and we had a lively discussion on the list on this topic. So, I agree that 'some' support is needed, although it is not yet clear to me what 'some' here means. Best, Karl Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm_______________________________________________ glas mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/glas Karl.Meerbergen.vcf (344 bytes) Download Attachment
Open this post in threaded view
|

## Re: multi-dimensional arrays?

 Hi Karl, IMHO, the matrix< matrix<..> > can be more or less difficult to implement depending on the constraints you accept. As an example, if you decide that the library must remain open to third party codes and handle different kind of matrix data storage : this is pretty easy to do with simple matrix type (matrix) because the return type of A(i,j) will be a simple ref to double (or const ref). In the 2D case, matrix< matrix > A, the accessor operator A(i,j) will be naturally a ref to matrix. And you loose the compatibility with third party data elements... One can avoid this problem but it is not a trivial issue. Another point in nested matrix issue is that it can help (again IMHO) to validate the very impressive work the GLAS team has done with vector space concepts (HI Peter). For example, the 0 and 1 matrix counter-part are to be efficiently treated. Last point is maybe not a so general issue : In my case, I have to handle sparse matrix with a complicated but highly structured sparsity pattern. This pattern can be express with a reduced set of simple sparsity patterns : e.g A =Dense > > + Sparse > > Best Laurent > I think this is an important point. Toon and I have thought about this > for a long time. We will certainly talk about this in detail. Providing > the container matrix< matrix > is not hard. I recall that algorithms > are application/interpretation dependent, and we had a lively discussion > on the list on this topic. So, I agree that 'some' support is needed, > although it is not yet clear to me what 'some' here means. > > Best, _______________________________________________ glas mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/glas
Open this post in threaded view
|

## Re: multi-dimensional arrays?

 Hi Laurent, Concerning nested matrix and vector types, we need to ask ourselves first if we need special algorithms to handle it or if a least in some cases the operators on the values already use the right algorithm. Second, is the use of operators efficient enough performance-wise?  In a matrix multiplication c(i, k)+= a(i, j) * b(j, k) is correct for any type with consistent operators but not very efficient if a, b, and c are matrices. Unless we have really sophisticated expression templates. Next question, do we need special concepts?  Say e.g. RecursiveTransposable for a recursive function transpose How would it look like? concept RecursiveTransposable {     where RecursiveTransposable;     // ... }; would recursively descent and break if it reaches a scalar value that has no value_type. Conversely, something like: auto // ??? concept RecursiveTransposable {      Matrix transpose(Matrix ); } Now we say this is defined for arithmetic scalars template      where Arithmetic concept_map RecursiveTransposable {} And now enable it from bottom up: template      where RecursiveTransposable concept_map RecursiveTransposable > {} Extending this to block-matrices, (A B) (C D) where A, B, C, and D are matrices of different type. Say we have a type for heterogeneous blocks template hb_matrix { ... }; We can define: template      where RecursiveTransposable          &&  RecursiveTransposable          &&  RecursiveTransposable          &&  RecursiveTransposable concept_map RecursiveTransposable > {} However, this are only some preliminary thoughts.  We need to look, which algorithms we want to implement recursively.  And it looks like   that there can be a great difference between a syntactically correct implementation and a high-performance implementation. Cheers, Peter On 15.12.2006, at 05:49, [hidden email] wrote: > Hi Karl, > > IMHO, the matrix< matrix<..> > can be more or less difficult to > implement > depending on the constraints you accept. As an example, if you decide > that the > library must remain open to third party codes and handle different > kind of > matrix data storage : this is pretty easy to do with simple matrix type > (matrix) because the return type of A(i,j) will be a simple > ref to > double (or const ref). In the 2D case, matrix< matrix > A, the > accessor > operator A(i,j) will be naturally a ref to matrix. And you > loose the > compatibility with third party data elements... > One can avoid this problem but it is not a trivial issue. > > Another point in nested matrix issue is that it can help (again IMHO) > to > validate the very impressive work the GLAS team has done with vector > space > concepts (HI Peter). For example, the 0 and 1 matrix counter-part are > to be > efficiently treated. > > Last point is maybe not a so general issue : In my case, I have to > handle sparse > matrix with a complicated but highly structured sparsity pattern. This > pattern > can be express with a reduced set of simple sparsity patterns : e.g A > =Dense > > + Sparse > > > > > Best > > Laurent > > >> I think this is an important point. Toon and I have thought about this >> for a long time. We will certainly talk about this in detail. >> Providing >> the container matrix< matrix > is not hard. I recall that >> algorithms >> are application/interpretation dependent, and we had a lively >> discussion >> on the list on this topic. So, I agree that 'some' support is needed, >> although it is not yet clear to me what 'some' here means. >> >> Best, > > > > _______________________________________________ > glas mailing list > [hidden email] > http://lists.boost.org/mailman/listinfo.cgi/glas> ------------ Peter Gottschling, Ph.D. Research Associate Open Systems Laboratory Indiana University 135 Lindley Hall Bloomington, IN 47405 Tel.: +1-812-855-3608   Fax: +1-812-856-0853 http://www.osl.iu.edu/~pgottsch_______________________________________________ glas mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/glas
Open this post in threaded view
|