uBLAS banded storage does not match common BLAS layout (from netlib)

[Gunter]

A banded_matrix stores the elements in an unusual way. This makes it impossible to call standard BLAS-libraries with these matrix type.

Example data taken from ​http://www.netlib.org/lapack/lug/node124.html

Running banded_matrix < column_major > test
Full matrix
[5,5]((11,12,0,0,0),(21,22,23,0,0),(31,32,33,34,0),(0,42,43,44,45),(0,0,53,54,55))
data() of matrix
0 12 23 34 45 11 22 33 44 55 21 32 43 54 0 31 42 53 0 0
Expected data() of matrix
0 11 21 31 12 22 32 42 23 33 43 53 34 44 54 0 45 55 0 0

Running banded_matrix < row_major > test
Full matrix
[5,5]((11,12,0,0,0),(21,22,23,0,0),(31,32,33,34,0),(0,42,43,44,45),(0,0,53,54,55))
data() of matrix
0 11 21 31 12 22 32 42 23 33 43 53 34 44 54 0 45 55 0 0
Expected data() of matrix
0 0 11 12 0 21 22 23 31 32 33 34 42 43 44 45 53 54 55 0

[Gunter]

using the define BOOST_UBLAS_OWN_BANDED makes the things even worse ...

[Gunter]

(In [81043])

• libs/numeric/ublas/test/test_banded_storage_layout.cpp - new failing test, see #7549
• libs/numeric/ublas/test/Jamfile.v2 - add test to test suite

[Gunter]

The responsible code is in banded.hpp around line 163. The mapping from index (i,j) to storage location is

   const size_type k = j;
   const size_type l = upper_ + i - j;
   if (k < size2_ && l < lower_ + 1 + upper_)
   return data () [layout_type::element (k, size2_, l, lower_ + 1 + upper_)];

where layout_type is either basic_row_major or basic_column_major (from functional.hpp) We should extract the existing mapping logic to a functor (similar to triangular types basic_lower and basic_upper) and introduce a new template argument.

[nasos_i@…]

Replying to guwi17:

(In [81043])

• libs/numeric/ublas/test/test_banded_storage_layout.cpp - new failing test, see #7549
• libs/numeric/ublas/test/Jamfile.v2 - add test to test suite

I am trying to fix this bug. So I am wondering why should the expected row-major data layout be:

0, 0, 11, 12, 0, 21, 22, 23, 31, 32, 33, 34, 42, 43, 44, 45, 53, 54, 55, 0 ?

I would expect something like:

0, 12, 23, 34, 45, 11, 22, 33, 44, 55, 21, 32, 43, 54, 0, 31, 42, 53, 0, 0

-Nasos

[nasos_i@…]

The bug is corrected in the ublas_develop branch in github and some more test cases were introduced. To enable the old incorrect behaviour one should define BOOST_UBLAS_LEGACY_BANDED.

-Nasos