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

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

2010/5/15 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...

We really don't have to add yet another template parameter, especially
not to the dense Matrix and Array classes where this feature il almost
useless (save up to a dozen bytes on a dynamically sized matrix,
woohoo, and save zero bytes on fixed-size matrices).

If and when someone needs this we can always make that part of the
existing Options template parameter.

For SparseMatrix, the situation may be different as it's a more useful
feature, anyway we're not yet close to offer API stability in the
Sparse module (at the meeting the plan was to move it to unsupported)
so I'll leave it to Gael to decide what he wants to do there!

Benoit


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