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)
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).
Thanks,
Matt
Date: Tue, 08 Jul 2008 18:35:51 +0200 From: cyrille henry cyrille.henry@la-kitchen.fr Subject: Re: [PD] better tabread4~ To: Charles Henry czhenry@gmail.com Cc: pd-list@iem.at Message-ID: 48739767.3050400@la-kitchen.fr Content-Type: text/plain; charset=ISO-8859-1; format=flowed
hello Chuck,
i tested this. (and commited) i think tabread6c~ is a bit better than tabread4c~. but differences are more smaller
thx
Cyrille
Charles Henry a ?crit :
On Sat, Jun 28, 2008 at 6:43 AM, cyrille henry cyrille.henry@la-kitchen.fr wrote:
The coefficients used in this scheme are
a0= Y[0] a1= 1/12*Y[-2] - 2/3*Y[-1] + 2/3*Y[1] - 1/12*Y[2] a2= -1/24*Y[-2] + 2/3*Y[-1] - 5/4*Y[0] + 2/3*Y[1] - 1/24*Y[2] a3= -3/8*Y[-2] + 13/8*Y[-1] - 35/12*Y[0] + 11/4*Y[1] - 11/8*Y[2] + 7/24*Y[3] a4= 13/24*Y[-2] - 8/3*Y[-1] + 21/4*Y[0] - 31/6*Y[1] + 61/24*Y[2] - 1/2*Y[3] a5= -5/24*Y[-2] + 25/24*y[-1] - 25/12*Y[0] + 25/12*Y[1] - 25/24*Y[2] + 5/24*Y[3]
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...
cyrille
Thanks,
Matt
Date: Tue, 08 Jul 2008 18:35:51 +0200 From: cyrille henry cyrille.henry@la-kitchen.fr Subject: Re: [PD] better tabread4~ To: Charles Henry czhenry@gmail.com Cc: pd-list@iem.at Message-ID: 48739767.3050400@la-kitchen.fr Content-Type: text/plain; charset=ISO-8859-1; format=flowed
hello Chuck,
i tested this. (and commited) i think tabread6c~ is a bit better than tabread4c~. but differences are more smaller
thx
Cyrille
Charles Henry a ?crit :
On Sat, Jun 28, 2008 at 6:43 AM, cyrille henry cyrille.henry@la-kitchen.fr wrote:
The coefficients used in this scheme are
a0= Y[0] a1= 1/12*Y[-2] - 2/3*Y[-1] + 2/3*Y[1] - 1/12*Y[2] a2= -1/24*Y[-2] + 2/3*Y[-1] - 5/4*Y[0] + 2/3*Y[1] - 1/24*Y[2] a3= -3/8*Y[-2] + 13/8*Y[-1] - 35/12*Y[0] + 11/4*Y[1] - 11/8*Y[2] + 7/24*Y[3] a4= 13/24*Y[-2] - 8/3*Y[-1] + 21/4*Y[0] - 31/6*Y[1] + 61/24*Y[2] - 1/2*Y[3] a5= -5/24*Y[-2] + 25/24*y[-1] - 25/12*Y[0] + 25/12*Y[1] - 25/24*Y[2] + 5/24*Y[3]
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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