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 
did not (and could not) know about this. If true, I would certainly concede 
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).