My understanding is that part of COBOL's longevity stems from its particular handling of fixed-point math being a specified requirement of various financial contracts. Odd to see this write-up not mention fixed-point math, actually.
And now I'm doing cryptocurrency analytics. The basic unit of Bitcoin is the satoshi, and in the protocol, all transactions are denominated in satoshis. (Similarly, in ethereum, the base unit is the wei and all transactions are denominated as 256-bit words of wei.) And yet basically all exchanges are still using floats. Sometimes they quote them as strings to avoid round-off, sometimes it's double-precision, but internally, it's all just floating point math. So once again I find myself doing everything in terms of floats, even though the underlying financial instrument uses integer units of a very small denomination.
Now that there's a huge proliferation of cryptocurrencies, I wonder if we'll eventually see one that gives up on this point and defines money as IEEE 754 double-precision floating point numbers.
This isn't directly attackable, but you could potentially trick a trading algorithm into performing stupid trades by feeding it subtly inaccurate data. If you know the particular algorithm used, though, there are probably easier ways to construct adversarial inputs and trade against them. This is why virtually all trading shops keep their algorithms secret, and also slice up & mix their outgoing orders randomly so you can't observe the output of the algorithm.
Sounds like all there customers had already worked around the bugs and they didn't want to backtrack. Floating point can be horrible because not only do both sides have to use it but they have to process their calculations in the exact same way with the same order, with decimal types you will get consistent results.
Throw in some other complexities like different clients using different value precisions, different currencies having different fractional values (japan has no decimal places, a Kuwait cent is a thousandth of a dollar) combinations of those two and more, then using decimals/money types are just easier.
languages without oddities and gotchas do tend to lend themselves to stable systems
What exactly is fixed point math? The way I deal with currency is to use decimal floating point, ie 'decimal' in C#. Is fixed point simply using integers with and making your base unit cents, not dollars?
Decimal versus binary is orthogonal. A decimal fixed-point number means that N will be a power of 10, and usually clips the range such that there are fixed number of decimal digits available (e.g., between -1,000,000 and +1,000,000). A binary fixed-point number means that N will be a power of 2, and clips its range to fix the number of binary digits (e.g., between -1,048,576 and +1,048,576). Binary floating point means that the base in arithmetic is 2, whereas decimal floating point means that base in the arithmetic is 10. C#'s `decimal` type is a non-standard decimal floating point, which looks to make the mantissa be a binary range instead of a decimal range (i.e., the maximum is not 10^n - 1 for some n).
Even more curious to me is how COBOL squares as fast if it's stuck using fixed point math.
The main reason people use floating-point math is convenience. It's like dynamic typing: write your real quadratic equation solver with floating-point math and you can use it for everything, whether the values are 6.02e23 or 555e-9, at the expense of having to do extra computation at run-time, just like dynamic typing lets you implement a single hash table type that works for any type of value. But in fixed-point, unless you're using a pretty fancy language, you need to decide on the magnitude range of your values up front. Maybe 3e-6 to 3e5? Use 16.16. Maybe 4e-3 to 1e11? Use 24.8. It's a pain in the bohonkus. But it's faster, more portable (if reproducible results are necessary) and easier to reason about than floating point.
AFAIK this is only because modern CPU's have floating point units (https://en.wikipedia.org/wiki/Floating-point_unit), from memory these became common on home PCs around the time of the 486. A lot of early 3D games used fixed point because it was much faster for those that didn't have a co-processor installed.
Whether any of this is applicable to mainframes I don't know.