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

I will do some more introspective implementations (this is already the 4th or 5th iteration) and will see what version I will finally choose (indexes vs iterators). Both will be included only if the same functionallity is achieved (unless list members think otherwise).

> it should be a separate header, maybe it is then included from
> matrix/vector.hpp

ok, will stick with that. Only concern here is whether project(..) << ....; can be implemented without touching range and slice classes. I guess this can be decided later.

> I don't know if "assigner.hpp" is a good name, but I could not find a 
> better one, yet.
A better name is indeed needed.

> (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)

I will try to follow an implementation that I feel is safe to release sometime in the future. Since my experience with sparse types is limited, any contribution is highly desirable.

> 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) ;

yes this can be implemented. Actually, the non_vector free function provides a type that is used to move the internal indexing to a new position, hence having effectively the functionallity of the above. I believe though that there is value in both interfaces, so will provide them both. Is there any reason that your example should be restricted to sparse types? Maybe something like that? : cm << set(1, 3, 2.0), ... ;

I also consider providing classes so that more elegant filling is possible. i.e.:
an operator move(dx,dy) that will move dx rows and dy columns, an operator move_to(x, y) that will move to specific locations, as well as enable matrix assignments:

matrix<double> big(100,100);
matrix<double> small(10,10);

big<< move_to(45,45), small, move(0,10), small;

Finally do you all prefer operator << or maybe operator <<= (so that we avoid ambiquities with streaming and also have a chance to let templates resolve some type combinations?)

Best
Nasos





Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox. Learn More.