Re: [boost] Fixed point implicity

Subject: Re: [boost] Fixed point implicity
From: Soren Holstebroe (holstebroe_at_[hidden])
Date: 2009-07-02 14:51:39

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

My worry is that a N32 * N32 operation giving an out of bits compile
error would be really annoying in many scenarios (assuming 64 bit is
not allowed or considered a performance killer). Perhaps the best
would be to make the return type as a trait, but we would still need a
convenient default behavior.

I think it is important to understand all common usage scenarios and
how likely they are to judge if some behavior has least surprise.

I have used a fixed point template in a couple of scenarios.
The most simple is just as a convenient conversion of external data.
For example sound stream input in 32:28 signed fixed point, DSP filter
in floats and output in 16:16 signed fixed point. In that scenario I
didn't use any arithmetic, so the fixed template was mostly for a
convenient easy maintainable notation.

In another scenario I replaced a rather complicated float based image
processing algorithm with a fixed point to gain speed. In that
scenario arithmetic and comparison was used. Some error margin was
acceptable so the most important issue was seamless type replacement
without having to add casts and conversions to the existing code base.

In yet another scenario I used fixed points in high performance
computer graphics, where a fixed point type was not relevant since I
used MMX assembly for maximum performance.

My point is that, while a boost template should be general purpose,
there are some usages that are more relevant than other and some where
a general purpose library just doesn't do the job anyway.

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

Rounding, etc. is another discussion. I agree that a fixed point
should have optional policies for rounding, but I kept rounding and
saturation out of the operator discussion to keep it simple.

Soren