
Boost : 
From: Kevin Atkinson (kevin_at_[hidden])
Date: 20030227 20:23:27
On Thu, 27 Feb 2003, Paul A. Bristow wrote:
> Yes  this looks potentially rather useful for some tasks, especially embedded
> systems.
> Why on earth didn't the language include fixed point and/or fractional types?
Well in order for fractions to be really useful, that is to support exact
values for basic arithmetic, you would also need a arbitrary size integer
class as the numerator and denominator can get very large very fast unless
the fraction is automatically reduces after each operation and even than
the numbers can get big.
> As you observe, the increased accuracy compared to float (just a little too
> small for some measurements like weights) but with half the memory of double,
> and of course the integer/binary nature are sometimes useful.
I am curious why you say a float is "just a little tool small for some
measurements like weights". I have always used doubles, but I never put
much thought into it.
> Do you have any test programs?
>
> Have you made any comparison with float and double speeds?
No. However in general fixed point math is comparable to speed to
floating point math on systems with a good FPU. However, you might gain
some speed when most operations or integer based and a floating point
number is only used occasionally (say for taking an average) as you would
save cycles on the conversion from an int to a floating point number.
Of course, fixed point is extremely useful on FPU less systems and the
speed up will be substantial. However, my library lacks fixed point
versions of the basic math functions (sqrt, exp, sin, etc...), making it
of limited usefulness speed wise on a FPU less system. If someone knows
of a C library that provided these routines I might consider porting it.
Also, When using fixed point math you might lose some precision (if going
from a double to a 32 bit fixed point number as a 64 bit would be too
slow).
>
> HTH to encourage you.
>
> Paul
>

http://kevin.atkinson.dhs.org
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk