On 15/08/17 23:46, Matt Davey wrote to <pd-list@lists.iem.at>: > I've always used: > > tanh(x) ~= x*(27+x*x) / (27+9*x*x) > > works well and is pretty CPU cheap
Nice.
That seems accurate to about 5 or 6 bits in my tests (over the range -4
to 4). A slightly more accurate (about 7 or 8 bits) variant is:
x * (27.2837670294674 + 1.22070209109864 * x * x)
/ (27.2837670294674 + 9.86205301460732 * x * x)
A higher degree version is accurate to about 16 or 17 bits:
x * (44220389.1067293 + 4672204.74255456 * x * x
+ 34604.8550273853 * x * x * x * x)
/ (44220389.1067293 + 19409074.7654446 * x * x
+ 612890.122925575 * x * x * x * x)
(Though I realize now, later, that there is some redundancy and they
could be normalized to have a leading "1 +" instead of these large
values...)
I found these using gnuplot's fit functionality:
F(x) = x * (a + b * x * x) / (a + c * x * x)
fit F(x) 'tanh.dat' via a,b,c
and similarly for the higher degree version. 'tanh.dat' contains 1024
equally spaced samples of x,tanh(x) in [-4,4], calculated in double
precision with a small C program, similar to the input generation in the
help patches.
I evaluated the accuracy visually in gnuplot:
bits(x,y) = log(abs(y - tanh(x))+2**(-53)) / log(2.0)
plot [-4:4] bits(x,F(x))
I don't know if single-precision rounding will affect the results much.
I put the full precision coefficients into the patches using a text
editor, so double precision Pd can benefit just in case.
It's probably also best to use [clip~ -4 4] before these functions, to
avoid possible Inf or NaN explosions, or maybe [clip~ -1 1] afterwards
would be enough to be safe?
I haven't benchmarked yet.
Consider the patches placed into the Public Domain. Message-rate
versions are left as an exercise.
Claude
--
https://mathr.co.uk
tanh~.tar.gz
Description: application/gzip
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
