Re: [eigen] Overflow in sum() |

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

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] Overflow in sum()*From*: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>*Date*: Thu, 2 Apr 2009 16:04:37 +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=iEBie+v10+NZnYJ+DlEHLGy/iHIsEq1JU+CS2jvuTrM=; b=vJVR8P+CERu9VPqda/zRd8uabsO9lyDmTPDeJxMNM7p6z1UKSggzU1DHbJfR3DJQQG q4YAiVQx4ZLBGMh+VfgKUBTKgWZdfSVugXY9vQPSHuNhYisf2ZYXHxYK1GahM4+Da+FP CzXdTXOt2XuQkQPUx2D0fDoYgSZnGa2wZeWh4=*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=tz2j/f1f+m5XzZp9D2Sqayx5gq1OQ3Ru9mHgTdB3X7l9UVOREibJaX82yeyATOoN3Q kzn6agAr9Vc1ZtqIiNsroXAIAcfPwf1pzfF1v4v0dwMMliD97xWH23ryQkWA33N5yJxB Cd6FBYuhwbs1ug39sUh/O6SIm/JLH7OtqioBY=

The idea was also to use it in matrix products, dot product, etc. But then I have doubts: if really all these operations overflow then maybe the user really needs to use a bigger scalar type in the first place. There isn't much of a point in using uint8 if you need to cast everytime you do something nontrivial... i'd need to see how this is used in practice. Benoit 2009/4/2 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----- >>>> >> > >>>> >> > >>>> >> > >>>> >> >>>> > >>>> > >>>> > >>>> >>> >>> >>> >> >> >> > > >

**Follow-Ups**:**Re: [eigen] Overflow in sum()***From:*Patrick Mihelich

**References**:**[eigen] Overflow in sum()***From:*Jens Mueller

**Re: [eigen] Overflow in sum()***From:*Patrick Mihelich

**Re: [eigen] Overflow in sum()***From:*Benoit Jacob

**Re: [eigen] Overflow in sum()***From:*Christian Mayer

**Re: [eigen] Overflow in sum()***From:*Benoit Jacob

**Re: [eigen] Overflow in sum()***From:*Jens Mueller

**Re: [eigen] Overflow in sum()***From:*Gael Guennebaud

**Re: [eigen] Overflow in sum()***From:*Jens Mueller

**Re: [eigen] Overflow in sum()***From:*Benoit Jacob

**Re: [eigen] Overflow in sum()***From:*Gael Guennebaud

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] Overflow in sum()** - Next by Date:
**Re: [eigen] Overflow in sum()** - Previous by thread:
**Re: [eigen] Overflow in sum()** - Next by thread:
**Re: [eigen] Overflow in sum()**

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