Re: [eigen] Indexes: why signed instead of unsigned?

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

2010/5/13 Manoj Rajagopalan <rmanoj@xxxxxxxxx>:
>
>> There remains the question of signed vs. unsigned. In other words,
>> ptrdiff_t vs. size_t. I'm totally unable to decide either way. Help!
>>
>> Benoit
>>
>
> Would it be a bad idea to add the integer-type as a template parameter and let
> the user decide based on his/her "taste"? A small, non-eigen, contrived
> example:
>
> template<typename T, typename I=int>
> class vector
> {
> public:
>    typedef I idx_type;
>    idx_type rows() const;
>    idx_type cols() const;
>    T const& operator [] (idx_type const& n) const;
>    // etc.
> };

See answer to Leon, for the Dense matrix classes this feature is
nearly useless and we have too many templ params already, and if/when
needed this can go into the existing Options param.

For Sparse matrices it's up to Gael, but there is more time.

> Instantiations like vector<double> will default to using int for index-type as
> Eigen has all along (for backward compatibility).

No no, we're switching to ptrdiff_t now, as now is the only time we
can break ABI compatibility.

>
> Instantiations like vector<double, ptrdiff_t> will cover user-desired cases.
>
> Since Eigen is header-only and doesn't have to worry about
> library-binary-compatibility across platforms and versions

"Across platforms" ---> Of course we don't have to worry about binary
compatibility across platforms, but that's not because we're a
template library.

"Across versions" ---> We DO have to worry about binary compatibility
across versions, at least of our plain matrix / array classes. Indeed,
there are people who are developing binary libraries using Eigen,
passing around pointers to Eigen matrices and arrays. They want that
if they build their library against Eigen 3.x it's usable by an
application built against Eigen 3.y. Otherwise, if that's not
possible, then suppose that you're developing an application using
Eigen and some library installed on your system, that uses Eigen, then
you would have to make sure to use the exact same version of Eigen
that your system uses, you wouldn't be able to move to the latest
Eigen version when it becomes available, and as a result the adoption
of newer Eigen versions would be far slower.

>, this change could
> be a one-size-fits-all solution (assuming there are no caveats that I have
> missed). Of course, it is a bigger headache for the library programmers :-)
> It will also be a bigger testing issue but these tests can be generated since
> templates are being used. The suite will just take longer to run.
>
> When writing loops with down-counters maybe some kind of static assertion or
> warning could be included if an unsigned type is used? This could be achieved
> with a traits struct.

We can static assert once and for all in e.g. the Matrix constructor,
to block unsigned types.

>
> The documentation could warn users about the pitfalls of using unsigned types
> by consolidating this recent discussion.

No no, let's completely disallow unsigned types, rather than allowing
something "dangerous".

> Someone raised a question about large indices. I had a friend in image
> processing who dealt with very large vectors, since in a raw image we have
> MxN pixels with RGBA channels for each pixel. So it might make sense to allow
> for large indices on machines that can support them.

We have already decided to move to ptrdiff_t which will be 64bits on
64bit platforms.

> Also, we can imagine
> dealing with volumetric image data that resides on disk and is paged into RAM
> on-demand by a library like STXXL or Global-Arrays and might require large
> indices for "global" indexing.

Yes, see above discussion about distributed storage.

Benoit

> More generally, large indices can result from linearizations of
> multidimensional grids - my simulations involve 3D real-space and its related
> 3D reciprocal space and I sometimes work with distributions that are
> therefore 6-dimensional. Another example: state-spaces in quantum computing
> grow exponentially with number of qubits (tensor-product spaces of dim
> 2^{#bits}) and related simulations might quickly require large indices when
> the number of bits crosses 31.
>
> Just my 2 bits.
>
> Thanks,
> Manoj
>
>
>
>