[PD-dev] faster more accurate cos than costab

[Claude Heiland-Allen]

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 at lists.iem.at wrote:
> commit 68814591c121db8c613cef5d48d854db0c864d7c
> Author: Miller Puckette<msp at 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
-- 
http://mathr.co.uk