Re: [boost] Fixed point integer proposal

Subject: Re: [boost] Fixed point integer proposal
From: Soren Holstebroe (holstebroe_at_[hidden])
Date: 2009-06-25 12:38:57

> > Some years ago I wrote a fixed point template for transparent fixed point
> > integer arithmetics and conversion.
>
> To me, "fixed point" => !"integer".

Obviously fixed point is not an integer in mathematical sense. What I
meant was that a fixed point represented by an integer shares some of
the same computational properties:
Arithmetic is faster than floats on most architectures.
Adding (and accumulating) fixed points or multiplying by an integer is exact.
Conversion to integer is fast.

> particular, saturating or otherwise detecting overflows seemed to be
> required.

Saturation and overflow detection can be specified as a policy.
For me there are two important design criteria:
1st priority is that computational performance matches integer performance.
2nd priority is that it is possible to make a seamless float type and
the fixed point type exchange.

Adding saturation handling and overflow checks, that are not natively
supported by the underlying integer is of lower priority for me.
In my fixed point class I implemented overflow check as an optional
policy. That way you can add all the overhead checks you want in your
debug configuration and strip it in your release build.
As of saturation  (I assume it's computer graphics people that want
that feature) it should be straight forward to implement that as a
policy too in the same way as the overflow check.
In my option I see little practical use of a saturation policy.
Saturation code would kill performance and people would be better off
using MMS registers for native saturation.

> recall that someone was actually working on that.  It was also
> suggested that I ought to provide all of the features that <cmath>
> provides for floating point.

It makes sense to support rounding, abs and mod.
I don't see a practical need to natively support trigonometry
functions. A conversion to float and back has to be fine.

Soren