It's not really relevant to Julia, but there are many who would argue that there should be a base unit for angles. My personal favorite consequence of this choice is that Torque and Energy appear to have the same units.
For example: Issue 10: the SI needs a base unit of angle ‘Angle’ is as tangible a geometric quantity as length, but the SI does not have a corresponding base quantity or unit for angle. The radian is a derived unit in the SI, defined from the identity s = r · θ (in which r is the radius of a circle and s is the length of the arc subtended by the angle θ ). From this definition, the radian has the unit m/m, and is said to be a dimensionless derived unit [34]. This definition has several undesirable consequences for rotational quantities, for example the SI unit for a rate of rotation is a ‘per second’, without any reference to the angle through which rotation takes place, or its unit [50]. There is ongoing confusion in textbooks about when radian units should be inserted or deleted in quantity expressions [51, 52]. >From The next 50 years of the SI: a review of the opportunities for the e-Science age <https://publications.csiro.au/rpr/download?pid=csiro:EP11794&dsid=DS4> On Monday, March 2, 2015 at 11:05:00 AM UTC-7, Kevin Squire wrote: > > (Sorry, I missed the bottom of your message where you distinguish > "dimensionless" and "unitless".) > > On Monday, March 2, 2015, Gustavo Goretkin <gustavo....@gmail.com > <javascript:>> wrote: > >> Radian has dimensions of [(arc) length] / [(radius) length], so it's >> dimensionless because the two dimensions of [length] cancel out. >> Turn has dimensions of [(arc) length] / [(circumference) length], so it's >> just as dimensionless as Radian, right? >> >> https://en.wikipedia.org/wiki/Dimensionless_quantity#Properties seems to >> make a distinction between "dimension(less)" and "unit(less)". I think it >> could make sense to have types to distinguish among different dimensionless >> quantities that have different units. >> >> On Wednesday, February 5, 2014 at 10:38:12 AM UTC-5, Stefan Karpinski >> 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. >>> >>> >>> On Wed, Feb 5, 2014 at 7:48 AM, Johan Sigfrids <johan.s...@gmail.com> >>> wrote: >>> >>>> Oh, you beat me to it. I was just about to say that using a Degree type >>>> and dispatching on it would be a lot more Julian. In fact, I had this >>>> great >>>> idea on how to use the degree sign to construct degrees: >>>> >>>> module DegreeModule >>>> >>>> export Degree, DegreeSign, ° >>>> >>>> immutable Degree{T<:Number} <:Number >>>> d::T >>>> end >>>> >>>> immutable DegreeSign >>>> filler::Bool >>>> end >>>> >>>> const ° = DegreeSign(true) >>>> >>>> *(num::Number, s::DegreeSign) = Degree(num) >>>> >>>> Base.sin(d::Degree) = sinpi(d.d/180) >>>> >>>> end >>>> >>>> >>>> >>>> Then it would Just Work™: >>>> >>>> using DegreeModule >>>> >>>> Degree(125) # ==> Degree{Int64}(125) >>>> >>>> 130° # ==> Degree{Int64}(130) >>>> >>>> sin(180°) # ==> 0.0 >>>> >>>> I'm not familiar enough with Julia to know if that is the best way to >>>> construct the degree sign functionality, but I thought it was kinda >>>> elegant. >>>> >>>> >>>> On Wednesday, February 5, 2014 12:18:38 PM UTC+2, Simon Byrne wrote: >>>>> >>>>> As I understand it, the original reason for the degree functions was >>>>> for matlab compatibility, but they were later modified (and pi-multiple >>>>> functions sinpi/cospi introduced) so as to be more accurate outside the >>>>> the >>>>> interval [-pi/2,pi/2], as Ivar points out. Note that we haven't improved >>>>> on >>>>> the naive approach on values within this interval, e.g. >>>>> >>>>> julia> sind(30) >>>>> >>>>> 0.49999999999999994 >>>>> Matlab gets this wrong as well, but lies about it: >>>>> >>>>> >> sind(30) >>>>> >>>>> ans = >>>>> >>>>> 0.5000 >>>>> >>>>> >> sind(30)-0.5 >>>>> >>>>> ans = >>>>> >>>>> -5.5511e-17 >>>>> >>>>> As to their use, I don't know about the degree functions, but the >>>>> sinpi/cospi functions are actually used internally in a couple of places, >>>>> in the definition of sinc and a couple of the bessel functions. >>>>> >>>>> However that doesn't mean the interface couldn't be improved. One >>>>> possible approach I've been thinking about is defining "degree" and >>>>> "pi-multiple" types >>>>> >>>>> immutable Degree <: Real >>>>> deg::Float64 >>>>> end >>>>> >>>>> immutable PiMultiple <: Real >>>>> mult::Float64 >>>>> end >>>>> >>>>> In this way we could leverage multiple dispatch: i.e. sind(x) becomes >>>>> sin(Degree(x)) and sinpi(x) becomes sin(PiMultiple(x)). Of course, since >>>>> julia doesn't (yet) provide a way to dispatch on return types, there's >>>>> not >>>>> an easy way to define the corresponding inverse functions, but this is >>>>> typically less of an issue in terms of numerical error due to the >>>>> constrained output range (the exception being atan2, where something >>>>> like this could be very useful >>>>> <https://github.com/JuliaLang/julia/issues/3246#issuecomment-18691772> >>>>> . >>>>> >>>>> Simon >>>>> >>>>> On Wednesday, 5 February 2014 08:42:59 UTC, Ivar Nesje wrote: >>>>>> >>>>>> Hans W Borchers: Your definition is not equivalent. >>>>>> >>>>>> julia> sin(pi) >>>>>> 1.2246467991473532e-16 >>>>>> >>>>>> julia> sind(180) >>>>>> 0.0 >>>>>> >>>>>> julia> sinpi(1) >>>>>> 0 >>>>>> >>>>>> julia> sin(big(pi)) >>>>>> 1.096917440979352076742130626395698021050758236508687951179005716992142688513354e-77 >>>>>> >>>>>> with 256 bits of precision >>>>>> >>>>>> The answer for sin(pi) is somewhat correct, because float(pi) is not >>>>>> the π you know from mathematics. It is the closest representable *IEEE >>>>>> 754* floating point number. >>>>>> >>>>>> Ivar >>>>>> >>>>>> kl. 09:31:42 UTC+1 onsdag 5. februar 2014 skrev Hans W Borchers >>>>>> følgende: >>>>>>> >>>>>>> You could easily add these two lines of function definitions to your >>>>>>> code. >>>>>>> >>>>>>> sind(x) = sin(degrees2radians(x)) >>>>>>> cosd(x) = cos(degrees2radians(x)) >>>>>>> >>>>>>> and your haversine function stands as is, not littered with >>>>>>> conversions. >>>>>>> >>>>>>> >>>>>>> On Tuesday, February 4, 2014 6:55:13 PM UTC+1, Jacob Quinn wrote: >>>>>>>> >>>>>>>> As someone who doesn't have to work with the functions very often >>>>>>>> or deal with degrees/radians conversions, I actually have found it >>>>>>>> convenient to have the sind functions. It saves me time from having to >>>>>>>> remember what the conversion is or make my code uglier littered with >>>>>>>> degrees2radians() conversions, for example, in the following haversine >>>>>>>> distance calc. >>>>>>>> >>>>>>>> haversine(lat1,lon1,lat2,lon2) = 12745.6 * >>>>>>>> asin(sqrt(sind((lat2-lat1)/2)^2 + cosd(lat1) * cosd(lat2) * >>>>>>>> sind((lon2 - lon1)/2)^2)) >>>>>>>> >>>>>>>> >>>
