Re: [boost] Fixed point integer proposal

Subject: Re: [boost] Fixed point integer proposal
From: Christian Schladetsch (christian.schladetsch_at_[hidden])
Date: 2009-06-25 18:41:43

Hello,

In fact, fixed point is not faster on many architectures than floating
point. One assumes that it is mainly PSP, DS and Gamecube guys that want
fixed-point just for speed these days (I'm looking at you, Kenny ;).

It was the case years ago that fixed-point was faster than floating-point,
but it is less commonly true now than conversely. Modern systems typically
have at least one if not many dedicated FPU's which can work in parallel
with the main ALU(s).

Similarly, it is often faster to use floating-point trig than fixed-point
trig. FPU trig is heavily optimised in micro-code and, perhaps surprisingly,
it is often faster to do trig on an FPU than break the cache with the table
lookup that is often used in fixed-point. And lastly, converting to and from
fixed- and floating-point is generally very slow.

Of course, I am referring mainly to embedded hardware systems like game
consoles, but I think in general the idea that fixed-point is faster is not
as true as it once was.

The reason for this preamble is  to make the case that the main reason for
fixed-point these days is accuracy and not speed. As has been noted in this
thread, fixed point is accurate and does not drift. This is not entirely
accurate (no pun intended), as there is drift in both fixed- and
floating-point, but fixed-point is generally more stable for things like
physics simulators.

Given that, I would vote for a fixed-point system that favored accuracy and
resolution over speed. Indeed, there is a case to be made for a so-called
"floating-fixed-point" system; I wrote one of these some time ago and it
helped a great deal with accuracy.

The basic idea is to use an N.M fixed-point format for numbers, and the
result of operations changed to a minimal N2.M2 format in order to preserve
accuracy.

Has anyone put forward a generalised arithmetic system that used
arbitrarily-sized "floating-fixed-point" values to allow for an arbitrarily
large (or arbitrarily small) number system? This would seem to me to be of
more value than a "fixed-fixed-point" system designed primarily for speed,
which has a dubious premise and has all the associated issues of accuracy
and operation result types.

Regards,
Christian.

On Fri, Jun 26, 2009 at 4:38 AM, Soren Holstebroe <holstebroe_at_[hidden]>wrote:

> > > 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
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>