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

[leon zadorin <leonleon77@xxxxxxxxx>]

On 5/14/10, Manoj Rajagopalan <rmanoj@xxxxxxxxx> wrote:
>
>> 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"?


I like this idea possibly the most.

It allows for the most-customizable approach. In some of my progs, I
have similar mechanisms where the exact declaration of int resolution
and float resolution are being kept outside the logic of the
underlying, possibly library-level, mechanisms and algorithms.

Whether such declarations are explicit template parameters as in "each
template parameter for each resolution" or whether there is a commonly
expected "traits types policy" bundled type which is plugged into the
vector/matrix/etc. as a single template arg, etc. etc. etc. is also
fine by me...

Keeping in mind that one may also want to have a single program which
wants to use two distinct instances of the eigen-related mechanisms:
one with large numeric range/resolution and another not; this approach
(i.e. template-based definition of int resolution) would also allow
for such a finer-level customization.

kind regards
Leon.

> 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.
> };
>
> Instantiations like vector<double> will default to using int for index-type
> as
> Eigen has all along (for backward 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, 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.
>
> The documentation could warn users about the pitfalls of using unsigned
> types
> by consolidating this recent discussion.
>
> 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. 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.
>
> 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
>
>
>
>