This is getting pretty deep into the internals, but ...
I was thinking of replacing my implementation of ##cabs (complex
absolute value) in _num.scm with glibc's hypot. Turns out that ##cabs
(which is based on one of Kahan's papers) returns the correctly-rounded
answer more often than hypot (which Kahan also had a hand in): Here's a
count of how many times hypot and magnitude returned answers that were
off by between 1/2 and 1 ulp:
> (time (test 100000))
(n: 100000 hypot-errors: 12906 magnitude-errors: 4557)
(time (test 100000))
3.600013 secs real time
3.599883 secs cpu time (3.592672 user, 0.007211 system)
401 collections accounting for 0.047208 secs real time (0.047259
user, 0.000060 system)
1942508792 bytes allocated
no minor faults
no major faults
These shouldn't really be called "errors" just because they have
slightly bigger than optimal floating-point errors.
The correctly-rounded answers were computed using my computable reals
package.
I haven't yet compared computation speed, but it appears I'll leave
##cabs as is.
This is on Ubuntu 18.04 on x86-64.
Brad