On Wed, 14 Aug 2024 at 07:31, Joel Jacobson <j...@compiler.org> wrote: > > I think this is acceptable, since it produces more correct results. >
Thanks for checking. I did a bit more testing myself and didn't see any problems, so I have committed both these patches. > In addition, I've traced the rscale_adjustment -15 mul_var() calls to > originate > from numeric_exp() and numeric_power(), so I thought it would be good to > brute-force test those as well, to get an idea of the probability of different > results from those functions. > > Brute-force testing of course doesn't prove it's impossible to happen, > but millions of inputs didn't cause any observable differences in the > returned results, so I think it's at least very improbable to > happen in practice. > Indeed, there certainly will be cases where the result changes. I saw some with ln(), for which HEAD rounded the final digit the wrong way, and the result is now correct, but the opposite cannot be ruled out either, since these functions are inherently inexact. The aim is to have them generate the correctly rounded result in the vast majority of cases, while accepting an occasional off-by-one error in the final digit. Having them generate the correct result in all cases is certainly possible, but would require a fair bit of additional code that probably isn't worth the effort. In my testing, exp() rounded the final digit incorrectly with a probability of roughly 1 in 50-100 million when computing results with a handful of digits (consistent with the "+8" digits added to "sig_digits"), rising to roughly 1 in 5-10 million when computing around 1000 digits (presumably because we don't take into account the number of Taylor series terms when deciding on the local rscale). That wasn't affected significantly by the patch, and it's not surprising that you saw nothing with brute-force testing. In any case, I'm pretty content with those results. Regards, Dean
