Neal, Please excuse me if I'm widening the scope of the discussion too far. I use an internally developed fixed_point_10 class for financial work to combat base2 vs base10 representation issues (e.g. it is impossible to represent 0.10 exactly as a float, double or base2 fixed_pt). The implementation is fundamentally very similar to youf fixed_pt class, but instead of specifying frac_bits you specify frac_digits. Instead of using left/right shifts for scaling it multiplies/divides by a compile time calculated denominator based on frac_digits. It seems like it might be possible to extend your implementation to support both base2/base10, either by specifying an integer base to go along with frac_bits (mabye better named frac_places given the generic base) or by specifying the denominator directly (e.g. 10000 or 32768) intead of the bits/digits. Shift is probably faster than multiply/divide when the denominator is a power of 2. However, given a denominator known at compile time, the optimizer could (no guarantees) choose shifts. Allowing specification of base (or numerator) opens up oddball cases like base 3, etc. This could be constrained by a STATIC_ASSERT, or just allowed to be. Does fixed_pt_10 deserve to be its own class to allow fixed_pt to concentrate on the DSP crowd? I don't know, but I thought I'd throw it out while the discussion is still young. Also, I assume input/output stream operators will come when/if this library becomes a reality? Thanks, Paul Rose
Here is an improved version of fixed-pt, incorporating some of the suggestions given here: