Boost C++ Libraries: Ticket #7549: uBLAS banded storage does not match common BLAS layout (from netlib)

Gunter — Sun, 21 Oct 2012 20:40:40 GMT

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

Gunter — Sun, 21 Oct 2012 20:45:17 GMT

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 — Sun, 21 Oct 2012 20:54:34 GMT

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.

cc changed

nasos_i@… — Wed, 31 Jul 2013 15:11:04 GMT

cc Rutger ter Borg <rutger@…> added; Rutger ter Borg <rutger@…> removed

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@… — Wed, 02 Apr 2014 14:52:36 GMT

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