|Re: [eigen] Overflow in sum()|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Overflow in sum()
- From: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
- Date: Thu, 2 Apr 2009 11:16:42 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=eYVUheCRqnqJCGxf5A3ofUayAmQeAkjkAYOCbNXb8Bc=; b=w569Gw934kA/uvHwhSg0qluwROyoNlBUDQeqFQrjwc1VSPByUi/H+VLI+pUFC5980c eyTf+qsua0XEfb8ojPT814obECVai6HyYEhw6dZ4A40mZ+Xttsp0W7quxbuiFqALRTo0 PbmGd8opcQwjSIixEwOFAJC2s8KHo9Mz+JUzk=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=JICrKHn40hJfMCeue2H/NMzgC41K8bgWZT/PhdapP3C5rL/CsLpu92QLpYCRKVFLhT xJZB0MthguX3KbOvORB9v3338EFKRY9Z9yINn7XcnkjioiG678KQ+6zAOrIvx0eMg0IF h8Rg1q7ZseNsPE/iU4Ws6Qk5msgVsu4c9qBDY=
(this already works without creating any temporary matrix)
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?
> 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.
>> 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-----