Were you thinking of using glibc for better performance?
Marc
On Mar 29, 2019, at 5:26 PM, Bradley Lucier lucier@math.purdue.edu wrote:
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 _______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://mailman.iro.umontreal.ca/cgi-bin/mailman/listinfo/gambit-list