[music-dsp] floating point running sum optimization

[Ross Bencina]

Well, there seems to be two issues: stability and accuracy. I was mainly
musing on what it would take to achieve stability in a similar way to what
you get when you use integers (ie what you add into the accumulator is
exactly what you subtract out).

As for accuracy, the whole idea of getting an accurate sum of a set of
floating point values is pretty difficult -- the order in which you evaluate
the sum determines which pieces of data get rounded / thrown away. It
occured to me the other day that the most accurate ordering for a sum of
floating point numbers is from values with the smalest exponents to values
with the largest exponents. Doing this kind of sorting is not something
which I'd do given the choice.

Ross.

> and ross said:
> > Going straight to integer is a reasonable solution in this case, but
> > i'm
> > still curious to understand if it's possible to construct a portable
> > floating point solution. My suspicion is that it is not easy because
> > although it is possible to calculate the exact error of any single
> > floating
> > point operation, keeping track of the exact accumulated error would
> > require
> > storing every bit of accumulated error (ie you would need to avoid ever
> > throwing any information away), and this would require a large fixed
> > point
> > number representation.
>
> So dan suggested:
> It's an interesting conundrum, since you, I assume, do want that
> accuracy. And it would seem to be a pity to keep all those bits, when
> the entire point of the running sum thingy since you _want_ it to throw
> out a lot of information. (such as all the harmonics of periods
> factored by n, and part of the fregencies of periods <n) Watcha gonna
> do?