
Boost : 
From: Toon Knapen (toon.knapen_at_[hidden])
Date: 20020712 09:27:35
> > 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.
> 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.
I understand that the implementation of a different strategy is hard,
especially at this stage of the project.
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? 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?
Karl

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk