Bug#572746: libm: sinf/cosf performance is awful on amd64
On 17.03.2010 14:36, Vincent Lefevre wrote:
On 2010-03-17 13:41:04 +0100, Giacomo A. Catenazzi wrote:
On 17.03.2010 11:29, Vincent Lefevre wrote:
On 2010-03-07 16:17:08 +0100, Aurelien Jarno wrote:
On amd64, only sincos has an optimized version,
It may be optimized, but completely buggy. For instance, on 1e22,
sincos returns 0.46261304076460174617 for the sine instead of
-0.85220084976718879499 (correctly rounded value). Even the sign
Sorry, but I don't see the error. Both are the correct values,
as any values from -1 to 1.
The double "1e22" is outside the *relevant* precision for double,
e.g. a whole range of 2*pi is described with the same number (1e22).
No, this is wrong. This could be correct with interval arithmetic,
but floating-point arithmetic works differently: inputs are
regarded as *exact*.
Are you sure?
From C standard (not really the standard, but the draft n1256:
22.214.171.124.2, point 5):
: The accuracy of the floating-point operations (+, -, *, /) and of
: the library functions in <math.h> and <complex.h> that return
: floating-point results is implementationdefined,
: as is the accuracy of the conversion between floating-point
: internal representations and string representations performed by
: the library functions in <stdio.h>, <stdlib.h>, and <wchar.h>.
: The implementation may state that the accuracy is unknown.
And also looking in POSIX, I find no further requirement,
so are you sure that 1e22 should be taken as exact.
So maybe the bug is to define __STDC_IEC_559__ on such case.
OTOH, section F9.1 don't require (my interpretation)
trigonometric to be IEC 60559 functions. It has such requirement
for more elementary functions, e.g. for sqrt (see section F3).
OTOH I think you are an expert on such standards, so
it is possible/probable that I'm completly wrong.