On Wed, Jul 9, 2008 at 4:39 AM, cyrille henry cyrille.henry@la-kitchen.fr wrote:
Matt Barber a écrit :
Cyrille,
Could you try this optimization for the tabread6c~ I threw together? It uses the same general notation as the tab4c~ suite:
t_sample a3plusa4plusa5 =0.25f*c+0.125f*e-0.3333333f*d-0.04166667*a; t_sample fminusa = f-a; t_sample eminusb = e-b; t_sample dminusc = d-c;
a5 = 0.2083333f*((fminusa-5.f*eminusb+10.f*dminusc)); a4 = 2.6666667f*eminusb-0.5f*fminusa-5.5f*dminusc-a3plusa4plusa5; a3 = a3plusa4plusa5-a4-a5; a2 = 0.6666667f*(d+b)-0.04166667f*(a+e)-1.25f*c; a1 = 0.6666667f*(d-b)+0.08333333f*(a-e); a0 = c; *out++ = ((((a5 * frac + a4 ) * frac + a3) * frac + a2) * frac +a1)
- frac + a0;
ok
I've tested it and I think it works... I count 20 *'s and 25 +'s = 45 ops vs. 31 *'s, and 27 +'s = 58 ops (if the fractions were written out as decimals).
The compiler should be intelligent enough to convert (2./3.) to 0.666... but using more precision than the 8 digit you write in your code. so i prefer the exact fraction than approximation...
A great point I had considered a while back but didn't trust -- I'm glad you let me know this would work. I'm making a collection of these schemes, so I'll go check that out in the other formulas.
Thanks again,
Matt