Sending again, this time including ghc-devs.

Edward Kmett <ekmett@gmail.com> writes:

> Note: From skimming your readme it is worth noting that  log1p _is_ in base
> now (alongside expm1, log1pexp, and log1mexp). We added them all a couple
> of years back as a result of the very thread linked in your README.
>
> You need to `import Numeric` to see them, though.
>
> Switching to more accurate functions for doubles and floats for asinh,
> atanh, etc. to exploit this sort of functionality at least seems to make a
> lot of sense.
>
> That can be done locally without any user API impact as the current
> definitions aren't supplied as defaults, merely as pointwise
> implementations instance by instance. Things will just become more accurate.
>
> In that same spirit, we can probably crib a better version for complex
> numbers from somewhere as well, as it follows the same general simplistic
> formula right now, even if it can't be plugged directly into the equations
> you've given. For that matter, the log1p definition we're using for complex
> numbers was the best I could come up with, but there may well be a more
> accurate version you can find down in the mines of libm or another math
> library written by real analysts.
>
[snip]
>
> So, here's a +1 from the libraries committee side towards improving the
> situation.
>
> From there, it's a small matter of implementation.
>
> Here's where I'd usually get Ben involved. Hi Ben!
>
Hi Edward and Matt!

Indeed the sinh sinh situation should already be improved in 8.6. See
#14927 and GHC commit 3ea33411d7cbf32c20940cc72ca07df6830eeed7. I
suspect this should fix Matt's issue.

Regarding log1p, I'd happily accept patches improving on the status quo.

Cheers,

- Ben
