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 be
On 12/10/12 12:42 PM, Dave Gamble wrote:
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/eqnedito
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 si
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 read
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 sing
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 single signal over many time
>
>
> 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 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
Hello Alessandro,
On 10/12/2012 12:18 PM, Alessandro Saccoia wrote:
> In my original question, I was thinkin of mixing signals of arbitrary
> sizes.
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
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 signa
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
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.
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 samp
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 c
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
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 intuiti
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
Given the limited precision, intuitively something bad will happen for a large
N.
Is th
17 matches
Mail list logo
