grrr, i had forgotten but a while ago someone inquired about the
possibility to use eigen with distributed storage, and we took that
into account when doing the big class-hierarchy-refactorings, to
ensure it's possible to plug in a new storage system, see
StorageKind... so it would be a bit too bad to restrict the indices
types to int.
This actually suggests that no matter what the default is, the indices
type should be something that the Storage can control. This would also
allow Sparse matrices to use different index types. We could make it a
typedef in ei_traits, that is propagated to nested expressions, ...
Gael, what's your opinion?
Benoit
2010/5/11 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
2010/5/11 Rui Maciel <rui.maciel@xxxxxxxxx>:
On 11 May 2010 16:47, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
I just had a diabolic idea, if we agree that bigger-than-2^31-support
is not a top priority and will at most be used by relatively few
people, then we can keep things unchanged for now, so keep 'int' in
Eigen 3.0, and later on, when actual people actually need it (perhaps
in eigen 3.45), add a non-default compile-time option
EIGEN_USE_LONG_INDICES. Such an option would then break the ABI of
Eigen classes, so it couldn't become default.
Question - is BLAS/LAPACK using int or ptrdiff_t ?
Benoit
As this move will break the ABI then why not implement it right on the
3.0 release instead of pushing it to a point release in the future?
Because we've a lot on our plates already now.
Benoit
Rui Maciel