Re: [ublas] Matrix with vector interface.

Subject: Re: [ublas] Matrix with vector interface.
From: Oswin Krause (Oswin.Krause_at_[hidden])
Date: 2012-09-22 04:57:01

Hi,

Here is my slightly adapted version of the range. I didn't find the 
boost coding guidelines so i just tried to fit it to other ublas 
headers(with limited success). Since i am not breathing standardese, I 
am not sure whether i am 100% correct in every aspect.

Out of standard reasons, the implementation using proxy objects like 
matrix_row does not lead to a random_access_iterator even though it 
meets all traversal requirements. So algorithms like random_shuffle(and 
sort(?)) will work in practice but overeager compilers as for example 
MSVC will complain in debug mode. A solution to this is lying about the 
iterator category, but since i am a honest person, i don't ;)

the implementation comes with a short test case, but i can also add a 
bit more if required.

----
Than maybe a note should be added to the documentation stating that 
uBLAS is outdated and should not be used for new projects. Maybe this 
leads to a bit of drive to the development ;).
Even though i would volunteer to work on a new version and already have 
some ideas, uBLAS is just too big for me. It surpasses most BLAS 
Libraries in the amount features while calling itself "micro"-BLAS. (I 
think, this is one of the main sources of the problem. remove half of 
the features, call it nano-BLAS and ensure a good implementation).
Gretings,
Oswin
On 2012-09-21 23:51, Gunter Winkler wrote:
> Hello,
>
> Am Tuesday 18 September 2012 schrieb Oswin Krause:
>> Hi,
>>
>> > Regarding uBlas: Long time ago there was a design decision to not
>> > handle
>> > a matrix as a set of vectors in order to avoid bad surprises when
>> > playing with the storage layout and iteration order. However, I'd
>> > gladly
>> > accept a new matrix view as list of vectors using boost:range .
>>
>> So a matrix which also behaves as a range? or just a range adaptor
>> which maps a matrix_expression to a range_of_vectors which isn't
>> interpreted as matrix_expression anymore?
>
> 2nd option sounds good.
>
>> Having said that: are there any plans for an ublas2? Or something
>> like that? At the moment the advise i hear a lot from people having
>> looked at ublas is: "don't use it. There are many better libraries
>> our there". I don't think that this is an ideal state for a boost
>> library :/.
>
> Yes, you're right:
> * The uBLAS code is more than 10 years old, and little progress was 
> made
> during last 5 years.
> * There is no active developer (just check the list of open issues 
> ^^)
> * There is no active maintainer (There is a good chance that I
> "disappear" again when 1.52 is done ...)
> * There are really good alternatives out there which outperform uBLAS 
> by
> far
>
> Thus we are stuck unless we find a university which develops yet 
> another
> matrix library (compatible to uBLAS interface) or starts a full 
> rewrite
> of uBLAS' internal logic.
>
> mfg
> Gunter