# Should there be a native angle type?

**URL:** <https://discourse.julialang.org/t/should-there-be-a-native-angle-type/4611>\
**Category:** Internals & Design\
**Tags:** proposal, unitful\
**Created:** [July 3, 2017, 8:32am UTC](https://discourse.julialang.org/t/should-there-be-a-native-angle-type/4611 "2017-07-03T08:32:13Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![yakir12](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yakir12/32/297_2.png) [@yakir12](https://discourse.julialang.org/u/yakir12)\
**Post date:** [July 3, 2017, 8:32am UTC](https://discourse.julialang.org/t/should-there-be-a-native-angle-type/4611/1 "2017-07-03T08:32:13Z")

</div>

Between dealing with degrees versus radians, their specialized functions (e.g. `cosd` versus `cos`), optimizing their representation (wrapping around, defining counter- and clockwise, etc), and using `Unitful.jl`, I started thinking, should `Julia` have a native `Angle` type…? Will the overhead not be worth the gain?

---

<div class="post-metadata">

**Author:** ![andyferris](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/andyferris/32/235_2.png) [@andyferris](https://discourse.julialang.org/u/andyferris)\
**Post date:** [July 3, 2017, 10:08am UTC](https://discourse.julialang.org/t/should-there-be-a-native-angle-type/4611/2 "2017-07-03T10:08:02Z")

</div>

It’s not an overhead issue - the question is “what should be in Base” vs “what should be in packages”.

On one hand _Unitful_ seems like the perfect place for these units. On the other hand, Base defines (and therefore “owns”) trigonometry functions like `sin` and `sind` and therefore obviously has a pretty good idea of what radians and degrees are, and interface improvements are always welcome. It might be possible something simple and subtle would be accepted, but having all possible windings and sense of directions… this seems less likely to me.

---

<div class="post-metadata">

**Author:** ![yakir12](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yakir12/32/297_2.png) [@yakir12](https://discourse.julialang.org/u/yakir12)\
**Post date:** [July 3, 2017, 10:24am UTC](https://discourse.julialang.org/t/should-there-be-a-native-angle-type/4611/3 "2017-07-03T10:24:02Z")

</div>

I have a feeling that forcing everyone to predefine quantities that go into a `sin` function as `Degree` or `Radian` (both subtypes of `Angle`) wouldn’t be very popular. But it does make _some_ sense… On the other hand, what should `acos` return, `Degree` or `Radian`…? hmm…

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [July 3, 2017, 10:44am UTC](https://discourse.julialang.org/t/should-there-be-a-native-angle-type/4611/4 "2017-07-03T10:44:34Z")

</div>

Just out of curiosity, in what context would you want `acos(x)` to return degrees?

Degrees are convenient because people find small, conveniently factorizable integers easy to work with — eg 60° is more intuitive to most non-mathematicians than π/3. But when you use an arbitrary argument to `acos`, you will get some float anyway, and getting that in degrees instead of radians may not be that large of an advantage.

---

<div class="post-metadata">

**Author:** ![lobingera](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lobingera/32/211_2.png) [@lobingera](https://discourse.julialang.org/u/lobingera)\
**Post date:** [July 3, 2017, 10:54am UTC](https://discourse.julialang.org/t/should-there-be-a-native-angle-type/4611/5 "2017-07-03T10:54:43Z")

</div>

Over at the libcairo mailing list there is currently a medium sized discussion to add API to deal with angles in deg because angles in deg (esp. 30/45/90 multiples) have more ‘meaning’ and lead to exact transformation matrices. It’s really a matter of perspective and personal preferences.  
(read as: you get numerical problems, as irrational numbers like pi/3 cannot be represented in float)

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [July 3, 2017, 11:05am UTC](https://discourse.julialang.org/t/should-there-be-a-native-angle-type/4611/6 "2017-07-03T11:05:49Z")

</div>

The issue you mention is well understood, and Julia has dealt with it already (eg `Base.cospi`). The question was about `acos`. I am not arguing that a version that gives degrees is not useful, merely asking for examples in actual code; I think they would focus the discussion.

---

<div class="post-metadata">

**Author:** ![yakir12](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yakir12/32/297_2.png) [@yakir12](https://discourse.julialang.org/u/yakir12)\
**Post date:** [July 3, 2017, 11:15am UTC](https://discourse.julialang.org/t/should-there-be-a-native-angle-type/4611/7 "2017-07-03T11:15:45Z")

</div>

The usefulness of `acos` returning degrees is not different from any other situation where angles are expressed in terms of degrees instead of radians. They are easier for biologists (in my case).

Normally you’d never touch degrees and therefore never worry about which is it, but if the interface with the user includes the possibility of degrees, then this becomes a concern (which one can solve locally). It would be nice to not worry about it. Theoretically, the type of angle `acos` would return could be assigned randomly and things would still just work…

---

<div class="post-metadata">

**Author:** ![yakir12](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yakir12/32/297_2.png) [@yakir12](https://discourse.julialang.org/u/yakir12)\
**Post date:** [July 3, 2017, 11:21am UTC](https://discourse.julialang.org/t/should-there-be-a-native-angle-type/4611/8 "2017-07-03T11:21:00Z")

</div>

A wild thought, with a Angle type, we could have specialized angles that are multiples of pi (or 180, depending on the type), and therefore would elicit the cospi automatically. cool…

---

<div class="post-metadata">

**Author:** ![lobingera](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lobingera/32/211_2.png) [@lobingera](https://discourse.julialang.org/u/lobingera)\
**Post date:** [July 3, 2017, 11:43am UTC](https://discourse.julialang.org/t/should-there-be-a-native-angle-type/4611/9 "2017-07-03T11:43:00Z")

</div>

Base.cospi is not really a matching example, as:

> Compute cos(πx) more accurately than cos(pi\*x), especially for large x.

and 1/3 still isn’t represented in float.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [July 3, 2017, 11:47am UTC](https://discourse.julialang.org/t/should-there-be-a-native-angle-type/4611/10 "2017-07-03T11:47:30Z")

</div>

Indeed. Try

```julia
cospi(1//3)

```

---

<div class="post-metadata">

**Author:** ![yakir12](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yakir12/32/297_2.png) [@yakir12](https://discourse.julialang.org/u/yakir12)\
**Post date:** [July 3, 2017, 12:54pm UTC](https://discourse.julialang.org/t/should-there-be-a-native-angle-type/4611/11 "2017-07-03T12:54:01Z")

</div>

It occurs to me that there are a bunch of cases where julia’s type system could be used to introduce cool functionalities when it comes to these entities that traditionally are not considered “worth” typing. Angle is the subject of this thread, but Sign is another. Examples of such entities that I think are not typed (or less so) in other languages are Time, Diagonal, Irrational, etc. It’s not entirely clear to me why these get their own (native) type and, say, Angle doesn’t.

---

<div class="post-metadata">

**Author:** ![bramtayl](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bramtayl/32/3614_2.png) [@bramtayl](https://discourse.julialang.org/u/bramtayl)\
**Post date:** [July 3, 2017, 2:39pm UTC](https://discourse.julialang.org/t/should-there-be-a-native-angle-type/4611/12 "2017-07-03T14:39:43Z")

</div>

It seems like there’s a huge potential to refactor trig functions. Here’s a list of sin family functions in base exports; there’s a similar family for every trig function.

```
asin,
asind,
asinh,
sin,
sinc,
sind,
sinh,
sinpi

```

It seems like this would better be handled with dispatch and/or keyword arguments? Just keyword arguments like `hyperbolic = true`, `degrees = true`, and `inverse = true` would go a long way.

---

<div class="post-metadata">

**Author:** ![bramtayl](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bramtayl/32/3614_2.png) [@bramtayl](https://discourse.julialang.org/u/bramtayl)\
**Post date:** [July 3, 2017, 2:49pm UTC](https://discourse.julialang.org/t/should-there-be-a-native-angle-type/4611/13 "2017-07-03T14:49:33Z")

</div>

A combination of angle types (`AngleInDegrees`, `AngleInRadians`, `AngleInPis`) and keywords (`hyperbolic`, `cardinal`, `inverse`, `cofunction` and `reciprocal`) could in fact get you down to exactly two trig functions (`sin` and `tan`). Of course this is a bit extreme, but so is the amount of trig exports in base.

---

<div class="post-metadata">

**Author:** ![Per](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/per/32/10387_2.png) [@Per](https://discourse.julialang.org/u/Per)\
**Post date:** [July 3, 2017, 2:57pm UTC](https://discourse.julialang.org/t/should-there-be-a-native-angle-type/4611/14 "2017-07-03T14:57:19Z")

</div>

Branching on arguments is too slow. Trig functions are expected to run as fast as possible.

Also, the names are standard across almost every language that has these functions, so changing them would confuse a lot of users.

---

<div class="post-metadata">

**Author:** ![yakir12](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yakir12/32/297_2.png) [@yakir12](https://discourse.julialang.org/u/yakir12)\
**Post date:** [July 3, 2017, 3:00pm UTC](https://discourse.julialang.org/t/should-there-be-a-native-angle-type/4611/15 "2017-07-03T15:00:55Z")

</div>

There shouldn’t be a problem with adding a few methods for an Angle type. So people will always be able to run `sin` on a float, but they could also run `sin` on a `Degree <: Angle`, and `sin` will behave like `sind`.

---

<div class="post-metadata">

**Author:** ![DNF](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dnf/32/10191_2.png) [@DNF](https://discourse.julialang.org/u/DNF)\
**Post date:** [July 3, 2017, 3:02pm UTC](https://discourse.julialang.org/t/should-there-be-a-native-angle-type/4611/16 "2017-07-03T15:02:17Z")

</div>

> [@Per](#):
>
> Also, the names are standard across almost every language that has these functions, so changing them would confuse a lot of users.

And not just programming languages. These names mostly correspond to the names used in mathematics. They are different functions, and should have different names.

---

<div class="post-metadata">

**Author:** ![yakir12](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yakir12/32/297_2.png) [@yakir12](https://discourse.julialang.org/u/yakir12)\
**Post date:** [July 3, 2017, 3:03pm UTC](https://discourse.julialang.org/t/should-there-be-a-native-angle-type/4611/17 "2017-07-03T15:03:28Z")

</div>

Agreed, but `sind` versus `sin` isn’t a “real” mathematical distinction (or is it?). On the other hand, that’s something an Angle type might take care of.

---

<div class="post-metadata">

**Author:** ![DNF](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dnf/32/10191_2.png) [@DNF](https://discourse.julialang.org/u/DNF)\
**Post date:** [July 3, 2017, 3:10pm UTC](https://discourse.julialang.org/t/should-there-be-a-native-angle-type/4611/18 "2017-07-03T15:10:22Z")

</div>

Yes, sin and sind is a different story.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [July 3, 2017, 3:10pm UTC](https://discourse.julialang.org/t/should-there-be-a-native-angle-type/4611/19 "2017-07-03T15:10:24Z")

</div>

@yakir12, there are two issues here:

1. would a separate `Angle` type be useful?
2. should this be part of `Base`?

_A priori_ arguments can only get you so far; the best way to demonstrate 1. is to write a package and see if it gets used. This should also help you refine the interface.

I guess 2. will only be relevant if the package is widely used, and you demonstrate that inclusion in `Base` could achieve something that a package could not. That’s a tall order, but even if you think so, it comes after the package.

---

<div class="post-metadata">

**Author:** ![ajkeller34](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ajkeller34/32/4416_2.png) [@ajkeller34](https://discourse.julialang.org/u/ajkeller34)\
**Post date:** [July 3, 2017, 4:41pm UTC](https://discourse.julialang.org/t/should-there-be-a-native-angle-type/4611/20 "2017-07-03T16:41:21Z")

</div>

Unitful does the correct thing already with respect to `sin` vs `sind`:

```julia
julia> using Unitful.°

julia> sin(720π/180)
-4.898587196589413e-16

julia> sin(720°)
0.0

julia> sind(720)
0.0

```

[Next page](https://discourse.julialang.org/t/should-there-be-a-native-angle-type/4611.md?page=2)