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

From: Jason House (jhouse_at_[hidden])
Date: 2003-02-27 10:25:52

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.

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

Is there an integer-based complex number class in existence in boost? 
If it supports >> and <<, then it could be used in the fixed point class
just as naturally as an integer type.  Of course the conversion to/from
double really doesn't make much sense...  So maybe there would be some
trouble...  I could imagine using some special coding tricks to make the
conversion normally be to double, but be a double precision complex
number class when an integer based complex number class is passed in... 
It's starting to sound more complicated to support complex numbers :( 
But all the requirements might already exist in boost :)

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

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

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

> 
> --
> http://kevin.atkinson.dhs.org
> 
>   ------------------------------------------------------------------------
>                 Name: fixed.hpp
>    fixed.hpp    Type: Plain Text (TEXT/PLAIN)
>             Encoding: 7BIT
> 
>   ------------------------------------------------------------------------
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost