piclist 1998\11\20\071451a >
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

> 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 :)

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

<Pine.LNX.3.95.981105202005.736V-100000@plp4.plp.home.org>