Geoff said:

I believe it's supposed to be papered over with something like:

double dresult = cos(dang);

if(dresult < DBL_EPSILON && dresult > -DBL_EPSILON) dresult = 0.0;

On my system

printf("%le\n", DBL_EPSILON);

yields 2.220446e-016, which is far greater than your 6.xxxxe-17.

But, as it turns out, will not work to resolve this difference. Here is

another small test program:

#include <stdlib.h>

#include <stdio.h>

#include <math.h>

#define MY_PI 3.14159265358979323846 /* pi */

int main(void){

int i;

double eps;

double pi=MY_PI;

printf("pi (asin) = %20.20le\n",2.0*asin(1));

printf("pi (MY_PI) = %20.20le\n",pi);

eps = 1/8.0;

for(i=1;i<20;i++){

printf("i:%2d eps:%18.14le dsin:%18.14le\n",i,eps, sin(pi - eps));

eps /= 8.0;

}

exit(EXIT_SUCCESS);

}

On the 4.7.2 system it emits:

pi (asin) = 3.14159265358979311600e+00

pi (MY_PI) = 3.14159265358979311600e+00

i: 1 eps:1.25000000000000e-01 dsin:1.24674733385228e-01

i: 2 eps:1.56250000000000e-02 dsin:1.56243642248835e-02

i: 3 eps:1.95312500000000e-03 dsin:1.95312375823693e-03

i: 4 eps:2.44140625000000e-04 dsin:2.44140622574803e-04

i: 5 eps:3.05175781250000e-05 dsin:3.05175781203855e-05

i: 6 eps:3.81469726562500e-06 dsin:3.81469726573821e-06

i: 7 eps:4.76837158203125e-07 dsin:4.76837158325572e-07

i: 8 eps:5.96046447753906e-08 dsin:5.96046448978553e-08

i: 9 eps:7.45058059692383e-09 dsin:7.45058071938851e-09

i:10 eps:9.31322574615479e-10 dsin:9.31322697080158e-10

i:11 eps:1.16415321826935e-10 dsin:1.16415444291615e-10

i:12 eps:1.45519152283669e-11 dsin:1.45520376930468e-11

i:13 eps:1.81898940354586e-12 dsin:1.81911186822577e-12

i:14 eps:2.27373675443232e-13 dsin:2.27496140123147e-13

i:15 eps:2.84217094304040e-14 dsin:2.85441741103187e-14

i:16 eps:3.55271367880050e-15 dsin:3.67517835871524e-15

i:17 eps:4.44089209850063e-16 dsin:5.66553889764798e-16

i:18 eps:5.55111512312578e-17 dsin:1.22464679914735e-16

i:19 eps:6.93889390390723e-18 dsin:1.22464679914735e-16

and when the _same_ 32 bit binary is run on the 4.6.3 system it emits:

pi (asin) = 3.14159265358979311600e+00

pi (MY_PI) = 3.14159265358979311600e+00

i: 1 eps:1.25000000000000e-01 dsin:1.24674733385228e-01

i: 2 eps:1.56250000000000e-02 dsin:1.56243642248835e-02

i: 3 eps:1.95312500000000e-03 dsin:1.95312375823693e-03

i: 4 eps:2.44140625000000e-04 dsin:2.44140622574803e-04

i: 5 eps:3.05175781250000e-05 dsin:3.05175781203855e-05

i: 6 eps:3.81469726562500e-06 dsin:3.81469726573821e-06

i: 7 eps:4.76837158203125e-07 dsin:4.76837158325568e-07

i: 8 eps:5.96046447753906e-08 dsin:5.96046448978512e-08

i: 9 eps:7.45058059692383e-09 dsin:7.45058071938446e-09

i:10 eps:9.31322574615479e-10 dsin:9.31322697076114e-10

i:11 eps:1.16415321826935e-10 dsin:1.16415444287570e-10

i:12 eps:1.45519152283669e-11 dsin:1.45520376890022e-11

i:13 eps:1.81898940354586e-12 dsin:1.81911186418124e-12

i:14 eps:2.27373675443232e-13 dsin:2.27496136078614e-13

i:15 eps:2.84217094304040e-14 dsin:2.85441700657862e-14

i:16 eps:3.55271367880050e-15 dsin:3.67517431418274e-15

i:17 eps:4.44089209850063e-16 dsin:5.66549845232300e-16

i:18 eps:5.55111512312578e-17 dsin:1.22460635382238e-16

i:19 eps:6.93889390390723e-18 dsin:1.22460635382238e-16

Notice that the dsin values diverge from i = 7, with a result

in the 10^-7 range, so DBL_EPSILON is too small for this problem.

If the function sin(eps) is tested instead the results are identical on

both platforms. Not surprisingly, even though mathematically

the results for sin(pi-eps) should be the same as the preceeding,

numerically they are not. The interesting thing is that they diverge

very early, at the 3rd step. For sin(eps) we know the expected result

for very small eps: eps. And that is what it returns from 10-8 on down.

i: 1 eps:1.25000000000000e-01 dsin:1.24674733385228e-01

i: 2 eps:1.56250000000000e-02 dsin:1.56243642248834e-02

i: 3 eps:1.95312500000000e-03 dsin:1.95312375823680e-03

i: 4 eps:2.44140625000000e-04 dsin:2.44140622574681e-04

i: 5 eps:3.05175781250000e-05 dsin:3.05175781202630e-05

i: 6 eps:3.81469726562500e-06 dsin:3.81469726561575e-06

i: 7 eps:4.76837158203125e-07 dsin:4.76837158203107e-07

i: 8 eps:5.96046447753906e-08 dsin:5.96046447753906e-08

i: 9 eps:7.45058059692383e-09 dsin:7.45058059692383e-09

i:10 eps:9.31322574615479e-10 dsin:9.31322574615479e-10

i:11 eps:1.16415321826935e-10 dsin:1.16415321826935e-10

i:12 eps:1.45519152283669e-11 dsin:1.45519152283669e-11

i:13 eps:1.81898940354586e-12 dsin:1.81898940354586e-12

i:14 eps:2.27373675443232e-13 dsin:2.27373675443232e-13

i:15 eps:2.84217094304040e-14 dsin:2.84217094304040e-14

i:16 eps:3.55271367880050e-15 dsin:3.55271367880050e-15

i:17 eps:4.44089209850063e-16 dsin:4.44089209850063e-16

i:18 eps:5.55111512312578e-17 dsin:5.55111512312578e-17

i:19 eps:6.93889390390723e-18 dsin:6.93889390390723e-18

So, which, if either version of the sin(pi-eps) calculation

is actually the right value? Looking at step 16 eps is

3.55271367880050e-15 so

3.67517835871524e-15 expected sin(pi-eps)[== sin(eps) == eps)

3.67517835871524e-15 observed, newer library (2.18, correct)

3.67517431418274e-15 observed, older library (2.15, incorrect)

Apparently they cleaned up a problem in the math library recently

affecting trig calculations that gave results near zero. This is

probably one of the trig cases referred to in the 2.16 release notes

here:

http://sourceware.org/ml/libc-alpha/2012-06/msg00807.html
Regards,

David Mathog