Re: [boost] Re:(boost) Fixed point integer template library

From: Stephen Nutt (snutt_at_[hidden])
Date: 2002-09-02 08:36:46

Jeff, sorry it took so long to reply.

> Well, here's one to bounce.  Suppose we decide that Bill's proposal
defines
> the desired interface for fixed_decimals.  Perhaps your implementation
> idea, which seems to have potential, could be dropped into the current
> interface?

Sorry I'm not sure what you mean.  Are you suggesting extending
fixed_decimals to also handle fixed binary, or are you suggesting keeping
the interface the same, so as to simplify learning the class interface.

> However, just scanning Bill's new proposal, it looks like you are going
back
> to a proposal he has already rejected, that is 'scale' is fixed at
> compile time....

Bill rational for changing from a template to a non template class is as
follows
>In a previous version of the library, the decimal type was a class template
that
>took an int, the object's scale, as the only template parameter. This
allowed
>decimals of different scales to be different types; but it also required
them to be
>different types, thus increasing complexity (decimals of different scales
still had
>to inter-operate, thus requiring lots of member function templates) without
really
>buying any greater simplicity for the user (the scale still had to be
specified, just
>as a template argument instead of a constructor argument). The decimal
class is
>no longer a template.

It is not clear to me why it would have added lots of member functions.
Unless there is a compelling reason to avoid a template, my rational for
using one is both performance and to save the additional data member for the
following reason.

Today most CPU's come with high performance FPU's whose performance are
typically well within an order of magnitude to the CPU's integer arithmetic.
The once common use of fixed point arithmetic is now rapidly being replaced
with floating point arithmetic without noticable performance degradation.
However there still remains today several areas where fixed point arithmetic
prevails.
1) Exact decimal arithmetic.  Several domains today, most notably financial,
require exact decimal arithmetic.  Floating point arithemtic is inexact and
thus cannot be used.
2) Embedded CPUs.  These are frequently smaller low power CPUs that do not
come with built in FPU's.  While frequently fixed point arithmetic libraries
are available, they run a couple of orders of magnitude slower than integer
arithmetic.  Also typically performance and memory requirements are also a
consideration.
3) Number crunching.  As CPU's become faster people find more complex jobs
for them to perform.  Today CPUs are frequently used to perform highly CPU
intensive tasks that may involve many hours, days or even years of
calculations.  In these cases fixed point arithmetic is still the prefered
method as having an answer in half the time can make a huge difference.

Bill has very successfully implemented a solution for the decimal
arithmetic.  Neither speed nor memory are huge requirements for him as
financial applications will tyically run on anything from a desktops to a
mainframe.  What I am trying to solve is 2 and 3.

Stephen