OSDev.org

I've choosed to reimplement the standard c library in my OS to have more controll on what is happening. I'm still implementing all the functionalities that aren't directly bound to the kernel such as string manipulation functions leaving others like malloc fot later. In this way when I'll start to implement some serious stuffs on the kernel I'll have a soldi std library to rely on.
It was going all well since I've faced the math.h header: I've tried to implement some functions such as sin, cos and log10 using various approximations but were very imprecise and slow. Is there a page, paper, book or something you could suggest me to implement this stuffs? By now I've tried only pure mathematical methods but there could be some bit manipulation methods that I don't know.
What can i do?

It's a lot easier to come up with good approximations for sin() and cos() if you can ensure the argument will always be within a small range, such as (-π/4,π/4). Here's a paper about argument reduction. It's possible to implement this argument reduction using only integer operations, which I think is easier than using floating point operations.

If the reduced argument is sufficiently small, sin() returns the reduced argument, and cos() returns 1. With that, you can further reduce the range over which your approximations need to be accurate, although you may find this step to be unnecessary.

Note that the argument reduction algorithm presented in the paper I linked above includes r = f·(π/2) for the final step of computing the reduced argument. You'll get some odd results if you forget that step!

Unfortunately, that's as far as I've gotten - I don't have any good approximations for sine or cosine after the argument is appropriately reduced.

Some mathematical functions are available directly from the FPU on your target platform.

For things like sine/cosine, a common approach after argument reduction is to use a table. For better results, you can lerp between the neighboring table entries to get smooth transitions.

True, but they may not be suitable for a general-purpose math library. For example, the x86 FSIN, FCOS, FSINCOS, and FPTAN instructions can produce inaccurate results due to imprecise argument reduction, and they're only valid when the input is within the range (-2⁶³,2⁶³).

I'm not sure about FPTAN, but you can solve the problems with the other three instructions by reducing the argument yourself using the method outlined in that paper I linked above. (But note that they always operate with 64 bits of precision, even when you don't need a long double, so using a table or a polynomial approximation may still be faster.)


If you're optimizing for speed, make sure you benchmark against a polynomial approximation. The cache miss(es) from using a table might be so expensive that the polynomial is faster.

I think the table approach is best for more custom applications like signal analysis where the precision of the argument & result is given, which also results in optimal table sizes. For instance, if the argument is 16 bits, using 64 k table entries makes it possible to calculate sin() and cos() with only two look-ups and almost no overhead. I don't think this can be beaten. The table entries could also be parts (integers), as many of these applications will work on integers rather than floating-point data.

For more general-purpose uses, the FPU is probably the best alternative. It already has the smart algorithms built-into the hardware and so the performance is not likely to be better if the normal CPU is used.

Of course, if you want sin() and cos() with higher precision than the FPU can deliver, then a custom approach might be warranted.

Scaling the arguments will be necessary regardless of the method used.

Tanks to all for the suggestions, I'm working hard on implementing them, I'll let you know when I'm at a good point.