[issue34376] Improve accuracy of math.hypot() and math.dist()

Tim Peters added the comment: Sure, if we make more assumptions. For 754 doubles, e.g., scaling isn't needed if `1e-100 < absmax < 1e100` unless there are a truly ludicrous number of points. Because, if that holds, the true sum is between 1e-200 and number_of_points*1e200, both far from

[issue34376] Improve accuracy of math.hypot() and math.dist()

Stefan Behnel added the comment: Could we maybe make an educated guess based on absmin and absmax whether scaling is needed or not? -- nosy: +scoder ___ Python tracker ___

[issue34376] Improve accuracy of math.hypot() and math.dist()

Serhiy Storchaka added the comment: I think that in most real cases (unless max is too large or too small) we can get rid of scaling at all. -- ___ Python tracker ___

[issue34376] Improve accuracy of math.hypot() and math.dist()

Tim Peters added the comment: Thanks for doing the "real ulp" calc, Raymond! It was intended to make the Kahan gimmick look better, and it succeeded ;-) I don't personally care whether adding 10K things ends up with 50 ulp error, but to each their own. Division can be mostly removed from

[issue34376] Improve accuracy of math.hypot() and math.dist()

Raymond Hettinger added the comment: Applied in: https://mail.python.org/pipermail/python-checkins/2018-August/156572.html Note, the BPO number was left off the checkin message. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed

[issue34376] Improve accuracy of math.hypot() and math.dist()

Raymond Hettinger added the comment: Retested using Tim's ulp(x) function (see attached script). The accuracy results are for 1,000 trials using 10,000 arguments to hypot() where the arguments are generated using triangular(0.999, 1.001) and arranged in the least favorable order,

[issue34376] Improve accuracy of math.hypot() and math.dist()

Raymond Hettinger added the comment: Here's a little more performance data that might suggest where possible speed optimizations may lay (I was mostly going for accuracy improvements in this patch). On my 2.6GHz (3.6Ghz burst) Haswell, the hypot() function for n arguments takes about

[issue34376] Improve accuracy of math.hypot() and math.dist()

Tim Peters added the comment: Not that it matters: "ulp" is a measure of absolute error, but the script is computing some notion of relative error and _calling_ that "ulp". It can understate the true ulp error by up to a factor of 2 (the "wobble" of base 2 fp). Staying away from denorms,

[issue34376] Improve accuracy of math.hypot() and math.dist()

Raymond Hettinger added the comment: > What results for all components equal? hypot(1.0, 1.0, ..., 1.0) The scaled summation will be exact (all elements scale to 1.0 and frac is always 0.0). > Would it give a performance benefit if get rid of multiplication > and division, and scale by the

[issue34376] Improve accuracy of math.hypot() and math.dist()

Serhiy Storchaka added the comment: Would it give a performance benefit if get rid of multiplication and division, and scale by the power of two approximation of the max using ldexp()? -- ___ Python tracker

[issue34376] Improve accuracy of math.hypot() and math.dist()

Serhiy Storchaka added the comment: What results for all components equal? hypot(1.0, 1.0, ..., 1.0) -- ___ Python tracker ___ ___

[issue34376] Improve accuracy of math.hypot() and math.dist()

Change by Raymond Hettinger : -- keywords: +patch pull_requests: +8211 stage: -> patch review ___ Python tracker ___ ___

[issue34376] Improve accuracy of math.hypot() and math.dist()

New submission from Raymond Hettinger : Apply two accuracy improvements that work well together and that are both cheap (less than 5% difference in speed). 1. Moving the max value to the end saves an iteration and can improve accuracy (especially in the case where len(args) <= 3 where the