Re: Radians Or Degrees?

On Sun, 17 Mar 2024 10:59:46 +0000
bart <bc@freeuk.com> wrote:

On 17/03/2024 09:06, Michael S wrote:

On Sat, 16 Mar 2024 16:19:11 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: 

 

As written, your example does not emphasize that the problem has
nothing to do with implementation of sinX() library routine.
It's best illustrated by followup conversation with bart, IMHO 100%
O.T. 

 
 
Actually, the thread topic is the more basic one of whether angles to
these functions should be specified as degrees or radians.
 

Degrees can be seen as a form of turn==circle-based units, but for most
purposes except interaction with user they are not quite as convenient
as plain turns or than turns multiplied by some negative power of two.

In answer to that, I decided long ago (in my language designs) to
keep them as radians, but allow degrees for constants if written in
one of these styles like this:
 
    sin(30°) + cos(60 deg)
 
Because, once they're inside a variable:
 
    sin(alpha) + cos(beta)
 
then the unit used is irrelevant.
 
As for the value returned from sin() etc, I haven't worried about
that since last century.
 
Except briefly more recently when I had an arbitrary precision
floating point library and considered whether to add such functions,
but concluded I didn't have the right skills, experience (of using
ultra-high precision trig functions) or motivation.
 
The first problem was: exactly how accurately should it be generated.
With ieee754 it's easy, you only have 53 binary digits to fill.
 
In my (decimal) library, the default precision for a calculation like
1.0/3.0 is typically set up to 500 decimal digits, or about 1600
bits, otherwise it will keep going forever (the theoretical limit is
19 billion decimal digits, or 64 billion bits).
 
The second problem was, how do you even calculate sin(x) so that it
converges to that accuracy within a reasonable amount of time? The
Taylor series that I used to use wouldn't cut it.

There exist better series than Taylor, but in case of high-precision
sin()/cos() they are not MUCH better. Typically, just one term shorter
than Taylor for a given precision, at most two terms. And quite often
this additional terms can be done with lower precision (e.g. IEEE
binary) so in terms of execution time the difference is close to noise.

The key to faster high-prec sin()/cos() is breaking quarter-circle
of input into more ranges. For 1600 bits you would almost certainly want
to do it hierarchically. I never dealt with such high precision myself
so has no intuition about number of levels. For (much) lower precision I
used 6 or 7 bits per level of hierarchy, but with 1600 bits I'd think
that it makes sense to use fewer bit per level in order to keep total
size of the tables within limits of 2nd-level cache of typical CPU.
May be, 7 bits on few higher levels and then 1 or 2 bits for the rest?
Now, too many levels of hierarchy cause the problems of their own,
specifically, intermediate calculations would likely need higher
precision. The trade offs are not simple :(

 
(Dealing with inputs that are extreme multiples of +/- 2pi radians
would be an additional difficulty.)
 
I decided not to bother with transcendental functions.
 

You can solve most of your problems by integrating MPFR into your
runtime.