Boost logo

Boost :

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??
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


Boost list run by bdawes at, gregod at, cpdaniel at, john at