The Ariane bug was an overflow casting 64-bit floating point to 16-bit integer. It would still have overflowed at the same point if it had been 64-bit decimal

The Ariane bug was an overflow casting 64-bit floating point to 16-bit integer. It would still have overflowed at the same point if it had been 64-bit decimal floating point using the same units. The integer part of the floating point number still wouldn't have fit in a signed 16-bit integer. 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.)