RE: [ublas-dev] Re: [boost] Re: Boost Mathematicians

From: Reid Sweatman (drunkardswalk_at_[hidden])
Date: 2004-07-05 18:27:12

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Jeremy Graham Siek
> Sent: Monday, July 05, 2004 3:12 PM
> To: ublas-dev_at_[hidden]
> 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