What units should be used for angles in trig functions?

Radians are the most natural unit for most trig calculations, and that’s
what the library routines in C and many other languages use. However,
degrees are a more natural unit for humans to input, and to get results
in.

Thus, other languages, but not (yet?) C, provide conversion functions. For
example, Python has math.radians() for converting degrees to radians, and
math.degrees() for going the other way. Java has something similar.

But I think providing conversion functions is an unnecessarily clumsy way
of doing it, because for every alternative angle unit, you need two
functions.

Better to provide just a single conversion factor. E.g.

DEG = π / 180

Now it is easy enough to input angles to a calculation in degrees, e.g.

sin(45 * DEG)

And getting outputs in degrees is equally easy, e.g.

atan2(Y, X) / DEG

Sometimes it is convenient to work in terms of whole circles (360°):

CIRCLE = 2 * π

Thus the examples become:

sin(CIRCLE / 8)

and

atan2(Y, X) / CIRCLE

Anybody remember “gradians”?

GRAD = π / 200

And of course, for completeness, we can have a factor for explicitly
specifying that you are working radians:

RAD = 1.0

On 2/21/24 17:35, Lawrence D'Oliveiro wrote:
> What units should be used for angles in trig functions?

The standard specifies that sin, cos, and tan() take arguments measured
in radians. Degrees are mentioned only in the context of the complex
versions of the trig functions, and only for the purpose of mentioning
that they do NOT take arguments in degrees.

Lawrence D'Oliveiro wrote:
> What units should be used for angles in trig functions?
>
> Radians are the most natural unit for most trig calculations, and that’s
> what the library routines in C and many other languages use. However,
> degrees are a more natural unit for humans to input, and to get results
> in.
>
> Thus, other languages, but not (yet?) C, provide conversion functions. For
> example, Python has math.radians() for converting degrees to radians, and
> math.degrees() for going the other way. Java has something similar.
>
> But I think providing conversion functions is an unnecessarily clumsy way
> of doing it, because for every alternative angle unit, you need two
> functions.
>
> Better to provide just a single conversion factor. E.g.
>
> DEG = π / 180
>
> Now it is easy enough to input angles to a calculation in degrees, e.g.
>
> sin(45 * DEG)
>
> And getting outputs in degrees is equally easy, e.g.
>
> atan2(Y, X) / DEG
>
> Sometimes it is convenient to work in terms of whole circles (360°):
>
> CIRCLE = 2 * π
>
> Thus the examples become:
>
> sin(CIRCLE / 8)
>
> and
>
> atan2(Y, X) / CIRCLE
>
> Anybody remember “gradians”?
>
> GRAD = π / 200
>
> And of course, for completeness, we can have a factor for explicitly
> specifying that you are working radians:
>
> RAD = 1.0
>

long time i think it should be measured in what you call here circle,
it is rather in "1" not in "360" nor "2PI" ..in my coding hovevver i use
degree360 = 2*PI/360.0

this what you call circle imo wpuld be better and i doubt in a reason to
use PI in mathematics yet defien it as 3.14 instead of 6.28 here if this
value is really needed

also on assembly level i would like if fsin arguments woyld be not on
radians but in "1.0" floats

if someone knows the reason why "6.28" radians are expected to better
than "1.0" 'circkles' in both mathemathics and assembly tell me
- as i dont know the reason

On Wed, 21 Feb 2024 17:55:01 -0500
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:

> On 2/21/24 17:35, Lawrence D'Oliveiro wrote:
> > What units should be used for angles in trig functions?
>
> The standard specifies that sin, cos, and tan() take arguments
> measured in radians. Degrees are mentioned only in the context of the
> complex versions of the trig functions, and only for the purpose of
> mentioning that they do NOT take arguments in degrees.
>

The latest version of IEEE-754 Standard (or, may be, the one that is
still in preparation? I don't remember), specifiies additional set of
trig routines for which argument=1.0 corresponds to 180 degrees (pi
Radians). The names are SinPi, CosPi etc...
I find this choice somewhat less logical than 1.0 corresponding to 360
degrees, but that's a matter of personal taste.

On Thu, 22 Feb 2024 00:15:47 +0100, fir wrote:

> if someone knows the reason why "6.28" radians are expected to better
> than "1.0" 'circkles' in both mathemathics and assembly tell me - as i
> dont know the reason

It’s because trig calculations are most naturally done in radians. E.g.
the approximation

sin x ≅ tan x ≅ x as x → 0

works only if x is in radians. Also the Euler identity

ix
e = cos x + i sin x

only holds if x is in radians. And so on and so on.

On Thu, 22 Feb 2024 01:59:20 +0200, Michael S wrote:

> The latest version of IEEE-754 Standard (or, may be, the one that is
> still in preparation? I don't remember), specifiies additional set of
> trig routines for which argument=1.0 corresponds to 180 degrees (pi
> Radians). The names are SinPi, CosPi etc...
> I find this choice somewhat less logical than 1.0 corresponding to 360
> degrees, but that's a matter of personal taste.

Also quite unnecessary to invent a whole set of parallel functions just
for a different angle unit.

On 21/02/2024 22:35, Lawrence D'Oliveiro wrote:
> What units should be used for angles in trig functions?
>
The derivative of the sine is the cosine and vice versa, but only if you
measure in radians. And for some mathematical calculations this is an
important property, and so you really must use radians. And so if we
wish to support that type of mathematics with C, we must provide
functions which take radians.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 21/02/2024 23:35, Lawrence D'Oliveiro wrote:
> What units should be used for angles in trig functions?
>
> Radians are the most natural unit for most trig calculations, and that’s
> what the library routines in C and many other languages use. However,
> degrees are a more natural unit for humans to input, and to get results
> in.
>
> Thus, other languages, but not (yet?) C, provide conversion functions. For
> example, Python has math.radians() for converting degrees to radians, and
> math.degrees() for going the other way. Java has something similar.
>
> But I think providing conversion functions is an unnecessarily clumsy way
> of doing it, because for every alternative angle unit, you need two
> functions.
>
> Better to provide just a single conversion factor. E.g.
>
> DEG = π / 180
>
> Now it is easy enough to input angles to a calculation in degrees, e.g.
>
> sin(45 * DEG)
>
> And getting outputs in degrees is equally easy, e.g.
>
> atan2(Y, X) / DEG >
> Sometimes it is convenient to work in terms of whole circles (360°):
>
> CIRCLE = 2 * π
>
> Thus the examples become:
>
> sin(CIRCLE / 8)
>
> and
>
> atan2(Y, X) / CIRCLE
>
> Anybody remember “gradians”?
>
> GRAD = π / 200
>
> And of course, for completeness, we can have a factor for explicitly
> specifying that you are working radians:
>
> RAD = 1.0

This all sounds reasonable to me. I would not bother with GRAD unless
you are writing code for the French military - despite being common on
calculators for a while, it's extremely rare to see it in use.

If you want a third unit, I'd pick the "Furman", scale factor 2π / 2^16.
It's the kind of thing you see in embedded systems where you want to
do your trig with fixed point numbers, integers, table lookups, splines,
etc., rather than floating point and slow, unnecessarily accurate
library functions. But it's not so common to see the name, and the
power of two is not always 16.

Maybe just TURN = 2π would be more useful?

Radians is the only angle unit which is not arbitrary.

--
Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr.
blue-maned_hawk.srht.site
Skylights: Trepanning for houses

On 22/02/2024 02:55, Lawrence D'Oliveiro wrote:
> On Thu, 22 Feb 2024 00:15:47 +0100, fir wrote:
>
>> if someone knows the reason why "6.28" radians are expected to better
>> than "1.0" 'circkles' in both mathemathics and assembly tell me - as i
>> dont know the reason
>
> It’s because trig calculations are most naturally done in radians. E.g.
> the approximation
>
> sin x ≅ tan x ≅ x as x → 0
>
> works only if x is in radians. Also the Euler identity
>
> ix
> e = cos x + i sin x
>
> only holds if x is in radians. And so on and so on.

From a mathematical standpoint, clearly radians are a far more natural
choice of unit than anything else for trig. But it is not as certain
that they are a good choice for programming.

For implementing "sin", you first have to reduce the value modulo 2π. I
would have thought it would easier to do that if the units were turns,
as the modulo reduction would then simply be taking the fractional part
of the number. You may also want to reduce to a 0°-90°, or 0-π/2 range
for the main calculation.

If you are doing with main calculation by Taylor series, radians are the
nicest units. But I believe it is more common to use Chebyshev
polynomials, and for that there is no great advantage in radians. It's
a very long time since I looked at Chebyshevs, but I think your most
efficient method would be to map 0°-90° to the range -1 to 1 - i.e.,
centred around 45°. This brings you to an ideal unit of an eighth of a
turn.

Turns divided by some power of two would also be ideal for faster but
less accurate implementations, such as Cordic or tables with linear or
cubic interpolation.

From the user viewpoint, radians are a natural unit for a lot of
applications - as are degrees. Turns, or turns divided by a power of
two, are also very useful for many applications, but there is no
consensus about what power of two to use.

And the user viewpoint is the important one here - the value can be
scaled before doing the calculations.

So choice number one for programming languages should be radians, except
perhaps for languages aimed at beginners or kids, where degrees might be
more appropriate. And if you have a second set, degrees would be the
choice, then followed by turns. (Half turns - SinPi and CosPi - seems
odd to me.)

On 22/02/2024 08:32, David Brown wrote:
>
> For implementing "sin", you first have to reduce the value modulo 2π.

For an efficient implentation yes. But applying the formula to values
outside the range of 0 - 2PI also produces the correct result if you go
on for long enough.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 22/02/2024 10:38, Malcolm McLean wrote:
> On 22/02/2024 08:32, David Brown wrote:
>>
>> For implementing "sin", you first have to reduce the value modulo 2π.
>
> For an efficient implentation yes. But applying the formula to values
> outside the range of 0 - 2PI also produces the correct result if you go
> on for long enough.
>

Assuming that "the formula" you are referring to is one of the infinite
polynomials for sin, then yes - I think anyone who knows about such
maths will be aware of that. However, it is pretty much entirely
irrelevant in the context of computing values for trig functions.

On 22/02/2024 09:27, Blue-Maned_Hawk wrote:
>
> Radians is the only angle unit which is not arbitrary.
>
>

No, it is not. "Turns" are also not arbitrary, and are also
mathematically fundamental.

And while degrees were created by people, rather than something
fundamental in the mathematics, the number of divisions was picked
carefully for particular properties (lots of divisors). And since
degrees are a well-established and commonly known angle unit, using them
is not arbitrary. Even gradians were defined that way for good reasons.
So these units are not arbitrary - even though they were defined by
humans and not mathematics.

On 22/02/2024 10:09, David Brown wrote:
> On 22/02/2024 09:27, Blue-Maned_Hawk wrote:
>>
>> Radians is the only angle unit which is not arbitrary.
>>
>>
>
> No, it is not.  "Turns" are also not arbitrary, and are also
> mathematically fundamental.
>
> And while degrees were created by people, rather than something
> fundamental in the mathematics, the number of divisions was picked
> carefully for particular properties (lots of divisors).  And since
> degrees are a well-established and commonly known angle unit, using them
> is not arbitrary.  Even gradians were defined that way for good reasons.
>  So these units are not arbitrary - even though they were defined by
> humans and not mathematics.
>
We did have a lengthy and of course totally off topic discussion about
this over in comp.theory. I said that the Babylonians thought that
having 360 degrees was an inherent property of a circle, whilst others
said not.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> On Thu, 22 Feb 2024 00:15:47 +0100, fir wrote:
>
>> if someone knows the reason why "6.28" radians are expected to better
>> than "1.0" 'circkles' in both mathemathics and assembly tell me - as i
>> dont know the reason
>
> It’s because trig calculations are most naturally done in radians. E.g.
> the approximation
>
> sin x ≅ tan x ≅ x as x → 0
>
> works only if x is in radians.

No, that applies to lots of angle measures. Radians are the natural
angle measure because we want sin' x = cos x and cos' x = -sin x. sin
and cos are the unique solution to that pair of differential equations
(with initial conditions sin 0 = 0 and cos 0 = 1).

> Also the Euler identity
>
> ix
> e = cos x + i sin x
>
> only holds if x is in radians. And so on and so on.

Yes, and there's another nod to the calculus here because just as sin an
cos are (with a minus sign) derivatives of each other, e^x is the
derivative of itself.

--
Ben.

On 22/02/2024 15:28, Ben Bacarisse wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> On Thu, 22 Feb 2024 00:15:47 +0100, fir wrote:
>>
>>> if someone knows the reason why "6.28" radians are expected to better
>>> than "1.0" 'circkles' in both mathemathics and assembly tell me - as i
>>> dont know the reason
>>
>> It’s because trig calculations are most naturally done in radians. E.g.
>> the approximation
>>
>> sin x ≅ tan x ≅ x as x → 0
>>
>> works only if x is in radians.
>
> No, that applies to lots of angle measures.

The Taylor expansion of sin x near 0 is x + O(x³), as is that of tan x.
So for any angle measure with a scale factor k (such as k = π/180 for
degrees), the Taylor expansions for sin(kx) and tan(kx) are both k.x +
O(x³).

Thus as x tends to 0, sin(kx) / tan(kx) tends to 1, but sin(kx)/x tends
to k. It only tends to 1 if k is 1, i.e., we are working in radians.

I don't think that this (that sin(x)/x tends to 1 as x tends to 0) is a
particularly good justification for using radians, however - the
calculus argument is much better IMHO.

David Brown wrote:

> On 22/02/2024 09:27, Blue-Maned_Hawk wrote:
>>
>> Radians is the only angle unit which is not arbitrary.
>>
>>
>>
> No, it is not. "Turns" are also not arbitrary, and are also
> mathematically fundamental.

That is a good point that i had not thought about. Thank you.

> And while degrees were created by people, rather than something
> fundamental in the mathematics, the number of divisions was picked
> carefully for particular properties (lots of divisors). And since
> degrees are a well-established and commonly known angle unit, using them
> is not arbitrary. Even gradians were defined that way for good reasons.
> So these units are not arbitrary - even though they were defined by
> humans and not mathematics.

I do not see how this is not still completely arbitrary.

--
Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr.
blue-maned_hawk.srht.site
foldable (once)

On 2024-02-22, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> On 21/02/2024 22:35, Lawrence D'Oliveiro wrote:
>> What units should be used for angles in trig functions?
>>
> The derivative of the sine is the cosine and vice versa, but only if you
> measure in radians.

Related to b^x being its own derivative w.r.t. x, only if b = e.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 22/02/2024 16:29, Blue-Maned_Hawk wrote:
> David Brown wrote:
>
>> On 22/02/2024 09:27, Blue-Maned_Hawk wrote:
>>>
>>> Radians is the only angle unit which is not arbitrary.
>>>
>>>
>>>
>> No, it is not. "Turns" are also not arbitrary, and are also
>> mathematically fundamental.
>
> That is a good point that i had not thought about. Thank you.
>
>> And while degrees were created by people, rather than something
>> fundamental in the mathematics, the number of divisions was picked
>> carefully for particular properties (lots of divisors). And since
>> degrees are a well-established and commonly known angle unit, using them
>> is not arbitrary. Even gradians were defined that way for good reasons.
>> So these units are not arbitrary - even though they were defined by
>> humans and not mathematics.
>
> I do not see how this is not still completely arbitrary.
>

"Arbitrary" means that you picked something without any particular
reason, and could just as well have picked something else. We use base
ten - that is not arbitrary, it is based on the number of fingers we
have. The Babylonians and Sumerians liked 5, 12 and 60 - also not
arbitrary, but picked as numbers with a lot of convenient factors. The
French revolutionists picked 400 for gradians, because 100 parts in a
right angle fit well with their new metric system, which fit well with
our standard number base. And one gradian of arc on a map corresponds
almost exactly to 100 km in distance - also very intentional, and not
arbitrary.

From a purely mathematical viewpoint, these units are arbitrary - but
from a human and historical viewpoint, they are not.

On Thu, 22 Feb 2024 01:55:54 +0000, Lawrence D'Oliveiro wrote:

> On Thu, 22 Feb 2024 01:59:20 +0200, Michael S wrote:
>
>> The latest version of IEEE-754 Standard (or, may be, the one that is
>> still in preparation? I don't remember), specifiies additional set of
>> trig routines for which argument=1.0 corresponds to 180 degrees (pi
>> Radians). The names are SinPi, CosPi etc...
>> I find this choice somewhat less logical than 1.0 corresponding to 360
>> degrees, but that's a matter of personal taste.
>
> Also quite unnecessary to invent a whole set of parallel functions just
> for a different angle unit.

It depends on your numerical requirements. For single precision,
sinpi(1234.5) = 1 exactly. sin(3.1415926*1234.5) = sin(3878.2961) = 1
with an error of ULP = 0.0015 and FE_INEXACT raised.

If you're also trying to implement sinpi(x), sin(x), and sind(x)
over some extended domain such as x in [0,2^23], then argument
reduction for sinpi(x) and sind(x) are much easier than for
sin(x), but still require attention to detail.

--
steve

On Thu, 22 Feb 2024 11:09:50 +0100, David Brown wrote:

> And while degrees were created by people, rather than something
> fundamental in the mathematics, the number of divisions was picked
> carefully for particular properties (lots of divisors).

I know base-360 is supposed to have come from the Babylonians. But
consider: you get exactly the same range of exact divisors (2, 3, 5, and
powers and products thereof) with base-30.

On Thu, 22 Feb 2024 11:09:50 +0100, David Brown wrote:

> On 22/02/2024 09:27, Blue-Maned_Hawk wrote:
>>
>> Radians is the only angle unit which is not arbitrary.
>>
> No, it is not. "Turns" are also not arbitrary, and are also
> mathematically fundamental.

In maths, there are things that are “simple” and “natural”, or not
“arbitrary” or “fundamental”.

For example, the formula for centripetal acceleration can be expressed (a
= acceleration in ms¯², f = revolutions per second, r = radius in metres)
as

a = 4π²f²r

But if you express the rotational frequency in radians per second

ω = 2πf

then the formula becomes significantly simpler:

a = ω²r

On Thu, 22 Feb 2024 16:26:39 +0100, David Brown wrote:

> I don't think that this (that sin(x)/x tends to 1 as x tends to 0) is a
> particularly good justification for using radians, however - the
> calculus argument is much better IMHO.

These are just two among many examples of calculations being particularly
simple(r) in radians.

On Thu, 22 Feb 2024 19:14:24 -0000 (UTC), Steven G. Kargl wrote:

> For single precision,
> sinpi(1234.5) = 1 exactly. sin(3.1415926*1234.5) = sin(3878.2961) = 1
> with an error of ULP = 0.0015 and FE_INEXACT raised.

That seems like a pretty arbitrary example with no earthly real-world use.

> If you're also trying to implement sinpi(x), sin(x), and sind(x)
> over some extended domain such as x in [0,2^23], then argument reduction
> for sinpi(x) and sind(x) are much easier than for sin(x), but still
> require attention to detail.

Doesn’t CORDIC take care of that?

On Thu, 22 Feb 2024 19:48:20 +0000, Lawrence D'Oliveiro wrote:

> On Thu, 22 Feb 2024 19:14:24 -0000 (UTC), Steven G. Kargl wrote:
>
>> For single precision,
>> sinpi(1234.5) = 1 exactly. sin(3.1415926*1234.5) = sin(3878.2961) = 1
>> with an error of ULP = 0.0015 and FE_INEXACT raised.
>
> That seems like a pretty arbitrary example with no earthly real-world use.

Apparently, you missed the part about argument reduction. For
sinpi(x), it is fairly easy to reduce x = n + r with n an integer
and r in [0,1). For the extended interval, x in [0,2^23], there
are roughly 2^23 values with r = 0.5; and thus, sinpi(x) = 1
exactly. There are no such values for sin(x), and argument reduction
for sin(x) is much more involved.

As to real-world use, how about any physical phenomena where one
is interest in resonance frequencies of the system. For a simple
example see https://www.feynmanlectures.caltech.edu/I_49.html
where one might write f(x) = sin(kx) = sin(pi * (2*x/L)) with
L a length of say a clamped string.

There are also uses with computing other functions, e.g., the
true gamma function via the Euler reflection formula.

gamma(x) * gamma(1 - x) = pi / sin(pi * x) = pi / sinpi(x)

>> If you're also trying to implement sinpi(x), sin(x), and sind(x)
>> over some extended domain such as x in [0,2^23], then argument reduction
>> for sinpi(x) and sind(x) are much easier than for sin(x), but still
>> require attention to detail.
>
> Doesn’t CORDIC take care of that?

What does google tell you?

--
steve