NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/arch/10503

Internet Message Format | 1992-11-08 | 3.0 KB

Path: sparky!uunet!decwrl!waikato.ac.nz!comp.vuw.ac.nz!zl2tnm!toyunix!don
Newsgroups: comp.arch
Subject: Re: IEEE used for Dollars and Cents
Message-ID: <[e-mail]>
From: [e-mail] (Don Stokes)
Date: 7 Nov 92 11:00:54 GMT
Sender: [e-mail] (GNEWS Version 2.0 news poster.)
Distribution: world
Organization: The Wolery
Lines: 55

[e-mail] (Keith Smith) writes:
> In article <[e-mail]> [e-mail] (Don Stokes) writes:
> >Machines that can handle 64 bit integers cleanly will make this problem
> >largely go away.  8-)
>
> A pretty darn big assumption that you only need 2 or 3 decimal places of
> precision in a financial calculation.  We have some 4 decimal place
> multiplication here.

I did say "largely".  You can get yourself screwed up with BCD or decimal
character datatypes too -- I have fond memories of the fun and games when
a customer of a bureau I was working for started putting through >$10M
transactions, and the system dropped the 10th digit (dollar amounts were
represented by ascii representations of an integer number of cents).  But
I digress.

A signed 64 bit integer gives nearly 19 digits of precision.  A four decimal
place multiplication of a dollar amount (thinking of them as integral
numbers of cents makes this easier) will only lose four of those digits
before you divide the result by 10,000 to bring it back to a cent value
again.  That still leaves you with dollar values of up to
$9,223,372,036,854.77.

The "other" approach to the problem of datatypes that are too small is to
use floating point but keep to integer values.  The peril there of course
is that you silently lose digits if the value exceeds the precision of the
mantissa.

128 bit integers, anyone?

> Why doesen't someone build a bcd or bcddouble type INTO the 'C' compiler
> with a higher order than float.  Numbers could be 8 or 16 bytes, 2 bytes
> of sign/exponent, and eith 7 or 15 bytes of mantissa, (14 or 30
> *DECIMAL* as in BASE 10 places of precision).

Possibly because they feel, as I do, that C isn't the language to write
"business" applications in.  But a bit of extended precision support in the
language wouldn't go amis.  (He says having just written code _full_ of 64
bit arithmetic on a 32 bit machine to cope with monthly network traffic
values in bytes....)

Extended precision fixed point would be a reasonable compromise, and could
be made to run quite a bit faster than decimal on current hardware.

While I'm ranting:  Bricks to DEC for putting 64 bit integer support in the
Alpha C compiler only, and making the "same" datatype 32 bits on "compatible"
MIPS platforms.  Jeez!  Extended precision isn't _that_ hard.  Sure, it'll
run a little slower than a native datatype and operations won't be atomic,
but surely documenting this fact (or not treating programmers as idiots) is
a better way?

--
Don Stokes, ZL2TNM (DS555)                        [e-mail] (home)
Network Manager, Computing Services Centre            [e-mail] (work)
Victoria University of Wellington, New Zealand              [phone]