On Mon, Dec 10, 2012 at 01:39:48PM +1100, Ross Bencina wrote:
avoid any loss of precision due to truncation... etc. There is also
arbitrary precision arithmetic if you don't want to throw any bits
away.
This seemed most pertainent to Alessandro's requirement that N was unknown
and might
I don't think you have been clear about what you are trying to achieve.
Are you trying to compute the sum of many signals for each time point? Or are
you trying to compute the running sum of a single signal over many time
points?
Hello, thanks for helping. I want to sum prerecorded
On 12/10/12 11:18 AM, Bjorn Roche wrote:
On Dec 10, 2012, at 4:41 AM, Alessandro Saccoia wrote:
I don't think you have been clear about what you are trying to achieve.
Are you trying to compute the sum of many signals for each time point? Or are
you trying to compute the running sum of a
I dream of a time when TeX notation will be acceptable and universal
in contexts like this.
y=(1/N) \sum_{i=0}^N x_i
doesn't stay ugly for very long, and is ultimately easier to read.
And you can paste it into here:
http://www.codecogs.com/latex/eqneditor.php and then it's actually
even MORE
On Dec 10, 2012, at 12:35 PM, robert bristow-johnson wrote:
On 12/10/12 11:18 AM, Bjorn Roche wrote:
On Dec 10, 2012, at 4:41 AM, Alessandro Saccoia wrote:
I don't think you have been clear about what you are trying to achieve.
Are you trying to compute the sum of many signals for each
On Dec 9, 2012, at 2:33 PM, Alessandro Saccoia wrote:
Hi list,
given a large number of signals (N 1000), I wonder what happens when adding
them with a running sum Y.
1N - 1
Y = - * X + ( ---) * Y
N N
Yes, your intuition is
Thanks Bjorn,
On Dec 9, 2012, at 2:33 PM, Alessandro Saccoia wrote:
Hi list,
given a large number of signals (N 1000), I wonder what happens when
adding them with a running sum Y.
1N - 1
Y = - * X + ( ---) * Y
N N
Yes,
I would consider storing N and your sum separately, doing the division
only to read the output (don't destroy your original sum in the
process). I guess this is the first thing that Bjorn suggested, but
maybe stated a little differently.
There's a technique called Kahan's Algorithm that tries to
That is really interesting, but I can't see how to apply the Kahan's algorithm
to a set of signals.
In my original question, I was thinkin of mixing signals of arbitrary sizes.
I could relax this requirement, and forcing all the signals to be of a given
size, but I can't see how a sample by
um, a sorta dumb question is, if you know that all signals are mixed
with equal weight, then why not just sum the fixed-point values into a
big long word? if you're doing this in C or C++, the type long long
is, i believe, 64 bits. i cannot believe that your sum needs any more
than that.
Hi Alessandro,
A lot has been written about this. Google precision of summing floating
point values and read the .pdfs on the first page for some analysis.
Follow the citations for more.
Somewhere there is a paper that analyses the performance of different
methods and suggests the optimal
On Dec 9, 2012, at 8:18 PM, Alessandro Saccoia wrote:
That is really interesting, but I can't see how to apply the Kahan's
algorithm to a set of signals.
In my original question, I was thinkin of mixing signals of arbitrary sizes.
I could relax this requirement, and forcing all the signals
On 10/12/2012 1:47 PM, Bjorn Roche wrote:
There is something called double double which is a software 128
bit floating point type that maybe isn't too expensive.
long double, I believe
No. long double afaik usually means extended precision, as supported
in hardware by the x86 FPU, and is 80
13 matches
Mail list logo
