Re: [eigen] Iterators with dense matrices: (was: Areas of eigen3 variation and using eigen2/3 in generic code)

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

2010/1/3 Jesse Perla <jesseperla@xxxxxxxxx>:
> On Sun, Jan 3, 2010 at 8:59 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
> wrote:
>>
>> 2010/1/3 Paul C. Leopardi <paul.leopardi@xxxxxxxxxxxx>:
>>
>> So Eigen's approach has been to let the user write higher-level code in
>> terms of /expressions/ and /functors/. The user can provide his own
>> expressions and functors, which describe how coefficient(i,j) is computed,
>> optionnally providing a SIMD implementation for which we have a portable
>> infrastructure; and then the user uses that with Eigen's built-in loops.
>
> Definitely the right approach.  The higher level and closer to linear
> algebra the better... But for cases where you have not implemented an
> algorithm and default generic algorithms exist, it is necessary to be able
> to use them without initially implementing extensions to Eigen.
> For example:  is there an Eigen equivalent to the following things I do all
> day long:
> std::vector<double> vec(4);
> //... fill it
> std::vector<double> vec2(4);
> std::transform(vec.begin(), vec.end(), vec2.begin(), [](double x){return
> my_func(x)}); //for some function

For this, yes: first you would wrap my_func into a functor, and then you'd call:
  vec2 = vec.unaryExpr(my_functor());

Again, the advantages are vectorization and unrolling (we make it easy
to SIMD-enable your functor in a portable way).

See:
http://eigen.tuxfamily.org/dox/classEigen_1_1MatrixBase.html#a1d1835f182c0141dc073a1045c8a2e9e

> //or do a binary search from the 2nd item for the number 1.0, with it sorted
> with some functor
> std::binary_search(vec.begin() + 1, vec.end(), 1.0,
> my_strict_weak_ordering_functor());

OK, for this one, we don't provide anything, so indeed using STL
algorithms is useful.

One remark: you could work by directly addressing the underlying array.
  vector.data()  returns a pointer to the vector's coeffs
  vector.size()  returns the number of coeffs

STL algorithms can be applied directly to such an array, right?

So in the case of a plain vector, all you need is data() an size() ?

In the case of more general expressions (e.g. the sum of two vectors),
of course, this is no longer enough.

>
>>
>> I still wonder:
>> general-purpose Array class, maybe people will also need general purpose
>> array
>> processing, so our built-in loops might no longer be enough and
>> iterators migth become
>> really needed?
>>
> I think they are necessary for me to standardize on the library to have the
> option (at least for Vectors).  I have too much of my brain and code
> invested in generic code around std patterns, iterators, and eventually
> ranges.

OK, so, I'm not against it and it does seem useful. My next question
is: is it important that the methods returning begin and end iterators
are named begin(void) and end(void) ?

Everybody: how about:
  start ---> head
  end ---> tail
Keep start and end(int) for compatibility in Eigen2Support
Remove end<int>() altogether

Or is it OK to give a different name to the iterator-returning methods?

Benoit