Re: [boost] [Review Request] Multiprecision Arithmetic Library

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
Christopher
> 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
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
[phone]  07714330204
pbristow_at_[hidden]