[PD] better tabread4~

[Matt Barber]

On Wed, Jul 9, 2008 at 4:39 AM, cyrille henry
<cyrille.henry at 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