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