In article <firstname.lastname@example.org>, Dann Corbit <email@example.com> wrote: >In article <hpa.31ba9c8e.I.use.Linux@freya.yggdrasil.com>, firstname.lastname@example.org says... >>FINANCIAL DATA ARE INTEGER DATA, THE UNIT OF WHICH IS THE SMALLEST >>AVAILABLE CURRENCY UNIT. >> >>In other words: for U.S. currency, you keep track of cents. Not >>dollars. Cents. >> >This approach works in simplistic terms, for instance, when you are adding >two amounts. But how do you figure tax using only integers? If you >use only integer types, how do you figure interest, which is an exponential? >You are back to using floating point in either case, which never eliminates >the problem. > >All real world accounting systems have to deal with non-integer amounts at >some point in the calculation stream.
To handle numeric data of this type, you need fixed point arithmetic, not integer arithmetic. Decimal fixed point arithmetic keeps the decimal (not binary) point a fixed number of digits from the right end of the field. It uses decimal arithmetic rules for rounding and truncation. Integer arithmetic is a special case of fixed point arithmetic, with zero digits to the right of the point.
Fixed point numbers can be represented in any numeric format. The "trick" to dealing with them correctly is in doing the correct rounding, truncation, and scaling after *each* operation. Since many of the computers we use do not have decimal fixed point arithmetic built into the hardware, it becomes a software exercise (that is often done incorrectly by those who don't understand all the implications). -- Michael D. Shapiro, Ph.D. Internet: email@example.com Code 4123, NCCOSC RDT&E Division (NRaD) San Diego CA 92152 Voice: (619) 553-4080 FAX: (619) 553-4808 DSN: 553-4080