Subject: Re: [boost] Fixed point implicity
From: Neal Becker (ndbecker2_at_[hidden])
Date: 2009-07-02 08:25:11
> 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.
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk