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)) On Tue, Feb 4, 2014 at 12:49 PM, Kevin Squire <[email protected]>wrote: > Seems like a reasonable suggestion to me, and it's certainly good to bring > it up for discussion. > > It doesn't have to be immediate, but if there is further consensus, it > would be good to file an issue, or this is likely to get lost. > > Cheers, > > Kevin > > > On Tue, Feb 4, 2014 at 9:09 AM, Johan Sigfrids > <[email protected]>wrote: > >> I agree with this. It seems like a lot of extra namespace usage. Besides, >> if degrees2radians() is too long you always could define a constant and >> use that: >> >> const DEGREE = pi/180 >> sin(90DEGREE) >> >> >> >> On Tuesday, February 4, 2014 6:57:16 PM UTC+2, Hans W Borchers wrote: >>> >>> I was astonished to see the following functions in the Julia Standard >>> Library, >>> functions that accept (or return) degrees instead of radians: >>> >>> sind asind secd asecd >>> cosd acosd cscd acscd >>> tand atand cotd acotd >>> >>> I didn't find these function names in any other technical computing >>> system. >>> Each of these functions can easily be reconstructed by the user applying >>> the >>> functions degrees2radians() and radians2degrees(). >>> >>> I feel these function names clutter the namespace of Julia Base without >>> being >>> of any real value. Therefore, I would like to vote for deprecating use >>> of these >>> functions in the next version of Julia. >>> >>> Hans Werner >>> >>> >
