Boost logo

Boost :

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
> Kormanyos
> 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
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 A. Bristow,
Prizet Farmhouse, Kendal LA8 8AB  UK
+44 1539 561830  07714330204

Boost list run by bdawes at, gregod at, cpdaniel at, john at