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).