This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rhettinger
Recipients mark.dickinson, rhettinger, serhiy.storchaka, tim.peters
Date 2020-08-15.18:37:31
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1597516651.7.0.426786448058.issue41513@roundup.psfhosted.org>
In-reply-to
Content
> Cheapest way I know of that "seemingly always" reproduces 
> the Decimal result (when that's rounded back to float) 
> combines fsum(), Veltkamp splitting, and the correction 
> trick from the paper.

That's impressive.  Do you think this is worth implementing?  Or should we declare victory with the current PR which is both faster and more accurate than what we have now?

Having 1-ulp error 17% of the time and correctly rounded 83% of the time is pretty darned good (and on par with C library code for the two-argument case).

Unless we go all-out with the technique you described, the paper shows that we're already near the limit of what can be done by trying to make the sum of squares more accurate, "... the correctly rounded square root of the correctly rounded a**2+b**2 can still be off by as much as one ulp. This hints at the possibility that working harder to compute a**2+b**2 accurately may not be the best path to a better answer".  

FWIW, in my use cases, the properties that matter most are monotonicity, commutativity, cross-platform portability, and speed.  Extra accuracy would nice to have but isn't essential and would likely never be noticed.
History
Date User Action Args
2020-08-15 18:37:31rhettingersetrecipients: + rhettinger, tim.peters, mark.dickinson, serhiy.storchaka
2020-08-15 18:37:31rhettingersetmessageid: <1597516651.7.0.426786448058.issue41513@roundup.psfhosted.org>
2020-08-15 18:37:31rhettingerlinkissue41513 messages
2020-08-15 18:37:31rhettingercreate