Boost C++ Libraries: Ticket #4034: better vector/matrix assignment (or initialization)

attachment set

Gunter — Mon, 22 Mar 2010 21:58:25 GMT

attachment → assigner.zip

proposed header file and example

attachment set

nasos_i@… — Sun, 28 Mar 2010 20:33:17 GMT

attachment → assignment.patch.tar.gz

universal assignment operator<< for vector and matrix expressions

nasos_i@… — Sun, 28 Mar 2010 20:39:41 GMT

I attach a whole new version of the assignment operator (assignment.patch.tar.gz). The patch contains a header assignment.hpp and unit tests (test_assignment.cpp). I think some sophisticated assignment tricks can be used with those operators (still finding news ways they can be used). This version is a complete rewrite, but in terms of interface the differences are the following:

Name was changed to assignment after Boost.Assignment.

non_vector(T i) was removed and was replaced by move(T i)

move(T i, T j) was added for matrix expression traversing

Absolute traverser was added so that move_to(T i) and move_to(T i, T j) can be used on vector and matrix containers respectively.

mat1 << mat2, ... support was added

A simple traits mechanism so that fill policy can be chosen was implemented. This allows for:

compressed_matrix<double> cm;
cm << fill_policy::sparse_push_back(),
      1, 2, mat, vec, vec_expres, ...;

A number of test cases were added in the spirit of http://svn.boost.org/svn/boost/trunk/libs/numeric/ublas/test/test_coordinate_matrix_sort.cpp.

They patch looks ready for merging to ublas, but of course this is only under my eyes. Comments, suggestions are HIGHLY desired.

Beside the sparse_push_back policy, performance was not considered but with the fill_policy tag it looks that we can implement more sophisticated assignments now. I can write a small tutorial or guide, but I would like to now the format I should provide it in.

Best Nasos

cassioliandre@… — Sat, 10 Apr 2010 10:41:44 GMT

Hi guys, I found the overall discussion very stimulating.

Using uBlas can be quite annoying for the lack of such assignement operators that in my experience (i'm working on the optimization and fem simulation field).

I was wondering if it not might be the case to take a look to the Boost::Assign library and see if it can be extended and adapted to work with uBlas. For naive assignament it already provides operator+= and similar that could be useful to simply fill vectors. For a matrix, a machinery similar to the one in place for map could be used.

In this way uBlas could be used more freely besides for instance a std::vector, for which Boost::Assign already works.

For what concern how to rule the access if by rows or columns, I suggest to possibilities:

do not allow free access but force user to specify the column or row access explicitly, as for instance as

 boost::numeric::ublas::matrix<double> m(10,10);
 m += row(2, a_vector_of_values ), row(1, another_list_of_values);

an std::stream modificator like syntax might be used:

 boost::numeric::ublas::matrix<double> m(10,10);
 m << row(1)<< 0, 1, 2,3<< row(2)<< 4,5,6,7;

Best Regards, Andrea

nasos_i@… — Sat, 10 Apr 2010 23:10:42 GMT

Hi Andrea, I just saw your post as I am getting ready to upload the new version of assignment operator. Anyway, you have some nice comments and as having worked on the subject I would like to add my experience:

My first choice was to take a look at Boost::Assign. The basics of the ublas assignment code are inspired from Boost::Assign, but because of the relatively small (just 50 or 60) lines of code that were needed from Boost Assign, the rest should be considerably different (because of matrices and especially sparse containers).

I am not sure whether it must be restricted to just rows (or columns). Anyway the code following allows for that behaviour if such verbosity is desired, based on Gunter's comments in the mailing list.

Best Nasos

attachment set

nasos_i@… — Sat, 10 Apr 2010 23:26:57 GMT

attachment → assignment2.zip

Assignment operator<<=

nasos_i@… — Sat, 10 Apr 2010 23:28:33 GMT

Based on the comments by Gunter (http://lists.boost.org/MailArchives/ublas/2010/03/4121.php) and David (http://lists.boost.org/MailArchives/ublas/2010/03/4123.php), I attach the new version of the assignment operator (assignment2.zip). The main differences with the previous are the following:

Added a number of manipulators based on standard library concepts (like std::setprecision). Those allow for functionality like moving to the next row or column, moving to the begining of a row, etc.

Changed the assigner overall design from tag dispatch based to policy based. I figured out that this allows for better extensibility.

Added a fairly extensive number of unit tests (this takes some time to compile)

Added benchmarks that show that the performance is equivalent to classical assignment even for small containers.

Added a number of examples of how the assignment may be used in a variety of situations.

Commented most of the code.

Changed the operator from << to <<=, as I feel it is more representative of the work done by the assignment.

Best regards

Nasos

cassioliandre@… — Sun, 11 Apr 2010 14:41:03 GMT

Nice job! I want to make few comments I hope that will be useful:

I found sometimes misleading the plain sintax:

matrix<double> A(3,3);
A <<= 1,2,3,4,5,6,7,8,9;

and in any case too many modificators may give rise to confusion and code mess. Why do not use the column_adaptor and row adaptor to explicitly insert cols and rows?

matrix<double> A(3,3);
//sorry for the non-standard syntax....
row_adaptor(A,0) <<= 1,2,3;
row_adaptor(A,1) <<= 4,5,6;
row_adaptor(A,2) <<= 7,8,9;

the use of new_col and next_row is nice, and I might say in my opinion the plain traversing should be avoided, at least if no performance issues arise. The use of BOOST_UBLAS_DEFAULT_ASSIGN_BY_COLUMN define is not as clear as a many people might think. Instead, if traversing is needed, an explicit manipulator can do the trick.

I do not think that assuming row_traversing by default is a clean and safe policy. I 'd rather imagine no default policy and explicit control by the user. The same applies to the wrapping.

Another suggestion might be the inserte based syntax proposed for the MTL4:

matrix<double> A(3,3);
row_inserter row_ins(A);
//sorry for the non-standard syntax....
row_ins(0) <<= 1,2,3;
row_ins(1) <<= 4,5,6;
row_ins(2) <<= 7,8,9;

performances are not equivalent to the standard assignement as claimed. I've played a little bit with the g++ compiler (version 4.4.3 with boost 1.42) with my old intel centrino laptop and the results show a loss of performance between 13% to 1566.67%, depending on the test and the optimization options (from -DNDEBUG only to -DNDEBUG -O3 -ftree-vectorize -funroll-all-loops).

From my point of view, it sounds strange that performances could decay in such way, for the containers are created of the right size and no resizing take place (as for push_back operations). I can't see at the moment what might cause such overhead, but a code profiling might help. Forcing a more aggressive compilation helps, but I deep understand might be a good starting point to work out some hidden problems.

By the way, it looks very promising! And indeed I do appreciate the idea of a set of static manipulators , possibly faster than the normal ones.

nasos_i@… — Mon, 12 Apr 2010 00:49:50 GMT

Andrea,

I suppose this debate will go on for a while, as I feel that people are divided in the explicit or implicit traversing options :). Anyway both can be implemented so I suppose it is a matter of choice from Gunter and David, or from the overall popularity in the mailing list or here.

Why do not use the column_adaptor and row adaptor to explicitly insert cols and rows?

This can be achieved in a way as for example:

    matrix<double> m;
    matrix_row<matrix<double> > mr (m, 0);
    mr <<= 1,2,3;
    std::cout << m << std::endl;

I think there may be the need for a few more overloads to achieve what you propose in general. What do you think of just using the matrix proxies? What do others think?

in my opinion the plain traversing should be avoided, at least if no performance issues arise .... I do not think that assuming row_traversing by default is a clean and safe policy. I 'd rather imagine no default policy and explicit control by the user. The same applies to the wrapping

It indeed may be safer and I think no performance issues arise from that. I am not personally convinced though that the safety penalty in stake is that big to drop such convenience. Another consideration for uBlas also is the way people look into it for the first time, I believe an interface that makes sense for the first time user, with certain customisation options for the most advance would turn to be beneficial.

Anyway a simple redirection will disable the assignment without an explicit definition of the traverse and wrap policies.

performances are not equivalent to the standard assignement as claimed

Unfortunately on my intel core 2 duo laptop (like 2 years old) I see no statistically significant difference in performance. Other times the classical assignment is faster and other times the assigner assignment is faster (this difference ranges from 0 to 10% both ways). I will look in the assembly code and maybe try to compile on other machines too.

My understanding though is that for very small containers, and for certain compilers or architectures, there maybe the need of creating empty objects (like the ones used for certain manipulators), that may still require an 1-byte constructor to be invoked. If you see such a difference maybe something like that is happening with the specific setup. I tried to avoid such a problem by using function based manipulators (like std::endl), but because of the generally more complicated nature of the assigner objects relative to streams, a good design could not be achieved. After all my benchmarks did not signify that this was necessary. Will look more into that and if somebody has something to input (like architectures or compilers that this is the case) I will really like to look into it.

Also what is the performance penalty (negative or positive, the last test in the benchmarks gives you for full optimization? This is supposed to be very light weight).

Thanx for the very constructive input!

status, milestone changed; cc, resolution set

David Bellot — Mon, 05 Jul 2010 08:33:35 GMT

cc David Bellot added
status new → closed
resolution → fixed
milestone To Be Determined → Boost 1.44.0