public static double Sin( double x )
Public Shared Function Sin ( x As Double ) As Double
public: static double Sin( double x )
static member Sin : x : float -> float
This method addresses several subtle shortcommings of the Sin(Double) method. One shortcoming, quite striking but rarely encountered, is that Sin(Double) returns entirely wrong results very large arguments -- for x larger than about 1020, it simply returns the argument as the function value! (I have no idea why the base class library designers did not at least choose to return NaN, so as to signal to the caller that the result should not be trusted. No floating point standard specifies this crazy behavior.) Another shortcomming, more commonly encountered but often unnoticed, is that for large but not necessarily very large arguments, function values loose precision, particularly near zeros of the function.
One way to view these shortcommings is that they are justified by the uncertainty inherent in floating point representations. In this view, any Double should be seen as an uncertain value with a relative error of ~10-16. If the number is very large, then the absolute size of this error can be as large or larger than 2π; in this circumstance we should not expect to be able to say anything about the value (except, of course, that it is between -1 and +1, which is violated by the designers' crazy choice to return the argument as the value). Even if the absolute error is just a non-negligable faction of 2π, there is a non-neglible fraction of the values between -1 and +1 in the corresponding range of function values; any of these values is as possible as any other as a value for the sine of our uncertain argument, so we should be satisfied with any returned value in this non-negligible range.
A different view is that it is better regard every representable floating point value as some exact rational number, and when computing functions of floating point numbers, to always strive to return the representable floating point value nearest to the actual function of that exact rational. Callers are unlikely to complain if we are careful in the regard, and this behavior is particularly useful when the argument is an intermediate result that the programmer may not even realize has become large.
For typical arguments, say between 10-4 and 104, the extra cost of calling this function instead of Sin(Double) is just a couple of comparisons and a single floating point operation; less than 0.1% of arguments in this range are then routed to our much slower, high-accuracy algorithm. We therefore suggest that, for general use, you prefer this method over Sin(Double); only in very unusual situations where (i) you are guaranteed never to encounter very large arguments, (ii) full precision values are not required, and (iii) the run-time of your application is critical and dominated by trigonometric calculations, should you prefer the base class library method.