Re: [eigen] Overflow in sum()

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

ah that's yet another different problem...

with sparse matrices, the overflow problem arises only with a few
operations like sum().

But with what you say, dense matrices of uint8, the overflow can
happen with a lot more operations: for example, any matrix product
will typically overflow! So I guess that a matrix product of unit8
matrices should return a matrix with a bigger scalar type...

So how are you dealing with that:
-are you simply not doing matrix products?
-or do your matrices happen to be sparse?
-do you mean that you would need Eigen's matrix product to potentially
return a matrix with a different scalar type?

The latter would be problematic because there is no universal good
choice. The produce of two uint8 matrices should be a uint16 matrix ?
or a uint32 matrix? That depends on the matrix size which is not
necessarily known at compile time. Only the user knows what's best in
his context. So the best approach then would be to let him specify
manually the accumulation type for a matrix, but that would be another
template parameter, would add more complexity everywhere, etc, so
while that seemed potentially OK for sparse matrices i'm very
reluctant to do it for dense ones...

This is starting to look like a potentially very big discussion that
we aren't going to solve easily!

Cheers,
Benoit

2009/4/1 Patrick Mihelich <patrick.mihelich@xxxxxxxxx>:
>> It depends how common your use case is: if many people are going to do
>> the same, we could have another template parameter for sparse
>> matrices, the "accumulated scalar type", decoupled from the "scalar
>> type".
>
> I also have this use case, and not only for sparse matrices. I often use
> uint8 arrays, either because I'm dealing with images or when I have some
> floating-point feature vector that I quantize to uint8 for better time &
> space efficiency. It would be *awesome* if Eigen had good support (SSE,
> etc.) for small integer types; I already have code where I am using Eigen
> for manipulating float feature vectors and my own ugly hand-rolled SSE stuff
> for the quantized uint8 feature vectors. This does require choosing the
> accumulation type intelligently, and maybe the unsigned types have their own
> issues.
>
> An approach that has worked nicely for me is to use a very simple
> metaprogram:
>
> template<typename T> struct Accumulation { typedef T type; }
> template<> struct Accumulation<unsigned char> { typedef unsigned int type; }
> // etc.
>
> Then it is very easy for the user to define an accumulated scalar type
> different from the custom scalar type using partial specialization, and this
> type can be used transparently throughout Eigen.
> Patrick
>