Re: [boost] Fixed-Point Decimal Type

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-05-09 14:42:22

scleary_at_[hidden] wrote:

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

> If the above seems too extreme, just consider dividing by 10, and realize
> that an exact result can't be stored using a binary-encoded fixed-point
> number.  Do enough decimal calculations, and you'll eventually slip a digit.

        Fixed point representations do decimal point shifting
exactly. This is not the same as multiplication however.

        Consider:

        decimal<1>(1) * decimal<1>(1) // .1 * .1 = .01

Now, in theory, the result is

        decimal<2>(1)

which is exact. In practice, it has to be decided whether the result
should not be

        decimal<1>(0)

so one can write:

        z = z + z + z;

For division, of course, the result is unlikely to exact.
One can argue that division shouldn't even be allowed :-)
In fact, one can argue that multiplication shouldn't be allowed:
you can't muliply money by money!

> I'm not against fixed-point arithmetic; I just don't think it solves the
> problem.

        Fixed point arithmetic makes it easy to remember
where the decimal place is, when you are mainly doing accounting.
Accounting usually consists almost entirely of addition, subtraction,
and scaling.

> 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?]

        As someone with extensive COBOL experience, I can tell
you that my usual technique for handling decimals .. was to
immediately convert them to integers, and do all the real
work with integers. It was too hard to figure out all the
conversions, etc.

        Nevertheless, I think a decimal type is a good idea.
As Bill stated, too many people just use float to get
around the problem, when a long is a better solution.
A decimal type uses the right solution: and tracks the decimal
point using the type system. It's easier to handle rounding
problems with a decimal type than float, since with float
they occur when not expected in 'usual' operations like
addition. 

        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.

-- 
John (Max) Skaller, mailto:skaller_at_[hidden]
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net