Boost logo

Boost :

From: Jani Kajala (jani_at_[hidden])
Date: 2002-01-04 04:36:32


> How wise would it be to define the full set of operators?
> E.g., do you want them to work element-wise or as matrix
> operations (a * b), or element-wise (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 multi-arrays 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: multi-array 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 multi-array 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 element-wise or as matrix
> operations (a * b), or element-wise (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 run-time 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; // element-wise 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 matrix-algebra operators here
> };
> class marray : public multi_array {
> // define the element-wise operators here
> };
> But this could easily lead to a proliferation of derived
> types (matrix algebra with < working as reduction,
> matrix algebra with < working element-wise, etc.).
>
> Ralf
>
>
>
> Info: http://www.boost.org Send unsubscribe requests to:
<mailto:boost-unsubscribe_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