Re: [boost] ublas notation

From: Joerg Walter (jhr.walter_at_[hidden])
Date: 2002-07-13 13:10:45

----- Original Message -----
From: "Toon Knapen" <toon.knapen_at_[hidden]>
To: <boost_at_[hidden]>
Cc: "Karl Meerbergen" <Karl.Meerbergen_at_[hidden]>
Sent: Friday, July 12, 2002 4:27 PM
Subject: Re: [boost] ublas notation

> > > A(range(0,3), range(4,6)).assign( prod( B(range(4,6),range(0,10)),
> > > C(range(9,19), range(0,2))));
> >
> > First of all, ublas doesn't support operator() for ranges, but only for
> > element access. We deliberately decided to use project() functions
> > (although this isn't fully correct mathematically) instead. With earlier
> > versions of ublas one could write
>
> Would it be hard to support operator() for ranges? If not, I suggest to do
>  it: it is a short, clear and powerful notation.

See below.

> > A.project(range(0,3), range(4,6)).assign( prod(
B(range(4,6),range(0,10)),
> > C(range(9,19), range(0,2))));
> >
> > but we then realized, that we could use free functions to achieve the
same
> > expressiveness:
> >
> > project (A, range(0,3), range(4,6)).assign( prod(
> > B(range(4,6),range(0,10)), C(range(9,19), range(0,2))));
> >
> > This is the recommended way currently. The rationale to eliminate the
> > earlier member functions was to decouple vector/matrix and vector
> > proxies/matrix proxies. See
> >
> > http://aspn.activestate.com/ASPN/Mail/Message/1156090
> >
> > > Another suggestion to make life simpler, is to define range() or
> > > norange() to indicate the full scope of the range, for example
> > > A(range(0,2), norange()) is then equivalent to
> > > A(range(0,2),range(0,A.size2()))
> >
> > Yes, I've seen similar in the past. We'll consider it.
> >
> > > A row can be selected as A(2, norange()) and a column as A(norange(),
3).
> > > A vector_range of a row is then A(2, range(2,4)), etc.
> >
> > Recommended:
> >
> > project (row (A, 2), range (2, 4)) etc.
>
> This looks complicated.
> Do not forget that mathematicians are no computer scientists.
> Mathematical expressions should be represented in a way as natural as
> possible, meaning: natural to mathematician, not to computer
> scientists. Mathematicians do not like long expressions.
> The designers of Matlab and Fortran90 have thought a long time about
matrix
> operations, and the solutions they came up with have been accepted widely.
> I recommend to stay as closely as possible to that notation.

Agreed, but I'm neither a language designer nor a compiler writer ;-) I've
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:

#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 6.0
compatibility, as far as I see. So this should be a feature for a future
version of ublas IMO.

> I understand that the implementation of a different strategy is hard,
> especially at this stage of the project.

It'll be much more difficult later.

> Anyway, I think that the `project' function would be an important step
> forward, although my concerns about simple expressions remain.
> I just wanted to express my concerns when mathematicians are going to use
> ublas. It is your free choice to consider suggestions. The question you
have
> to pose is the following: are mathematians going to give up Fortran90 when
> ublas is available?

I simply do not know enough about the chances of Fortran90 (although I
believe, that it doesn't support generic programming like C++). My current
goal is to get a good interface and to enable the reuse of platform specific
tuned (procedural) kernels at the same time.

> Are they willing to move to C++ and all its advantages of
> templating and inheritance, when they have to give a up a comfortable and
> friendly way to express maths?

I'm unsure. As far as I see, they could win some performance and would have
to pay a price in terms of compile time and deciphering impractical compiler
diagnostics.

Regards

Joerg