Re: Monetary calculations in CL



"John Thingstad" <jpthing@xxxxxxxxx> writes:

På Thu, 14 Feb 2008 13:50:18 +0100, skrev Greg Menke <gusenet@xxxxxxxxxxx>:


It sounds reasonable for accounting purposes but is insufficient for
financial arithmetic- there are often rules for the application of
things like yield rates that specify a number of places of precision and
specific rules for rouding; for example, maintain 12 decimal places and
round the 13th (by implication do not employ precision to more than the
13th place to the right of the decimal). Intermediate products of some
calculations can easily consume 20 or more significant digits.

Simple arithmetic on such calculations is inappropriate. Cobol handles
this sort of thing quite well (intentionally I am sure). CL's numeric
types will easily handle the required precision but the rounding rules
will probably be somewhat troublesome. The class-based approach is
probably the way to handle it- perhaps an "interest" class where the #
of places of significance and the rounding policy are supplied.

Gregm

Well the most straightforward way is Binary Coded Decimal (BCD).
One nibble (4 bits) is reserved for each digit 0-9. So you write a
library to access numbers this way.
(Many processors have support for this.) Writing such a library is a bit
cumbersome, but still easier than dealing with the imprecision
explicitly in bignums I would think. (Because humans think of precision
in digits not binary)


Probably the easiest way would be to try and do it how COBOL does- since
it was designed to handle this sort of problem. Its worth observing
that when doing this kind of math, conformance to the specified rounding
policy is far more important than speed, both in the operational sense,
and when the time comes to audit the system, and maybe even more
importantly when you have to start tracking down where the 1 cent error
came from...

This is perhaps an example of an "Anti-Greenspun Law", such as, "Any
sufficiently complex financial application contains an ad-hoc,
informally specified, bug ridden slow implementation of COBOL's fixed
place numeric types".

I've seen it happen on a number of occasions, and I've perpetrated it
myself.

Gregm
.

Relevant Pages

  • Re: Oracle-Number werden tlw. als Zahl/Double erstellt
    ... you can also specify a precision (total number of digits) and scale. ... der wohl in unterschiedlichen Versionen unterschiedliche DDL-Anweisungen für ein Number-Feld ohne jegliche Dimensionierung erstellt hat. ...
    (microsoft.public.de.access.clientserver)
  • Re: How do you round off a float?
    ... o Floating point formats are almost always in binary, ... binary digits is very different from rounding to a certain number of decimal ... o A corollary to the above rule is use the maximum precision available on ...
    (comp.lang.cpp)
  • Re: Rounding errors
    ... >There is no 'error' in rounding. ... >precision numbers and to give an accurate representation in a limited ... >When that set is rounded to 2 digits of precision it only needs to ... >truncation does not represent. ...
    (comp.lang.cobol)
  • Re: IBM System z9
    ... doesn't just offer programmers the ability to forget about the ... It also offers advanced rounding ... where they meant precision. ... digits after the decimal point). ...
    (comp.arch)
  • Re: SELECTED_REAL_KIND clarification plse
    ... sign, would satisfy four digits. ... There is work toward a decimal based floating point standard ... available precision and range as binary. ... It would make sense to specify ...
    (comp.lang.fortran)