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))
>>>
>>>
