A Few Strange Functions

Hi Folks,

A post on the spatial forum last week caught my attention for entirely non-spatial reasons: it made use of two functions---RADIANS() and DEGREES()---that I never knew existed.

It seems rather strange that out of the innumerable (well, technically enumerable) list of functions that we could implement, someone felt these were worth the effort.  For example, we save exactly 0 characters by using these functions:

 RADIANS(@x)

 DEGREES(@y)

Becomes:

 @x*PI()/180

 @y*180/PI()

Granted, using the functions is clearer and less error prone; but I’m not arguing that they are bad functions, just surprising.

What is surprising and bad, if you ask me, is that both RADIANS() and DEGREES() have int—>int overloads.  In other words, if you call these functions with an integer, you get an integer result:

 SELECT RADIANS(180) -- 3, not 3.141592653589793100

 SELECT DEGREES(3)   -- 171, not 171.887338539246970000

This behavior is very strange.  I cannot think of a case in which it is useful, yet plenty where it could cause harm.  The behavior is noted in BOL:

Arithmetic functions, such as ABS, CEILING, DEGREES, FLOOR, POWER, RADIANS, and SIGN, return a value having the same data type as the input value.

Of these, only RADIANS() and DEGREES() have natural floating-point return values: all others are naturally integers, and while promoting them to floats may not be necessary, it doesn’t seem problematic.

Let me know if you can see a benefit of this behavior; I’d love to see these overloads on our deprecation list.

Cheers,

-Isaac