Searched hist:153086 (Results 1 - 2 of 2) sorted by relevance
| /freebsd-9.3-release/lib/msun/src/ | ||
| H A D | s_log1p.c | diff 153086 Sun Dec 04 10:30:44 MST 2005 bde For log1pf(), fixed the approximations to sqrt(2), sqrt(2)-1 and sqrt(2)/2-1. For log1p(), fixed the approximation to sqrt(2)/2-1. The end result is to fix an error of 1.293 ulps in log1pf(0.41421395540 (hex 0x3ed413da)) and an error of 1.783 ulps in log1p(-0.292893409729003961761) (hex 0x12bec4 00000001)). The former was the only error of > 1 ulp for log1pf() and the latter is the only such error that I know of for log1p(). The approximations don't need to be very accurate, but the last 2 need to be related to the first and be rounded up a little (even more than 1 ulp for sqrt(2)/2-1) for the following implementation-detail reason: when the arg (x) is not between (the approximations to) sqrt(2)/2-1 and sqrt(2)-1, we commit to using a correction term, but we only actually use it if 1+x is between sqrt(2)/2 and sqrt(2) according to the first approximation. Thus we must ensure that !(sqrt(2)/2-1 < x < sqrt(2)-1) implies !(sqrt(2)/2 < x+1 < sqrt(2)), where all the sqrt(2)'s are really slightly different approximations to sqrt(2) and some of the "<"'s are really "<="'s. This was not done. In log1pf(), the last 2 approximations were rounded up by about 6 ulps more than needed relative to a good approximation to sqrt(2), but the actual approximation to sqrt(2) was off by 3 ulps. The approximation to sqrt(2)-1 ended up being 4 ulps too small, so the algoritm was broken in 4 cases. The result happened to be broken in 1 case. This is fixed by using a natural approximation to sqrt(2) and derived approximations for the others. In logf(), all the approximations made sense, but the approximation to sqrt(2)/2-1 was 2 ulps too small (a tiny amount, since we compare with a granularity of 2**32 ulps), so the algorithm was broken in 2 cases. The result was broken in 1 case. This is fixed by rounding up the approximation to sqrt(2)/2-1 by 2**32 ulps, so 2**32 cases are now handled a little differently (still correctly according to my assertion that the approximations don't need to be very accurate, but this has not been checked). |
| H A D | s_log1pf.c | diff 153086 Sun Dec 04 10:30:44 MST 2005 bde For log1pf(), fixed the approximations to sqrt(2), sqrt(2)-1 and sqrt(2)/2-1. For log1p(), fixed the approximation to sqrt(2)/2-1. The end result is to fix an error of 1.293 ulps in log1pf(0.41421395540 (hex 0x3ed413da)) and an error of 1.783 ulps in log1p(-0.292893409729003961761) (hex 0x12bec4 00000001)). The former was the only error of > 1 ulp for log1pf() and the latter is the only such error that I know of for log1p(). The approximations don't need to be very accurate, but the last 2 need to be related to the first and be rounded up a little (even more than 1 ulp for sqrt(2)/2-1) for the following implementation-detail reason: when the arg (x) is not between (the approximations to) sqrt(2)/2-1 and sqrt(2)-1, we commit to using a correction term, but we only actually use it if 1+x is between sqrt(2)/2 and sqrt(2) according to the first approximation. Thus we must ensure that !(sqrt(2)/2-1 < x < sqrt(2)-1) implies !(sqrt(2)/2 < x+1 < sqrt(2)), where all the sqrt(2)'s are really slightly different approximations to sqrt(2) and some of the "<"'s are really "<="'s. This was not done. In log1pf(), the last 2 approximations were rounded up by about 6 ulps more than needed relative to a good approximation to sqrt(2), but the actual approximation to sqrt(2) was off by 3 ulps. The approximation to sqrt(2)-1 ended up being 4 ulps too small, so the algoritm was broken in 4 cases. The result happened to be broken in 1 case. This is fixed by using a natural approximation to sqrt(2) and derived approximations for the others. In logf(), all the approximations made sense, but the approximation to sqrt(2)/2-1 was 2 ulps too small (a tiny amount, since we compare with a granularity of 2**32 ulps), so the algorithm was broken in 2 cases. The result was broken in 1 case. This is fixed by rounding up the approximation to sqrt(2)/2-1 by 2**32 ulps, so 2**32 cases are now handled a little differently (still correctly according to my assertion that the approximations don't need to be very accurate, but this has not been checked). |
Completed in 45 milliseconds