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

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]


> 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.
};

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




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/