On Friday 10 of February 2012 13:30:25 James Courtier-Dutton wrote: > On 10 February 2012 10:42, Andrew Haley <a...@redhat.com> wrote: > > On 02/10/2012 10:07 AM, Richard Guenther wrote: > >> > >> The issue with libm in glibc here is that Drepper absolutely does > >> not want new ABIs in libm - he believes that for example vectorized > >> routines do not belong there (nor the SSE calling-convention variants > >> for i686 I tried to push once). > > > > That's a good reason why we can't do this in glibc. I accept > > the point; it'll have to be GNU libm. > > > > Andrew. > > I think a starting point would be at least documenting correctly the > accuracy of the current libm, because what is currently in the > documents is obviously wrong. > It certainly does not document that sin() is currently more accurate > than sinl() on x86_64 platforms, even with -O0. > I think the documentation should be along the lines of for > Function name: sin(x) > -pi/2 < x < pi/2, accuracy is +-N > pi/2 < x < large number, accuracy is +-N > large number < x < max_float, accuracy is +-N > If a performance figure could also be added, so much the better. We > could then know that implementation 1 is quicker than implementation 2 > and the programmer can do the trade offs. > > And have the figures repeated for various options such as -ffast-math > etc, and also repeated for different CPUs etc.
it would be also nice to see functions for reducing argument range in public api. finally the end-user can use e.g. sin(reduce(x)) to get the best precision with some declared cpu overhead. > Once we have the documentation, we can then ensure, using automated > testing, that the libm actually performs as designed.
