| 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: Christian Mayer <mail@xxxxxxxxxxxxxxxxx>
- Date: Wed, 01 Apr 2009 21:29:40 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :reply-to:user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=DBjdMFJSRXsbiG/Ltf1a5FunE54ADxmq0XFpjpOxXhs=; b=GSG4aYUQluHInTFflytHtdFI63JaistCeJFyd0mfq2Fq4eJqSpo+GFOVXoJYyGxcgz Vi1Uc/bUb3iq/sjZiaPlNH49+Llv8yF8oGhsDJKwTPVW49GtIuZiv1aKHFrk7L5XbnNZ 7KKDKisDZvDue9yg1PWqL9CB5IKmFT3JWGu/E=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to :subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=m1JOxw8GmmPF5scydSOKbgdGgECWXCEF9ZQ4sSumwLN6z0JsiLz/bdDk3QhrDYtJed elkzDGt1QYO6R/y4mrH1/+Q/rXLH7dmSz0sf6DuadrQ7kCtjSUGvrzO5DwZMBvLLWtPz QzdM0T+Eq4n3SkAmivoinp5wXkVYu2Uue1aPk=
-----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-----