you cannot know how much time you will save us. Especially during testing !

On Mon, Mar 22, 2010 at 23:18, Gunter Winkler <guwi17@gmx.de> wrote:
Hello Nasos,

this is a feature that was missing long time. So I definitely vote for
it. What do others think?

Am Sunday 21 March 2010 schrieb Nasos Iliopoulos:
> Insipired by the fucntionality of boost.assignment, i decided to
> implement something similar in ublas. Unfortunately due to the
> special way ublas is handling its containers I did not find it that
> convenient to use boost.assignment.

I opened a new ticket to track progress.
https://svn.boost.org/trac/boost/ticket/4034

> - Where do you think this should be added? As a separate header file,
> or included in vector_ and matrix_ expression headers?

it should be a separate header, maybe it is then included from
matrix/vector.hpp
I don't know if "assigner.hpp" is a good name, but I could not find a
better one, yet.

> - I found it incovenient to implement this functionallity using
> iterators

For dense, triangular and banded matrices it is efficient to access the
matrix elements by index. However for most sparse types you will get a
very bad performance because calling the mutable operator(i,j) results
in the following steps:
* look up element (i,j) - this takes O(nnz) operations in worst case
* if element (i,j) exists return a reference to the value
* otherwise insert the element (i,j) into the sparse data structure and
return a reference to this element - this is another O(nnz) operation
in worst case
(if BOOST_UBLAS_NO_ELEMENT_PROXIES is not defined then a proxy is
returned instead of the real element and the insert is performed during
the destruction of the proxy - obviously this makes things only worse)

For the several sparse types we would need more intelligent assignments.
Personally I don't see any use here (except for toy examples).

Do you think it is possible to use triples (i,j,value) to fill a sparse
matrix, e.g. like

cm << sparse_element(0,0,1.0), sparse_element(1,3,2.0) ;


mfg
Gunter

(But I am still not convinced that this makes any benefit)

_______________________________________________
ublas mailing list
ublas@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: david.bellot@gmail.com



--
David Bellot, PhD
david.bellot@gmail.com
http://david.bellot.free.fr