Is there any particular reason to only include 3 out of the 6 trigonometry functions?

Question

Most languages seem to only have sin cos and tan. While the other 3 are just 1/cos 1/sin and 1/tan, is there any way that supporting the other 3 directly could be faster than calculating one and then performing a division? Are there any other reasons beyond the triviality of deriving the other csc sec and cot from the existing sin cos and tan to exclude them?

Answer 1

This does just roll the barrel slightly lower on the hill (or whatever the saying is), but:

The IEEE 754 floating point standard includes the following trig-related operations as "recommended"

• sin(x)
• cos(x)
• tan(x)
• arcsin(x)
• arccos(x)
• arctan(x)
• atan2(y, x)

Since the 2019 revision, these are also recommended (though I've never seen these):

• sinPi(x) = sin(pi * x)
• cosPi(x)
• tanPi(x)
• arcsinPi(x) = arcsin(x) / pi
• arccosPi(x)
• arctanPi(x)
• atan2Pi(y, x) = atan2(y, x) / pi

Now, why does IEEE 754 not recommend (arc)sec/csc/cot I have no idea.

Answer 2

One possible reason is that it is quite difficult to implement these functions with high accuracy.

For + - * / the IEEE standard requires that the error is at most 1/2 of the least significant bit (0.5 ulp). For sin, cos, tan and others, that limit is quite difficult but not impossible to achieve, while a careful implementation can achieve an error of up to say 0.6ulp without major problems. I think Apple's implementation in C and C++ achieves that for inputs less than 10^15, and I'd hope other implementations do the same.

If you want to calculate 1 / sin x, and do this in the naive way by calculating z = sin x and dividing 1 / z, then your rounding error will be much larger. And 1 / sin x is not a polynomial but close to 1 / x, so if you try to calculate it directly you will also have difficulties keeping the rounding error small (close to 0.5ulp, and definitly less than 1.0ulp).

PS. Just noticed in another post "1 - cos b" was mentioned. Since cos b ≈ 1 - b^2/2 for small b, 1 - cos b could be calculated with much higher precision for small b without going through the cos function.

Answer 3

Older processors had instructions to compute the sine, cosine and tangent of floating-point numbers, but not the secant, cosecant or cotangent. So the reason could just be that especially for older languages, the standard library's mathematical functions were just thin wrappers around the processor's capabilities; and newer languages might have just been copying from those languages ever since.

On the other hand, I can think of a concrete performance reason why it's better not to provide these functions in the standard library. In almost all use-cases, you don't want just the secant, cosecant or cotangent, you want it multiplied by some value; these trigonometric functions are defined as ratios of side lengths in triangles, so you can find an unknown side of a triangle by multiplying a known side by the appropriate trigonometric function of a known angle.

For example, you could write code like this:

let hypotenuse = adjacent * sec(theta);

But if sec(theta) is a function which returns 1.0 / cos(theta) then (without compiler optimisations) this code will do an unnecessary multiplication by 1 and also an extra function call. The alternative way of writing it is:

let hypotenuse = adjacent / cos(theta);

For the compiler to optimise the former into the latter, it must inline the sec function, rewrite the expression a * (1.0 / c) as (a * 1.0) / c, and then eliminate the unnecessary multiplication. In reality, even modern compilers don't do this optimisation, because it can change the result slightly, and the compiler can't know that the user doesn't mind the slight difference (or that the latter version is slightly more accurate according to the user's intent).

But even though the version with cos is more efficient and slightly more accurate, many programmers might presume that if sec exists in the standard library then it must be better to use it. Therefore, excluding it from the standard library causes users to write the better version with cos. Exactly the same reasoning applies to cosec and cot.

Answer 4

Frequency of use

The main three are vastly more commonly used than the other three.

Answer 5

A very huge system library with functions for trivial, easy to derive features is more difficult to remember. The code using them may easily be less readable. Imagine you see:

a = haversine(b)

Some will know, but for many, Google will be they friend, losing the productive time on that. And when the developer will need to write it next time, one may get in doubt, maybe it was hav or hsin or haversed_sine instead and need to google again. Maybe again. The only benefit, this would boost the page rank of web resources focused on this uncommon function. At the same time,

a = (1 - cos(b) )/2

(the same) would be understood by any developer in a fraction of second. haversine actually reduces readability, unless needed very often.

P.S: As correctly pointed in the comment to this answer, some rarely used functions make sense if there are code readers that have the fundamental knowledge about them, bringing up lots of useful associations. Maybe haversine is actually not a so good example if used for the task where it is commonly used (not if the expression matched just by chance). In any case the answer argues that smaller API is easier to remember and used without excessive and repeated googling.

P.S: Some "easy" functions may be present in the library if the naive formula may give overflow on intermediate result (like hypot(x, y) = sqrt(x*x + y*y)) or significant rounding errors. The actual way of computing in this case is actually different from naive.

It is important to keep the balance.