4 ms·

> why was BCD popular? https://www.truenorthfloatingpoint.com/problem https://www.truenorthfloatingpoint.com/problem Floating point arithmetic has its problem

> why was BCD popular? https://www.truenorthfloatingpoint.com/problem 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 https://en.wikipedia.org/wiki/Ariane_flight_V88 [2] https://en.wikipedia.org 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 https://www-users.cse.umn.edu/~arnold/disasters/patriot.html [4] https://en.wikipedia.org/wiki/Sleipner_A#Collapse https://en.wikipedia.org/wiki/Sleipner_A#Collapse

elpocko 4y ago
Can you elaborate? How/why is BCD a better alternative to floating point arithmetic?
- finnh 4y ago
  floating point error. BCD guarantees you that 1/10th, 1/100th, 1/100th, etc (to some configurable level) will be perfectly accurate, without accumulating error during repeat calculations. 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.0625
  - elpocko 4y ago
    You can have infinite precision in pretty much any accurate representation though, no? Where is the advantage in using BCD over any other fixed point representation?
  - danbruc 4y ago
    You are confusing two things. Usually you represent decimal numbers as rational fractions p/q with two integers. If you fix q, you get a fixed point format, if you allow q to vary, you get a floating point format. Unless you are representing rational numbers you usually limit the possible values of q, usually either powers of two or ten. Powers of two will give you your familiar floating point numbers but there are also base ten floating point numbers, for example currency data types. BCD 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.
    - elpocko 4y ago
      This was one of those things where I know just enough to realize something about the reasoning is not right. Thank you for putting that feeling into competent words.
      - jasomill 4y ago
        As a practical example, POWER architecture uses the densely-packed decimal encoding[1] to encode decimal digits within its IEEE 754-compliant decimal floating-point format[2]. 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 https://en.wikipedia.org/wiki/Densely_packed_decimal [2] https://files.openpower.foundation/s/dAYSdGzTfW4j2r2#page=221 https://files.openpower.foundation/s/dAYSdGzTfW4j2r2#page=22...
  - ajross 4y ago
    As others are pointing out, decimal fidelity and "error" are different things. Any fixed point mantissa representation in any base has a minimal precision of one unit in its last place, the question is just which numbers are exactly representable and which results have only inexact representations that can accumulate error. 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).
  - deleted 4y ago
    [deleted]
- moremetadata 4y ago
  For the reasons others have mentioned, plus BCD doesnt suffer data type issues in the same way unless the output data type is wrong, but then the coder has more problems than they realise. 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.
pestatije 4y ago
BCD is not floating point
- coldtea 4y ago
  That's the parent's point
  - pflanze 4y ago
    Avoiding floating point doesn't imply BCD. Any representation for integers would do fine, including binary. 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.
    - coldtea 4y ago
      >Avoiding floating point doesn't imply BCD 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).
      - pflanze 4y ago
        Sidestep which issue? The one of human representation, or the problems with floating point? 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 https://news.ycombinator.com/item?id=35057850) says it better than me.
KMag 4y ago
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.)

elpocko 4y ago

Can you elaborate? How/why is BCD a better alternative to floating point arithmetic?

finnh 4y ago
floating point error. BCD guarantees you that 1/10th, 1/100th, 1/100th, etc (to some configurable level) will be perfectly accurate, without accumulating error during repeat calculations. 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.0625
- elpocko 4y ago
  You can have infinite precision in pretty much any accurate representation though, no? Where is the advantage in using BCD over any other fixed point representation?
- danbruc 4y ago
  You are confusing two things. Usually you represent decimal numbers as rational fractions p/q with two integers. If you fix q, you get a fixed point format, if you allow q to vary, you get a floating point format. Unless you are representing rational numbers you usually limit the possible values of q, usually either powers of two or ten. Powers of two will give you your familiar floating point numbers but there are also base ten floating point numbers, for example currency data types. BCD 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.
  - elpocko 4y ago
    This was one of those things where I know just enough to realize something about the reasoning is not right. Thank you for putting that feeling into competent words.
    - jasomill 4y ago
      As a practical example, POWER architecture uses the densely-packed decimal encoding[1] to encode decimal digits within its IEEE 754-compliant decimal floating-point format[2]. 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 https://en.wikipedia.org/wiki/Densely_packed_decimal [2] https://files.openpower.foundation/s/dAYSdGzTfW4j2r2#page=221 https://files.openpower.foundation/s/dAYSdGzTfW4j2r2#page=22...
- ajross 4y ago
  As others are pointing out, decimal fidelity and "error" are different things. Any fixed point mantissa representation in any base has a minimal precision of one unit in its last place, the question is just which numbers are exactly representable and which results have only inexact representations that can accumulate error. 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).
- deleted 4y ago
  [deleted]
moremetadata 4y ago
For the reasons others have mentioned, plus BCD doesnt suffer data type issues in the same way unless the output data type is wrong, but then the coder has more problems than they realise. 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.

pestatije 4y ago

BCD is not floating point

coldtea 4y ago
That's the parent's point
- pflanze 4y ago
  Avoiding floating point doesn't imply BCD. Any representation for integers would do fine, including binary. 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.
  - coldtea 4y ago
    >Avoiding floating point doesn't imply BCD 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).
    - pflanze 4y ago
      Sidestep which issue? The one of human representation, or the problems with floating point? 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 https://news.ycombinator.com/item?id=35057850) says it better than me.

KMag 4y ago

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