Glas List: Re: [glas] arithmetic operations

From: Karl Meerbergen (Karl.Meerbergen_at_[hidden])
Date: 2005-11-07 10:03:59

Guntram Berti wrote:

>On Fri, Oct 28, 2005 at 08:14:46AM -0500, Andrew Lumsdaine wrote:
>  
>
>>On Oct 28, 2005, at 2:23 AM, Karl Meerbergen wrote:
>>    
>>
>
>
>  
>
>>>To make the choice easier, we could assume that a vector is a column 
>>>(as
>>>is always the case in linear algebra). In this case
>>>trans(x)*y = dot product
>>>x*trans(y) = outer product
>>>herm(x)*y = hermitian inner product
>>>
>>>This is probably the closest we can get to linear algebra notation.
>>>      
>>>
>>Right.  I think these all make perfect sense mathematically.  I wasn't 
>>suggesting to leave out the use of * altogether, but rather to use it 
>>only in the ways that make sense mathematically.  And to have it always 
>>mean the same thing.
>>
>>    
>>
>
>Another point to note is that if we use * on unqualified vectors like u*v
>for the dot (inner) product, we loose associativity:
>(u*v)*w != u*(v*w)
>(if we assume * also is used for the multiplication with a scalar).
>Therefore I personally never use * for the dot product.
>
>So if we use operators like *, we must make sure (in addition to corresponding
>to mathemtical convention) that its use is 100% unambigous and can be deduced from the types.
>So Karl's suggestion, using trans(x)*y etc. seems to make sense,
>because then any multiplication involving non-scalar quantities 
>is formally a matrix multiplication, and errors can be detected easily (at least at
>run time).
>

It is close to the notation that matlab uses. I have added an 
orientation_type to the attribute of a collection. This allows the 
compiler to select the inner or outer product algorithm when a * is 
encountered:
  column_orientation * row_orientation : outer prod, or cross prod
  row_orientation * column_orientation : inner or dot prod
When the two vectors have the same orientation, a compiler error should 
be generated.

>If we want an operator for element-wise multiplication, we must then
>use something like elem(v) * elem(w) (to keep with Karl's notation)
>or elemwise_mul(v,w), as has been suggested before.
>
>
>Concerning the dot product: If we overload the comma operator,
>we can probably use the notation (v,w) common in mathemetics ;-)
>(just kidding ...)
>
>
>Another remark/idea concerning the inner product (also concerning norms):
>Sometimes it may be useful to make this a parameter of an algorithm,
>for instance, using different norms to compute stopping criteria,
>or orthonormalization using different inner products.
>This is perhaps an argument for preferring inner_prod(v,w)
>over a notation using operator *, because I feel that it is easier
>to influence the former using template parameters. 
>Perhaps something like space::inner_product(v,w) ...
>

The one does not exclude the other: even with the * notation, we can 
have a function or functor dot() that can serve for this purpose. 
Although I could use an inner product and norm templated function in 
some Krylov and related stuff, I am not very enthousiastic to support 
this by GLAS. I think GLAS should focus on vector and matrix operations. 
I consider orthogonalization (by Gram-Schmidt and its derivatives) an 
application and not the core of GLAS. We could, of course, build a layer 
on top of GLAS that helps the implementation of specific applications, a 
kind of toolbox organization, e.g. iterative methods, ode, etc.

Karl