Re: [boost] Re: Is there any Interest in a Fixed Point Library?

From: Kevin Atkinson (kevin_at_[hidden])
Date: 2003-02-27 11:18:53

On Thu, 27 Feb 2003, Jason House wrote:

> Kevin Atkinson wrote:
> > 
> > Is there any interest in a fixed point math library.  
> 
> Well, I'm interested in a fixed point library :)  
> Especially if it can be used as a template argument in place of a
> floating point type.

Thanks.

> > Using templates the
> > compiler can keep track of the radix point for you making using fixed
> > point math a lot less tedious and error prone.
> 
> One thought... It looks like the template parameter should be an integer
> type (of course, right?)...   I think that there is some way to cause a
> non integer type to generate a compiler error.  Of course, considering
> other types might have some value (ie. complex numbers, a double that
> overflows due to adding of large numbers?, and probably others that
> don't come to mind at the moment)

Be careful that you are not overly restrictive.  For example what about a 
class that supports very large integers.  What about a class that is a 
wrapper around an integers, such as one that is designed  to guarantee 
atomic operations, etc...

> > Attached is a rudimentary implementation which would work acceptably when
> > the exponent is not too large or too small.  If the exponent is smaller or
> > larger than the size of the underlying integer in bits this code will
> > likely behave badly.
> 
> I once had a bug that I ended up tracking down to assembly that relates
> to that...  Effectively shifting 32 bit numbers would cause a modulo 32
> on the shift amount.  The problem I had was that a case of shifting by
> 32 bits logically come up in my code... instead of clearing the number,
> it gave me the original number back!
> 
> I would have to assume that there is some kind of type trait that would
> help with enabling some kind of error check.  Even if it is just some
> kind of assert.  The fixed point to fixed point conversion is the most
> likely candidate for hitting this kind of a bug.  A base of 20 converted
> to a base of -15 would have a shift by 35...  (in effect, on my
> compiler/processor, that would only shift by 3)

Yes a check would be useful.  I think an assert to check the the shift 
size is not equal to or larger than the integer it is shifting in bits 
would work.  But what about an variable length integer class where the 
sizeof() operator won't work?

Also, please not that It IS possible to have a fixed point number with the
radix larger or smaller than the size of the integer in bits.  You just
have to be careful.  Some of my methods (like the frac one) also need to 
be written more carefully.

> > Comments on the code welcome.  I am not a numerical analysis specialist so
> > don't expect me to write a fixed point library for anything beyond simple
> > arithmetic.
> 
> 
> My comments are above...  Nothing on higher math functions :)
> 
> (Although, the conversion to double and back probably allows for the
> fixed point number to be used as a floating point number, and just cause
> higher math operations to operate on doubles, and then convert back.
> I believe that the code fragment "x = sqrt(x)" would compile fine.)

Yes, that would work.  But if your goal is to avoid floating point math
for speed (for a processor that doesn't have a FPU) than fixed point math
functions would be useful.  Of course the software emulation for the
floating point version of the math function may be just as fast.  I really
don't know.

> I think operators like += -= etc... would also be nice... they could
> actually be written to accept all bases, and possible be specialized for
> the same base...

Yes, I agree.  I just haven't written them.  Also currently 
  FixedPoint <operation> integer will not work since the compiler has no
clue what FixedPoint to convert the integers into.  Thus overloaded
operators where one operand is an integer (or for that matter double)
should also be written.

I did say it was rudimentary ;)

--- 
http://kevin.atkinson.dhs.org