|
Boost : |
From: Joerg Walter (jhr.walter_at_[hidden])
Date: 2002-07-10 15:57:55
----- Original Message -----
From: "Toon Knapen" <toon.knapen_at_[hidden]>
To: <boost_at_[hidden]>
Cc: "Karl Meerbergen" <Karl.Meerbergen_at_[hidden]>
Sent: Wednesday, July 10, 2002 3:28 PM
Subject: [boost] ublas notation
> Recently I adviced using uBLAS to our Linear Algebra experts who have been
> working mostly in f77, fortran90 and Matlab. And although pleased with the
> functionality of uBLAS, we learned that probably a weak point is the
> notation. To make it easier on people in mathematics, we probably should
try
> to support an interface that resembles that of matlab (which _is_ the
> reference).
>
> So here are his comments :
>
> ---------- Forwarded Message ----------
>
> Dear ublas-ers,
>
> First of all I want to congratulate with your contribution. This is great
> work and I expect many people will use the templates.
Thanks.
> Though, I have one
> major question, that was raised when a colleague and I started to use
ublas.
> We find its use fairly complicated and believe that it can be simplified
(I
> give examples further). Simplification is very important, since we do not
> believe that mathematicians are very keen using very long expressions for
> mathematically simple expressions, that can be expressed very briefly in
> matlab, fortran 90 and even fortran 77.
>
> My major concerns is about ranges (matrix and vector).
> The code really becomes unreadable when expressions are getting
complicated.
>
> Suppose I want to compute (in Matlab notation)
> A(1:3,5:6) = B(5:6,1:10)' * C(10:19,1:2)
> In fortran 90 this would become
> A(1:3,5:6) = matmul(conjg(transpose(B(5:6,1:10))), C(10:19,1:2) )
>
> I can do the following in ublas:
>
> typedef matrix<double, column_major> MType;
> typedef matrix_range<MType> MRType;
>
> MRType(A, range(0,3), range(4,6)).assign( prod( MRType(B, range(4,6),
> range(0,10)), MRType(C, range(9,19), range(0,2))));
>
> This could become simpler by avoiding the need to define the MRType, for
> example as follows:
>
> 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
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
> This is still a simple expression, but I guess you see the advantages for
> longer expressions. In addition, there is no need to explicitly add the
range
> types of A, B and C. The compiler does it for you.
>
> 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:
row (A, 2), column (A, 3), project (row (A, 2), range (2, 4)) etc.
> May I ask you to take these suggestions seriously: they may make ublas
more
> popular.
>
> Best regards,
>
> Karl Meerbergen
>
> -------------------------------------------------------
>
> This suggestion will indeed make it easier and is easy to implement. IIRC
> this way of working was supported initially but deprecated because
> dependencies between the different include files have been reduced.
Thanks for your feedback.
Regards
Joerg
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk