```Robert Mann has reported to me privately that he has a friend in computing
who says that there were other implementations of excess-nnnn decimal
algorithms, assumedly for both computation and external storage of decimal
numbers, before I developed them in 1968-69. (see below for explanation)
Since there were few publications of computing work at the time, I certainly
that I was not the first one who did it. I was certainly the first one who
did it on Digital Equipment Corp machinery, as the decimal implementation
provided on those systems was the same as on IBM systems, which was BCD and
slow as molasses.

Robert also corrected me with regard to my assertion about I/O of large
numbers at Digital. I did not mean that by that time no one else anywhere
had done this; I would have been astonished if it hadn't been done before. I
am certain that IBM, for instance, had developed efficient I/O algorithms
for large numbers years before, but they were proprietary. I meant that I
was the one who developed the algorithms for Digital, that is all. Nothing
was published at the time, so we were on our own.

Jonathan

Excess-nnnn arithmetic, when used for both numeric storage and arithmetic
calculations, involves the use of an array of words/longwords, each
representing the number greater than -10**n and less than 10**n. Thus, for a
PDP-8, which had 12 bits in each word, each word represented a number
between -999 and 999. Report Program Generator (RPG) required 23 decimal
digits, 15.8, if I remember correctly (it was almost 40 years ago), so it
required 8 PDP-8 words. Addition calculations were straightforward, starting
at the right word and proceeding left. If the sum of two words was equal to
or greater than 1000, then 1000 was subtracted and a carry of 1 was added to
the next addition on the left. My implementation represented the decimal
numbers in this way throughout. Multiplication and division were somewhat
more involved, obviously.

Many years later at Digital, the I/O of extremely large numbers represented
a special challenge when new hardware was introduced that could do the math
with them. If you go about just printing the numbers according to standard
algorithms, you'll spend minutes printing a single number. What was required
was a method of scaling the number. We used an array of decimal exponents to
first scale the number, and then used the standard I/O algorithm for
printing thereafter, thus enabling I/O of these numbers in about the same
time as ordinary floating point ranges (typically 10**-40 to 10**40).
```