I like that idea as well, but I would argue that radians should indeed have their own type *despite* being unitless. Julia's multi-dispatch system would make calling angle-dependent functions safer, and promote the use of shorter names.
As an added benefit, unit conversion could be easily achieved on a function-by-function basis (I feel blanketed auto-promotion for units might be dangerous). I built a very simple mockup to try it out. I used Inch <-> Meter conversion as an example (hoping it might capture a broader audience), but I think it would deal perfectly with this very issue: https://github.com/ma-laforge/testcases/tree/master/units_test (see units_test.jl) I do not fully appreciate what would be needed to retrofit Julia's basic operations, but I would guess you could comment on that. On Wednesday, February 5, 2014 at 10:40:41 AM UTC-5, Stefan Karpinski wrote: > > What's particularly nice about having Degree and Turn and such is that you > can apply the same exact generic code to any mixture of angular > measurements in different units and still get the correct answers. I'm a > little concerned about the need to redefine so many basic operations for > angular quantities, but maybe that's ok. > > On Wed, Feb 5, 2014 at 10:38 AM, Stefan Karpinski <ste...@karpinski.org > <javascript:>> wrote: > >> I rather like the Degree type idea. Radians are unitless so they don't >> need a type – i.e. PiMultiple is just the default for all trig functions. >> You could, however, also have things angular units like Turns. >> >>
