ACOS: Check the Cosine Domain Before Calculating Angles

ACOS calculates an angle from a cosine value within the supported domain. I check that input before requesting the angle. A number outside the domain is a data decision, not another valid angle.

Start with the meaning of the input

The input represents a cosine ratio rather than a degree measurement. Passing ninety does not ask for a ninety-degree angle. It asks for an inverse cosine of a number that cannot be a valid ratio.

The query names the input CosineRatio to keep that distinction visible. Every supplied ratio is an explicit decimal value. The angle expression then converts accepted values to the function’s approximate numeric input.

I include both endpoints, the midpoint, a missing value and two outside values. Those cases exercise different parts of the input contract. They do not deliberately execute an invalid function argument.

Pass a safe argument to the function

The CASE expression sits inside ACOS. It supplies a supported ratio or a typed NULL. The function therefore receives no outside-domain value from this example.

The status column retains the reason for an absent angle. Missing input receives Missing, while an outside ratio receives Outside domain. Neither row is presented as a valid angle of zero.

The expected angle for one is zero radians. Zero is expected to display as 1.570796, and negative one as 3.141593. These are six-place decimal displays of approximate angle results.

The three remaining rows are expected to have NULL angles. Their status values still distinguish missing data from an invalid supplied ratio. Keeping both columns prevents a rejected measurement from disappearing into one unexplained blank.

WITH Ratios AS
(
    SELECT CaseId,CosineRatio
    FROM (VALUES
        (1,CAST(1 AS decimal(4,2))),
        (2,CAST(0 AS decimal(4,2))),
        (3,CAST(-1 AS decimal(4,2))),
        (4,CAST(NULL AS decimal(4,2))),
        (5,CAST(1.10 AS decimal(4,2))),
        (6,CAST(-1.10 AS decimal(4,2)))
    ) AS v(CaseId,CosineRatio)
)
SELECT CaseId,CosineRatio,
    CASE WHEN CosineRatio IS NULL THEN N'Missing'
         WHEN CosineRatio BETWEEN -1 AND 1 THEN N'Valid'
         ELSE N'Outside domain' END AS InputStatus,
    CAST(ACOS(CASE WHEN CosineRatio BETWEEN -1 AND 1
        THEN CAST(CosineRatio AS float)
        ELSE CAST(NULL AS float) END) AS decimal(10,6)) AS AngleRadians
FROM Ratios
ORDER BY CaseId;

Avoid repairing the ratio silently

A computed ratio slightly above one can arise from approximation or an upstream mistake. Those possibilities need different policies. I wouldn’t automatically turn every outside value into the nearest endpoint.

Clamping 1.10 to one would invent a zero angle for this sample. Clamping negative 1.10 would invent the opposite endpoint. A tidy result would conceal the invalid inputs still visible in the status column.

A tolerance policy can be reasonable for a specific calculation. It needs a documented limit and a reason tied to that calculation. This example applies the stated domain directly and introduces no tolerance.

If the ratio comes from a division, validate that operation separately. A zero denominator is not fixed by checking the finished ratio. Missing source measurements also deserve their own explanation before angle calculation.

Keep radians and display precision separate

The output unit is radians. Converting it to degrees would require a separate expression and a clearly named result. Relabeling the existing number does not change its unit.

The decimal cast controls the displayed scale in this example. It does not turn the underlying trigonometric calculation into exact decimal arithmetic. Do not use the displayed rounded value to claim an exact geometric identity.

I compare the complete expected rows rather than inspecting only the positive endpoint. The negative endpoint confirms the other end of the domain. The midpoint exposes the difference between radians and degrees.

This query reads only made-up values and changes no settings. A production calculation may need additional unit, tolerance and measurement rules. Keep those rules separate from the narrow question of whether ACOS receives an allowed argument.

When adapting the example, retain the original ratio beside the outcome. Add explicit status values for any additional validation policy. That makes an absent result reviewable without fabricating an angle for unsuitable input.

Check the ratio first, and the angle takes care of itself.

A missing angle is not always missing input, it is sometimes a refusal of a bad ratio.

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