Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 3 Nov 2013 09:48:22 +1100 (EST)
From:      Bruce Evans <>
To:        Steve Kargl <>
Cc:        "" <>, David Chisnall <>, Bruce Evans <>
Subject:   Re: MUSL math functions
Message-ID:  <>
In-Reply-To: <>
References:  <> <> <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Sat, 2 Nov 2013, Steve Kargl wrote:

> On Fri, Nov 01, 2013 at 07:52:27AM +1100, Bruce Evans wrote:
>> cerfl (not in C99) is apparently amazingly complicated.  There is a
>> whole library libcerf for it on the net.
> openlibm includes
> I haven't looked into the quality.  The webpage claims 13 significant
> digits, which is not quite good enough for double.

This might be the same (I remember the NOST web page and libcerf mentioning
something like Faddeev's algorithm).  I thought it was better.

>> erf support is very patchy in calculators.  See the list in the NIST
>> web pages that update Abramowicz and Stegun.  I find it hard to test
>> since it is not in pari.
> MPFR has implementations for erf and erfc.  Testing on flame is
> extremely slow due to this.  I think that I've only tested
> around 50000 values in the non-asymptotic range.

I hoped mpfr wouldn't be so (relatively) slow on flame (old/terminanal
sparc64).  pari does everything using fixed point so it doesn't notice
long doubles being slower.

Numerical integration of exp(-x^2) to give erf() is only 1000 times slower
than exp() in pari (5ms/call vs 5us/call for 28 decimal digits on freefall)
so it might be usable.  It is just ~100000 times slower than FreeBSD libm
erf().  gamma() is native and is 3 times slower than exp() in pari.


Want to link to this message? Use this URL: <>