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

Subject: Re: [boost] [Review Request] Multiprecision Arithmetic Library
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-04-03 12:01:08

Le 03/04/12 13:13, Neal Becker a écrit :
> Vicente J. Botet Escriba wrote:
>
>> Le 02/04/12 10:53, John Maddock a écrit :
>>>> I'm wondering if the following compiles and what is the type of c
>>>>
>>>> mp_uint128_t a;
>>>> mp_uint256_t  b;
>>>> auto c = a + b;
>>>>
>>>>  From the documentation I have the impression that we can not mix
>>>> back-ends.
>>> Correct, it's a compiler error.
>>>
>>> Allowing mixed type arithmetic opens up a whole can of worms it seems
>>> to me, plus I don't even want to think about how complex the operator
>>> overloads would have to be to support that!
>>>
>>> So for now, if you want to conduct mixed arithmetic, you must
>>> explicitly cast one of the types.
>> Humm, casting seems to be not the good option for fixed point
>> arithmetic. The type of a fixed_point operation depends on the
>> quantization of its arguments.
>>
>> With fixed_point arithmetic the type of fixed_point<7,0>  +
>> fixed_point<8,0>  is fixed_point<9,0>. Note that no overflow is needed as
>> the resulting type has enough range.
>>
>> Another example
>>
>> fixed_point<10,2>  a;
>> fixed_point<2,3>  b;
>> fixed_point<2,2>  c;
>> auto d = (a + b) * c;
>>
> I have implemented my own fixed_point, and I debated whether the result of
> operations should automatically be a wider type.  In the end, I decided it was
> best to use explicit casting.  Explicit is better than implicit.  It's a bit
> more verbose, but I can live with that.
>
> Would you advocate that in C++, int8 * int8 ->  int16??
>
>
Hi,
I can not change C/C++. But why not do it for user defined types as a 
fixed point class? This avoids at least unexpected overflows while been 
efficient.

Vicente