Re: [eigen] Overflow in sum()

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

what about:

mat.cast<uint>().sum()

(this already works without creating any temporary matrix)

gael.

On Thu, Apr 2, 2009 at 11:03 AM, Jens Mueller <jens.k.mueller@xxxxxx> wrote:
> The first proprosed plugin solution is acceptable for me. Since this
> plugin feature is neat anyway.
> If this overflow thing really matters for users, then extending
> NumTraits is reasonable, since people with custom matrices write their
> own NumTraits declarations anyway. So at the moment there are three
> users bothered with this problem. Is this considered enough?
>
> Regards,
> Jens
>
> Benoit Jacob wrote:
>> Thanks for your input; here's a proposal.
>>
>> First of all, what I really don't want is to add another template
>> parameter to Matrix and to add more enums/typedefs in xpr classes. So
>> I'm trying to put all the stuff related to that issue in the numeric
>> type itself. This way, only people who use that feature, pay for it.
>>
>> So here's the proposal. in NumTraits<T> we just add another typedef
>> for the accumulation type, and we define a function ei_saturate<T>(T
>> t) for all possible accumulation types T. For all basic types
>> (including uint8) we define the accumulation type to be just T and
>> ei_saturate(t) returns just t, so the default for integer types is the
>> clipping behavior. But then we can define (or let the user define)
>> more types, like a type that is a wrapper around uint8 with the
>> accumulation type set to uint32 and ei_saturate(t) actually saturating
>> to 255, etc. The user can then use a matrix with that type as scalar
>> type. If for a different matrix he wants a different accum type, he
>> just uses a different scalar type with a different type as
>> NumTraits<T>::AccumType. In fact, it's even OK to let the AccumType be
>> a template parameter of the wrapper-around-uint8 scalar type.
>>
>> Cheers,
>> Benoit
>>
>> 2009/4/1 Christian Mayer <mail@xxxxxxxxxxxxxxxxx>:
>> > -----BEGIN PGP SIGNED MESSAGE-----
>> > Hash: SHA256
>> >
>> > Benoit Jacob schrieb:
>> >> 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...
>> >
>> > I'm working in the area of embedded software development where huge
>> > amounts of numerical software has to be dealt with in real time. As some
>> > of that code is quite old it's mostly written in fixed point, i.e. it's
>> > using normal integer operations (the variables usually have to be
>> > multiplied by a factor and an offset has to be added to get the "real
>> > world meaning" of each variable).
>> >
>> > In this context lots of programmers are looking for data types and
>> > possible overflows just to handle that problem, as each multiplication
>> > and addition could cause a problem.
>> >
>> > And there are usually two solutions: saturate or clip (i.e. just use the
>> > modulo value).
>> >
>> > => that's too far for eigen to handle
>> >
>> > But it might be a nice solution to offer (as a template parameter) a
>> > different data type as an result, so that the eigen user can handle this
>> > requirement each time it could appear in the best way for his algorithm.
>> > (And if possible we could also offer an saturating and an clipping
>> > version of the algorithm)
>> >
>> > CU,
>> > Chris
>> >
>> > -----BEGIN PGP SIGNATURE-----
>> > Version: GnuPG v1.4.9 (GNU/Linux)
>> >
>> > iEYEAREIAAYFAknTwKMACgkQoWM1JLkHou3scwCfSlLGepOwfZHX7/2a+X7de/MC
>> > eZcAn2a0doVjFW4/M8witEbO0Op8HWPI
>> > =eZE/
>> > -----END PGP SIGNATURE-----
>> >
>> >
>> >
>>
>
>
>