Oh, please note that the error that I'm talking about is the comparison with the result obtained before and after the simplification. It is possible that the result obtained after the simplification be more precise when compared to an arbitrary precise value (example, a 30 digits precise approximation). Well, I will try check that.
But yes, with regard to compatibility this may be a problem. On Wed, Oct 17, 2018 at 6:42 PM Jeff Law <l...@redhat.com> wrote: > > On 10/17/18 3:25 PM, Giuliano Augusto Faulin Belinassi wrote: > >> Hmm, do we have problems as we get close to -1 or 1 where the outputs of > >> the two forms might diverge? > > > > Well, I did some minor testing with that with input x around nextafter(1, > > -1); > > There are a minor imprecision when comparing directly with > > sinh(atanh(x)) and cosh(atanh(x)). > > * On 32-bits floats, for such x the error is about 10^-4 > > * On 64-bits floats, for such x the error is about 10^-7 > > * On 80-bits floats, for such x the error is about 10^-9 > > > > here are the code that I used for the test: https://pastebin.com/JzYZyigQ > > > > I can create a testcase based on this if needed :-) > My gut instinct is those errors are too significant in practice. > > It also just occurred to me that we may have problems as X approaches X > from either direction. > > Clearly when x^2 is indistinguishable from 0 or 1, then the result has > to be +-0 or +-1. But I'm not sure if figuring out where those points > are is sufficient to avoid the imprecisions noted above. This is *well* > outside my areas of expertise. > > jeff
