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

**From:** Andrew Lumsdaine (*lums_at_[hidden]*)

**Date:** 2005-10-27 17:29:20

**Next message:**Karl Meerbergen: "Re: [glas] arithmetic operations"**Previous message:**Toon Knapen: "Re: [glas] arithmetic operations"**In reply to:**Toon Knapen: "Re: [glas] arithmetic operations"**Next in thread:**Karl Meerbergen: "Re: [glas] arithmetic operations"**Reply:**Karl Meerbergen: "Re: [glas] arithmetic operations"**Reply:**KF: "Re: [glas] arithmetic operations"

I think this would be a very dangerous path to go down.

One important reason for introducing operator notation for linear

algebra operations is so that the program notation can match the

corresponding mathematics. This is a very powerful correspondence.

It makes code more straightforward to write, but just as importantly

(or perhaps even more importantly) it makes the code more

straightforward to read. By corresponding to an established language

of mathematics, the code itself communicates significant mathematical

meanings.

If we start introducing non-mathematical meanings to operators, that

subverts in a very significant way the expressiveness of the

mathematical operator notation. There may be a few more things that

can be expressed with operators in this case, but the clarity of

expression is ruined -- the reader (and writer) of the code can no

longer have confidence in the "language" being used -- it is no

longer the well established language of mathematics.

Even worse is the case where the meaning of the operators might not

have any fixed meaning at all. In that case, the expression of

statements with operators has no fixed meaning and doesn't

communicate anything.

I really think that for mathematical libraries, the use of

mathematical notation absolutely must conform to their mathematical

meanings.

On Oct 27, 2005, at 4:01 PM, Toon Knapen wrote:

> What if as a user you can configure himself what operator* means?

>

> It will always be controversial to assign a specific behaviour to an

> object/symbol. The expected behaviour is always going to be different

> for different people with different backgrounds.

>

> Looking specifically at operator overloading. Operator overloading is

> necessary if we would like to pass glas-objects to existing algorithms

> , algorithms that rely on these specific operators. But since we're

> also

> developing the algorithms in glas, this is not really an issue.

> OTOH we

> might reuse other generic algorithms out there, like those in the STL

> but those algorithms allow to pass a functor to specify the operation

> (e.g. inner_prod, accumulate). So in our case, operator overloading is

> just about 'notation'.

>

> So what if we give the different products clearly distinct names (like

> el_prod, inner_prod, ...) ?

>

> Additionally, if a user wants operator* to do an inner_prod, he can

> just

> define operator* to default to inner_prod. OTOH if the user wants

> opeator* to default to el_prod, he just needs to define (via an

> include

> or by importing the operator* into the glas namespace) the free

> operator* function. Would'nt that suit all???

>

> (I attached a small example of such an example operator*)

>

> --

> Toon Knapen

> Skype Name: toonknapen

>

>

> ------------------------------------------------

> Check out our training program on acoustics

> and register on-line at http://www.fft.be/?id=35

> #include <iostream>

>

> struct Vector

> {

> double dot(const Vector& that) const

> {

> std::cout << "dot" << std::endl ;

> double result = 0 ;

> for(int i = 0 ; i < 3 ; ++i ) result = values_[i] * that.values_

> [i] ;

> return result ;

> }

>

> void el_prod(const Vector& that)

> {

> std::cout << "el_prod" << std::endl ;

> for(int i = 0 ; i < 3 ; ++i ) values_[i] *= that.values_[i] ;

> }

>

> double values_[3] ;

> } ;

>

> #if 0

> void operator*(Vector& first, Vector& second) { first.dot

> ( second ) ; }

> #else

> void operator*(Vector& first, Vector& second) { first.el_prod

> ( second ) ; }

> #endif

>

> int main()

> {

> Vector a, b ;

> a * b ;

>

> return 0 ;

> }

> _______________________________________________

> glas mailing list

> glas_at_[hidden]

> http://lists.boost.org/mailman/listinfo.cgi/glas

**Next message:**Karl Meerbergen: "Re: [glas] arithmetic operations"**Previous message:**Toon Knapen: "Re: [glas] arithmetic operations"**In reply to:**Toon Knapen: "Re: [glas] arithmetic operations"**Next in thread:**Karl Meerbergen: "Re: [glas] arithmetic operations"**Reply:**Karl Meerbergen: "Re: [glas] arithmetic operations"**Reply:**KF: "Re: [glas] arithmetic operations"