Hi,

Even without double everywhere there are improvements that could be made to accuracy without sacrificing performance.

On 21/04/15 11:00, pd-cvs-request@lists.iem.at wrote:

commit 68814591c121db8c613cef5d48d854db0c864d7c Author: Miller Puckettemsp@ucsd.edu Date: Mon Apr 20 12:08:09 2015 -0700

 first cut at compiling with t_float set to double.  Using some ideas
 from Katja's fork of 0.43, but re-doing it with more willingness to let
 objects such as bonk~ simply use 'float' when suitable.

 It might be desirable to revisit phasor~, etc., whose phase accuracy
 limitations are noticeable in double (not so much in single precision).
 In particular, the long-varispeed example now sounds OK with
 just a phasor~ driving teh read, but the phase increment is
 too quantized.

 Scattered things appear to need a closer look (e.g., smeck
 doesn't produce any outout).

float costab[513] with linear interpolation isn't very accurate - some points are exact, most are too close to 0, the unusual costab initialization probably doesn't help - it could be improved by storing values that aren't exact cos() but when interpolated the errors average out a bit better, some above and some below the true value.

I made a 9th order polynomial approximation, it's faster than costab (at least on my amd64 architecture / gcc version) and more accurate too:

http://mathr.co.uk/blog/2015-04-21_approximating_cosine.html

I didn't check yet whether the noise spectrum is more or less audibly objectionable than costab. There may also be a hybrid approach that does better on both counts (piecewise polynomials?). Also I didn't put any work in trying to optimize costab, as I don't really understand the tabfudge stuff properly.

Claude