Subject: Re: [ublas] Banded matrix storage
From: Nasos Iliopoulos (nasos_i_at_[hidden])
Date: 2013-07-31 13:27:58
I implemented both your thinking (to my understanding) and mine. I
think that yours reflects the symmetry of indexing (i.e. a row by row
banded matrix is stored row by row, while a column-by column is stored
column by column) while my original thinking doesn't (i.e. a column by
column banded matrix as per netlib is either stored in a row-major or
a column-major container (as per the template argument).
I got both implementations running but I think I prefer your idea after
all. I will apply the patch after the transition to github is complete.
> I am working on this bug, but based on the test case 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
> And not
> 0, 12, 23, 34, 45, 11, 22, 33, 44, 55, 21, 32, 43, 54, 0, 31, 42, 53,
> 0, 0 ?
> For the moment I got the column-major implementation working as
> expected, but I need to add some more tests cases to make sure it is
> working for non-square matrices as well.
> On 10/21/2012 04:57 PM, Gunter Winkler wrote:
>> Am Monday 15 October 2012 schrieb Rutger ter Borg:
>>> On 2012-10-15 18:09, Gunter Winkler wrote:
>>>> Could you please provide a simple test program which checks the
>>>> storage format? Then we (or maybe you) can create a new ticket.
>>> thanks for the response. I've attached a test program, its output is
>>> shown below. I haven't created a ticket yet, because I would like to
>>> make sure the test is correct first. I double-checked the 'expected
>>> data()' values, to me they seem to be correct.
>> I agree, the mapping from (i,j) to storage location is weird. I created
>> an issue:https://svn.boost.org/trac/boost/ticket/7549
>> Now we only need a volunteer to fix it ...
>> ublas mailing list
>> Sent to:athanasios.iliopoulos.ctr.gr_at_[hidden]
> ublas mailing list
> Sent to: athanasios.iliopoulos.ctr.gr_at_[hidden]