Re: accuracy of asinh and atanh

I believe there was but IMHO calling the libm library function is the better solution, as discussed in the previous emails below. Less maintenance, less testing, and possibly better performance, e.g. as explained here https://software.intel.com/en-us/articles/using-avx-without-writing-avx-code: the C compiler used to produce libm may generate appropriate 128 and 256-bit Intel AVX VEX-encoded instructions, generating multiple, processor-specific, auto-dispatched code paths when there is a performance benefit. The most appropriate code would be executed at run time. Cheers George On Thu, Aug 2, 2018 at 5:19 PM David Feuer wrote:

Wasn't there a very recent commit to improve these functions, by leftaroundabout?

...

Here is the patch: https://phabricator.haskell.org/D5034

-- Best, Artem

On Thu, 2 Aug 2018 at 06:26 Artem Pelenitsyn wrote:

...

I'd be willing to do this.

-- Best wishes, Artem

On Thu, 2 Aug 2018, 04:38 Matt Peddie, wrote:

...

Thanks, Ben, for chiming in. I think calling out to C for these functions is the way to go if it's now feasible. (Calling out to libm is the workaround I'm using in the application that led me to discover the inaccuracy.)

Matt

On Thu, Aug 2, 2018 at 11:33 AM, Ben Gamari wrote:

...

Matt Peddie writes:

...

Hi George,

Not a stupid question. I don't have a single source at hand, but I think I read in a few places on the wiki that calling out to the system math library is not an option due to the variety of system math libraries on the platforms GHC supports. It'd be great if I got

On Thursday, August 2, 2018 8:16:10 AM EDT Artem Pelenitsyn wrote: the

...

...

...

...

...

wrong impression and this could just be a call to C. Can anyone set me straight on this point?

Indeed it's not a stupid question at all. Indeed this is precisely what we do for the simpler transcendentals (e.g. sin, asin, log). We very well could move in this direction in the case of asinh/atanh as well. I believe the reason we don't currently is that atanh was only standardized in C99, which we only started requiring a few releases ago. Perhaps this is ultimately the right direction.

Cheers,

- Ben

---

ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-- David Feuer Well-Typed _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs