I was slightly surprised to read these words by William Kahan (via this discussion):

but I see there's something there. He goes on to say that IBM agreed, and I believe they still offer high-performance decimal floating point in their big machines.

So: technically, binary is better, but for the real world, there are benefits in decimal (if you can afford it - outside a calculator, it's always going to be more difficult.)

(I didn't want to derail the thread about IEEE-754)

I think that a lot of the (early) IBM machines were used for something like financial accounting.
Values are supposed to be decimal numbers, like 12.34€, but converting some of them innocent looking small decimal values to binary could take a lot of Bits.

So converting floating point numbers from decimal to binary and back might cause some little rounding errors sometimes.
For an application like financial accounting, decimal floating point would be better, because one would have to worry less about rounding errors.

A practical engineer probably won't mind if the computer stubbornly insists that a piece of sheet metal has to be 9.9999999999999999 meters long instead of 10.0 meters.
But for accountants and bureaucrats, the difference between 9999999999999999.99€ and 10000000000000000.00€ is something like "the end of the world".

Originally IBM mainframes used base 16 floating point so the mantissa is shifted 4 bits for every increment of the exponent. This means that you rapidly use accuracy in calculations, especially when using the 32-bit single precision (1 byte for sign and binary exponent + 3 bytes (6 nybbles) of mantissa with no 'hidden' bits as in IEEE 754).

Later versions of the 390 added binary floating point to provide greater accuracy in the same size mantissa.

Early mainframes were mainly used for commercial rather than scientific computing. They had very elaborate BCD opcodes for numerical calculations (the IBM supports arithmetic on up to 31 digit BCD values - one nybble holds the sign).

Some machines also had a pounds, shillings and pence mode for pre-decimalisation arithmetic.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

It's interesting to read about the two(!) formats for IEEE decimal floats. One has a binary significand, and the other a decimal significand. And in the decimal case, Densely Packed Decimal is used, which has some advantages over BCD and is also worth reading about.
https://en.wikipedia.org/wiki/Decimal_f ... 8_encoding

While on the topic of decimals and accuracy, there are at least three things a calculator can do with a calculation like

10 divided by 3
times 3
minus 10

which are:

Display 9.999... as intermediate result, and a tiny negative number as final result
Display 10.000... as intermediate, but again a tiny negative as final
Display 10.000... as intermediate, and zero as a final result.

There are probably people to be found with strong opinions about each of these choices.

Such rounding errors arise due to the divisor's reciprocal not being representable exactly in the radix chosen for calculations. That is the reason why some mathematicians of the pre-digital era did major calculations in base 60 (sexagesimal), which contains 2, 3, and 5 as prime factors, thereby making it more flexible for accurate calculations than base 10 (2 and 5), base 12 (2 and 3), or binary (only 2).

However, for any non-trivial calculation, such rounding errors will always potentially occur because you simply can't choose a radix with enough prime factors to handle every possible divisor. So you need to carefully design your calculations to minimise the effects of rounding and avoid catastrophic cancellations (eg. the Kahan Summation Algorithm), or use some system other than straight floating-point which is not susceptible to rounding error at all, such as a rational or polynomial system. Or, you can use interval arithmetic in which you round both up and down, and keep track of the extreme limits of the range in which the true answer must lie; this can at least guide you as to how many significant digits can sensibly be printed.

In my opinion, the only valid reason to use decimal arithmetic on a computer is to comply with legal requirements for financial calculations. I note that decimal arithmetic was removed from the AMD64 instruction set as a direct successor to x86.

Just for say: no matter the base used, any machine work with a finite number of bits, or nibbles, or digits, so in any base the range of number is just one restricted subset of irrational number, and with variable distance between consecutive numbers.

_________________
http://65xx.unet.bz/ - Hardware & Software 65XX family

Binary does not have to be a problem at all for financial applications. Just make 1.00000... represent the penny, not the dollar, so it is exact. Convert only when it's time for human output. If you need tenths of cents to be perfectly accurate, then represent the dollar as 1,000d (3E8h) instead. This does not keep you from converting to a more-normal representation (like $28.39) when it's time for human-readable output. In the internal representation, $.99 times two is still $1.98, $2.49 + $14.40 is still $16.89, etc., and it is exact.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Yea, but then you get all of the joys of fixed point integer arithmetic with the expense of floating point, since you're basically just working with the mantissa (and a fixed exponent) at this point.

You can still do it in floating-point. My point was to show that you can still do it in binary internally. Whether it's handled in decimal or binary is separate from whether it's floating or integer. (Also, fixed-point is a limited subset of scaled-integer; but that a discussion for another thread.)

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Yeah, I'm not seeing the advantages of floating-point for financial calculations (or any other field where accuracy down to the nth digit is mission-critical,) either. All floating-point ultimately gets you (well, aside from esoteric things like valid representations of non-quantifiable numbers) is the ability to express a wider range of values in a certain space, at a potential accuracy cost - and if you need both a wide range and total precision, you really just need a larger-sized integer.

There are functions of currency values that are used in financial applications that are easier to handle in floating point, such as the compound-interest exponential function (to take a relatively familiar example). But my understanding is that some jurisdictions literally mandate the use of *decimal* floating point for these purposes when money is involved. I think this is so that the computer's calculations can be precisely audited by hand calculation when required.

I think the HP-12C's results on financial calculations are more or less enshrined in the US as canon. And William Kahan tells us that the ability of the 12C to give good answers quickly is a consequence of it having an extra three digits within for all intermediate results. (Similarly the x87 works internally with 80 bit floats, to give adequate precision on complicated calculations.)

I remember I spent weeks trying to get a large GL report to balance that did lot of distributions across accounts. You know, one of those reports that's 2 inches thick, thousands of transactions, and on the last page read something like:

Totals: Gazintas: $123,347,345.32 Gazouttas: $123,347,345.31

ARGH!

I was adding stuff up, detecting "missing" pennies, trying to allocate them appropriately.

I don't know if that thing ever balanced. Boy, was it frustrating.

Would decimal math have helped? Eh, I honestly don't know. But, it probably wouldn't have hurt.

(All we had was floating point, we didn't even have integer math on that system. And, yes, I was rounding, truncating, multiplying by 100, rounding/truncating, then dividing by 100 to try and get rid of "hidden bits". I did everything I could think of at the time save adding up string variables...)

For rounding difficulties, addition and subtraction aren't too much of a problem, multiplication by integers doesn't introduce any difficulty so long as the word is wide enough. But as soon as you have multiplication by non-integers, as with the calculation of discounts or taxes, or division, or any kind of interest payment or yield calculation, that's when you find that fixed or floating point doesn't match the behaviour of the real numbers, and currency insists on finite representation so that's not a real number either.

The solution, I think, is not in computer arithmetic, but in accounting practices which define what the right answer is. And those practices had better be compatible with some kind of computer arithmetic!

Looking briefly at the HP-12C's design, it has a 10-decimal-digit mantissa, equivalent to about 33-34 bits in binary. This means it's incapable of accurately representing the 11-digit sums given in @whartung's example. I don't know what the precision of his machine was, but it can't possibly have been a HP-12C!

Most floating-point formats predating the IEEE-754 standard had serious problems with non-standard behaviour, particularly concerning rounding, overflow and error handling. If that machine was not using IEEE arithmetic, then that probably contributed noticeably to the problems with handling a large report.