Notably, during subtraction of values of similar magnitude a large number of valid digits can be cancelled out. On a machine using 6 BCD digits consider:
From a mathematical viewpoint an infinitely precise value X can be written as:31416.0 - 10000.0*Pi = 31416.0 - 31415.9 = 0.1This is nowhere near the true 6-digit-precision result of 0.0734641 because of the cancellation of the leading valid digits.
X = Xm + ewhere Xm is the limited-precision machine number and e is a small error value that corresponds to the precision of the calculator.
One (or more) of these numbers X are converted by the algorithm A into a result R:
R = A(Xm + e)and the precision of the result R strongly depends on whether A "amplifies" the inaccuracy introduced by e.
Finding an acceptable algorithm for a specific problem (ie. integration, solving differential equations, matrix operations etc.) is often a complicated issue. This is not our topic. However, it will be our topic to assess the precision of built-in algorithms of calculators.
Example: Decimal number 10.5. In binary this is 1100.1. Split into mantissa and exponent: 1.1001 E 3decAdvantage: The big advantage of binary floating point numbers is that most computers have powerful and fast built-in instructions to directly manipulate long integer numbers (usually 16, 32 or 64 bit). For example multiplication and division is often implemented in hardware units. Most computers therefore use binary coding. There are of course computer software packages that perform BCD arithmetic as explained below.
So the mantissa would be 11001 and the exponent +3dec.
Since the mantissa is required to always have a leading 1 it is often omitted to gain space for an additional bit of precision. In this case the leading 1 is implicitly assumed to sit to the left of the most significant digit of the mantissa.
Disadvantage: Whenever a number has to be displayed it must be converted into decimal format. Similarly, decimal input must be converted to binary before calculation can start. This is a quite time consuming process but of course it only occures once before and after a - possibly lengthy - calculation.
Example: Decimal number 10.5. The binary representation of the BCD digits is 0001 0000 0101. So the mantissa would be 000100000101 and the exponent +1dec.Advantage: No complicated conversion between textual and internal representation of a BCD number is needed. This is especially useful for calculators where after each operation the result has to be displayed. In fact, I don't know of any handheld calculator that doesn't use BCD arithmetic!
Disadvantage: BCD arithmetic is slow because it lacks the
dedicated hardware support. This usually doesn't matter because
handheld calculators don't have high-performance CPUs anyway. Rather,
their processors are optimized for low power consumption.
Another disadvantage of BCD numbers is their increased memory requirement. A n-digit decimal number needs n*4 bits in BCD and n*ln(10)/ln(2)=n*3.322 bits in binary mode. So the BCD representation requires 20% more storage.
Consider the decimal number 0.1 which has an exact representation in BCD. However, in binary mode it must be expressed as a sum of powers of 2:It turns out that the binary digits sequence "1100" repeats infinitely. But since every binary representation uses a limited number of bits the value 0.1 cannot be expressed exactly. To distinguish between binary and BCD usage the idea is to "amplify" this inaccuracy so that it can be observed:0.1 = 2-4 + 2-5 + 2-8 + 2-9 + 2-12 + 2-13 + 2-16 + 2-17 + ... = 0.000110011001100110... (binary)
Calculate: R = (0.1 * 1024 - 102) * 10 - 4In theory as well as on a BCD machine this should give 0. However, on a binary machine 0.1 will have some error e that is amplified by a factor of 10240:
((0.1 + e)*1024 - 102)*10 - 4 = (102.4 + 1024*e - 102) * 10 - 4 = (0.4 + 1024*e)*10 - 4 = 4 + 10240*e - 4 = 10240*eAs a result, calculating R on a machine using binary representation will yield a non-zero value.
Side note 1: Although some limited-length BCD numbers have no exact (=no limited length) representation in binary mode the reverse is not true. All limited length binary numbers do have a limited length representation in BCD. The reason is that all powers of 2 have a limited length representation in BCD (ie. 0.5, 0.25, 0.125, 0.0625 etc.) but not all powers of 10 have a limited-length representation in binary mode.
Side note 2: Try calculating R = (0.1+e)*10240 - 1024 = 1024 + 10240*e - 1024 = 10240*e.
Surprisingly, this will yield 0 even on a binary machine! The reason is that due to rounding (0.1+e)*10240 will in fact result in the exact value 1024.
There are three solutions to this dilemma:
But the ultimate goal is to calculate results that are always correct to the number of displayed digits.
The correct rounding scheme examines the digit n+1 following the least significant digit n (and thus needs at least one additional hidden digit). If digit n+1 is in the range 5..9 then digit n is incremented to minimize the difference. Otherwise digit n is left unchanged.
Examples of correct rounding:
|Correct value||Expanded correct value||Rounded value, to 5 digits after decimal point|
To determine whether your calculator uses correct rounding simply calculate 1/18 and examine the last digit: It should be 6.
Besides correct rounding there are of course other less desirable methods, ie. cutting off all digits beyond the least significant one.
R = asin( acos( atan( tan( cos( sin(9) ) ) ) ) )Of course the correct result is 9. At the various steps the intermediate results are:
|sin(9)||0.156 434 465 040 230 869 010...|
|cos(x)||0.999 996 272 742 885 024 117...|
|tan(x)||0.017 454 999 855 488 660 791...|
|atan(x)||0.999 996 272 742 885 024 117...|
|acos(x)||0.156 434 465 040 230 869 010...|
|atan(x)||9.000 000 000 000 000 000 000...|
Now consider a calculator that uses built-in algorithms that are
correct up to the 12th digit. And of course the 12-digit precision
result of one
step is taken as the input for the next step of the calculation:
|X rounded to 12 digits|
|sin(9)||0.156 434 465 040|
|cos(x)||0.999 996 272 743|
|tan(x)||0.174 549 998 555 E -1|
|atan(x)||0.999 996 272 744|
|acos(x)||0.156 434 441 642|
|atan(x)||0.899 999 864 267 E 1|
This is a perfect example of a badly chosen algorithm because it amplifies the inaccuracies of the 12-th digit to a considerable error. Compared to the table with precise results the first noticable deviation occurs when the arcus tangent is calculated. The resulting small error of 1.12E-12 (absolute) is then tremendously amplified by more than 104 by the arcus cosine to 2.34E-8 (absolute).
By looking at the derivative of the arcus cosine near the value of 1 it is immediately clear why this amplification occurs:It must be strongly emphasised that the above result of 8.99999864267 is the correct result for a calculator using 12 digits of precision and perfect built-in algorithms for trigonometric functions! Naturally, similar arguments apply for calculators of different precision.
d/dx acos(x) = -1/sqrt(1-x²) and for x -> 1 the derivative reaches infinity.
If those hidden digits are in fact always correct then why not present them to the user? The display may not be able to show all the digits. But usually one can safely suspect that the hidden digits are sometimes correct and sometimes not.Together with the above mentioned confusion that arises from hidden digits in conjunction with manually entered vs. calculated values it is obvious that storing results with hidden digits is a not a good idea.
This "pulls out" the hidden digits. There may be none, one or more, depending on the calculator.