Subject: Re: [boost] [Review Request] Multiprecision Arithmetic Library
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2012-04-17 05:05:50
> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]] On Behalf Of
> Sent: Monday, April 16, 2012 8:52 PM
> To: boost_at_[hidden]
> 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
> design trade-offs.
> The limbs of cpp_dec_float are 32-bit unsigned integers, in each one of which 8 decimal digits are
> 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
> 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
> 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 A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk