This post originated from an RSS feed registered with Java Buzz
by James Gosling.
Original Post: Transcendental Two
Feed Title: James Gosling: on the Java road...
Feed URL: /jag/feed/entries/rss?cat=%2FJava
Feed Description: I've been inescapably tagged as "the Java guy", despite the fact that I havn't worked in the Java product organization for a couple of years (I do still kibbitz). These days I work at Sun's research lab about two thirds of the time, and do customer visits and talks the other third. For more detail...
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.
Previous Topic
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.