# Transcendental Two [updated]

There's a piece of historical baggage in the definition of*sin/cos*that is much older than just "whatever the 8087 chip happened to do": why are the

*sin*and

*cos*functions defined based on parameters that are periodic in a transcendental number? Having the period be 2*

*pi*is based on decades (centuries!) of mathematical standard practice. This whole problem with

*sin*and

*cos*would go away if only the period had a nice clean representation in floating point. For example, either degrees or turns (1 turn == 360 degrees) would be great. In particular, if the parameter to

*sin/cos*were turns then argument reduction would be easy: just throw away the integer bits. Then you could do a table lookup based on extracting mantissa bits.

What is especially ironic is that if
you grep through piles of source code you'll find a huge number of
calls that look roughly like *sin(angle*(2*Math.PI/360))*.
This has a necessarily slightly inaccurate value of *pi*,
which is likely to be exactly the same value as the one in the
8087's *sin/cos* implementation - the two errors come pretty
close to canceling since the argument is divided by the value of
*pi* used in the implementation of *sin/cos*.

*Update:* Yes, I understand that
there are lots of deep, important mathematical reasons that
*sin* & *cos* are defined in terms of 2**pi*.
The point I was trying to make is that if you peel open the covers
of an implementation of *sin/cos*, 2**pi* is a very
difficult period to cope with. At the same time, if you look at
software that uses *sin/cos*, you'll find that a huge fraction
of them use something other than 2**pi* (degrees are real
common), and convert when invoking *sin/cos*.

August 1, 2005 |