Re: [eigen] Overflow in sum()

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]


2009/4/1 Patrick Mihelich <patrick.mihelich@xxxxxxxxx>:
> 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.

About uint8 support: OK, the only reason why we don't have it is we
didn't think there would be much use, but adding support for that,
including SSE, should be doable (i don't say trivial because i don't
have experience about SSE for uint8 scalars...)

The only difficult question here is, should Eigen do something about
overflow (or leave that entirely to the user) and if yes, what.

If it's ok to make the accumulation type depend only on the scalar
type, and not configurable per matrix, then that can be done via a
macro like EIGEN_ACCUM_TYPE_FOR_UINT8 which the user can define. The
only really annoying thing would be to have to let the accumulation
type be configurable per matrix.

Cheers,
Benoit

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



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