Re: Re: [boost] ublas notation

From: Joerg Walter (jhr.walter_at_[hidden])
Date: 2002-07-16 03:05:51

----- Original Message -----
From: "Toon Knapen" <toon.knapen_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, July 16, 2002 9:37 AM
Subject: Re: Re: [boost] ublas notation

> On Tuesday 16 July 2002 08:55, Joerg Walter wrote:
> > > Blitz++ has Range::all() which is pretty clear IMO.
> > > BTW blitz++ also supports `A(Range(2,2), Range::all());`
> >
> > Ok.
>
> That means OK on supporting range::all() I assume, not on the ranges as
> arguments to operator().

This means, that we should work towards such a notation.

[snip]

> > Nope. The compromise is to add the project() functions to
> > vector_expression<>/matrix_expression<> for standard compliant compilers
> > instead of adding them to *every* statically derived class, which is
> > neccessary for MSVC 6.0 (that was tight coupling). If I change the
> > project() functions in vector_expression<>/matrix_expression<> to
> > operator() then, name resolution doesn't find them anymore due to
element
> > subscription via operator(). So to achieve your goal I'd have to move
> > element subscription via operator() to
> > vector_expression<>/matrix_expression<> too, but only for non MSVC 6.0
> > environments :-(
>
> So MSVC does not support overloading of operator(). If I understand you
> correctly (sorry but have almost no experience with MSVC) you can't do the
> following
>
> class matrix_expression
> {
> public:
>   value_type operator(size_t i, size_t j); // element-wise access
>   range_type operator(range r1, range r2);  // range creation
> };

I've just checked this again. The following doesn't compile with MSVC 6.0

template<class E>
class matrix_expression
{
public:
    typedef typename E::value_type value_type; <- This one fails with C2027
'use of undefined type'
    value_type operator () (size_t i, size_t j); // element-wise access
};

class matrix: public matrix_expression<matrix>
{
public:
    typedef double value_type;
    value_type operator () (size_t i, size_t j); // element-wise access
};

IIRC, this work for other compilers.

> > > ublas notation:
> > > ----------------
> > >    typedef numerics::matrix_range<BlockType> RangeBlockType;
> > >    typedef const numerics::matrix_range<const BlockType>
> >
> > ConstRangeBlockType;
> >
> > >    typedef const numerics::matrix_range<const MatrixType>
> >
> > ConstRangeMatType;
> >
> > >    typedef numerics::matrix_range<MatrixType> RangeMatType;
> > >
> > >    RangeMatType(Temp, range(0,last-start), range(0,V.size2())).assign
(
> > >       prod(herm(RangeMatType(WW, range(0,WW.size1()), range(start,
> >
> > last))),
> >
> > > ConstRangeBlockType(V, range(WW.size1(),VV.size1()),
range(0,V.size2())))
> > >       + prod( herm(ConstRangeMatType(Hessenberg, range(start, next),
> > > range(start, last))),
> > >               prod(herm(RangeMatType(WW, range(0,WW.size1()),
> > > range(start, next))), ConstRangeBlockType(V, range(0, WW.size1()),
> > > range(0,V.size2()))) ) );
> >
> > Ouch ;-)
> >
> > > Shorter notation (as being discussed currently):
> > >
> > > Temp(range(0, last-start), range::all() ) .assign (
> > >   prod( herm(WW(range::all(), range(start, last))),
> > > V(range(WW.size1(),VV.size1()), range::all()))
> > >   + prod( herm(Hessenberg(range(start, next), range(start, last))),
> > >   prod( herm(WW(range::all(), range(start, next))), V(range(0,
> >
> > WW.size1()),
> >
> > > range::all()))
> > > ) );
> >
> > Ok.
> >
> > > Matlab notation:
> > >
> > > Temp(1:last-start, :) =
> > >    WW(:, start:last)' * V(size(WW,1)+1:size(VV,1), :)
> > >   + Hessenberg(start:next, start:last)' *
> > >       ( WW(:, start:next)' * V(1:size(WW,1),:) )
> >
> > Inaccessible.
>
> Yep, as dave already said, we simply have not enough operators in C++ to
> support the richness of mathematics so we got to be creative. BTW, what
about
> supporting operator* instead of numerics::prod (BTW I made an error in
mail
> last night, element-wise multiply in matlab is '.*').

Yes, this will be supported (but again: probably not under MSVC 6.0).

> We could for instance
> give two different meanings to operator* : In namespace algebraic it
always
> means matrix-vector operations whereas e.g. element_wise means ..... well
> element-wise.

Regards

Joerg