RADIANS: Cast Integer Degrees Before Conversion

RADIANS converts degrees, but an integer argument keeps an integer return type. I cast before the function when the calculation needs the fractional part of the angle.

Keep the unit and type together

An angle described as thirty degrees has a fractional radian equivalent. Writing thirty as an integer doesn’t change that mathematical fact. It does affect the SQL return contract. The function must be called with a type capable of retaining the needed fraction.

RADIANS returns int for int, smallint and tinyint inputs. A float or real input returns float. Decimal input follows its own return rule. This example compares int and float deliberately, rather than mixing every supported type.

I’d label the source unit explicitly when an application exchanges angles. A numeric value without a unit can be interpreted incorrectly even with a suitable type. The output column names state radians. The original column remains DegreesInput.

Cast before the function runs

The script supplies zero, thirty, ninety, 180 and negative ninety degrees. A sixth input is NULL. One expression calls RADIANS directly on the integer. Another converts that integer to float before calling the function.

The float expression is then cast to decimal(12,6) for display. That final cast serves a different purpose from the earlier input cast. Casting an already narrowed integer result to decimal would not restore its discarded fractional portion.

The thirty-degree case is expected to show integer zero beside 0.523599. Ninety degrees shows one beside 1.570796. The input and two outputs make the timing of conversion visible. A decimal-looking display alone wouldn’t establish where narrowing occurred.

WITH Inputs AS
(
    SELECT Id, DegreesInput
    FROM (VALUES (1, 0), (2, 30), (3, 90), (4, 180),
                 (5, -90), (6, NULL)) AS v(Id, DegreesInput)
)
SELECT Id, DegreesInput, RADIANS(DegreesInput) AS IntegerRadians,
       CAST(RADIANS(CAST(DegreesInput AS float))
           AS decimal(12,6)) AS DisplayRadians
FROM Inputs
ORDER BY Id;

Do not assume every numeric type behaves identically

Other types such as bigint, decimal, money and bit follow their own return rules. Their precision or range can differ. This small script doesn’t establish results for every category. Review the actual declared expression type used at the call site.

An arithmetic expression supplied to RADIANS can have a different type from its original column. A preceding integer division can already remove a fraction. Casting after that division is too late. I’d inspect the whole expression before blaming the angle conversion.

I can justify an integer radian result when the consumer intentionally needs whole units. That decision should be explicit in its specification. Most trigonometric calculations require more detail. Retain a suitable representation before passing the result to another function.

Check the sign and missing value

Negative ninety degrees produces a negative fractional radian result in the float path. The comparison also retains a true zero. NULL stays missing in both paths. The script doesn’t replace a missing angle with a neutral orientation.

The final decimal scale is a display choice over an approximate float calculation. It isn’t a claim of exact irrational values. Choose a tolerance or displayed precision suited to the consumer. This specification compares the selected six-digit decimal outputs.

Every query operation reads literal values through a CTE. No objects or settings are changed. ORDER BY fixes the six-row case sequence. Compare complete tuples from both typed conversion paths rather than relying on a plausible angle label.

Cast first, and the fraction makes it through.

A later decimal cast is not a recovered fraction, it is a wider view of the result.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.