In article Frr@world.std.com, miket@world.std.com (Michael Trachtman) writes:
>
>My problem is that I have to represent amounts ranging from
>$ .0001 (100ths of a penny) through 100,000,000,000 (100 billion) dollars.
>To do this in integer requires about 43 bits of accuracy.
>I.e. the ratio of the smallest number to the largest is about 1000 ^ 4.x.
>It takes about 10 bits for each power of a thousand. (2 ^ 10  ~= 1000).
>
>Regular integers, even the 32 bit kind won't work. Double precision
>floating point will, however there will be roundoff error.
>
>For accounting purposes, we have to match things exactly to the
>accounting system. Thus, we need either 64 bit integers
>or BCD, or some other arbitrary precision representation,
>that guarantees at least  16 digits or so of decimal accuracy.
>
[...cut...]
I briefly remember reading two articles that could be a solution to your
problem and may be of wide-spread use to others.  Although the solutions
are not written in C++, one could very easily design C++ classes to
encapsulate the implementation.  The following articles are in
Dr. Dobb's Journal issue #256, January 1995.

 Article: Using the Multiple-Precision Library
 Author: John Rogers
 Comment: "Although the multiple-precision (MP library is
 available for many systems, it has never been fully documented.
 John provides hints, tips, and sample code for using this high-
 performance numeric library."

 Article: Basic Arithmetic with Infinite Integers
 Author: Jeffrey W. Hamilton
 Comment: "Jeff describes how to implement an efficient method for
 representing infinite integers and algorithms for doing simple
 arithmetic with infinite integers."

Code is available via anonymous FTP from site ftp.mv.com (192.80.84.3)
in the /pub/ddj directory.

Hope this helps!

If anyone creates a C++ class or classes based on the above articles, please
share them with the rest of us!

 ---------------------------------------------------------------------
|  James Scalio             |  Whose word is it?  That's right; mine! |
|  james.scalio@att.com     |                                         |
 ---------------------------------------------------------------------

In article <D1pB3B.Eyo@world.std.com>, Michael Trachtman (miket@world.std.com) writes:
>Will C++ ever have a standard set of types and operations for
>packed decimal based numbers ?

There are no packed decimal proposals pending, so there is
virtually no chance the Standard C++ Library will have such
classes this time around.  There will be another chance in five
years when the standard gets updated.

>Such a set of types would be useful for writing base 10, arbitrary
>precision, penny accuracy (i.e. no floating point round off errors)
>programs.

Yes, they are very useful for accounting applications.  A proposal
for standardization would have to deal with internationalization
issues, if any.

>
>The standard would not have to give the implementation.
>It would just give the class declaration together with a sample
>implementation. This would not require new keywords, since it would
>be a class library. However, a compiler vendor would be free
>to implement it internally, and generate high quality assembler
>on those machines that have hardware support for Packed decimal.

Yes, the standard specifices behavior not implementation for
library classes.

It would be a lot easier to get such a packed decimal (or
similar) class standardized in the future if there was "existing
practice".  So consider making such a class widely available with a
reasonable implementation.  If programmers found it useful, it
would give any future standardization proposal a head start.

-- Beman    (beman@dawes.win.net)

Will C++ ever have a standard set of types and operations for
packed decimal based numbers ?

Such a set of types would be useful for writing base 10, arbitrary
precision, penny accuracy (i.e. no floating point round off errors)
programs.

The standard would not have to give the implementation.
It would just give the class declaration together with a sample
implementation. This would not require new keywords, since it would
be a class library. However, a compiler vendor would be free
to implement it internally, and generate high quality assembler
on those machines that have hardware support for Packed decimal.

Michael T.

miket@world.std.com (Michael Trachtman) writes:

>Will C++ ever have a standard set of types and operations for
>packed decimal based numbers ?

>Such a set of types would be useful for writing base 10, arbitrary
>precision, penny accuracy (i.e. no floating point round off errors)
>programs.

>The standard would not have to give the implementation.
>It would just give the class declaration ...

So far as I know, no one has ever submitted a proposal for such
a type or class. At this late date, it seems unlikely that it could
be included in the standard.

If it is as useful as you believe, you now have an opportunity to
become rich and famous: implement and sell such a class library!

(I'm quite serious. A number of companies do very well selling
specialized class libraries.)
--
Steve Clamage, stephen.clamage@eng.sun.com

In article <D1pB3B.Eyo@world.std.com> miket@world.std.com (Michael Trachtman) writes:
>Will C++ ever have a standard set of types and operations for
>packed decimal based numbers ?

 A "very long int" (class or built in type) would be more useful
don't you think? I suppose "long double float" can do the job these days.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article <D1pB3B.Eyo@world.std.com>,
Michael Trachtman <miket@world.std.com> wrote:
>Will C++ ever have a standard set of types and operations for
>packed decimal based numbers ?

The great thing about C++ is that you can write your own type
-- or buy it from anybody who did.  [plug alert:] Rogue Wave Software
(e.g.) offers such a library, called "Money.h++".

>Such a set of types would be useful for writing base 10, arbitrary
>precision, penny accuracy (i.e. no floating point round off errors)
>programs.

> ... However, a compiler vendor would be free
>to implement it internally, and generate high quality assembler
>on those machines that have hardware support for Packed decimal.

It is a common misconception that more accurate computation is possible
in BCD than in binary.  In fact, the only advantage that I know of for
BCD is that conversion to and from ASCII is quicker.  [Er, and that
the Pentium bug doesn't affect you :-)]

Any package can be optimized for any given compiler (given asm {}
support) without imposing a requirement for such support on every
implementation.  In environments where such a package is popular
one could ask one's library vendor to do it, without any help from
an overburdened standards committees.

Generally, IMHO we are better served by asking the committee for better
support for library writing, than for features that can already be
implemented (more or less well) in a library.  That way you will see
more and better libraries to choose among, including those you forgot
to have standardized.

Nathan Myers (speaking personally, but employed by...)
Rogue Wave Software

In article <3e85tg$l30@engnews2.Eng.Sun.COM>,
clamage@Eng.Sun.COM (Steve Clamage) wrote:
> miket@world.std.com (Michael Trachtman) writes:
>
> >Will C++ ever have a standard set of types and operations for
> >packed decimal based numbers ?
>
> >Such a set of types would be useful for writing base 10, arbitrary
> >precision, penny accuracy (i.e. no floating point round off errors)
> >programs.

> If it is as useful as you believe, you now have an opportunity to
> become rich and famous: implement and sell such a class library!

Rogue Wave has a set of MONEY classes for just this. Works pretty well.

Vince
=====

>It is a common misconception that more accurate computation is possible
>in BCD than in binary.  In fact, the only advantage that I know of for
>BCD is that conversion to and from ASCII is quicker.  [Er, and that
>the Pentium bug doesn't affect you :-)]

Writing in BCD does keep you from getting some roundoff errors that occur
when you change $1.24 into a base 2 representation.  People use BCD in
financial calculations to make sure that the pennies always add up.

Incidentally, Borland C++ has included a bcd type for several years now,
complete with source.

+--------------------+------------------------------------------------+
| crayton@delphi.com | I have come to chew bubble-gum and kick butt,  |
| Team OS/2          | and I'm all out of butt.  -- Crow T. Robot     |

>>It is a common misconception that more accurate computation is possible
>>in BCD than in binary.  In fact, the only advantage that I know of for
>>BCD is that conversion to and from ASCII is quicker.  [Er, and that
>>the Pentium bug doesn't affect you :-)]

In article <95010300005913.DLITE.crayton@delphi.com>,
Chris Crayton <crayton@delphi.com> wrote:
>Writing in BCD does keep you from getting some roundoff errors that occur
>when you change $1.24 into a base 2 representation.  People use BCD in
>financial calculations to make sure that the pennies always add up.

This is *exactly* the misconception I was referring to.  If you represent
money in terms of a count of pennies, floating point arithmetic is as
exact as BCD (modulo Pentium, as always), and a damn sight faster!

This technique is as old as computing -- John von Neumann mentioned
it in his paper that established the industry (the same one where he
mentioned virtual memory), back in '47 or '48.  [Has anybody got a
reference for that?]

I say again, the only advantage of BCD is faster ASCII conversions.

RWS's Money.h++ has types that use each of double floating point,
64-bit integer, and BCD representations.  All are equally accurate
(modulo pentium) but the floating point-based type is fastest by
an order of magnitude.  (The BCD type is included merely because some
people just *can't* believe that binary calculations can be precise!
Superstitious people spend money too. :-)
[To be fair, BCD file representations are still fairly common,
 and providing conversions is worthwhile.]

Nathan Myers

In article <D1pB3B.Eyo@world.std.com>
Michael Trachtman <miket@world.std.com> writes:
>Will C++ ever have a standard set of types and operations for
>packed decimal based numbers ?

I hope not.

>However, a compiler vendor would be free
>to implement it internally, and generate high quality assembler
>on those machines that have hardware support for Packed decimal.

Even if you have a VAX, do you know that using these instructions will help?
Fortunately most RISC machines have tossed support for this sort of thing.

If you use g++, you should note that there's already a class Integer.  Read in
some integers, do arithmetic on them, write them out.  It works no matter how
big the numbers are, and you don't care how it works inside.  There's also a
class Rational for exact rational arithmetic, which i think is very useful.

radix 10: bad
radix 2^16: good

--
Joe Keane, amateur mathematician

In article <95010300005913.DLITE.crayton@delphi.com> crayton@delphi.com (Chris Crayton) writes:
>Writing in BCD does keep you from getting some roundoff errors that occur
>when you change $1.24 into a base 2 representation.  People use BCD in
>financial calculations to make sure that the pennies always add up.

A better solution for the roundoff problem is to use a shifted integer
representation, e.g. represent $1.24 as 124.  This way you can use the
CPU's built-in arithmetic operations when manipulating the values, and only
have to do conversion during I/O.  Languages like PL/I and COBOL have
built-in types for such representations; in C/C++ you have to roll your own
(in C++ a class should be able to do it pretty easily -- maybe this is how
the MONEY class works).
--

Barry Margolin
BBN Internet Services Corp.
barmar@near.net

In an article, Nathan Myers (ncm@netcom.com) wrote:
: >>It is a common misconception that more accurate computation is possible
: >>in BCD than in binary.  In fact, the only advantage that I know of for
: >>BCD is that conversion to and from ASCII is quicker.  [Er, and that
: >>the Pentium bug doesn't affect you :-)]

My problem is that I have to represent amounts ranging from

$ .0001 (100ths of a penny) through 100,000,000,000 (100 billion) dollars.
To do this in integer requires about 43 bits of accuracy.
I.e. the ratio of the smallest number to the largest is about 1000 ^ 4.x.
It takes about 10 bits for each power of a thousand. (2 ^ 10  ~= 1000).

Regular integers, even the 32 bit kind won't work. Double precision
floating point will, however there will be roundoff error.

For accounting purposes, we have to match things exactly to the
accounting system. Thus, we need either 64 bit integers
or BCD, or some other arbitrary precision representation,
that guarantees at least  16 digits or so of decimal accuracy.

Michael T.

In article Frr@world.std.com, miket@world.std.com (Michael Trachtman) writes:
>
>My problem is that I have to represent amounts ranging from
>$ .0001 (100ths of a penny) through 100,000,000,000 (100 billion) dollars.
>To do this in integer requires about 43 bits of accuracy.
>I.e. the ratio of the smallest number to the largest is about 1000 ^ 4.x.
>It takes about 10 bits for each power of a thousand. (2 ^ 10  ~= 1000).
>
>Regular integers, even the 32 bit kind won't work. Double precision
>floating point will, however there will be roundoff error.
>
>For accounting purposes, we have to match things exactly to the
>accounting system. Thus, we need either 64 bit integers
>or BCD, or some other arbitrary precision representation,
>that guarantees at least  16 digits or so of decimal accuracy.

Typical implementations of type double provide about 53 bits of
precision. If you scale the numbers in 100ths of a penny (that is
the value 100 means one penny, 10000 means one dollar) you will
not have any fractional values (unless you perform a division
which needs better than $0.0001 precision).

You can hide the scaling inside a class, and the internal representation
will always be an integral value. The representation will be exact as
long as the true value can be represented in no more than (typically) 53
bits. This is (just barely) true for the range you mention. (You indicated
43 bits above, but it is really about 52 or 53 bits.)

Example: $10.5 plus $1.0022 gets calculated as if you wrote

 105000 + 10022

The result is in 100ths of a penny. Output is formatted by manipulation
of the text representation, not by dividing by 10000. Again, the
manipulations are hidden in the class implementation.

---
Steve Clamage, stephen.clamage@eng.sun.com