There seems to be also a rounding challenge in (/)/2. But I didn’t
provide a test case for that. My test case here was only for (**)/2.
What test cases do you have for (/)/2 ?
Rounding error in (**)/2
mpq_get_d_nearest adds some bits to the numerator to increase
precision. And uses modulo to determine whether HALF_EVEN can
round up and doesn’t need to consider the EVEN rule.
Roughly the algorithm does the following, so instead that it computes,
assuming a and b have already the same exponent
a // b
a*2^54 // b
And from this it determines the float mantissa, and uses an adjusted
exponent. Ater this it does the aforenentioned rounding, Possibly the
result of a / 1 is indeed some float(a) with HALF_EVEN, but its utterly slow!
Please be patient I will try to produce some test cases. In
the past ECLiPSe Prolog had the most precise rounding for (/)/2.
I already posted about this in comp.lang.prolog. But this was
a while ago. But I guess it is worth to investigate the same
again, and also do some counting testing, which gives a
statistical view of the precision. In my systems I use a
a / b which is bootstrapped from float(a) and float(b), those
float/1 implementations with HALF_EVEN rounding, and in
many cases it is on par with what ECLIPSe Prolog does.
Now lets look into SWI-Prolog as well.