RE: [boost] Fixed-Point Decimal Type

From: scleary_at_[hidden]
Date: 2001-05-09 15:08:22

> > Fixed-point arithmetic therefore shares several annoying 
> attributes with
> > floating-point arithmetic; as an extreme example, assuming a 4-bit
> > underlying representation (ignoring signs) with the implied 
> decimal in the
> > middle:
> >   0.1 + 0.1 != 0.2
> 
> 	This is not true for fixed point. Addition and subtraction
> are always exact (or overflow).

My apologies.  I thought you were recommending a fixed-point binary (not
decimal) type.  Not paying attention again...

> > If the intention is to help newbies by providing a class 
> that behaves like
> > "textbook" (i.e., decimal) algebra, I'd rather see a C++ 
> implementation of:
> >   http://www2.hursley.ibm.com/decimal/
> 
> 	This might be a good idea, but it is distinct from
> the proposal, according to my cursory reading that specification
> required arbitrary length numbers. The current proposal explicitly
> restricts the number of digits to a small value like 18.
> [Did I misread the IBM document?]

No, it doesn't require arbitrary length numbers; it's a proposal that can be
applied to different lengths.  For example, see the "Strawman proposal"
under the base specification -- it defines a single-precision (64-bit) and
double-precision (128-bit) floating-point decimal types.

The proposal also claims it can be applied to fixed-point decimal types, but
after just looking through it again, I don't see how this can be done -- it
looks like it would only apply to floating-point decimals -- sorry for the
misleading pointer.

> 	To put this another way, accountant types can
> deal with rounding problems on multiply/divide,
> because there are usual house/industry rules for it.
> Rescaling binary ints, or fudging floats, to obey these
> rules is likely to be very difficult and error prone.

Quoting from the IBM proposal:  "Exact results are given when mandated by
the rules of decimal arithmetic (for instance, 0.9 / 10 gives 0.09, not
0.089999996)", but, for example, 0.5 / 3 has no such guarantee.  I'd like to
see similar guarantees for your class -- that would at least help out users.

        -Steve