# 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:** 13\
**Page:** 2

<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, 5:22pm UTC](https://discourse.julialang.org/t/should-there-be-a-native-angle-type/4611/21 "2017-07-03T17:22:19Z")

</div>

That’s awesome. Should that occur there (and only there) or should the right thing happen under a broader context?

---

<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, 5:24pm UTC](https://discourse.julialang.org/t/should-there-be-a-native-angle-type/4611/22 "2017-07-03T17:24:24Z")

</div>

I reckon you are totally right. I can’t come with anything substantial to add to that other than that _maybe_ I’ll have time to work towards a package like that. But yea, that is probably the way to go.

---

<div class="post-metadata">

**Author:** ![tuckermcclure](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tuckermcclure/32/1187_2.png) [@tuckermcclure](https://discourse.julialang.org/u/tuckermcclure)\
**Post date:** [July 4, 2017, 2:15am UTC](https://discourse.julialang.org/t/should-there-be-a-native-angle-type/4611/23 "2017-07-04T02:15:04Z")

</div>

I work with a ton of quantities that are _almost_ angles. A good example is modified Rodrigues parameters. These are unitless, but for small rotations, they approach the “rotation vector” when that vector is expressed in radians. But when big, they’re not much like radians at all. It would definitely be awkward to go around calling MRPs “radians” when they aren’t, just so that I can use certain trig approximations where they’re small. Perhaps not-really-angle use-cases like this are worth considering? I’m a big fan of “regular” trig functions for this reason, but I have no problem with decorators like Unitful as long as I don’t have to program everything that way. I suppose that’s my vote that Unitful (or some other package) should handle this, and not Base.

---

<div class="post-metadata">

**Author:** ![malmaud](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/malmaud/32/29_2.png) [@malmaud](https://discourse.julialang.org/u/malmaud)\
**Post date:** [July 4, 2017, 2:41am UTC](https://discourse.julialang.org/t/should-there-be-a-native-angle-type/4611/24 "2017-07-04T02:41:14Z")

</div>

A package could just define a `Radian` and `Degree` type and overload the `Base `trig functions on them. As long as the types are immutables and the argument types to these overloaded are statically inferable in user code, this won’t introduce any overhead.

I don’t immediately see the advantage of having those types in `Base`.

---

<div class="post-metadata">

**Author:** ![dlfivefifty](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dlfivefifty/32/1959_2.png) [@dlfivefifty](https://discourse.julialang.org/u/dlfivefifty)\
**Post date:** [July 6, 2017, 2:54pm UTC](https://discourse.julialang.org/t/should-there-be-a-native-angle-type/4611/25 "2017-07-06T14:54:24Z")

</div>

Shouldn’t `Angle` use fixed precision numbers so that [0,2pi) is as densely represented as possible? Using Float64 seems very inefficient.

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [July 6, 2017, 4:35pm UTC](https://discourse.julialang.org/t/should-there-be-a-native-angle-type/4611/26 "2017-07-06T16:35:11Z")

</div>

> [@dlfivefifty](#):
>
> Shouldn’t Angle use fixed precision numbers so that [0,2pi) is as densely represented as possible?

You want very small angles (important in lots of applications) to have few significant digits? Also, hardware floating-point arithmetic is a lot faster than software fixed-point arithmetic modulo 2π.

---

<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 6, 2017, 6:39pm UTC](https://discourse.julialang.org/t/should-there-be-a-native-angle-type/4611/27 "2017-07-06T18:39:01Z")

</div>

We could have an option to turn extra precision on and off for different applications…

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [July 6, 2017, 7:36pm UTC](https://discourse.julialang.org/t/should-there-be-a-native-angle-type/4611/28 "2017-07-06T19:36:57Z")

</div>

> [@yakir12](#):
>
> We could have an option to turn extra precision on and off for different applications…

Any sensible angle type will presumably be a wrapper around an arbitrary `Number` type, much like Unitful’s `°` type already is:

```jl
julia> using Unitful: °

julia> BigFloat("7.3")°
7.300000000000000000000000000000000000000000000000000000000000000000000000000028 °

julia> typeof(ans)
Quantity{BigFloat, Dimensions:{}, Units:{°}}

```

(Substitute your favorite extended-precision type for `BigFloat`.)

---

<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 7, 2017, 5:37am UTC](https://discourse.julialang.org/t/should-there-be-a-native-angle-type/4611/29 "2017-07-07T05:37:51Z")

</div>

Sure. I guess the way I see it, an Angle is more primitive than a Unitful’s Quantity. Just like a Bool is more primitive than a (albeit non-existent) “true/flase” Unit.  
But at the end of the day, it’s all about how to best type an Angle, as a specific type, with its own specialized methods etc, or as a part of a units system (i.e. Unitful).

I have to add, there must be a few other “entities” that might benefit from getting “their own type”. Sign is also one of them, but maybe there are more? Not sure if it’s “new possibilities due to Julia” or “overzealous typing”.

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [July 7, 2017, 1:17pm UTC](https://discourse.julialang.org/t/should-there-be-a-native-angle-type/4611/30 "2017-07-07T13:17:08Z")

</div>

> [@yakir12](#):
>
> Sure. I guess the way I see it, an `Angle` is more primitive than a Unitful’s `Quantity`

`Quantity` is already zero runtime overhead over the underlying numeric type (when used in a type-stable fashion), and an angle type is similar in that it is an underlying numeric value + type metadata. `Bool` is different: it is a distinct quasi-numeric primitive type, that would not be reasonable to “wrap” around another arbitrary numeric type (what would `Bool{Float64}` mean?).

---

<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 10, 2017, 8:55am UTC](https://discourse.julialang.org/t/should-there-be-a-native-angle-type/4611/31 "2017-07-10T08:55:18Z")

</div>

I see. But what do you think about adding some trigonometry functions to the exported methods of the Unitful package? My opinion is that it doesn’t make total sense to add those methods _there_. But that there should be a separate package for that kind of functionality, namely, `Angle.jl`. And _then_ allow for automatic “unitifying” of the Angle type when using `Angle.jl` in conjunction with `Uniful.jl`…

As to performance:  
My main question with this thread is: Within this new ecosystem (Julia), are there any niceties we can now have, that would introduce very little if any computational cost, things like a new Angle type that we couldn’t afford to have before?

---

<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 10, 2017, 10:29am UTC](https://discourse.julialang.org/t/should-there-be-a-native-angle-type/4611/32 "2017-07-10T10:29:51Z")

</div>

> [@yakir12](#):
>
> things like a new Angle type that we couldn’t afford to have before?

What’s “before”? Before Julia? Basically, you get costless abstraction, both in term of computational cost and implementation cost.

Why don’t you just try writing `Angle.jl` and see where it goes? I am getting the impression that the discussion about it is now longer than the actual code would be.

---

<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 10, 2017, 10:36am UTC](https://discourse.julialang.org/t/should-there-be-a-native-angle-type/4611/33 "2017-07-10T10:36:21Z")

</div>

Totally. Right, I’ll shut up now 😄

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