That’s awesome. Should that occur there (and only there) or should the right thing happen under a broader context?
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.
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.
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.
6 Likes
Shouldn’t Angle use fixed precision numbers so that [0,2pi) is as densely represented as possible? Using Float64 seems very inefficient.
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π.
1 Like
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:
julia> using Unitful: °
julia> BigFloat("7.3")°
7.300000000000000000000000000000000000000000000000000000000000000000000000000028 °
julia> typeof(ans)
Quantity{BigFloat, Dimensions:{}, Units:{°}}
(Substitute your favorite extended-precision type for BigFloat.)
1 Like
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”.
1 Like
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?).
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?
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.
2 Likes
Totally. Right, I’ll shut up now 