TAN: Keep the Angle Away From Its Undefined Point

TAN reads a radian angle and can grow sharply near a right angle. I choose safe demonstration inputs instead of treating an enormous finite output as a meaningful infinity.

Read the angle before reading the magnitude

Tangent can be viewed mathematically as sine divided by cosine. As cosine approaches zero, that ratio becomes large. At an exact right angle the mathematical ratio is undefined. Approximate input representation makes that boundary particularly important in SQL calculations.

TAN returns a float and reads its input in radians. At PI divided by two it gives a very large finite value, not a mathematical infinity. A finite approximation near the boundary still needs an application-specific interpretation.

I’d define the permitted angle domain before calculating a slope or ratio. An input merely being numeric is insufficient. The original unit matters too. Passing degrees directly as radians can answer a different question without producing an obvious error.

Convert safe degree inputs explicitly

The script uses negative forty-five, zero, thirty, forty-five and sixty degrees. A sixth row contains NULL. These values remain away from the demonstrated right-angle boundary. The integer degrees are converted to float before RADIANS.

The resulting tangent is cast to decimal(12,6) for display. Negative forty-five and positive forty-five show opposite unit magnitudes. Thirty and sixty show different positive fractions. The original degrees remain beside each calculated result.

This display cast also has a finite range. A near-boundary tangent could exceed that range. The script’s bounded inputs avoid turning a useful result example into an overflow experiment. It doesn’t claim the same display width suits every angle.

WITH Inputs AS
(
    SELECT Id, DegreesInput
    FROM (VALUES (1, -45), (2, 0), (3, 30), (4, 45),
                 (5, 60), (6, NULL)) AS v(Id, DegreesInput)
)
SELECT Id, DegreesInput,
       CAST(TAN(RADIANS(CAST(DegreesInput AS float)))
           AS decimal(12,6)) AS DisplayTangent
FROM Inputs
ORDER BY Id;

Separate numerical output from a domain decision

A very large finite value can mean the chosen angle is too close to a forbidden boundary. That decision depends on the application’s accepted interval and tolerance. TAN itself doesn’t know that contract. A numeric return cannot certify a usable orientation.

I can justify rejecting near-vertical slopes when the destination uses a finite ratio. Another design might store an angle directly. Those choices solve different representation problems. Neither should be inferred from one convenient decimal output.

The calculation remains approximate even after the final decimal cast. The cast fixes six displayed fractional digits. It doesn’t turn an irrational tangent into an exact finite decimal. Avoid comparing arbitrary float intermediates as though every mathematically equal expression must match exactly.

Keep sign and missingness in the result

Zero is a real angle with a real zero tangent. NULL is an unknown input and stays NULL. Substituting zero would hide that distinction. The script preserves both cases without an application default.

The complete query reads literal values through a CTE. It creates no objects or connection options. ORDER BY fixes the six-row sequence. Its output retains the degree input and selected displayed tangent for each case.

Compare all six tuples with their declared SQL types. Keep the negative result, fractions, zero and missing row in the check. The useful result is bounded and explicit. It isn’t evidence for calculations arbitrarily close to a right angle.

Keep your own angles well away from ninety degrees and the output stays sensible.

A huge tangent is not a useful infinity, it is a finite value that needs an angle-domain decision.

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