https://www.truenorthfloatingpoint.com/problem
Floating point arithmetic has its problems.
[1] Ariane 5 ROCKET, Flight 501
[2] Vancouver Stock Exchange
[3] PATRIOT MISSILE FAILURE
[4] The sinking of the Sleipner A offshore platform
[1] https://en.wikipedia.org/wiki/Ariane_flight_V88
[2] https://en.wikipedia.org /wiki/Vancouver_Stock_Exchange#Rounding_errors_on_its_Index_price
[3] https://www-users.cse.umn.edu/~arnold/disasters/patriot.html
As per the provided link, the Patriot missile error was 24-bit fixed point arithmetic, not floating point. Granted, a fixed-point representation in tenths of a second would have fixed this particular problem, as would have using a clock frequency that's a power of 1/2 (in Hz). Though, using a base 10 representation would have prevented this rounding error, it would also have reduced the time before overflow.
I think IEEE-754r decimal floating point is a huge step forward. In particular, I think there was a huge missed opportunity in defining open spreadsheet formats that decimal floating point option wasn't introduced.
However, binary floating point rounding is irrelevant to the Patriot fixed-point bug.
It's not reasonable to expect accountants and laypeople to understand binary floating point rounding. I've seen plenty of programmers make goofy rounding errors in financial models and trading systems. I've encountered a few developers who literally believed the least significant few bits of a floating point calculation are literally non-deterministic. (The best I can tell, they thought spilling/loading x87 80-bit floats from 64-bit stack-allocated storage resulted in whatever bits were already present in the low-order bits in the x87 registers.)
floating point cannot do that, its precision is based on powers of 2 (1/2, 1/4, 1/8, and so on). For small values (in the range 0-1), there are _so many_ values represented that the powers of 2 map pretty tightly to the powers of 10. But as you repeat calculations, or get into larger values (say, in the range 1,000,000 - 1,000,001), the floating points become more sparse and errors crop up even easier.
For example, using 32 bit floating point values, each consecutive floating point in the range 1,000,000 - 1,000,001 is 0.0625 away from the next.
jshell> Math.ulp((float)1_000_000)
$5 ==> 0.0625BCD is a completely different thing, instead of tightly encoding an integer you encode it digit by digit wasting some fraction of a bit each time but make conversion to and from decimal numbers much easier. But there is no advantage compared to a base ten fixed or floating point representation when it comes to representable numbers.
IEEE 754 also supports encoding decimal integers as binary, by converting the entire decimal integer to a single binary integer (i.e., not by storing each decimal digit as a separate binary number).
[1] https://en.wikipedia.org/wiki/Densely_packed_decimal
[2] https://files.openpower.foundation/s/dAYSdGzTfW4j2r2#page=22...
BCD is attractive to human beings programming computers to duplicate algorithms (generally financial ones) intended for other human beings to execute using arabic numerals. But it's not any more "accurate" (per transistor, it's actually less accurate due to the overhead).
The only real disadvantage for BCD is its not as quick as Floating point arithmetic, or bit swapping data types, but with todays faster processors, for most people I'd say the slower speed of BCD is a non issue.
Throw in other hardware issues, like bit swapping in non ECC memory and the chances of error's accumulate if not using BCD.
There are two reasons for BCD, (1) to avoid the cost of division for conversion to human readable representation as implied in the OP, (2) when used to represent floating point, to avoid "odd" representations in the human format resulting from the conversion (like 1/10 not shown as 0.1). (2) implies floating point.
Eben in floating point represented using BCD you'd have rounding errors when doing number calculations, that's independent of the conversion to human readable formats; so I don't see any reason to think that BCD would have avoided any disasters unless humans were involved. BCD or not is all about talking to humans, not to physics.
Parent didn't say it's a logical necessity, as in "avoid floating point ==> MUST use BCD".
Just casually mentioned that one reason BCD got popular to sidestep such issues in floating point.
(I'm not saying that's the reason, or that it's the best such option. It might even be historically untrue that this was the reason - just saying the parent's statements can and probably should be read like that).
If they just want to side step problems with floating point rounding targetting the physical world, they need to go with integers. Choosing BCD to represent those integers makes no sense at all for that purpose. All I sense is a conflation of issues.
Also, thinking about it from a different angle, avoiding issues with the physical world is one of properly calculating so that rounding errors become no issues. Choosing integers probably helps with that more in the sense that it is making the programmer aware. Integers are still discrete and you'll have rounding issues. Higher precision can hide risks from rounding errors becoming relevant, which is why f64 is often chosen over f32. Going with an explicit resolution and range will presumably (I'm not a specialist in this area) make issues more upfront. Maybe at the risk of missing some others (like with the Ariane rocket that blew up because of a range overflow on integer numbers -- Edit: that didn't happen on the integer numbers though, but when converting to them).
A BCD number representation helps over the binary representation when humans are involved who shouldn't be surprised by the machine having different rounding than what the human is used to from base 10. And maybe historically the cost of conversion. That's all. (Pocket calculators, and finance are the only areas I'm aware of where that matters.)
PS. danbruc (https://news.ycombinator.com/item?id=35057850) says it better than me.