Subject: Re: [ublas] Banded matrix storage
From: Nasos Iliopoulos (nasos_i_at_[hidden])
Date: 2013-08-01 21:31:42
Generally it would not be nice to massively break other codes. So I see
a) I will either add a BOOST_UBLAS_LEGACY_BANDED #define that will wrap
the old layout scheme, so that people have a way out.
b) Wrap the netlib banded scheme using a BOOST_UBLAS_LAPACK_BANDED
#define and retain the current ublas scheme as the default.
Generally I would prefer a) even if it might surprise some. Any thoughts
or preferences anyone?
Can you also elaborate a little bit on why an all netlib code would
break traits code? I would think it could break code that is
non-agnostic to the storage layout, which is not good either, but I
that would affect a lot less (if any) codebases.
On 08/01/2013 05:37 PM, pmamales_at_[hidden] wrote:
> No problem, just wanted to make sure that I don't do something wrong.
> In case it makes sense :
> >From a quick look, it seems to me that one should replace the packed storage with banded.
> This is in accordance with netlib nomenclature, but I guess would break all shorts (mine included ;) )
> traits code.
> ---- Nasos Iliopoulos <nasos_i_at_[hidden]> wrote:
>> To all:
>> it would be of great help if at least another pair of eyes can review
>> the code before it moves forward into an official release. Here is the
>> github branch:
>> modified test cases (added non square matrices):
>> and modified banded.hpp:
>> relevant lines are 25-56 and and anything that contains the
>> "banded_indexing" specializations.
>> One important change I made relatively to the old code is that I
>> enabled range checking only in debug builds (where appropriate).
>> Please also note that I didn't follow Gunter's suggestion on adding a
>> new template argument, since I felt it would break backwards
>> compatibility in certain cases.
>> test instructions (not final but they should work):
>> please do a git checkout ublas_bugfix0002_fix_banded_tc7549 prior to
>> compiling with b2 otherwise you will be compiling the master branch.
>> I will megre it into ublas_develop after 1-2months so that there is
>> enough time for review and maybe apply some minor modifications I have
>> in mind.
>> On 08/01/2013 01:05 PM, pmamales_at_[hidden] wrote:
>>> PS: Although I asked a very-related question, I did not see any answer, so I thought it was ignored as
>>> trivial/already answered elsewhere. However, I did receive these very relevant emails. Am I doing something wrong ?
>> Gunter had created some test cases and a bug report on boost trac, so I
>> figured it would help the discussion more to answer to that thread. I
>> restrained myself flooding the mailing list with responses, since yours
>> was just around the corner.
>>> ---- Rutger ter Borg <rutger_at_[hidden]> wrote:
>>>> On 2013-07-31 17:22, Nasos Iliopoulos wrote:
>>>>> 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.
>>>> Hey Nasos,
>>>> great work. The data in banded matrices is stored either row-by-row
>>>> (row-major), or column-by-column (column-major). This is defined by
>>>> netlib. AFAIK, a diagonal-by-diagonal storage scheme is not supported by
>>>> ublas mailing list
>>>> Sent to: pmamales_at_[hidden]
>>> ublas mailing list
>>> Sent to: athanasios.iliopoulos.ctr.gr_at_[hidden]
>> ublas mailing list
>> Sent to: pmamales_at_[hidden]
> ublas mailing list
> Sent to: athanasios.iliopoulos.ctr.gr_at_[hidden]