Monday August 01, 2005

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.