|
|
Ublas : |
Subject: [ublas] banded_matrix and bindings
From: Vardan Akopian (vakopian_at_[hidden])
Date: 2008-11-25 13:47:57
On Sun, Nov 23, 2008 at 7:35 AM, Thomas Klimpel
<Thomas.Klimpel_at_[hidden]> wrote:
> ...
>
> Vardan Akopian:
> http://lists.boost.org/MailArchives/ublas/2006/10/1435.php
> gbsv.hpp
>
> ...
> I will probably work on Vardan Akopian's patch next weekend. There were some discussions about it lately, so that I already started to review it, in a certain sense.
>
Hi Thomas,
During the last discussion a couple of things came to my attention,
and I want to point them out as a documentation and in the hope that
it can help you with the review:
1) As I pointed out here
http://lists.boost.org/MailArchives/ublas/2008/11/3074.php
BOOST_UBLAS_OWN_BANDED must not be defined for this binding to work.
So perhaps this should be checked in the binding and #error out.
2) Related to the same flag, it seams to me that banded_matrix has
some inconsistent code. In the functions that need to access elements
of the matrix the code is branched based on this flag. However the
constructor for banded_matrix is not - it always allocates
std::max(size1, size2)*(lower + 1 + upper). This strikes me as
inconsistent, wasting memory in some cases (when the flag is not
defined and the number of columns is larger than the number of rows)
and potentially confusing for the binding (see 3 below).
3) The documentation
(http://www.netlib.org/lapack/explore-html/sgbtrf.f.html ) requires
that AB's dimension be (LDAB,N), where N is the number of columns in A
(M,N). In case if M > N, banded_matrix will actually allocate LDAB*M
memory (instead of LDAB*N). Fortunately, because LDAB is the leading
dimension, this is ok (it only wastes memory).
4) The current signature of the gbtrf() function does not allow to
check if the proper banded matrix was allocated. For example if a
matrix with 2 lower and 3 upper allocated diagonals is passed to
gbtrf(), then it assumes that the actual matrix it's dealing with, has
2 lower and 1 upper diagonal. This does not provide any help with user
errors. In principle we could modify the signature of the function,
and require the actual number of upper diagonals (ku) to also be
passed in. Then we could do all the necessary checks to ensure that a
proper (larger) matrix is allocated.
Finally, I'm wandering what's the reason for the
BOOST_UBLAS_OWN_BANDED implementation? Is there any 3rd party library
that takes advantage of this. Or is there another reason for which
this approach is better? I'm tempted to propose the remove it.
Thanks.
-Vardan