## Glas :## Re: [glas] arithmetic operations |

**From:** Theodore Papadopoulo (*Theodore.Papadopoulo_at_[hidden]*)

**Date:** 2005-10-27 08:58:18

**Next message:**Wolfgang Bangerth: "Re: [glas] arithmetic operations"**Previous message:**Karl Meerbergen: "[glas] arithmetic operations"**In reply to:**Karl Meerbergen: "[glas] arithmetic operations"**Next in thread:**Wolfgang Bangerth: "Re: [glas] arithmetic operations"

On Thu, 2005-10-27 at 13:52 +0200, Karl Meerbergen wrote:

> Hello,

>

>

> I would like to discuss the syntax of arithmetic operations on

> vectors/matrices (collections).

>

> Matlab allows exp(v), sin(v), cos(v) etc on vectors (matrices) and the

> result is a vector (matrix) where the function is applied on each entry.

>

> Fortran95 goes one step further uses operations for scalars (+, *, -, /,

> abs, conj, ...) on vectors (matrices) where the result is a vector

> (matrix) whose elements are the result of the scalar operation on the

> respective elements of the argument collections.

> E.g. v * w is a new vector (or vector expression) where each entry is

> the product of the two corresponding entries in v and w. Operations that

> require interaction between elements of a vector (matrix) have specific

> function names, e.g sum(v) computes the sum of the elements of v, e.g.

> sum(abs(v)) is the 1-norm, and max(abs(v)) the inf-norm.

>

> I like this approach because it induces operations from the value_type

> to the collection.

>

> It also opens some possibilities that we have not thought of.

> For example, x = v * w * z

> is equivalent to a loop over all elements of x where the corresponding

> elements of v, w, and z are multiplied.

> sum(v*w) is the same as dot(v,w), and also sum(v*w*z) makes sense.

>

> It does not imply we have to forget about the function dot() or norm_1()

>

> v<w would then be a collection of bool. And (v<w) && (x>=z) also is a

> collection of bool.

>

> But what is v==w? If we are consistent, it also is a collection of bool.

> In order to test equality we should have to write min_elt(v==w) or

> perhaps better and(v==w). There is no loss of efficiency with the

> traditional v==w. This is all a matter of dispatching function calls.

>

> I quite like this approach, because the collection inherits operations

> from the value_type in a very intuitive way. (I repeat myself, so I

> really like it, don't I ;-) )

But how would you do the product of two matrices ?? The element-wise

product is not very interesting and you cannot deduce the regular matrix

product from it. The exponential or the log of a matrix has a meaning

which does not correspond to applying the function element-wise either

(here matlab is not so consistent because it does what you say for

function but reserves the standard operators for their standard meaning

and introduces new operators for element-wise operations .*).

In my opinion, because in C++ we cannot create new operators, we should

use them for the most standard and useful meaning (ie linear algebra

operations). Indeed, it might happen that the element-wise way is useful

(imagine a weighting vector for example). Providing such operation is

OK, but I'm not so sure that overloading the meaning of the usual

operations is a good thing.

Defining the vector*vector product might be OK since it has no other

standard meaning, but then a user might expect that matrix*matrix

behaves in a similar manner and would get instead a matrix product. So

in the end, I'm not so sure that it is a benefit. But having, ew_product

(vector,vector) and ew_product(matrix,matrix) (ew is for element wise,

the name is ugly, this is just for the discussion) and use it would be

great.

Just keep the operators strictly for their standard meanings.

Just my two cents,

Theo.

**Next message:**Wolfgang Bangerth: "Re: [glas] arithmetic operations"**Previous message:**Karl Meerbergen: "[glas] arithmetic operations"**In reply to:**Karl Meerbergen: "[glas] arithmetic operations"**Next in thread:**Wolfgang Bangerth: "Re: [glas] arithmetic operations"