Re: [boost] Fixed-Point Decimal Type

From: Greg Chicares (chicares_at_[hidden])
Date: 2001-05-20 19:56:31

Bill Seymour wrote:
> 
> Gabriel Dos Reis wrote:
> >
> > I think the ability of choosing rounding mode should not be
> > overlooked.  It is an essential part of LIA-1 and later standards.
> >
> and Beman Dawes responded:
> >
> > I'm convinced.
> >
> but I'm not sure that I am.  I'm under the impression that LIA-1
> relates more to numeric programming than to accounting.  If I
> hear from accountants that they care about multiple rounding
> modes, then I'll echo Beman's statement.

Well, I'm an actuary, not an accountant, but the two are probably
similar enough for this discussion. Here are part of the programming
specifications for one real-world life insurance policy in the US:

   quantity                           rounding

   Premium                            Nearest cent
   Death benefit                      Up to next whole dollar
   Minimum death benefit percentage   Up to next whole percentage
   Minimum premium                    Down to the next penny

I've omitted more than a dozen items, all of which are rounded to
the nearest cent or dollar--so 'round to nearest' is definitely the
predominant mode. Yet in some circumstances it's crucial to round
up or down, in order to comply with certain tax laws.

John Max Skaller wrote:
> Rounding is a property of the operation, NOT the operands.

Indeed. The example quoted above is confusing in that it portrays
rounding as a property of the result, when different types of
results may need to be stored in the same variable. (There are
two ways of calculating premium, but the insurance company can
write only one premium on your bill.) A better presentation is:

  premium0 = benefit0 * rate0, rounded to nearest cent
  premium0 = benefit0 / rate1, rounded down to next cent
  benefit0 = premium0 * rate1, rounded up to next dollar

Clearly 'premium0' cannot have any unique innate rounding mode.

The nature of 'rate1' requires
  division by rate1       --> round result up
  multiplication by rate1 --> round result down
  calculation of rate1 itself --> round result up
This behavior is required by law
  [ 'rate1' is this section of the tax code:
    http://www4.law.cornell.edu/uscode/26/7702.text.html
  subparagraph (d)(2) ]
so every life insurance policy in the US must follow it, and
violations can cost tens of thousands of dollars in penalties,
whether the error is pennies or a million dollars.

Since none of {round nearest, round up, round down, don't round}
can be assigned to any of these variables, rounding must be a
property of the operation, as John says.

John Max Skaller wrote:
>         Mixing is mandatory. A trivial example is:
> 
>         acc = acc + (principal[n] * rate[n])
> 
> where we use the bankers round for accumulation, and
> round down on the multiply: both by specification
> of business rules. You don't 'try out' these things
> to see what 'feels nice': you follow the business rules
> the accountant tells you to.

I use an equation like that every day. In my problem domain,
it's more simply

  acc = acc + (acc * rate[n])

where

  acc is integral cents,

  temp = acc * rate[n] must be rounded to nearest cent, and

  acc = acc + temp should involve no rounding

It's important to structure my calculations so that
rounding happens only on the operations that require it,
because run-time speed is critical and rounding is quite
expensive on a PC even with inline asm.