🚀 go-pugleaf

   I have been following the correspondence on decimal conversion with
some interest, and it seems to me that a number of the points raised on
the use of decimal arithmetic in data processing, particularly when
using COBOL as the programming language, can only be clarified if placed 
together in context.

   The first point is that there is nothing special about accounting and
   banking computations that lead to a requirement for decimal arithmetic
   in order to maintain accuracy.  Since most architectures provide only
   integer decimal arithmetic, accuracy to the nearest cent or fraction
   thereof is usually obtained by having the compiler generate appropri-
   ate scaling computations.  But whatever operations are used, they are
   independent of the base of the underlying arithmetic system.

   Second, for current implementation technologies (with the possible ex-
   ception of Integrated Injection Logic), radix 2 or a power thereof has
   a decided edge over decimal.  That is, you can get a better performance
   with binary for a given cost, compared with decimal, or you can achieve
   a fixed performance for a lower cost.  Moreover, binary integers are
   considerably more compact than decimal codings, and this will be trans-
   lated into higher I/O throughput and smaller data bases.

   Third, conversion between binary and display format need not be too
   expensive compare with conversion between BCD and display format, and
   in any case, it can be accomplished fast enough to keep up with all
   but the fastest I/O systems, keeping in mind that system throughput
   is considerably slower than raw I/O transfer rates.

   Finally, There is no real need for data conversion unless the target
   I/O transaction is a write to a display device such as a screen or a
   printer.

   Why then, does it pay to provide decimal arithmetic in terms of real,
measured, performance gains in real environments?  The usual argument
goes something like this.  Decimal arithmetic is slow compared to binary
arithmetic, but there is usually not much arithmetic in typical business
and accounting applications.  However, there is a lot of data movement,
and if binary arithmetic is used, then the numbers have to be converted
to decimal before each data movement. It is this conversion, which is
unnecessary if decimal arithmetic is used, which costs in performance.

   But why MUST the conversion be performed, except for the case of final
output to a screen or printer?  The answer is that it doesn't, but in
most cases, it is, and the reason can be found in the genesis of COBOL
and the bias built into the language.  The original COBOL -PRESUMED- that
the underlying arithmetic was decimal, and this presumption was cast in
concrete by making DISPLAY usage the default for numeric fields in the
RECORD DESCRIPTION clause.  Thus, most COBOL programmers as a matter of
practice will only use the USAGE IS COMPUTATIONAL option when a particu-
lar computation is clearly a performance bottleneck.  If COMPUTATIONAL
were the default, and DISPLAY the option, then it would be used only
where required (for DISPLAYing on a screen or printer), and we would, I
believe, in many cases see a considerable performance improvement, due
mainly to the resulting decrease in I/O traffic, but also because of
the improvement in computational speed.  Moreover, such programs would
show NO improvement if hardware decimal arithmetic were provided, and
consequently there would be no incentive for making it available.

    In conclusion, decimal arithmetic is only an advantage because it
supports a bad data paradigm found in an obsolete, but still widely-
used programming language.

----
Dr. G. W. Gerrity                              Phone: +61 62 68 8180
Dept. of Computer Science                      Fax:   +61 62 68 8581
University College, UNSW                       Email: gwg@cs.adfa.oz.au
ADFA, Northcott Drive                          Telex: ADFADM AA62030
Canberra, ACT 2600            
AUSTRALIA