This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: RFC: removing slow paths in various dbl-64 libm functions
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- Cc: Carlos O'Donell <carlos at redhat dot com>, Anton Blanchard <anton at au1 dot ibm dot com>, <libc-alpha at sourceware dot org>
- Date: Wed, 2 Dec 2015 00:47:36 +0000
- Subject: Re: RFC: removing slow paths in various dbl-64 libm functions
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1511261736421 dot 10502 at digraph dot polyomino dot org dot uk> <5657D3A5 dot 5090005 at redhat dot com> <20151130230324 dot 3dd0c293 at kryten> <565D24D0 dot 70804 at redhat dot com> <565DCE3E dot 7070307 at arm dot com>
On Tue, 1 Dec 2015, Szabolcs Nagy wrote:
> (low precision libm cannot solve this completely as the general
> bessel functions will take an enormous time depending on the n
> argument:
>
> double yn(int,double);
> int main(){return yn(1e9,1e9);}
>
> will dos gcc when it tries to eval yn at compile-time,
> but for other math functions than yn,jn a low time
> bound can be guaranteed for all inputs.)
A good implementation of cpow (i.e. following glibc's normal accuracy
goals; see bug 14473; ISO C explicitly intends to allow less good
implementations along the existing lines as cexp (y * clog (x))) will
require multiple-precision computation of log and atan2 to over 16000
places in some cases. The time can be bounded, but the bound may not be
that low.
--
Joseph S. Myers
joseph@codesourcery.com