Bicimal

[Tugdual]

Since simple real numbers such as 0.5 cannot be represented in binary, how do calculators actually work? If i’m not mistaken old calculator CPUs were using BCD but how do modern calculators (and computers) work to mitigate bicimal representation issues?

[Albert Chan]

Hi, Tugdual

strtod() can approximate the number string to binary, within 1/2 ULP (halfway to even)

Here are 2 of my strtod implementations: strtod-fast.c, strtod-mpfr.c

This is how GCC does it, by doing round-to-odd (followed by round-to-even, to avoid double-rounding error)

BTW, 0.5 = 0b0.1

[Thomas Okken]

0.5 is a bad example, since it can actually be represented in finite-precision binary, being 0.1 in that base.

As far as I'm aware, most calculators still work in BCD today, but some calculators and most computers work in binary.

This isn't really a problem in most cases. It is true that 0.2, for example, cannot be represented in finite-precision binary, being 0.001100110011... in that base; but of course lots of numbers can't be represented in finite-precision decimal either, like 1/3, and that doesn't stop anyone from using decimal (BCD) calculators anyway. As long as you are aware of the limits of representation, this is usually not an issue.

I have personally had to deal with representation issues when working with algorithms that use packed storage to combine multiple numbers into one for storage efficiency. For example, on an early HP with 10-digit decimal precision, you could pack five two-digit numbers into one register, like AA.BBCCDDEE for example, and the code to extract CC from that number would be something like 10000 x INT 100 MOD. Running such code on a binary computer could fail because of representation issues, and it would have to be changed to use groups of bits rather than decimal digits; with groups of 7 bits, the aforementioned logic would be 16384 x INT 128 MOD.

[KeithB]

Just what is the problem?

This is what floating point is for. To a first approximation, it uses scientific notation to easily represent real numbers. There is also fixed point which uses integer math with an implied, fixed decimal point. While there are numbers that can't be perfectly represented, like 1/3 in decimal, if you have enough digits, it usually works out OK.

Then, there is the Microsoft decimal format which AFAIK, is essentially infinite precision. Mainly for working with money.

[Druzyek]

Would the argument with calculators be that even though you don't get out of approximating, you are at least approximating in the exact same way humans expect you to? Even if it's not more accurate in the long run, it's more convenient for the user mixing calculator computations and intermediate results with mental calculations.

[Paul Dale]

(05-21-2019 02:06 PM)KeithB Wrote:  Just what is the problem?

An introduction to rounding needs to be inserted. It is a very difficult problem. Google Williams Kahan's publications for an introduction to the complexities and nuances -- remembering that he is a world leading genius on numerical analysis and presents results as if they required little thought even though few others could have found his solution.

I was recently discussing the most difficult programming I've ever had to do with a colleague. I couldn't decide between:

• Hardware bring up where there is no debug capability (until a serial port or LED can be controlled). Noting that hardware documentation is often misleading, lacking or just plain wrong.
• Numerical programming where there is always a result but you never know if it is correct or not. Often you have no idea how far from correct it is or what went wrong. Now expand this to a matrix operation over thousands or millions of numbers. Where was the error?
  

It really is a toss up between the two.

[KeithB]

Rounding is subtle, that is for sure. Otherwise there would not be so many methods. However, I am not sure what rounding has to do with the OP, which is why I asked for his specific issue.

Calculators punt on the problem when they use guard digits.

[Tugdual]

Rounding has always been a major issue, especially when working on pricing systems with discount on multiple items etc...
To keep the total and show correct price beak down I had been using a very tricky calculation that somehow resembles the floyd steinberg image conversion algorithm based on error propagation.

Also recently I found that all the data I had uploaded in a database had changed just because of the binary format and I immediately received questions from users.
Users don’t understand or accept that and I was wondering what was the correct way to handle these issues.