The programming problem with sine calculation

Computer languages such as C include library functions for computing sine and other periodic trig functions. In the old days of x86 PCs, the processor even included a built-in sine function that was often used by the library. These built-in functions had some imperfections of their own. Compiler trig functions today are better in many cases. But there is a more fundamental problem.
The problem is that the compiler function requires an input argument in units of radians. But the international standard unit for frequency is Hertz. Real world frequencies are often stated in Hertz for this reason. When is the last time you needed a sine wave of frequency 1000 radians per second?
Converting a rational, exact Hertz value into the needed radians per second value always results in data loss because the conversion factor (2pi) is irrational. In addition, the data loss accumulates as the argument grows. There is a technique to prevent this data loss accumulation, but the underlying inaccuracy can't be avoided.
It's surprising that after all these years the language committees haven't added a sine function variation to address this problem. The authors of the MPFR library have blazed the trail and given the world such a function, mpfr_sinu (and mpfr_sinpi). Thanks, guys!
But it is the standard double precision compiler libraries where the new functions are needed most. With MPFR, the extra precision could be used to work around the problem even before the new functions were added. But when working with straight double precision, there is no work-around.
Here is a long, related discussion.