> David Bellot <david.bellot <at> gmail.com> writes:

Thanks David, and thanks to Gunter, Rutger, Thomas, and everyone else

who has helped me over the years.

I really think the emphasis should be on getting the simple matrix and linear

algebra semantics up to snuff first.  As someone who looked at matrix libraries

fairly recently and has tried to get others to use ublas, they almost always

start by looking at the notation for basic operations (multiplication,

assignment of small vectors, whether big matrices can be returned by value,

how to interface with data already in a C array).

> (1) as you can imagine, in machine learning, one often needs to "randomly" ?

> access to sub-matrices. A good framework is already in place for matrix_view, >

> I would like to extend it so that to make it as versatile as it is in other

> libraries or even Matlab.

I use these features as well and would appeciate it, though I would put it at

a lower priority than other features.

>(2) after reading last week emails, I think we could provide basic

> implementations of a few standard algorithms like inversion, solvers, etc...

Yup, but only a few basics with caveats that these should not be considered

high performance.  I really think the bindings are a way to get the monkey off

everyones backs with this.  I think the ones that people commonly use are:

* cholesky

* LU

* determinant

* trace 

* inversion (I know, I know, but sometimes it actually is the right way

to do it and it isn't our job to teach good linear algebra....)

* Basic direct solver, probably like the one on gunters site.

* Basic direct sparse solver.  Having a baseline here is important since

MUMPS, etc. are less prevalent than LAPACK interfaces and tougher to build

* Hopefully all (or most) of these already have coding done.

(3) bindings are a hot topic. Let's be pragmatic: it's not supposed to

> be part of uBLAS but having a standard interface would add a strong value to uBLAS. And, I am like others, I want to play with my brand new nVidia card.

To me, bindings are the answer to almost all algorithms.  It is ublas's

job to get all of the other stuff right first and foremost.  Among other things

ublas may not be able to compete against newer libraries on performance

for organically coded algorithms.

All the GPU stuff would be nice, but I think it is a 3rd order concern.  Lets

get the semantics of the matrices closer to the newer libraries like eigen,

get the bindings working beautifully with LAPACK and a couple of sparse

routines, then worry about other gravy.

>(4) another hot topic which is a recurrent complain about uBLAS: the product

> of 2 matrices. Do we want prod(A,B) or A*B. Let's think about it because

> other libraries implemented A*B in a very efficient manner too.

Don't forget products of 3 matrices!  Try to get new users on ublas and this

is almost a deal breaker.  It was such a pain that I submitted a trivial patch

to try and get them off my back.

> (6) I will join Gunter in his effort to provide new documentation,

> covering more topics, with tutorial and advanced topics. uBLAS is a great

> library and a good documentation is of primary interest. That is one of

> the most important topic for me (yes, way more than prod(A,B) versus

> A*B)

I don't agree with basic semantics being less important here.  And if they

change at all, then tutorials would need to be rewritten.  I think that

most on this list has been using prod() for so long and been looking at

the lower level code forever, that they have forgotten what a pain and poor

semantic comparison ublas has to matlab or other C++ libraries.

When those things are fixed up, then the docs could be changed to support them.

A couple of the other user centric features that are missing (mostly in order):

0) Matrix products A*B*C

When I can implement things like the following I will shut up.

1) Construction of fixed sized matrices/vectors with something like:

ublas::vector<int> x = 1, 2, 3;

ublas::c_vector<int, 3> x = 1, 2, 3;

or at the vary least:

ublas::c_vector<int, 3> x = {1, 2, 3}; //(using old style assignment of structs

... I thought this might work and be similar to boost::array, but couldn't

get it to work myself.  I think it has something to do with inheritance.

Everyone else seems to do this and it makes ublas look pretty bad when

writing test cost where this comes up all the time.  But shouldn't we be

writing a huge chunk of our test code regardless?

2) Stacking of matrices/vectors.  Matlab guys, and especially those doing

econometrics/statistics/etc. do this all the time and don't even think about

it.  I think an efficient implementation is related to submatrix access...

matlab:

y = [A;B];

potential ublas:

auto y = stack_vertical(A, B);

This comes up all of the time in the type of code I write.

3) Efficient operations for small, fixed sized vectors (is this supposed to

be c_vector and c_matrix?).  I haven't done any direct comparisons to other

libraries on performance, but since they all say that they are heavily

optimized for this, I think a comparison and a few features as necessary

are important if ublas is going to be a general purpose matrix library.  Small

vectors come up ALL the time and if I use TVMet or something like that, then

I can't use linear algebra against my other ublas matrices.

4) Clear interface to existing C arrays.  I think that there is some sort of

patch or undocumented feature here from gunter, but it needs to be well thought

through and formalized..... in interfacing with external libraries, you end up

doing this all of the time and copying between vector types is not acceptable.

This also can't just be a read-only interface, though turning off resizing

could be acceptable.

5) kron.  I believe there is a patch out there that should be integrated

and verified.  Matlab guys use this all of the time.

6) row/column reductions.  Some of these might be there, but I have trouble

figuring out what to do.  Think matlab sum(A), etc.

7) Efficient return by value (can be contingent on rvalue refs in your compiler

A lot of work on patches here exists and I am sure it is close.

8) Adaptors for multi-array

This comes up frequently where people want to take a 1 or 2D slice of a 

multi_array and performance boost operations on it.  I have had to copy

data to ublas structures myself, and here was another post recently

9) Data interchange to matlab.

One of the first things I do when writing my programs is to generate data

for interpretation and graphing in matlab.  I hate to write generic,

non-linear code in matlab but it is great for analysis and graphing.  I

think most people would be in a similar boat.  It also looks like

K.M.A Chai graciously submitted code that does things like this:

Here is an older email when I made a plea about some of this.  It looks like

I am fairly consistent with what is here..

Sorry for the blast of features, but I think a decision needs to be made:

Is the goal of ublas to be competitive with features of newer libraries

that are semantically rich and target recovering matlab users (the biggest

and most important group if you ask me).  Or is it to make patches for the

existing users and slow down the point where ublas becomes non-competitive.

Both are defensible strategies.  If you want to do the former, then I think

the list I have given is a pretty comprehensive one and along with docs would

make ublas competitive.

Thanks so much for listening and getting this great library to the point it is

already at.

-Jesse