<div dir="ltr">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 <a href="https://software.intel.com/en-us/articles/using-avx-without-writing-avx-code">here</a>:  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.<div><br></div><div>Cheers</div><div>George<br><div><br><div class="gmail_quote"><div dir="ltr">On Thu, Aug 2, 2018 at 5:19 PM David Feuer <<a href="mailto:david@well-typed.com">david@well-typed.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Wasn't there a very recent commit to improve these functions, by leftaroundabout?<br>
<br>
On Thursday, August 2, 2018 8:16:10 AM EDT Artem Pelenitsyn wrote:<br>
> Here is the patch: <a href="https://phabricator.haskell.org/D5034" rel="noreferrer" target="_blank">https://phabricator.haskell.org/D5034</a><br>
> <br>
> --<br>
> Best, Artem<br>
> <br>
> On Thu, 2 Aug 2018 at 06:26 Artem Pelenitsyn <<a href="mailto:a.pelenitsyn@gmail.com" target="_blank">a.pelenitsyn@gmail.com</a>> wrote:<br>
> <br>
> > I'd be willing to do this.<br>
> ><br>
> > --<br>
> > Best wishes,<br>
> > Artem<br>
> ><br>
> ><br>
> > On Thu, 2 Aug 2018, 04:38 Matt Peddie, <<a href="mailto:mpeddie@gmail.com" target="_blank">mpeddie@gmail.com</a>> wrote:<br>
> ><br>
> >> Thanks, Ben, for chiming in.  I think calling out to C for these<br>
> >> functions is the way to go if it's now feasible.  (Calling out to libm<br>
> >> is the workaround I'm using in the application that led me to discover<br>
> >> the inaccuracy.)<br>
> >><br>
> >> Matt<br>
> >><br>
> >> On Thu, Aug 2, 2018 at 11:33 AM, Ben Gamari <<a href="mailto:ben@smart-cactus.org" target="_blank">ben@smart-cactus.org</a>> wrote:<br>
> >> > Matt Peddie <<a href="mailto:mpeddie@gmail.com" target="_blank">mpeddie@gmail.com</a>> writes:<br>
> >> ><br>
> >> >> Hi George,<br>
> >> >><br>
> >> >> Not a stupid question.  I don't have a single source at hand, but I<br>
> >> >> think I read in a few places on the wiki that calling out to the<br>
> >> >> system math library is not an option due to the variety of system math<br>
> >> >> libraries on the platforms GHC supports.  It'd be great if I got the<br>
> >> >> wrong impression and this could just be a call to C.  Can anyone set<br>
> >> >> me straight on this point?<br>
> >> >><br>
> >> > Indeed it's not a stupid question at all. Indeed this is precisely what<br>
> >> > we do for the simpler transcendentals (e.g. sin, asin, log). We very<br>
> >> > well could move in this direction in the case of asinh/atanh as well. I<br>
> >> > believe the reason we don't currently is that atanh was only<br>
> >> > standardized in C99, which we only started requiring a few releases ago.<br>
> >> > Perhaps this is ultimately the right direction.<br>
> >> ><br>
> >> > Cheers,<br>
> >> ><br>
> >> > - Ben<br>
> >> _______________________________________________<br>
> >> ghc-devs mailing list<br>
> >> <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
> >> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
> >><br>
> ><br>
> <br>
<br>
<br>
-- <br>
David Feuer<br>
Well-Typed<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div></div></div></div>