(Sorry, I missed the bottom of your message where you distinguish "dimensionless" and "unitless".)
On Monday, March 2, 2015, Gustavo Goretkin <[email protected]> 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 <[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)) >>>>>>> >>>>>>> >>
