Currently, the Index type appear in different contexts:
1 - For classic dense expression, Index refers to the integer type used for storing and returning sizes, for coefficient indexes, etc. In this context it is always equal to DenseIndex (=ptrdiff_t).
2 - For PermutationMatrix, Transpositions and Sparse expression, it is used for the same purpose as above, but it also corresponds to the value type used to store all the indices. It defined through a template parameter and most of the time it is equal to 'int' for compactness purpose.
This results in a lot of conflicting conversions from 64 bits integers to 32 bits ints, and so a huge amount of legitimate warnings when such warnings are detected.
In my opinion, in the 2nd case all the sizes, coefficient indexes, loop counters, etc. should keep using the globally defined DenseIndex type (poorly named), and the templated Index type should only be used for the internal storage and for method that explicitly and directly returns such indices. Concretely, this would means that PermutationMatrix::rows() would always return a DenseIndex, PermutationMatrix::operator()(i) would always take a DenseIndex, but it would return the Index type defined from its template parameter.
The problem is that would slightly change the API since some method would now take/return long int instead of int. On the other
This does not strictly block bug 877, but removing typedef Index from all classes would partially simplify resolving that.
Agreement for bug 877 was to add a global Index typedef, and explicitly use that in the interface (where it makes a difference).
For now, I would suggest to still return the actually used Index type for methods like rows(), cols() in order to avoid conversion warnings if users store their result as int (for SparseMatrix<..., int>).
See bug 877 comment 20 for an update on this.
Fixed through this merge: https://bitbucket.org/eigen/eigen/commits/b5be5e10eb7f/
-- GitLab Migration Automatic Message --
This bug has been migrated to gitlab.com's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.com/libeigen/eigen/issues/572.