Re: [eigen] Indexes: why signed instead of unsigned? |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Indexes: why signed instead of unsigned?
- From: Manoj Rajagopalan <rmanoj@xxxxxxxxx>
- Date: Thu, 13 May 2010 14:24:34 -0400
- Organization: EECS Dept., University of Michigan, Ann Arbor, MI, USA
> 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