efficient tanh computation

Dozius · 16 Feb 2011

Nice! Going to check this out on the weekend.

trogluddite · 16 Feb 2011

Excellent article - haven't visited your blog for a while, and forgot how good it is. Having quite a maths day today what with DWB's complex numbers post too!!

Looking at your graphs (me like pictures), and your discussion about clipping, am I right in thinking that it would be 'safer' to accept some slight innacuracies for overloud signals, and simply reduce the gain by a dB or so to bring the asymptotes in a little. It looks to me as if the function isn't going to suddenly zoom off to infinity at any 'off the scale' point, but my maths ability has gathered a lot of cobwebs since I was at school!

DigitalWhiteByte · 17 Feb 2011

Very good explanation, now you just have to try it

infuzion · 17 Feb 2011

When even 20 cpu cycles is too much

LOL not sure when 20 cycles are too much for modern CPUs, unless we're talking about smartphones...

bootsy · 17 Feb 2011

trogluddite wrote: Looking at your graphs (me like pictures), and your discussion about clipping, am I right in thinking that it would be 'safer' to accept some slight innacuracies for overloud signals, ...

If safety "brickwall" limiting is not the goal then its better imho.

trogluddite · 17 Feb 2011

Thanks 🙂

Andrew J · 17 Feb 2011

Thanks bootsy, that's a nice compromise and is kind of a middle ground between two different options I tend to use.

Now, to save others some typing time (untested because I've got to go to work now!):

streamin in; streamout out;

float F378=378; float F17325=17325; float F135135=135135; float F28=28; float F3150=3150; float F62370=62370;

movaps xmm2,in; movaps xmm0,xmm2; // xmm0 = in = x mulps xmm2,xmm2; // xmm2 = x^2

movaps xmm3, xmm2; // a = (((x^2=378)*x^2+17325)*x^2+135135)*x addps xmm3,F378; mulps xmm3,xmm2; addps xmm3,F17325; mulps xmm3,xmm2; addps xmm3,F135135; mulps xmm3,xmm0;

movaps xmm4,F28; // b = ((28*x^2+3150)*x^2+62370)*x^2+135135 mulps xmm4,xmm2; addps xmm4,F3150; mulps xmm4,xmm2; addps xmm4,F62370; mulps xmm4,xmm2; addps xmm4,F135135;

divps xmm3,xmm4; // xmm3 = a / b movaps out,xmm3;

TomC · 17 Feb 2011

bootsy wrote: If safety "brickwall" limiting is not the goal then its better imho.

BTW, before someone else invests some time into that, I've done a Pade approximation for tanh some moons ago and it does NOT sound as good.

Tom

aliasant · 17 Feb 2011

Andrew J wrote: Thanks bootsy, that's a nice compromise and is kind of a middle ground between two different options I tend to use.

Now, to save others some typing time (untested because I've got to go to work now!):

Lol Im one of those who emediatly typed it by hand and it does work pretty well. It does break apart when the signal is above 20 something dB but it does it smoothly so there aint really a problem containing it.

infuzion · 18 Feb 2011

Andrew J wrote: Now, to save others some typing time (untested because I've got to go to work now!)

Seems to graph well on a Function Plot, though I don't know how it sounds. Only saves 1 cycle though from bootsy's.

Andrew J · 18 Feb 2011

infuzion wrote: Andrew J wrote: Now, to save others some typing time (untested because I've got to go to work now!)

Seems to graph well on a Function Plot, though I don't know how it sounds. Only saves 1 cycle though from bootsy's.

It is bootsy's! Glad my magic touch could save 1 cycle by just typing it up verbatim 😉

trogluddite · 18 Feb 2011

LOL 😀 Hey, why not print it out and then retype the printout all back in again - if you save just one clock cycle with every iteration, we can start saving some serious CPU! 😈

Oh, and remind me to send you a screenshot of my Soopa Loopa code - if you retyped all 800 odd lines, I ought to save about 200 cycles! 😉

Dozius · 18 Feb 2011

Had a chance to try it out. Most impressed! It's only 2x the cpu cycles of the best approx in my toolkit and it's 100% accurate in the working range. Which btw was up to around +/- 5 in terms of float numbers. Even after that the max error was marginal (around 0.0001). Even at +/- 10 the error only crept up to approx 0.009 which is only slightly worse than my other approximation.

The only advantage of the other is it takes half the cpu and the error stays consistent outside the normal +/-1 range even when it goes off into insane levels.

Great work Bootsy.

infuzion · 19 Feb 2011

Andrew J wrote: infuzion wrote: Andrew J wrote: Now, to save others some typing time (untested because I've got to go to work now!)

Seems to graph well on a Function Plot, though I don't know how it sounds. Only saves 1 cycle though from bootsy's.

It is bootsy's! Glad my magic touch could save 1 cycle by just typing it up verbatim 😉

I think I was comparing it to an older version bootsy emailed to me a month ago, then I suggested how to save that 1 cycle 😉