Re: [boost] fixed-pt [improved]

From: Paul Rose (prose_at_[hidden])
Date: 2008-08-01 11:07:21

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:
>