fast sin(x) function

[Stephen Blinkhorn-2]

Hi all,

I'm looking for a fast sin(x) type function.  So far I haven't found  
anything with the necessary precision for audio work.  Any ideas?

Thanks,
Stephen.
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp 
http://music.columbia.edu/mailman/listinfo/music-dsp

[Bob Grove]

Generate a lookup table.

Just use Matlab to generate the number of points you want of the sinusoid
and the precision (bit depth), you want, output the calculated coefficients
[y], ([y] = sin([x])) to a .txt file and do a look up table.  You can even
format the output in Matlab to whatever language syntax you're pulling the
function into.  i.e.
double y[] = {0.00023459f, 1.439568f, 1.723986f ........ 0.000016892f, 0f};

http://en.wikipedia.org/wiki/Lookup_table

Google should have more stuff out there.

You might have to do a floor, trunc, %, or max function to index your table
depending on what you're doing.  

If you don't have Matlab, you can also write up a fast python script or a c
executable to do the same thing.

-----Original Message-----
From: Stephen Blinkhorn [mailto:stephen.blinkhorn@...]
Sent: Tuesday, June 10, 2008 12:14 PM
To: music-dsp
Subject: [music-dsp] fast sin(x) function

Hi all,

I'm looking for a fast sin(x) type function.  So far I haven't found  
anything with the necessary precision for audio work.  Any ideas?

Thanks,
Stephen.
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp
links
http://music.columbia.edu/cmc/music-dsp 
http://music.columbia.edu/mailman/listinfo/music-dsp

--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp 
http://music.columbia.edu/mailman/listinfo/music-dsp

[Sampo Syreeni]

On 2008-06-10, Bob Grove wrote:

> Generate a lookup table.

I'd argue against that in today's memory starved environments; today
looking something up is often vastly inferior to just calculating it out
on the fly. I'd instead crack a book on polynomial approximations, and
go piecewise polynomial with an entirely code based approach.

Or, then, use one of the better math libraries, which...do that for you.
;)
--
Sampo Syreeni, aka decoy - mailto:decoy@..., tel:[phone]
student/math+cs/helsinki university, http://www.iki.fi/~decoy/front
openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp 
http://music.columbia.edu/mailman/listinfo/music-dsp

[Sampo Syreeni]

On 2008-06-10, Sampo Syreeni wrote:

> I'd argue against that in today's memory starved environments; [...]

(Naturally what I meant there wasn't "memory starved", but "memory
bandwidth and/or latency starved". Sorry.)
--
Sampo Syreeni, aka decoy - mailto:decoy@..., tel:[phone]
student/math+cs/helsinki university, http://www.iki.fi/~decoy/front
openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp 
http://music.columbia.edu/mailman/listinfo/music-dsp

[bastian.schnuerle]

via complex numbers a + jx ..

Am 10.06.2008 um 22:09 schrieb Sampo Syreeni:

> On 2008-06-10, Sampo Syreeni wrote:
>
>> I'd argue against that in today's memory starved environments; [...]
>
> (Naturally what I meant there wasn't "memory starved", but "memory  
> bandwidth and/or latency starved". Sorry.)
> --
> Sampo Syreeni, aka decoy - mailto:decoy@..., tel:[phone]
> student/math+cs/helsinki university, http://www.iki.fi/~decoy/front
> openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2
> --
> dupswapdrop -- the music-dsp mailing list and website: subscription  
> info, FAQ, source code archive, list archive, book reviews, dsp  
> links http://music.columbia.edu/cmc/music-dsp http://
> music.columbia.edu/mailman/listinfo/music-dsp

--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp 
http://music.columbia.edu/mailman/listinfo/music-dsp

[Eric Brombaugh-2]

Sampo Syreeni wrote:
> On 2008-06-10, Sampo Syreeni wrote:
>
>> I'd argue against that in today's memory starved environments; [...]
>
> (Naturally what I meant there wasn't "memory starved", but "memory
> bandwidth and/or latency starved". Sorry.)

Probably depends on what type of processor you're using (desktop vs
embedded), how large the LUT is (does it fit in cache on a high-end PC),
  what kind of FP support you've got and how many iterations of the
polynomial it takes to get the required accuracy on your function.

Definitely not just a one-size-fits-all type of answer...

Eric

--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp 
http://music.columbia.edu/mailman/listinfo/music-dsp

[Didier Dambrin]

I haven't found a (16k values) lookup table vastly inferior. With 16k values
you can ommit interpolation & get away with it, and then it's cheap
instruction-wise, and the cache does its job.
I have a highly optimized SSE1 version that computes 8 sinewaves at once
(talking about additive synth use) (it could compute a single sinewave but
then you'd have to init your algo with 8x3 sines instead of just 3) which is
only a little faster than a lookup table. Only problem, with single float
precision it quickly loses precision over time, and then has to be
re-initialized (3 costy sines) or you have to process in double precision
(only 2x packed).

..but that's to generate tones, not compute random sines, so better first
know what he needs a sine for.


I just went checking if Intel or AMD finally added something to help
low-quality sine computation (that everyone asks for, like FISTTP that they
introduced in SSE3, only 10 years too late, god knows why they add a new FPU
instruction while they advise SSE even for scalar stuff), saw nothing in
SSE4, and saw that the next gen will have the same fight as 3DNow vs SSE.
Except that it's now AMD that calls the new one SSE5, and Intel will
introduce 'AVX'. And we'll have to guess which one will win.




----- Original Message -----
From: "Sampo Syreeni" <decoy@...>
To: "A discussion list for music-related DSP" <music-dsp@...>
Sent: Tuesday, June 10, 2008 10:06 PM
Subject: RE: [music-dsp] fast sin(x) function

> On 2008-06-10, Bob Grove wrote:
>
>> Generate a lookup table.
>
> I'd argue against that in today's memory starved environments; today
> looking something up is often vastly inferior to just calculating it out
> on the fly. I'd instead crack a book on polynomial approximations, and
> go piecewise polynomial with an entirely code based approach.
>
> Or, then, use one of the better math libraries, which...do that for you.
> ;)
> --
> Sampo Syreeni, aka decoy - mailto:decoy@..., tel:[phone]
> student/math+cs/helsinki university, http://www.iki.fi/~decoy/front
> openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2
> --
> dupswapdrop -- the music-dsp mailing list and website:
> subscription info, FAQ, source code archive, list archive, book reviews,
> dsp links
> http://music.columbia.edu/cmc/music-dsp
> http://music.columbia.edu/mailman/listinfo/music-dsp

--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp 
http://music.columbia.edu/mailman/listinfo/music-dsp

[Sampo Syreeni]

On 2008-06-10, Eric Brombaugh wrote:

>> (Naturally what I meant there wasn't "memory starved", but "memory
>> bandwidth and/or latency starved". Sorry.)
>
> Probably depends on what type of processor you're using (desktop vs
> embedded), how large the LUT is (does it fit in cache on a high-end
> PC), what kind of FP support you've got and how many iterations of the
> polynomial it takes to get the required accuracy on your function.

Quite so, and I'm glad you pointed that out. In the typical desktop
processor, the bandwidth problem is heavily aggravated, and so you also
rely heavily on the cache design. A LUT might work, or it might not,
depending on the eviction policy, cache size, alignment, multitasking
conditions and whatnot. On an embedded processor, the gap is still
there, but because of dedicated processing features like well-pipelined
MAC and compilers that can deal with it, and of course a less-steep
incongruity between core and memory cycle lengths, it's less, on these
sorts of applications. But it's still there.

After that the tradeoff revolves around how fast you can code sin(x)
using the existing primitives, and whether your pipeline can hang upto
your code without significant stalls. (Special casing easily leads to
that, big time, and on the other hand, not special casing your code will
easily lead to many iterations beyond the piecewise polynomial
scenario.)

To me it also sounds the embedded limit is what we're talking about,
here. I mean, otherwise you'd use the fast, dedicated, hardware
accelerated and/or microcoded, solutions that your average desktop
processor already offers. You wouldn't code your own.

> Definitely not just a one-size-fits-all type of answer...

Again, quite true. I should have said as much myself.
--
Sampo Syreeni, aka decoy - mailto:decoy@..., tel:[phone]
student/math+cs/helsinki university, http://www.iki.fi/~decoy/front
openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp 
http://music.columbia.edu/mailman/listinfo/music-dsp

[Sampo Syreeni]

On 2008-06-10, Didier Dambrin wrote:

> I haven't found a (16k values) lookup table vastly inferior. With 16k
> values you can ommit interpolation & get away with it, and then it's
> cheap instruction-wise, and the cache does its job.

It does, but for audio apps, you usually need at least linear
interpolation (fast) there, and then you also have to consider what
happens when that particular loop interacts not just with the LUT, but
with the source and target buffers, any interfacing code, and so on.

> I have a highly optimized SSE1 version that computes 8 sinewaves at
> once (talking about additive synth use) (it could compute a single
> sinewave but then you'd have to init your algo with 8x3 sines instead
> of just 3) which is only a little faster than a lookup table.

That's just about the description I started with: think about how it'll
fare with the next CPU you acquire. The performance penalty is only
going to get aggravated.

> Only problem, with single float precision it quickly loses precision
> over time, and then has to be re-initialized (3 costy sines) or you
> have to process in double precision (only 2x packed).

Ah. That's a bit different then. A free-running sinusoid oscillator is a
completely different beast when compared to a pointwise evaluation of a
sin(x) function. Of course the problems are different in both cases.

> ..but that's to generate tones, not compute random sines, so better
> first know what he needs a sine for.

Yes, my point exactly.

> I just went checking if Intel or AMD finally added something to help
> low-quality sine computation (that everyone asks for, like FISTTP that
> they introduced in SSE3, only 10 years too late, god knows why they
> add a new FPU instruction while they advise SSE even for scalar
> stuff), saw nothing in SSE4, and saw that the next gen will have the
> same fight as 3DNow vs SSE. Except that it's now AMD that calls the
> new one SSE5, and Intel will introduce 'AVX'. And we'll have to guess
> which one will win.

Yes. Personally I think they ought to roll out an instruction set
somewhere between cordic assistance and dedicated FIR processing. That'd
be more or less ideal for oscillator building, at least from the
theoretical viewing point.

But then, audio isn't such a big priority for the CPU makers.
--
Sampo Syreeni, aka decoy - mailto:decoy@..., tel:[phone]
student/math+cs/helsinki university, http://www.iki.fi/~decoy/front
openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp 
http://music.columbia.edu/mailman/listinfo/music-dsp

[Eric Brombaugh-2]

Sampo Syreeni wrote:

>
> Yes. Personally I think they ought to roll out an instruction set
> somewhere between cordic assistance and dedicated FIR processing. That'd
> be more or less ideal for oscillator building, at least from the
> theoretical viewing point.
>
> But then, audio isn't such a big priority for the CPU makers.

Sadly true. I wonder if the vertex engines in GPUs would be better for
audio? They're good for coordinate transforms, so the trig functions are
likely to be optimized for speed & parallelism.

Eric
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp 
http://music.columbia.edu/mailman/listinfo/music-dsp

[robert bristow-johnson]

> ----- Original Message -----
> From: "Sampo Syreeni" <decoy@...>
> To: "A discussion list for music-related DSP" <music-dsp@...>
> Subject: RE: [music-dsp] fast sin(x) function
> Date: Tue, 10 Jun 2008 23:06:17 +0300 (EEST)
>
>
> On 2008-06-10, Bob Grove wrote:
>
> > Generate a lookup table.
>
> I'd argue against that in today's memory starved environments; today looking
> something up is often vastly inferior to just calculating it out on the fly.
> I'd instead crack a book on polynomial approximations, and go piecewise
> polynomial with an entirely code based approach.

rather than just take a truncated Taylor or Maclauren series, i might suggest to optimize the coefficients a little using the Remes Exchange Algorithm (not to be confused with MATLAB's Park-McClellan alg with the name of "remez").  using such, i optimized a finite order power series for a variety of functions and appended the results below.  this has been posted to comp.dsp a while ago.

if the OP wants a sin() function for the purpose of generating a nice sine wave for sound, then i would also recommend LUT that is large enough that linear interpolation would be good enough.  if instead the sin() function is used in control/coefficient generation, then i would suggest using the finite order series below.  with the exception of arctan(), there is no division in any of these.  should be fast for a DSP.


> Or, then, use one of the better math libraries, which...do that for you. ;)




       log2(1+x) ~=              1.4425449290 * x
                        +       -0.7181451002 * x^2
                        +        0.4575485901 * x^3
                        +       -0.2779042655 * x^4
                        +        0.1217970128 * x^5
                        +       -0.0258411662 * x^6

0 <= x <= 1     |error| < 2.217e-6   (exact when x=0 and x=1)
                   (about 1/375th of a cent)

        2^x ~=                   1.0
                        +        0.6930321187 * x
                        +        0.2413797743 * x^2
                        +        0.0520323499 * x^3
                        +        0.0135557571 * x^4

0 <= x <= 1     |error|/(2^x) < 3.340e-6  (exact when x=0 and x=1)
                   (about 1/173rd of a cent)

        sqrt(x) ~=               0.2286139087
                        +        1.3027308205 * x
                        +       -0.9125353819 * x^2
                        +        0.5029902702 * x^3
                        +       -0.1217996175 * x^4

1/2 <= x <= 1   |error|/sqrt(x) < 1.076e-5
(exact when x=1 and nearly exact when x=1/2)


  sin((pi/2)*x) ~=               1.5707963268 * x
                        +       -0.6459640619 * x^3
                        +        0.0796915849 * x^5
                        +       -0.0046768800 * x^7
                        +        0.0001530302 * x^9

-1 <= x <= 1  (i can't find the max error results, but it's small)


      arctan(x) ~=  x/f(x^2)

   where   f(u)  =               1.0
                        +        0.3328895051 * u
                        +       -0.0846792282 * u^2
                        +        0.0325223264 * u^3
                        +       -0.0074930586 * u^4

-1 <= x <= 1   (can't find the error results here either, but it's small.)


--

r b-j                  rbj@...

"Imagination is more important than knowledge."

--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

[Didier Dambrin]

>> I just went checking if Intel or AMD finally added something to help
>> low-quality sine computation (that everyone asks for, like FISTTP that
>> they introduced in SSE3, only 10 years too late, god knows why they
>> add a new FPU instruction while they advise SSE even for scalar
>> stuff), saw nothing in SSE4, and saw that the next gen will have the
>> same fight as 3DNow vs SSE. Except that it's now AMD that calls the
>> new one SSE5, and Intel will introduce 'AVX'. And we'll have to guess
>> which one will win.
>
> Yes. Personally I think they ought to roll out an instruction set
> somewhere between cordic assistance and dedicated FIR processing. That'd
> be more or less ideal for oscillator building, at least from the
> theoretical viewing point.
>
> But then, audio isn't such a big priority for the CPU makers.
> --

Well, Intel & AMD provide DSP-related libraries, with a big part for audio
(there's FIR stuff in them).

I think everyone should use them but I see 2 problems with them:

-they won't work together. Intel probably won't make anything optimized for
AMD's, and AMD for Intel. What I'd really like is Intel to partner with
nVidia, so that we can see a CUDA-enhanced version of their libraries (at
the same time, I can't imagine it'd work well without heavily paralellized
versions of their functions, but it would be nice for FFT).
It'd be really nice to use a single library, and see it use the fastest
resource available. It'd even be future-proof.
It should really be some kind of 'OpenDSP', a standard library that would
use any kind of DSP chip if present, and have a CPU version of everything
for full compatibility.

-it would always be block-processing (I mean, no point in calling a function
in a DLL if it takes more time to call the function than to process it), and
with users wanting smaller & smaller latencies (that they don't even need),
it starts to be less interesting to build code in layers of
block-processing.


There's a sine generator in Intel's IPP btw. Unfortunately not really as
fast as it could be.

--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp 
http://music.columbia.edu/mailman/listinfo/music-dsp

[Didier Dambrin]

The biggest problem with those approximations is that you have to wrap/limit
your phase yourself, and this can cost CPU depending on how it's done (can
you really wrap a float phase at low CPU cost?).  While it's really cheap to
wrap an integer power of 2 index.




>>rather than just take a truncated Taylor or Maclauren series, i might
>>suggest to optimize the coefficients a little using the Remes Exchange
>>Algorithm (not to be confused with MATLAB's Park-McClellan alg with the
>>name of "remez").  using such, i optimized a finite order power series for
>>a variety of functions and appended the results below.  this has been
>>posted to comp.dsp a while ago.


--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp 
http://music.columbia.edu/mailman/listinfo/music-dsp

[robert bristow-johnson]

> ----- Original Message -----
> From: "Didier Dambrin" <didid@...>
> To: "A discussion list for music-related DSP" <music-dsp@...>
> Subject: Re: [music-dsp] fast sin(x) function
> Date: Tue, 10 Jun 2008 23:42:19 +0200
>
>
> The biggest problem with those approximations is that you have to wrap/limit
> your phase yourself,

as you would for a lookup table also.

> and this can cost CPU depending on how it's done (can
> you really wrap a float phase at low CPU cost?).  While it's really cheap to
> wrap an integer power of 2 index.

i wouldn't necessarily do it in floating-point.  but either way, you can wrap the phase by masking off high-order bits (so that 2*pi is scaled to be some power of 2), convert to float if necessary, and run your fixed or float result though the finite power series.  but, again, for generating a signal, i wouldn't do it this way anyway: i would just use a lookup table.

but sometimes sin/cos is used for calculation of filter coefs (and then exceeding the domain limits is not going to happen).  sometimes it is to evaluate a filter frequency response (and it need not exceed the domain limits).  in these cases, you want really good accuracy for down in the bottom 3 or 4 octaves and LUT won't be good enough.

but if you want to use it to generate a sin wave, i wouldn't bother with this series stuff.  i would use an LUT that is large enough so that linear interpolation between table entries would be good enough.  unless memory is not cheap, i wouldn't bother with higher order interpolation.


--

r b-j                  rbj@...

"Imagination is more important than knowledge."

--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp
http://music.columbia.edu/mailman/listinfo/music-dsp

[Bob Grove]

You can also do bitwise masking in float, no reason to convert int-float and
back, which is computationally expensive, exp in x86 last time I checked.

-----Original Message-----
From: robert bristow-johnson [mailto:rbj@...]
Sent: Tuesday, June 10, 2008 3:04 PM
To: A discussion list for music-related DSP
Subject: Re: [music-dsp] fast sin(x) function


> ----- Original Message -----
> From: "Didier Dambrin" <didid@...>
> To: "A discussion list for music-related DSP"
<music-dsp@...>
> Subject: Re: [music-dsp] fast sin(x) function
> Date: Tue, 10 Jun 2008 23:42:19 +0200
>
>
> The biggest problem with those approximations is that you have to
wrap/limit
> your phase yourself,

as you would for a lookup table also.

> and this can cost CPU depending on how it's done (can
> you really wrap a float phase at low CPU cost?).  While it's really cheap
to
> wrap an integer power of 2 index.

i wouldn't necessarily do it in floating-point.  but either way, you can
wrap the phase by masking off high-order bits (so that 2*pi is scaled to be
some power of 2), convert to float if necessary, and run your fixed or float
result though the finite power series.  but, again, for generating a signal,
i wouldn't do it this way anyway: i would just use a lookup table.

but sometimes sin/cos is used for calculation of filter coefs (and then
exceeding the domain limits is not going to happen).  sometimes it is to
evaluate a filter frequency response (and it need not exceed the domain
limits).  in these cases, you want really good accuracy for down in the
bottom 3 or 4 octaves and LUT won't be good enough.

but if you want to use it to generate a sin wave, i wouldn't bother with
this series stuff.  i would use an LUT that is large enough so that linear
interpolation between table entries would be good enough.  unless memory is
not cheap, i wouldn't bother with higher order interpolation.


--

r b-j                  rbj@...

"Imagination is more important than knowledge."

--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp
links
http://music.columbia.edu/cmc/music-dsp 
http://music.columbia.edu/mailman/listinfo/music-dsp

--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp 
http://music.columbia.edu/mailman/listinfo/music-dsp

[Didier Dambrin]

really? how does it work? (& don't you need to pre-check if it's
denormalized or negative?)



----- Original Message -----
From: "Bob Grove" <music-dsp@...>
To: "'A discussion list for music-related DSP'"
<music-dsp@...>
Sent: Wednesday, June 11, 2008 12:27 AM
Subject: RE: [music-dsp] fast sin(x) function

> You can also do bitwise masking in float, no reason to convert int-float
> and
> back, which is computationally expensive, exp in x86 last time I checked.
>
> -----Original Message-----
> From: robert bristow-johnson [mailto:rbj@...]
> Sent: Tuesday, June 10, 2008 3:04 PM
> To: A discussion list for music-related DSP
> Subject: Re: [music-dsp] fast sin(x) function
>
>
>> ----- Original Message -----
>> From: "Didier Dambrin" <didid@...>
>> To: "A discussion list for music-related DSP"
> <music-dsp@...>
>> Subject: Re: [music-dsp] fast sin(x) function
>> Date: Tue, 10 Jun 2008 23:42:19 +0200
>>
>>
>> The biggest problem with those approximations is that you have to
> wrap/limit
>> your phase yourself,
>
> as you would for a lookup table also.
>
>> and this can cost CPU depending on how it's done (can
>> you really wrap a float phase at low CPU cost?).  While it's really cheap
> to
>> wrap an integer power of 2 index.
>
> i wouldn't necessarily do it in floating-point.  but either way, you can
> wrap the phase by masking off high-order bits (so that 2*pi is scaled to
> be
> some power of 2), convert to float if necessary, and run your fixed or
> float
> result though the finite power series.  but, again, for generating a
> signal,
> i wouldn't do it this way anyway: i would just use a lookup table.
>
> but sometimes sin/cos is used for calculation of filter coefs (and then
> exceeding the domain limits is not going to happen).  sometimes it is to
> evaluate a filter frequency response (and it need not exceed the domain
> limits).  in these cases, you want really good accuracy for down in the
> bottom 3 or 4 octaves and LUT won't be good enough.
>
> but if you want to use it to generate a sin wave, i wouldn't bother with
> this series stuff.  i would use an LUT that is large enough so that linear
> interpolation between table entries would be good enough.  unless memory
> is
> not cheap, i wouldn't bother with higher order interpolation.
>
>
> --
>
> r b-j                  rbj@...
>
> "Imagination is more important than knowledge."
>
> --
> dupswapdrop -- the music-dsp mailing list and website:
> subscription info, FAQ, source code archive, list archive, book reviews,
> dsp
> links
> http://music.columbia.edu/cmc/music-dsp
> http://music.columbia.edu/mailman/listinfo/music-dsp
>
> --
> dupswapdrop -- the music-dsp mailing list and website:
> subscription info, FAQ, source code archive, list archive, book reviews,
> dsp links
> http://music.columbia.edu/cmc/music-dsp
> http://music.columbia.edu/mailman/listinfo/music-dsp

--------------------------------------------------------------------------------



No virus found in this incoming message.
Checked by AVG.
Version: 8.0.100 / Virus Database: 270.2.0/1494 - Release Date: 10/06/2008
07:22

--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://music.columbia.edu/cmc/music-dsp 
http://music.columbia.edu/mailman/listinfo/music-dsp