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

Subject: Re: [boost] [Review Request] Multiprecision Arithmetic Library
From: Christopher Kormanyos (e_float_at_[hidden])
Date: 2012-04-16 16:03:54

> Here's what I think - firstly lets "Keep It Simple" - and if the digits

> are present in the internal representation, then why *shouldn't*
> they be used for comparisons and printing out?

Nod. I looked at a few possibilities today. But, as usual,
I had underestimated the difficulty.

> Let me give you an example - if there are guard digits which aren't
> used for comparisons - could you not get into a situation where two numbers>
> which compare equal lead to different results after some sequence
> of arithmetic operations?  IMO that would not be good, and at the
> very least could lead to all kinds of confusions.

> Consider what GMP's mpf_t does - there are hidden guard digits that you don't see,
> which do take part in comparisons and all arithmetic operations,
> on the other hand they don't provide a way to print those out
> which makes round tripping impossible - which IMO is very annoying.

> On the other hand, MPFR takes a much less loose approach,
> and rounds everything to *exactly* the requested precision after each step,
> round tripping is also possible in this case.

> The equivalent in cpp_dec_float would be to have no guard digits at all,
> and round after each operation to exactly Digits10 decimal places.
> While there may be use cases for that, I think we want to Keep It Simple
> for now and not go down that road.

This is too costly in base-10. If I (we) ever write another back-end,
base-2 might be a better way to go.

> So.... the situation we have now seems to be path of least resistance.
> It's somewhat inelegant having max_digits10 so much larger than digits10,
> but it seems to me that nothing really bad can happen here - just maybe
> that serialized numbers will occupy a touch more space on disk than expected?
> Cheers, John. 

You are right again. And if I keep fiddling around with it, then I'm just
wasting everyone's time. I designed the e_float back-end
(the basis of cpp_dec_float) and tested it for years with its present strategy.
I should just stop fiddling around and simply rely on the test suite
and adherence to the back-end requirements. And we are getting
very close to this, if not already there.

I think we're done with the digits10, max_digits10 thing now.

Thanks for your help.

Best regards, Chris.