Re: [boost] Fixed point implicity

Subject: Re: [boost] Fixed point implicity
From: Neal Becker (ndbecker2_at_[hidden])
Date: 2009-07-02 08:25:11

Ravi wrote:

> On Wednesday 01 July 2009 16:10:37 Soren Holstebroe wrote:
>> 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
> [snip more return type questions]
> 
> Given that both options (staying within the original widths and promoting
> to a larger width) are both valid (even crucial) in different contexts, it
> does not make sense to pick an option that would not let the user decide
> the meaning. Quoting from the zen of python: in the face of ambiguity,
> refuse the temptation to guess.
> 
> My preferred solution is to let the user decide. The return type of any
> expression has a bitwidth that completely allows for any values of the
> operands:
>   N + N -> N+1
>   N * N -> 2N
> The user can then assign it or cast it if necessary (for example, to
> minimize intermediate precision). Ok, but does this mean that precisions
> larger than some fixed bound (32-bit or 64-bit) must be provided? No. All
> that is needed is a compile-time error when instantiating a type with
> bit-width larger than 32 or 64. With a little bit of hackery, one can even
> return a proxy type that allows casting/assigning to an acceptable
> bit-width but provides a compile error for all other uses.
> 
...

I completely agree with the sentiment (explicit is better than implicit), 
but I would (and have) done it differently:

N @ N -> N.

If you want different, you cast the operands to wider field first.

BTW, if you are interested in policy-based round, etc, you might be 
interested in the code I posted.