Re: [PATCH] Fix for k_tan.c specific inputs
Corinna Vinschen via Newlib <[email protected]>
| Newsgroups | gmane.comp.lib.newlib |
|---|---|
| Message-ID | <[email protected]> |
On Mar 17 15:48, Fabian Schriever wrote: > This fix for k_tan.c is a copy from fdlibm version 5.3 (see also > http://www.netlib.org/fdlibm/readme), adjusted to use the macros > available in newlib (SET_LOW_WORD). > > This fix reduces the ULP error of the value shown in the fdlibm readme > (tan(1.7765241907548024E+269)) to 0.45 (thereby reducing the error by > 1). > > This issue only happens for large numbers that get reduced by the range > reduction to a value smaller in magnitude than 2^-28, that is also > reduced an uneven number of times. This seems rather unlikely given that > one ULP is (much) larger than 2^-28 for the values that may cause an > issue. Although given the sheer number of values a double can > represent, it is still possible that there are more affected values, > finding them however will be quite hard, if not impossible. > > We also took a look at how another library (libm in FreeBSD) handles the > issue: In FreeBSD the complete if branch which checks for values smaller > than 2^-28 (or rather 2^-27, another change done by FreeBSD) is moved > out of the kernel function and into the external function. This means > that the value that gets checked for this condition is the unreduced > value. Therefore the input value which caused a problem in the > fdlibm/newlib kernel tan will run through the full polynomial, including > the careful calculation of -1/(x+r). So the difference is really whether > r or y is used. r = y + p with p being the result of the polynomial with > 1/3*x^3 being the largest (and magnitude defining) value. With x being > <2^-27 we therefore know that p is smaller than y (y has to be at least > the size of the value of x last mantissa bit divided by 2, which is at > least x*2^-51 for doubles) by enough to warrant saying that r ~ y. So > we can conclude that the general implementation of this special case is > the same, FreeBSD simply has a different philosophy on when to handle > especially small numbers. > --- > newlib/libm/math/k_tan.c | 29 +++++++++++++++++++++-------- > 1 file changed, 21 insertions(+), 8 deletions(-) Pushed. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat
signature.asc
(application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAl5x5J4ACgkQ9TYGna5E T6CPTg/+JA3/3Y6QIFbRVPJS+mBXZQ9x9EEW50IzVvnqy7dz0y0jL8JGrW0hTJIN Yk2fz6HpZiaRARMgPy8Gnkzc9GmweVZE1iC4gQ9pYTijt4HnTmdOE/n0m9kBOwLd u0+bAekx163ddUcD6I/yxdFghB+vCGENVLpTpT6ColS8q6I2sO+iYAtboWjj8Vk5 Or3zsjC1O1RqIuuBepYOFR9H5V38NSN/z/7gMu4QCBwpJL3JF/6NMYKNnSPdcw65 6i356Del6HYLUgpRbQMiY4llDlmgTxDlOil944HVKuWM5jRwnHVdnY2gmNTXh+sW 9wZlk7h1ZLu9Dx1XQ2ofYabhMapuF9l340cnHEYxdrA9FIeLFNGQa0RUTtxBmvXr vhqs8mRp+v6rUzOsusfv0RqZ4Lmsn2d2dH4mFLklH5HPfVfdGg4Pg93zLUEl0hRN oRbf4MEHUwey+tU8yQsFyHCwmVkKc38Ooh9aMjl6Re7DP0SIXIAnaMNmzV/ErlNj ycgMSymfAKEGInRJlZt9HfTfJWGqXDMhchFdn7UMhb5dmW8c0QfDe677AkFsthON TS0R10xAlqCY+ANXBNm6uc1U/n3xerBIOW6IjZie9Wv10V/iYz/bGqHF8Hr1gbYC KmQv37n417pv4v5WvCTP5j/F/tftrggyebYJHsRFHNxnNVQGfYU= =j84g -----END PGP SIGNATURE-----