Calc always stores its numbers in decimal, so even though one-third has
an exact base-3 representation (``3#0.1'`), it is still stored as
0.3333333 (chopped off after 12 or however many decimal digits) inside
the calculator's memory. When this inexact number is converted back
to base 3 for display, it may still be slightly inexact. When we
multiply this number by 3, we get 0.999999, also an inexact value.

When Calc displays a number in base 3, it has to decide how many digits
to show. If the current precision is 12 (decimal) digits, that corresponds
to ``12 / log10(3) = 25.15'` base-3 digits. Because 25.15 is not an
exact integer, Calc shows only 25 digits, with the result that stored
numbers carry a little bit of extra information that may not show up on
the screen. When Joe entered ``3#0.2'`, the stored number 0.666666
happened to round to a pleasing value when it lost that last 0.15 of a
digit, but it was still inexact in Calc's memory. When he divided by 2,
he still got the dreaded inexact value 0.333333. (Actually, he divided
0.666667 by 2 to get 0.333334, which is why he got something a little
higher than `3#0.1`

instead of a little lower.)

If Joe didn't want to be bothered with all this, he could have typed
`M-24 d n` to display with one less digit than the default. (If
you give `d n` a negative argument, it uses default-minus-that,
so `M-- d n` would be an easier way to get the same effect.) Those
inexact results would still be lurking there, but they would now be
rounded to nice, natural-looking values for display purposes. (Remember,
``0.022222'` in base 3 is like ``0.099999'` in base 10; rounding
off one digit will round the number up to ``0.1'`.) Depending on the
nature of your work, this hiding of the inexactness may be a benefit or
a danger. With the `d n` command, Calc gives you the choice.

Incidentally, another consequence of all this is that if you type
`M-30 d n` to display more digits than are "really there,"
you'll see garbage digits at the end of the number. (In decimal
display mode, with decimally-stored numbers, these garbage digits are
always zero so they vanish and you don't notice them.) Because Calc
rounds off that 0.15 digit, there is the danger that two numbers could
be slightly different internally but still look the same. If you feel
uneasy about this, set the `d n` precision to be a little higher
than normal; you'll get ugly garbage digits, but you'll always be able
to tell two distinct numbers apart.

An interesting side note is that most computers store their
floating-point numbers in binary, and convert to decimal for display.
Thus everyday programs have the same problem: Decimal 0.1 cannot be
represented exactly in binary (try it: `0.1 d 2`), so ``0.1 * 10'`
comes out as an inexact approximation to 1 on some machines (though
they generally arrange to hide it from you by rounding off one digit as
we did above). Because Calc works in decimal instead of binary, you can
be sure that numbers that look exact *are* exact as long as you stay
in decimal display mode.

It's not hard to show that any number that can be represented exactly in binary, octal, or hexadecimal is also exact in decimal, so the kinds of problems we saw in this exercise are likely to be severe only when you use a relatively unusual radix like 3.

Go to the first, previous, next, last section, table of contents.