-----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