
Boost : 
From: Jeff Garland (jeff_at_[hidden])
Date: 20020903 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk