what happens is that the end() is the diagonal! so the row ends
there....this is not acceptable in my opinion.

I must say that I agree. It sounds strange, but in fact ublas iterates on real value rather than all the values.
It's quite old now and would mean to break the API to change this. Maybe by introducing a new type of "full" iterator.
Let think about it.

Otherwise iterators make no sense and uBlas could be in principle
remove them, using instead direct access and the row,range and project
function (also I've seen very interesting progress on the assignement
machinery!).

I think that's what most of the people do in fact, because it means to be more natural to parse vectors and matrices with indexes.
At least this is what I do most of the time, but maybe it's due to the type of computations I do.

Another example is the fact that we have no iterators on column or row from a matrix: if one want to parse each single row of a matrix, it will have to go through the row() and project functions. That's nice too but we can think having iterators on row and columns too. That's just an idea.

Cheers,
David

Cheers, Andrea

> Cheers,
> David
>
> On Wed, May 19, 2010 at 13:20, Andrea Cassioli
> <cassioliandre@gmail.com>wrote:
>
>> Hi Gunter,
>> I agree with you in using the range and project machinery to get what
>> I need, and I have to say I missed (probably for my lazynesss) this
>> set of functionalities the first time I looked the documentation.
>>
>> Apart from the expressiveness, my major concern is that is not clear
>> at all that ublas vectors are not as std::vector. Indeed, from the
>> very beginning, it is stated : " The glue between containers, views
>> and expression templated operations is a mostly STL conforming
>> iterator interface.". What does it exactly mean "mostly conforming"?
>>
>> Probably It should be better to say that it is not STL conforming,
>> despite some similarity. I fancy if no iterators at all would be
>> provided and only ragne and project functions would be needed...
>>
>> In my opinion, such uncertainties are a major reason for people not to
>> choose or support ublas. I like it and it is very nice to me also
>> because my code is already boost oriented. I think that before going
>> on with new functionalities, a major revision of documentation and
>> tuorial should be started.
>>
>> Andrea
>>
>> On Wed, May 19, 2010 at 1:41 AM, Gunter Winkler <guwi17@gmx.de> wrote:
>> > Hello Andrea,
>> >
>> > Andrea Cassioli schrieb:
>> >> I'm pretty sure I'm doing something wrong, but I would expect the
>> >> matrix_row adaptor to behave as a normal vector, that is I would like
>> >> to play with it seamlessly.
>> >>
>> >> Am I wrong or it is a bug??
>> >>
>> >
>> > I am not sure if I understand you code. However, a ublas::vector is
>> > _not_ a STL vector. The reason is that ublas' vectors and matrices
>> > represent object for linear algebra, where STL vectors are simply
>> > containers. An ublas vector is much more like a std::valarray than like
>> > any other STL container. Thus it is not possible to assign a vector of
>> > length n to a vector of length (n+1).
>> >
>> > Despite that: you can use the free functions project(), row() and
>> > column() to get more expressive code. For example:
>> >
>> > matrix<double> A(10,10);
>> > vector<double> v(5);
>> >
>> > // untested
>> > v = project( row(A, 3), range(0,5) );
>> > project( column(A, 4), range(5,10) ) = v;
>> >
>> > see also
>> >
>> http://www.boost.org/doc/libs/1_43_0/libs/numeric/ublas/doc/operations_overview.htm#sub
>> >
>> > mfg
>> > Gunter
>> >
>> >
>> >
>> > __________ Hinweis von ESET NOD32 Antivirus, Signaturdatenbank-Version
>> 5125 (20100518) __________
>> >
>> > E-Mail wurde geprüft mit ESET NOD32 Antivirus.
>> >
>> > http://www.eset.com
>> >
>> >
>> > _______________________________________________
>> > ublas mailing list
>> > ublas@lists.boost.org
>> > http://lists.boost.org/mailman/listinfo.cgi/ublas
>> > Sent to: cassioliandre@gmail.com
>> >
>>
>>
>>
>> --
>> Andrea Cassioli
>> _______________________________________________
>> 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
>

--

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