Re: [boost] Fixed point implicity

Subject: Re: [boost] Fixed point implicity
From: Ravi (lists_ravi_at_[hidden])
Date: 2009-07-01 22:09:52

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.

That said, I am unlikely to use your library given your current interface. Any 
fixed-point library without policies allowing for choice in rounding vs. 
truncation and in saturation vs. wrapping would not meet my needs. Please see 
the fixed-point classes from SystemC for a reasonable interface (with rather 
poor implementation).

Regards,
Ravi