Boost logo

Boost :

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
  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).


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