[issue41513] High accuracy math.hypot()
Tim Peters
report at bugs.python.org
Sun Aug 30 01:22:04 EDT 2020
Tim Peters <tim at python.org> added the comment:
About test_frac.py, I changed the main loop like so:
got = [float(expected)] # NEW
for hypot in hypots:
actual = hypot(*coords)
got.append(float(actual)) # NEW
err = (actual - expected) / expected
bits = round(1 / err).bit_length()
errs[hypot][bits] += 1
if len(set(got)) > 1: # NEW
print(got) # NEW
That is, to display every case where the four float results weren't identical.
Result: nothing was displayed (although it's still running the n=1000 chunk, there's no sign that will change). None of these variations made any difference to results users actually get.
Even the "worst" of these reliably develops dozens of "good bits" beyond IEEE double precision, but invisibly (under the covers, with no visible effect on delivered results).
So if there's something else that speeds the code, perhaps it's worth pursuing, but we're already long beyond the point of getting any payback for pursuing accuracy.
----------
_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41513>
_______________________________________
More information about the Python-bugs-list
mailing list