Re: [eigen] Overflow in sum()

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

I have to say I'm not sure to fully understand your proposal. Where
would you use the additional scalar type and ei_saturate ? only in
sum() ? to tweak the return type of operator+ and so ?


On Thu, Apr 2, 2009 at 1:56 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> I agree, that for Jens' use case, the cast() approach works well; now
> what do the dense-matrix-of-uint8 guys think? If they need to cast all
> the time then I guess this isn't convenient. Putting that into the
> NumTraits had the advantage of being very extensible without making
> the rest of Eigen significantly more complex. But we'll do it only if
> people need it...
>
> Benoit
>
> 2009/4/2 Jens Mueller <jens.k.mueller@xxxxxx>:
>> Oh yes. You are right. For me cast<>() is best. And even for the others,
>> I guess. Just cast the values such that there will be no overflows.
>>
>> Regards,
>> Jens
>>
>> Gael Guennebaud wrote:
>>> 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-----
>>> >> >
>>> >> >
>>> >> >
>>> >>
>>> >
>>> >
>>> >
>>>
>>
>>
>>
>
>
>