Re: Re: [boost] ublas notation

From: Toon Knapen (toon.knapen_at_[hidden])
Date: 2002-07-16 02:37:13

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().

> > > looked into this issue again and found, that we're able to support the
> > > following two notations (with a slight modification of the current
>
> version)
>
> > > under sufficient standard compliant compilers:
> >
> > I admire your effort to keep ublas compile-able with MSVC but we OTOH we
> > should'nt cripple the interface of such an important library because of 1
> > compiler (and IIRC VC7 will be able to handle all necessary features)
>
> I'm already working on the limit. So either I've to drop MSVC 6.0 support
> or I've to find some workable compromises. VC7 doesn't support PTS.

I thought the VC team was commited to be able to compile boost (and thus 
support PTS)

>
> > > #include <boost/numeric/ublas/config.h>
> > > #include <boost/numeric/ublas/vector.h>
> > > #include <boost/numeric/ublas/matrix.h>
> > > #include <boost/numeric/ublas/io.h>
> > >
> > > int main () {
> > > numerics::vector<double> v (1);
> > > v.clear ();
> > > std::cout << project (v, numerics::range (0, 1)) << std::endl;
> > > std::cout << v.project (numerics::range (0, 1)) << std::endl;
> > > std::cout << project (v, numerics::slice (0, 1, 1)) << std::endl;
> > > std::cout << v.project (numerics::slice (0, 1, 1)) << std::endl;
> > > numerics::matrix<double> m (1, 1);
> > > m.clear ();
> > > std::cout << row (m, 0) << std::endl;
> > > std::cout << m.row (0) << std::endl;
> > > std::cout << column (m, 0) << std::endl;
> > > std::cout << m.column (0) << std::endl;
> > > std::cout << project (m, numerics::range (0, 1), numerics::range (0,
> > > 1)) << std::endl;
> > > std::cout << m.project (numerics::range (0, 1), numerics::range (0, 1))
> > > << std::endl;
> > > std::cout << project (m, numerics::slice (0, 1, 1), numerics::slice (0,
> > > 1, 1)) << std::endl;
> > > std::cout << m.project (numerics::slice (0, 1, 1), numerics::slice (0,
> > > 1, 1)) << std::endl;
> > > return 0;
> > > }
> > >
> > > *without* reintroducing the tight coupling of vector/matrix and
> > > vector/matrix proxy classes. W.r.t. overloading operator() for ranges
> > > I've currently the problem that this would either reintroduce the
> > > earlier tight
> > > coupling of vector/matrix and vector/matrix proxy classes or break MSVC
> > > compatibility, as far as I see. So this should be a feature for a
> > > future version of ublas IMO.
> >
> > The project makes it easier indeed, it's not necessary anymore to declare
> > the types of all intermediate temporaries with typedefs.
> > Still I wonder how
> > 'm.project (numerics::range (0, 1), numerics::range (0, 1))' does not
> > introduce tight coupling whereas 'm(numerics::range (0, 1),
> > numerics::range(0, 1)))' would ?
> > And if I understand you correctly, your motivation is that users that
> > matrix.h should not always have to include matrix_pr.h too because also
> > having to include matrix_pr.h would be cause longer compiler times, right
>
> ?
>
> 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
};

> > 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 '.*'). 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.