I can't quite see why more than two or three guard digits should be needed? If we compare with thebuilt-in floating-point, then only two are needed from Kahan's formula even at 128-bit. So lots more sort of feels untidy?
Kahan is still the master of us all in float.
But John is right in saying that nothing too evil can happen from having too many. Paul
Hi Paul, Thanks for your insight. The cpp_dec_float back-end is based on my original design which did have some design trade-offs. The limbs of cpp_dec_float are 32-bit unsigned integers, in each one of which 8 decimal digits are present. However, the most significant limb and the second least significant limb can "slide" anywhere from 1...99,999,999. In addition, cpp_dec_float loses yet another limb during multiply because I only multiply half of the triangle and the carry from below simply gets lost. The digits in cpp_dec_float inherit these characteristics. They slide around within 3 extra limbs of slop, but do adhere to the requirements of the back-end and have fair performance at low precision. (We have discussed this at length.) I don't like the internal shifting and, if I ever write another big-float back-end, I will use base-2 and tight digit control such as that in MPFR. At times, I regret using base-10. Other times, when debugging, I'm glad to have it visible in recognizable form in the data array of limbs. Still, my next one (if there ever is such a thing) will be base-2. Thanks for keeping in touch, Paul. Best regards, Chris.