The coefficient C3 used by FDLIBM’s implementation of COS is NOT exactly 1/factorial(8). See this Cleve’s Corner article for a discussion of how the FDLIBM implementation of SIN was designed; the implementation of COS was designed in much the same way.

http://www.mathworks.com/company/newsletters/news_notes/clevescorner/winter02_cleve.html

Quoting from that article:

The six coefficients are close to, but not exactly equal to, the power series coefficients 1/3!, 1/5!, …, 1/13! . They minimize the maximum relative error, | (sin() - p())/sin() |, over the interval. Six terms are enough to make this approximation error less than 2^(-52), which is the roundoff error involved when all the terms, and the sum, are less than one.

That article is titled “The Tetragamma Function and Numerical Craftsmanship” — and there’s definitely some craftmanship involved in the implementation of the trig functions.

But i do want to see the exact reason for every number and then maybe come up with a solution. See i also found some interesting things;

Take a look at the cos() function which is said to be used in Matlab. I have cross checked and ensure that this is the code Matlab uses (http://www.netlib.org/fdlibm/k_cos.c).
Inside the code the constants are given as forexample C3=2.48015872894767294178e-05 and this is 1/8! (http://en.wikipedia.org/wiki/Cosine). However the difference is;
>> 1/factorial(8)-2.48015872894767294178e-05
ans =
1.2111e-014

These are clearly different numbers! And what is more interesting is that errors appear more when i try to use exact factorial values. Even with higher series..

EPS is not the min length to point 1. It is the distance from 1 to the _next largest_ floating point number. You’re correct that the next _largest_ number after 1 is 1+eps(1). However, the next _smallest_ number before 1 is not 1-eps(1) but is actually 1-(eps(1)/2).

You can see this by looking at the hexadecimal representation of these two numbers and one. To do this, use the HEX option for the FORMAT command. The first three hex digits are the sign and the exponent of the number, the last thirteen are the mantissa.

% Tell MATLAB to display the numbers in hex format
format hex

% Look at the number 1
one = 1

% This is the next largest number
% The last bit of the mantissa has been incremented
nextLargest = one+eps(one)

% This is the next smallest number
% We decremented the last bit of the mantissa
% which required borrowing from the exponent
nextSmallest = one - (eps(one)/2)

% Is nextSmallest actually less than 1?
isSmaller = nextSmallest < one

% Reset the format back to the default
format

Cleve’s newsletter article, linked at the end of Loren’s blog posting, describes the hexadecimal format displayed by FORMAT HEX.

Have a look at floatgui.m from Cleve Moler’s NCM book: http://www.mathworks.com/moler/ncmfilelist.html

>> 1-(cos(1/8)^2+sin(1/8)^2)
ans =
1.1102e-016
>> ans/eps(1)
ans =
0.5000

Eps is supposed to be the min length to point 1. How come half of it appears?

We could rearchitect MATLAB to do that, and it would slow everything down intolerably. In addition, who’s to say that 100*eps is the right cutoff?

–Loren

So far I’ve decided to take the numeric workaround by John D’Errico and Roger Stafford. My algorithm will greatly benefit from using straight numeric arithmetics, plus their workaround is compatible with required bit-wise operations.

I’ll check the fi toolbox, no doubt ;)

Thanks for your time, it’s much appreciated.