-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Christopher Kormanyos Sent: Monday, April 16, 2012 8:52 PM To: boost@lists.boost.org Subject: Re: [boost] [Review Request] Multiprecision Arithmetic Library
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.
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.)
OK - thanks - so there is a valid reason why it 'feels untidy'. So we should stick with that and get the code out to the users. (Perhaps document in case anyone is curious/puzzled by the number of guard digits?) And anyone who wants less guard digits can always ask for digits10+3, say? Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com