Re: [boost] [review] Multiprecision review scheduled for June 8th - 17th, 2012

Subject: Re: [boost] [review] Multiprecision review scheduled for June 8th - 17th, 2012
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-06-05 13:54:54

On Tue, Jun 5, 2012 at 10:26 AM, John Maddock <boost.regex_at_[hidden]>wrote:

> OK, clearly it's not a field I'm familiar with - for that reason I'd
>>> prefer not to be the one to write a backend for that - or at least I
>>> would
>>> need some considerable help - but I see no real obstacles to supporting
>>> such a type providing you don't want the transcendental functions.  If
>>> someone were willing to be the guinea pig, then it might make a good test
>>> case for seeing how easy it is for someone other than me to extend the
>>> library?
>>>
>>>
>> This is something I would be willing to contribute but probably not until
>> after the formal review.
>>
>
> Nod, thanks.  Also just realized that while a simple adapter backend:
>
> template <class BigInteger>
> class exact_float;
>
> Would be more or less trivial as far as the arithmetic goes, other stuff
> like string conversion would be *much* more complex, exactly which
> conversions and/or string formatting should be supported would require some
> careful thought.
>

Yes, agreed regarding the trickiness of string conversions :( I guess if
one doesn't want or need to implement such facilities, one could just throw
on such overloads. For many computational geometry applications, the inputs
are built-in floating point types, which I would imagine would be trivially
(or, at least, straightforwardly) convertible to the desired exact floating
point type, so string conversion may not be necessary.

- Jeff