Why an Angles.jl package is NOT a great idea

Community
,
1

So, after writing the Angles.jl package, and getting excited about it, I think I finally understand why it’s not such a great idea. But I would love to hear your opinions and thought about it.

The main reason not to have such a package is that it is unclear when an angle stops being an angle (apart from when you’ve run, for example, sin on it). Currently, the user needs to specifically extract the value out of the Angle subtype to stop it from being an angle.

There are two other ways to approach this (I think):

  1. Just use Unitful.jl. Angles exist there within the context of units: they might get canceled out, they might propagate through the whole calculation as intended, or you can purposefully strip off the unit and get their value.
  2. Have angles magically act exactly like any subtype of Number. You’d never need to even care if they stopped being an angle or not.

Since option #2 is not practical now (and might not even be in the future), it seems to me that I should instead add more “angular things” to Unitful.jl (if even needed), rather than hold this one unit separate from the others.

What do you think?

2

I would think the useful part of having an angle type would be to actually limit what you can do with them: add, subtract, sin, cos, etc., so you get an error at compliation if you make a typo, or accidentally pass a number into a function that requires an angle. That might be useful. Having them act like real numbers would actually just be weird, in my opinion. :slight_smile: Multiplying angles is just a mathematical convenience that you can exploit for series expansions, but not something that is really “angle-like”.

1 Like
3

I like the idea of integrating it into Unitful. It seems that some functionality already existed there anyway:

using Unitful: °,rad
sin(45°) # 0.7071
sin(π/4*rad) # 0.7071
45°-π/4 # 0.0
1 Like
4

I think Unitful.jl is the way to go. Packages live by manpower and fragmentation will not help with that.

1 Like