
Boost : 
From: Jani Kajala (jani_at_[hidden])
Date: 20020104 04:36:32
> How wise would it be to define the full set of operators?
> E.g., do you want them to work elementwise or as matrix
> operations (a * b), or elementwise (a < b > multiarray
> of bool) or as reductions (a < b > one bool)?
If everyone agrees that operator overloading should only be used for code
clarity and not for notational convenience, then multiarrays shouldn't have
operator* at all.
Namespace based solution is imho tricky, you might need both types of
multiplications in the same scope and you might also end up using wrong
multiplication by accident: By looking at the expression a*b you don't know
which multiplication is used. If really needed, then simple methods like
multiplyElements() and multiplyMatrix() (or whatever) are superior code clarity
wise in this case.
Regards,
Jani Kajala
 Original Message 
From: "rwgk" <rwgk_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, January 04, 2002 3:04 AM
Subject: [boost] Re: multiarray comments/questions
> > After a quick look at the code, I'm not seeing the full suite of
> > operators, that libraries like MTL and others have. (Expression
> template
> > stuff.) Is this because multiarray is designed for a different set
> of
> > problems?
>
> How wise would it be to define the full set of operators?
> E.g., do you want them to work elementwise or as matrix
> operations (a * b), or elementwise (a < b > multiarray
> of bool) or as reductions (a < b > one bool)?
>
> A few weeks ago I posted a proposal for a scheme that
> gives the user the choice of selecting the desired
> set of operators at runtime with a using directive.
> The basic idea:
>
> void foo()
> {
> using namespace matrix_algebra;
> somearray a,b,c;
> c = a * b; // matrix multiplication
> }
>
> void bar()
> {
> using namespace element_wise_algebra;
> somearray a,b,c;
> c = a * b; // elementwise multiplication
> }
>
> This works well with EDG based compilers, gcc, and
> Metrowerks.
>
> In this scheme it actually is a disadvantage if
> operators are predefined in the class scope.
>
> I believe that a tight integration of operators in multi_array
> would be a limitation. A technology that delivers array management
> as one building block and operations on these as other, separate
> building blocks seems more reusable and therefore superior.
> Otherwise we will need two or more versions of multi_array,
> with different sets of operators.
>
> An alternative to my proposed scheme that I could think of
> is to use inheritance, e.g.:
> class matrix : public multi_array {
> // define the matrixalgebra operators here
> };
> class marray : public multi_array {
> // define the elementwise operators here
> };
> But this could easily lead to a proliferation of derived
> types (matrix algebra with < working as reduction,
> matrix algebra with < working elementwise, etc.).
>
> Ralf
>
>
>
> Info: http://www.boost.org Send unsubscribe requests to:
<mailto:boostunsubscribe_at_[hidden]>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk