Sending again, this time including ghc-devs. Edward Kmett <ekm...@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
signature.asc
Description: PGP signature
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
