Re: [ublas-dev] Re: [boost] Re: Boost Mathematicians
On Jul 5, 2004, at 11:54 AM, Peter Schmitteckert wrote:
Salut,
(note that I only use the dense matrices of ublas)
On Mon, 5 Jul 2004, Toon Knapen wrote:
This is just a matter of documentation. AFAIK there is no accepted concept that demands 'num_rows' and 'num_columns'. The '1' and '2' refer to the first and second index which is also a nice convention IMO.
I prefer size1 and size2, since it fits to the sheme of having a tensor structure with a size3.
Mixing up abstractions is not a good idea. Matrices and tensors are different creatures. True, sometimes it is useful to think of a tensor as a matrix, and having adaptors or views that allow for this is a good thing. The names we use for operations should match the common terminology from the problem domain. In this case, the common terminology is rows and columns. When we create concepts for tensors, we can use size1, etc.
Columns and Rows can lead to confusion concernig storage layout.
I disagree.
* iterator1 and iterator2 should be named column_iterator and row_iterator or something memnonic.
same as above.
same as above.
* prod should be named operator*; this is a linear algebra library after all.
Mmmh, this open pitfalls concerning A*B*C in performance issues for non experts.
No, the right way to handle this is to have the expression template machinery identify that a temporary is needed, and create one automatically. Cheers, Jeremy _______________________________________________ Jeremy Siek <jsiek@osl.iu.edu> http://www.osl.iu.edu/~jsiek Ph.D. Candidate, Indiana University Bloomington C++ Booster (http://www.boost.org) _______________________________________________
Jeremy Graham Siek writes:
On Jul 5, 2004, at 11:54 AM, Peter Schmitteckert wrote:
Salut,
(note that I only use the dense matrices of ublas)
On Mon, 5 Jul 2004, Toon Knapen wrote:
This is just a matter of documentation. AFAIK there is no accepted concept that demands 'num_rows' and 'num_columns'. The '1' and '2' refer to the first and second index which is also a nice convention IMO.
I prefer size1 and size2, since it fits to the sheme of having a tensor structure with a size3.
Mixing up abstractions is not a good idea. Matrices and tensors are different creatures. True, sometimes it is useful to think of a tensor as a matrix, and having adaptors or views that allow for this is a good thing.
The names we use for operations should match the common terminology from the problem domain. In this case, the common terminology is rows and columns.
Neither 'size1' nor 'num_rows' are generic, though. What you want is something like template< int n > size(int_<n>); The particular int_<n> specializations then can be typedef'ed to something more mnemonic, e.g. typedef int_<0> rows; or even extern int_<0> rows; The lack of this genericity will force you, sooner or later, to resort to code duplication. I believe Vesa made the same point a long time ago... yep: http://thread.gmane.org/gmane.comp.lib.boost.devel/60338. -- Aleksey Gurtovoy MetaCommunications Engineering
Hi Aleksey, You are confusing the matrix abstraction with the multi-dimensional array abstraction. A *linear algebra* algorithm will never need to be generalized in the fashion you advocate below. That's because matrices are about systems of equations. A system of equations has a certain number of unknowns and a certain number of equations. Once the system is represented as a matrix, the number of rows corresponds to the number of equations, and the number of columns corresponds to the number of unknowns. That's it. There's no more numbers to talk about. Another way to look at this is to focus on the mathematical concept *Linear Operator*. A linear operator is something that you can multiply with a vector of a certain size to get another vector of a certain size. The "number of columns" of the linear operator is the required size of the input vector, and the "number of rows" of the linear operator is the required size of the output vector. Best Regards, Jeremy On Jul 5, 2004, at 6:04 PM, Aleksey Gurtovoy wrote:
Neither 'size1' nor 'num_rows' are generic, though. What you want is something like
template< int n > size(int_<n>);
The particular int_<n> specializations then can be typedef'ed to something more mnemonic, e.g.
typedef int_<0> rows;
or even
extern int_<0> rows;
The lack of this genericity will force you, sooner or later, to resort to code duplication. I believe Vesa made the same point a long time ago... yep: http://thread.gmane.org/gmane.comp.lib.boost.devel/60338.
-- Aleksey Gurtovoy MetaCommunications Engineering
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Jeremy Siek <jsiek@osl.iu.edu> http://www.osl.iu.edu/~jsiek Ph.D. Candidate, Indiana University Bloomington C++ Booster (http://www.boost.org) _______________________________________________
Jeremy Graham Siek writes:
Hi Aleksey,
Hi Jeremy,
You are confusing the matrix abstraction with the multi-dimensional array abstraction.
I don't think so :).
A *linear algebra* algorithm will never need to be generalized in the fashion you advocate below.
On the contrary, I think one can come up with numerous examples proving the opposite. For instance: template< int i, int j, typename M > bool is_triangular( M const& m ) { for ( typename index_type<M,i>::type k(0); k < m.size(int_<i>()); ++k ) for ( typename index_type<M,j>::type l(0); l < value(k); ++l ) if ( m[k][l] != 0 ) return false; return true; } template< typename M > bool is_upper_triangular( M const& m ) { return is_triangular<0,1>( m ); } template< typename M > bool is_lower_triangular( M const& m ) { return is_triangular<1,0>( m ); } -- Aleksey Gurtovoy MetaCommunications Engineering
Hi Aleksey, On Jul 5, 2004, at 9:34 PM, Aleksey Gurtovoy wrote:
A *linear algebra* algorithm will never need to be generalized in the fashion you advocate below.
On the contrary, I think one can come up with numerous examples proving the opposite. For instance:
The below algorithm is not a linear algebra algorithm in the sense that it is not defined in terms of linear algebra operations, such as addition and multiplication. The below algorithm operates at a slightly lower level of abstraction. I agree that for that level, it is sometimes convenient to ignore the row/column distinction. MTL-2 provides an alternative interface that provides for this capability. Note however, you've still only got 2 dimensions.
template< int i, int j, typename M > bool is_triangular( M const& m ) { for ( typename index_type<M,i>::type k(0); k < m.size(int_<i>()); ++k ) for ( typename index_type<M,j>::type l(0); l < value(k); ++l ) if ( m[k][l] != 0 ) return false;
return true; }
template< typename M > bool is_upper_triangular( M const& m ) { return is_triangular<0,1>( m ); }
template< typename M > bool is_lower_triangular( M const& m ) { return is_triangular<1,0>( m ); }
-- Aleksey Gurtovoy MetaCommunications Engineering
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Jeremy Siek <jsiek@osl.iu.edu> http://www.osl.iu.edu/~jsiek Ph.D. Student, Indiana University Bloomington C++ Booster (http://www.boost.org) _______________________________________________
Salut, On Tuesday 06 July 2004 03:06, Jeremy Graham Siek wrote:
A *linear algebra* algorithm will never need to be generalized in the fashion you advocate below. That's because matrices are about systems of equations. A system of equations has a certain number of unknowns and a certain number of equations. Once the system is represented as a matrix, the number of rows corresponds to the number of equations, and the number of columns corresponds to the number of unknowns. That's it. There's no more numbers to talk about.
Here I have to disagree. But the problem lies in the fact, that I'm a theoretical physicist, who learned numerics by doing. For me, matrices are far more, than just objects used to solve linear set of equations. Matrices are representations of algebras, they can be fused (e.g. tensor products), and one can calculate general functions on matrices, like the matrix exponential. In my work, vectors have double indices, i.e. a matrix has four indices, but it is still a matrix, the double index is just an implementation feature, since vectors are representated by a dyadic product of other vectors. You can now argues, wether this is still a vector, but in physics it is called a vector.
Another way to look at this is to focus on the mathematical concept *Linear Operator*. A linear operator is something that you can multiply with a vector of a certain size to get another vector of a certain size. The "number of columns" of the linear operator is the required size of the input vector, and the "number of rows" of the linear operator is the required size of the output vector.
I agree with you, if you restrict matrices to linear algebra. That's a fine definition. But I'm used to use the notion 'matrix' in a more general sense. Best wishes, Peter
On Jul 6, 2004, at 9:51 AM, Peter Schmitteckert (boost) wrote:
On Tuesday 06 July 2004 03:06, Jeremy Graham Siek wrote:
A *linear algebra* algorithm will never need to be generalized in the fashion you advocate below. That's because matrices are about systems of equations. A system of equations has a certain number of unknowns and a certain number of equations. Once the system is represented as a matrix, the number of rows corresponds to the number of equations, and the number of columns corresponds to the number of unknowns. That's it. There's no more numbers to talk about.
Here I have to disagree. But the problem lies in the fact, that I'm a theoretical physicist, who learned numerics by doing. For me, matrices are far more, than just objects used to solve linear set of equations. Matrices are representations of algebras, they can be fused (e.g. tensor products), and one can calculate general functions on matrices, like the matrix exponential.
In my work, vectors have double indices, i.e. a matrix has four indices, but it is still a matrix, the double index is just an implementation feature, since vectors are representated by a dyadic product of other vectors. You can now argues, wether this is still a vector, but in physics it is called a vector.
As another theoretical physicist I want to disagree with this definition. I would call the object with four indices a linear operator, but not a matrix. Matrices for me are representation of linear operators with two indices. You however point out an important requirement for generic algorithms on vector spaces: they should not require that a vector can be accessed with operator[] and a single subscript, or that once can construct a vector by passing just the size to the constructor. These too narrow requirements of the Iterative Template Library ITL, caused us to introduce the "vector space" concept in the our Iterative Eigenvalue Template Library IETL. Matthias
Salut, On Tuesday 06 July 2004 11:54, Matthias Troyer wrote: [...]
You can now argues, wether this is still a vector, but in physics it is called a vector.
As another theoretical physicist I want to disagree with this
Sorry for beeing unclear. I wanted to say, "in my special problem, it is a vector". I didn't want to claim that in general.
definition. I would call the object with four indices a linear operator, but not a matrix. Matrices for me are representation of linear operators with two indices.
As I said, that's a matter of taste, convention, education and notation, and it's fine with me.
You however point out an important requirement for generic algorithms on vector spaces: they should not require that a vector can be accessed with operator[] and a single subscript, or that once can construct a vector by passing just the size to the constructor. These too narrow requirements of the Iterative Template Library ITL, caused us to introduce the "vector space" concept in the our Iterative Eigenvalue Template Library IETL.
I agree. Best wishes, Peter
Hi Matthias, Yes, I agree that's an important generalization. On Jul 6, 2004, at 4:54 AM, Matthias Troyer wrote:
You however point out an important requirement for generic algorithms on vector spaces: they should not require that a vector can be accessed with operator[] and a single subscript, or that once can construct a vector by passing just the size to the constructor. These too narrow requirements of the Iterative Template Library ITL, caused us to introduce the "vector space" concept in the our Iterative Eigenvalue Template Library IETL.
Matthias
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Jeremy Siek <jsiek@osl.iu.edu> http://www.osl.iu.edu/~jsiek Ph.D. Student, Indiana University Bloomington C++ Booster (http://www.boost.org) _______________________________________________
Hi Peter, On Jul 6, 2004, at 2:51 AM, Peter Schmitteckert (boost) wrote:
I agree with you, if you restrict matrices to linear algebra. That's a fine definition. But I'm used to use the notion 'matrix' in a more general sense.
Yes... the term "matrix" has a multitude of meanings, all of which are confusingly similarly but slightly different. However, the current topic of conversation is a linear algebra library. Thus it makes sense for the purpose of this conversation to restrict the meaning to that of traditional linear algebra. Believe me, I'm not trying to exclude physicists or anyone. I'm highly in favor of there being lots of numerical libraries in Boost. There can even be many different concepts with the name "Matrix", they'll just be in different namespaces. All I'm saying is that the concept named "Matrix" in the linear algebra namespace should have the standard linear algebra meaning and syntax. Cheers, Jeremy _______________________________________________ Jeremy Siek <jsiek@osl.iu.edu> http://www.osl.iu.edu/~jsiek Ph.D. Student, Indiana University Bloomington C++ Booster (http://www.boost.org) _______________________________________________
On Tue, 6 Jul 2004 10:31:23 -0500, Jeremy Siek <jsiek@osl.iu.edu> wrote:
Believe me, I'm not trying to exclude physicists or anyone. I'm highly in favor of there being lots of numerical libraries in Boost. There can even be many different concepts with the name "Matrix", they'll just be in different namespaces.
Does this imply that a library such as libcalc.sourceforge.net which has bit of overlap with uBLAS but is targeted towards those who want some quick to use matrices would be a canidate for boost? David Sankel
Dear Jeremy, On Tuesday 06 July 2004 17:31, Jeremy Siek wrote:
Yes... the term "matrix" has a multitude of meanings, all of which are confusingly similarly but slightly different. However, the current topic of conversation is a linear algebra library. Thus it makes sense for the purpose of this conversation to restrict the meaning to that of traditional linear algebra.
This was not clear for me from the beginning, since I came aware of the discussion due to cross-posting to ublas-dev.
Believe me, I'm not trying to exclude physicists or anyone. I'm highly
don't worry, I think nobody ever assumed this,
in favor of there being lots of numerical libraries in Boost. There can even be many different concepts with the name "Matrix", they'll just be in
But we should avoid an explosion of matrix libraries, since users than have to evaluate them, to find the one fit their needs best.
different namespaces. All I'm saying is that the concept named "Matrix" in the linear algebra namespace should have the standard linear algebra meaning and syntax.
However, it would be nice to be aware of usage beyond 'standard linear algebra', and whenever possible, one should try to enable those applications. Best wishes Peter
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Jeremy Graham Siek Sent: Monday, July 05, 2004 3:12 PM To: ublas-dev@yahoogroups.com Cc: Boost mailing list Subject: Re: [ublas-dev] Re: [boost] Re: Boost Mathematicians
On Jul 5, 2004, at 11:54 AM, Peter Schmitteckert wrote:
Salut,
(note that I only use the dense matrices of ublas)
On Mon, 5 Jul 2004, Toon Knapen wrote:
This is just a matter of documentation. AFAIK there is no accepted concept that demands 'num_rows' and 'num_columns'. The '1' and '2' refer > to the first and second index which is also a nice convention IMO.
I prefer size1 and size2, since it fits to the sheme of having a tensor structure with a size3.
Mixing up abstractions is not a good idea. Matrices and tensors are different creatures. True, sometimes it is useful to think of a tensor as a matrix, and having adaptors or views that allow for this is a good thing.
Good point, and one that's often lost in the way tensor analysis and matrix theory are are taught. Matrices are a mathematical object with their own properties, as are tensors. That it happens that the range of objects that populate tensor cross-product spaces can be represented nicely, or at least, usefully, as matrices is a nice bit of synchronicity.
The names we use for operations should match the common terminology from the problem domain. In this case, the common terminology is rows and columns.
When we create concepts for tensors, we can use size1, etc.
Columns and Rows can lead to confusion concernig storage layout.
I disagree.
Gonna support (Peter, I think...lost track of who said what...which is the top-posting thread ;) ) on this one. I suppose my main argument would be that there isn't generally a unique matrix representation of a generalized tensor, especially those of higher rank and mixed order. As an example, check through any book on classical mechanics and check the little tricks commonly played with matrix representations in the name of making it easier to understand (which it sort of does).
* iterator1 and iterator2 should be named
column_iterator and > > > row_iterator or something memnonic. > same as above. > > same as above. > > > > > > > > > * prod should be named operator*; this is a linear algebra > library > > after all. > > Mmmh, this open pitfalls concerning A*B*C in performance issues for > non experts.
No, the right way to handle this is to have the expression template machinery identify that a temporary is needed, and create one automatically.
From a C++ standpoint, that one's on the money (have to turn in my copy of the spec if I didn't agree with that one ;) ).
Reid
participants (1)
-
Aleksey Gurtovoy -
David Sankel -
Jeremy Graham Siek -
Jeremy Siek
-
Matthias Troyer -
Peter Schmitteckert (boost) -
Reid Sweatman