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

Subject: Re: [boost] [Boost-users] [review] Multiprecision review scheduled for June 8th - 17th, 2012
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-05-31 02:34:06

Le 31/05/12 00:38, Simonson, Lucanus J a écrit :
> Vincente wrote :
> ...
>> * I think that the fact that operands of different backends can not be
>> mixed on the same operation limits some interesting operations:
> I agree, but supporting it comes with a lot of problems.
>
> ...
>> I think it should be possible to mix backends without too much
>> complexity and that the library could provide the mechanism so that
>> the backend developer could tell to the library about how to perform
>> the operation and what should be the result.
> That is assuming the backend isn't legacy.  We need to keep gmp in mind as being the example of a backend that needs to be supported.  Certainly the library could build a way to allow the user to specify the conversions, but that wouldn't be easy for the library or the user, nor would it be without problems.  If I want to mix backend A and backend B I have to provide specialization of some hypothetical library template for the conversion, but if someone else wants to mix backend A and backend B and does the same then we cannot coexist within the same compilation unit.  Forcing explicit conversion is both simpler and will make user code more clear because the types actually used in the operation will be explicit rather than requiring knowledge of how different mixes are handled by some code that is elsewhere and used implicitly.
>
> I see pluses and minuses to supporting mixed operations.
>
>
You are right in the context of multiple 3pp backends. My concern is 
more related to backends of the same 3pp. Maybe the library could add a 
family meta data associated to the backend.

For example, in the Boost.FixedPoint proposal I'm preparing you can add 
numbers that don't convert to each other, because they have a 
common_type on which the operation can be done. It would allow to add 
signed and unsigned ints with different precision

mp_number<cpp_int<10, true>,false> a;
mp_number<cpp_int<100, false>, false> b;

auto x = a+b;

I would expect this to work and to have the type of x be 
mp_number<cpp_int<100, true>,false> or even mp_number<cpp_int<101, 
true>,false>. The resulting type could default to the common_type but 
the library should be able to state a different result type.

By the way, the use of true and false on the preceding examples is not 
clear enough. As noted on the OP the user of enums could already help. 
In addition an enum for the sign could also be added.

mp_number<cpp_int<10, sign::signed>,expression_templates::disabled> a;
mp_number<cpp_int<100, sign::unsigned>, expression_templates::disabled> b;

What about defining a metafunctions basic_mp_number which disable 
expression templates

template <typename BE>
struct basic_mp_number {
   typedef mp_number<BE, expression_templates::disabled> type;
};

that can be used as

basic_mp_number<cpp_int<10, true>> a;
basic_mp_number<cpp_int<100, false>> b;

Best,
Vicente