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

**Follow-Ups**:**Re: [eigen] Indexes: why signed instead of unsigned?***From:*leon zadorin

**Re: [eigen] Indexes: why signed instead of unsigned?***From:*Benoit Jacob

**References**:**[eigen] Indexes: why signed instead of unsigned?***From:*Rui Maciel

**Re: [eigen] Indexes: why signed instead of unsigned?***From:*joel falcou

**Re: [eigen] Indexes: why signed instead of unsigned?***From:*Benoit Jacob

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] Indexes: why signed instead of unsigned?** - Next by Date:
**Re: [eigen] Indexes: why signed instead of unsigned?** - Previous by thread:
**Re: [eigen] Indexes: why signed instead of unsigned?** - Next by thread:
**Re: [eigen] Indexes: why signed instead of unsigned?**

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