[boost] Fixed point implicity

Subject: [boost] Fixed point implicity
From: Soren Holstebroe (holstebroe_at_[hidden])
Date: 2009-07-01 16:10:37

Hi,

I'm generalizing my fixed point class and have come across a few
design decisions.

1. Return type of additive arithmetic operation between integers and
fixed points

Example: a 16 bit integer is added to a 16 bit fixed point with 8 bit fraction.
I see three possible return types: 16 bit integer, 16:8 fixed point
and promoted 32:8 fixed point
If return type is 16 bit integer, the fraction is lost. Clearly not an option.
If return type is 16:8 fixed point overflow is possible.
A return type of 32:8 would eliminate overflow, but promotion quickly
becomes problematic for larger integer types, lets say a 32 bit
integer added to a fixed point. In that case we would need a 64 bit
integer which could cripple performance on many systems.
Another problem with promotion is that the arithmetic expression
typically would be in a context where the expression is assigned to a
fixed point of the type present in the expression. In that case we
have an overflow problem again.

I think I favor keeping the return type in 16:8. The user would then
have to use an explicit cast to avoid overflow.

2. Return type of additive arithmetic operation between float and fixed points

Example: fixed_point<int, 16>(10.5) + 5.5f  (integer is representing
type, 16 bit is the bit reserved for the fraction)
What would you expect the return type to be?
I think I favor returning a float. The accuracy of the fixed point is
compromised anyway.

3. Return type of additive arithmetic operation between different
fixed point types
Example: fixed_point<int, 16>(10.5) + fixed_point<int, 8>(10.5)
Like in case 1 there is the choice between losing precision, risking
overflow or promoting (ex. to fixed_point<boost::int_t<16 + 8>::fast,
16>)

I think I favor to simply disallow implicit arithmetic between
different fixed point types. This would require the user to cast
either type. The problem with that choice is less transparent use of
the fixed_point type, since changing a type could break existing code
where the previous type was in a valid arithmetic operation with
another fixed point type.

4. Similar problems exist for multiplication and division
If a fixed_point is multiplied with an integer there is a risk of overflow.
If a fixed_point is multiplied with another fixed_point there is a
risk of overflow and precision will be lost.
If a fixed_point is divided by an integer there is a risk of loss of precision.
If a fixed_point or integer is divided by another fixed_point there is
a risk of overflow and loss of precision.

Soren