www.piclist.com/techref/method/math.htm?key=sin

BY : Peter L. Peres email (remove spam text)

On Thu, 5 Nov 1998, Ben Stragnell wrote:

> Trouble is, even though you're given both the sine and cosine of an angle, I

> don't think there's an easy (ie. trivial and PICable) method of knowing what

> that angle is, much less of stepping though the algorithm with fixed angular

> increments.

As long as we talk generating sines with a digital contraption we talk

about approximations all the time. It would help a lot to define just what

exactly a good enough approximation for DTMF is, in terms of bits

resolution and sampling speed. I'll do this here. Very roughly speaking

0.5% distortion is an error of <= 1/200 and an 8 bit digital signal

(1/256) is good enough. BUT the DTMF tones are built out of two tones

each, which must be added. Since the phone digitizers use 7 or 8 bits

(assume 8), and the power needs to be divided by 2 (roughly, between the

two tones) it follows that only 7 bits are needed to generate each DTMF

tone. Further, the tones need not be sent at full line level, and thus we

dare to steal another two bits, which leads to 6 bits per sine for each

tone (signed). Because of symmetry and sign that's 5 bits of table data

per sine. Referencing to a unity circle it follows that we really need to

store 2^5 table entries == 32 of them. With RLL compression it could be

somewhat less (I think we can afford RLL because only 5 bits of each table

entry are used). A 6 bit table stores 64 entries.

The 'better' Bresenham (?) way of getting the sine would be better iff it

would beat these numbers. Since the Bresenham algorythm yields

reasonably good approximations of integer-scaled sinuses for radiuses

larger than 1024 (10 bits) it should work the better, the more bits are to

be generated imho. But this remains to be proved. I think that the error

grows with larger radiuses.

> I'm not sure about the ellipse algorithm, but I think if you try to

> approximate the sine function using the linear steps along an axis that

> Bresenham gives (as opposed to a fixed angular increment), you'll wind

> up approximating the sine function with straight lines from sin(-45 to

> 45), and quarter circles from (sin 45 to 135) (the tops and bottoms of

> the curves). Of course this may be a good enough approximation for DTMF,

> and other applications, but it's definately not a pure tone.

There is NO digital way to obtain a 'pure tone' using a finite number of

bits per sample and a finite sampling frequency. This results directly

from the definition. It's all about approximations.

The ellipse algorythm might approximate a suitable piece of sinus using a

more or less constant step on the (ellipse-distorted) cosine axis used as

phase-incremental input. The lure is again the beauty of the Bresenham

algorythm of course ;) It would be a pity not to try hard.

> You could always look into simple harmonic motion - keeping track of a

> point's position and velocity, and then using position to derive the

> acceleration each tick would yield a nice pure sine wave if you get the

> scalings right. sin''(t) = -sin(t). Trouble is, to make the frequency

> adjustable without breaking the amplitude would probably require a whole

> nasty bunch of multiplies. Ouch :)

imho it would help a lot to start with the idea that leads to the

Bresenham circle algorythm and to develop it in a slightly different

direction. This idea is very much along the lines of using an

approximation function for a derivate of a trigonometric function over a

small (incremental) interval, which, due to the large tolerable error

(select one pixel out of 3 next possibles), leads to a fiendishly simple

algorythm. I have a hunch about being able to derive a 2nd incremental

result at each step, that accumulates to true angle at each step and turn

the equation so the sine results from the angle and the previous sine. It

would be nice to find out whether this leads to the re-discovery of the

Goertzel formula (with which I am not familiar - i.e. I've never seen it -

yet).

Is there any data available on Mr. Bresenham, the person ? Web searches

yielded nothing interesting. Who owns these algorythms anyway ?

Peter

In reply to: <3641EC32.8E3452C5@codepuppies.com>

See also: www.piclist.com/techref/method/math.htm?key=sin