From: Stephen Nutt (snutt_at_[hidden])
Date: 2003-03-01 13:42:05
The classes still need much work (read as not fully implemented and full of
bugs etc). They compiler under MSVC++ 6.0 but you may find that you need to
add the following typedefs to get it to compile.
typedef unsigned __int64 uintmax_t;
typedef __int64 intmax_t;
fixed_integer.hpp defines the template fixed. This contents of this should
be fairly simple to follow.
fixed_math.cpp simply contains a templated routine to calculate fixed point
fixed_math.hpp contains the template class fixed_math plus lots of helper
classes. The public interface contains the following
A couple of helper methods exist to handle large multiplications and
divisions without loss of precision. The methods can be rather large, but
most of the information is known at compile time. So for example the
implementation of multiply is
static inline result multiply (const IntegerType1 multiplier, const
BOOST_STATIC_CONSTANT (int, mshift = FractionalBits1 + FractionalBits2 -
BOOST_STATIC_ASSERT (mshift >= 0);
if (std::numeric_limits<unsigned int>::digits >= traits::digits + mshift
return (static_cast<signed int> (multiplier) * multiplicand) >> mshift;
return (static_cast<unsigned int> (multiplier) * multiplicand) >>
if (std::numeric_limits<unsigned long>::digits >= traits::digits + mshift
return (static_cast<signed long> (multiplier) * multiplicand) >>
return (static_cast<unsigned long> (multiplier) * multiplicand) >>
if (std::numeric_limits<uint64_t>::digits >= traits::digits + mshift +
return (static_cast<int64_t> (multiplier) * multiplicand) >> mshift;
return (static_cast<uint64_t> (multiplier) * multiplicand) >> mshift;
return full_multiple (multiplier, multiplicand);
a good compiler should detect the only possible case and compile that line
in with the required constants.
Then there is a template to perform either saturated or non saturated math.
This would need changing if it were thought necessary to add another set of
methods that would throw an exception on overflow/underflow. (I did not
consider this at time of first writing.)
The biggest ugly mess in my mind is the shift template. This turned out to
be over half the file. The idea of it was to maximise compile time
knowledge of how to shift an integer, so the produced code would be as
efficient as hand coded shifts. Not sure what happened here, so I'll have
to take another look.
I'll try and do some more cleanup tomorrow or early in the week.
----- Original Message -----
From: "Kevin Atkinson" <kevin_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Saturday, March 01, 2003 12:03 AM
Subject: Re: [boost] Is there any Interest in a Fixed Point Library?
> On Fri, 28 Feb 2003, Stephen Nutt wrote:
> > Kevin,
> > I started on this must be close to a year ago, and I got wrapped up with
> > other stuff and never got back to it.
> Well I don't have a large interest in it beyond simple arithmetic. The
> main reason that I wrote is to avoid having to deal with portably sending
> floating point numbers over the network. With integers all I have to
> worry about is endian order.
> > One nifty option was to specify what would happen on overflow. There
> > two choices. Either the number would not overflow but go to its limit,
> > it would overflow in the 'expected' way.
> Yes I know what you mean. The problem is doing it efficiently.
> > fixed <int, 6> a = val1;
> > fixed <char, 3> b = val2;
> > fixed <long, 9> = a + b;
> > without loss of precision.
> Can you post the implementation?
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk