Glas List: Re: [glas] arithmetic operations

From: Andrew Lumsdaine (lums_at_[hidden])
Date: 2005-10-27 17:29:20

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