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 <[email protected]>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 > <[email protected]>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)) >>>>>> >>>>>> >
