The version of sinf() in sysdeps/ieee754/flt-32/ gives results that are wrong by more than 1 ulp for at least some inputs. The testcase below will demonstrate the problem for sinf(8.203124e-01). The output from this test on an x86_64 platform running RH Enterprise 3 is: inputs: a = 8.203124e-01 actual = 7.3135888576508e-01 (0x3f3b3a56) expected = 7.3135894536972e-01 (0x3f3b3a57) sin(a) = 7.3135894750029e-01 The sinf() result is 1 ulp smaller than the expected value, which is already slightly smaller than the real answer. Other math libraries derived from fdlibm (e.g., newlib) have the same problem. The test program is: #include <stdio.h> #include <math.h> unsigned int ta = 0x3f51ffff; main () { float a = *(float *)&ta; float c = sinf(a); float d = sin(a); printf("inputs: a = %e\n", a); printf("actual =\t%.13e\t(0x%08x)\n", c, *(unsigned *)&c); printf("expected =\t%.13e\t(0x%08x)\n", d, *(unsigned *)&d); printf("sin(a) =\t%.13e\n", sin(a)); }
Once somebody provides a better implementation we can use it.
We will not change this unless somebody provides a better implementation.
Also see gcc bug 34128 where g77 uses sin and gfortran uses sinf. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34128 sinf is grossly slower.
Still present, should be added to the testsuite.
There are many inputs give results that are wrong by more than 1 ulp for sinf() in sysdeps/ieee754/flt-32, and for cosf - also... I unintentionally attached my data to another tracker: http://sourceware.org/bugzilla/show_bug.cgi?id=5997 Summary is: Intel proprietary test system observed ~1.4 ulp errors on usual arguments, and observed total loss of accuracy on |x| > 1e30 for current glibc routines which use the flt-32 C implementations I've submitted a patch proposed new implementation which solves the issue for all architectures with SSE2 support and significantly improves performance. http://sourceware.org/ml/libc-alpha/2012-06/msg00624.html I intend submit a patch with x86_64 Sse2 implementation of sinf and cosf as well. New Asm versions, provided by Intel, are maximum 0.500121 ulp for sinf, 0.500573 ulp for cosf.
On Fri, 22 Jun 2012, liubov.dmitrieva at gmail dot com wrote: > I unintentionally attached my data to another tracker: > http://sourceware.org/bugzilla/show_bug.cgi?id=5997 > > Summary is: Intel proprietary test system observed ~1.4 ulp errors on usual > arguments, and observed total loss of accuracy on |x| > 1e30 for current glibc > routines which use the flt-32 C implementations Do those total-loss-of-accuracy failures appear on x86_64? If not, then you should file a new bug and put the data in that bug, rather than using this one, which is about x86_64 not 32-bit x86.
On Fri, 22 Jun 2012, joseph at codesourcery dot com wrote: > Do those total-loss-of-accuracy failures appear on x86_64? If not, then > you should file a new bug and put the data in that bug, rather than using > this one, which is about x86_64 not 32-bit x86. I can reproduce problems on x86_64, although with different bad results from x86. But, you should still file a *new* bug for these problems, since it seems quite clear that the range-reduction-accuracy problems can sensibly be fixed separately from the not-correctly-rounded issues this bug is about. In general, unless it is clear that two issues can only sensibly be fixed together, they should have *separate* bugs filed; always err on the side of filing duplicate bugs rather than confusing an existing bug with something that might not be fixed together with the originally reported issue.
I've filed bug 14283 for the cases of large errors. Please keep this bug for the matter of results that, although not correctly rounded, are within the general range (< 10 ulp) of errors recorded in libm-test-ulps files.
Collecting all reports of few-ulps errors together in one meta-bug. *** This bug has been marked as a duplicate of bug 14759 ***