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

Subject: Re: [boost] [review] Multiprecision review scheduled for June 8th - 17th, 2012
From: John Maddock (boost.regex_at_[hidden])
Date: 2012-06-06 04:10:52

>> On Tue, Jun 5, 2012 at 10:26 AM, John Maddock 
>> <boost.regex_at_[hidden]>wrote:
>>> 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.
>
> Actually, one could see it as a weakness of the library that so many of 
> the requirements are compulsory and not optional.

Actually, there isn't a huge list of compulsory requirements, and even then 
the term "compulsory" might need revising - maybe more like 
"non-synthesizable".   So if you want all of mp_number's documented 
operations to work, then you need to implement all of the 
"non-synthesizable" requirements.  However, for a type like a ring, you 
wouldn't implement eval_divide even though it's one of the "compulsory" 
requirements - the result would be that the divide operator for 
mp_number<my_ring> wouldn't instantiate, but everything else you've 
implemented would.

John.