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*: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>*Date*: Sat, 15 May 2010 09:25:12 -0400*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=qEaEIVSyNz31W0BHR/SDKj5+yAIW8mdx2xwkG+lU3qg=; b=tfOq8eMOZNC3YB0g0E8NsLuGBZwIGz+mN9P/KPxlt7RQ6OJMLOPKxTJDpavQTPZt6R 0YVdsazIIt5LAaebdYLB5hKehPIu0biOgq3HxnSYqR4dZiH6RZOvFuhM7jQQHtIQo7j2 G4uuBrICA9oTxdsrkjJ6wI8sR+Y1fkmiYy6yY=*Domainkey-signature*: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=UwfjgPgL1fqRzdJSmPVgcdWpKibwxqocRxqPme/fD9Mo/ZT8huM08B9kYImMu95fFG FGL/Wfa1CcqsKbU0DabNWoWB+OBR+GbIoe8BSuT0qJNoW6+D/riLBfe5klVSWikjHYPL th8P+iG8wMt+lGqZEK5ZlWFahXOtCUmmXGMlg=

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 > > > >

**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

**Re: [eigen] Indexes: why signed instead of unsigned?***From:*Manoj Rajagopalan

**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/ |