Boost logo

Boost :

From: Mike Cowlishaw (MFC_at_[hidden])
Date: 2003-07-22 06:49:00


First, apologies for this late entry into this discussion.

Bill's fixdec library has some very nice features (the treatment of
rounding modes is especially interesting), but I am confused as to why
anyone would be proposing a fixed-point decimal library today.

The trend in decimal arithmetic for commercial applications has been
towards decimal floating-point (DFP) for many years now. For example:

  -- The Rexx language (ANSI X3.274-1996) implemented DFP in 1981 (the
     earlier Rexx arithmetic, very similar to that in the fixdec
     proposal, was soundly rejected by users)

  -- The Java BigDecimal class (1996) is floating-point. This is in the
     process of being extended to a much more comprehensive DFP though
     JSR-13 (see http://www.jcp.org/en/jsr/detail?id=13), which will be
     in Java 1.5

  -- The C# ECMA and ISO standard decimal type is DFP, derived from the
     1990 Visual Basic DFP currency class

  -- The COBOL ISO standard, approved last year, requires 32-digit DFP
     for intermediate results in its standard decimal arithmetic

  -- The IEEE 754 revision committee has added decimal formats (32, 64,
     and 128 bits) to the proposed new Floating-point standard, along
     with full DFP arithmetic.

The fixdec proposal as it stands is not compatible with any of these
implementations and standards, which will make interoperation with other
languages and applications both difficult and slow. All the major
databases, for example, support at least 31-digit DECIMALs.

Further, fixed-point decimal arithmetic, which effectively requires
manual treatment of scaling, is highly error-prone, and requires at
least 20 decimal digits precision to be reasonably general-purpose.
I would expect the fixdec class, with its non-commutative operators and
restricted precision, to be especially confusing and hard-to-use.

May I suggest that the class be changed to implement the proposed IEEE
754 arithmetic? This would be a tremendous contribution, and it could
even use the existing representation (perhaps expanded to 128 bits), or
it could use the proposed IEEE 754 layouts. The latter offers the
possibility of changing the class later to take advantage of the
hardware DFP when that becomes available.

Full details of the proposed IEEE formats and arithmetic, a reference
implementation in C, and thousands of testcases, can be found on my
website:

  http://www2.hursley.ibm.com/decimal/

A recent working draft of the revised IEEE 754 standard is available at:

  http://754r.ucbtest.org/

(note that the March draft there does not include the arithmetic; a more
recent one does, but is not yet on that website).

Mike

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Mike Cowlishaw, IBM Fellow
IBM UK (MP5), PO Box 31, Birmingham Road, Warwick, CV34 5JL, UK
mailto:mfc_at_[hidden] -- http://www2.hursley.ibm.com/decimal



Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk