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

From: Jeff Garland (jeff_at_[hidden])
Date: 2002-09-03 16:32:23

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

Sorry, I missed the 'binary' part.  I was thinking yours would be a
replacement for Bill's rather than a similar library...

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

Actually I'm not sure I understand this reason either.  And for the most
part I'm not to worried about interoperation of decimals with different
scales.

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

Last I checked a 10X difference was still a big deal for some applications, 
but I'll concede that faster processors reduce the need for optimization in
some applications...

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

Thx, that clarifies the motivation...

Jeff